Replace android default sqlite build - java

I would like to replace android default sqlite build for a new one having rtree feature enabled. It looks like I have to use a java wrapper to accomplish that and the only one I found android compatible was sqlite4java. I prefer sticking with standards. Unfortunately I found out jdbc is not supported in dalvikvm (Androids VM) and native android.database.sqlite works with an rtree disabled build of sqlite.
Currently I have a new .so sqlite rtree enabled library compiled for android but would like to substitute androids native one without having to use a third party wrapper like sqlite4java. Any ideas? I was thinking about downloading android.database.sqlite package from android sdk and building a jar to substitute only the .so load withing my application context. Is that the best approach?

I was thinking about downloading android.database.sqlite package from android sdk and building a jar to substitute only the .so load withing my application context. Is that the best approach?
So long as you are willing to refactor all necessary classes into your own package, that is probably your only approach. For example, that is what SQLCipher for Android does. They cloned ~37 classes from android.database and android.database.sqlite and modified them to use their own SQLCipher-enabled build of SQLite.

Related

Whether it Library org.garret.prest?

I discovered this when decompiler an application, no one knows what it's kind of a Library? I found it in an Android app, because I want to look to try the library
It's a database library called Perst.

Android How do I use the same native library (.so) for multiple projects and classes?

I am making a android project with some native code . running javah results in header files which contain function prototypes with fully qualified java class name in their names. I assume this means that those functions and headers are generated to be called only by the java class which was used to create them using javah.
How do I go on making a native lib that I can use with other classes as well as other projects. Like say I made a library that has a function that I want to use in all my projects then how would I build it so that I can use just the .so file each time without recompiling it for the project. I think we call this dynamic library?
Is it possible? or do I have to create seperate jni headers for each class and then reuse the remaining c/c++ code?
if you want to reuse your native library from various Java projects, you should directly bundle your native library with a Java class that is independent from your initial project.
This way you'll be able to distribute it as an Android Library Project, and use it from your various classes and projects.

How do I use MUpdf in an existing java project

Mupdf documentation shows me how to use the library as an application and deploy it. However, I want to suck it into an existing java project and build my application on top of it. Can this be done? If so, how do I bring just the pieces needed, into my project?
Take a look at jMuPdf. I never used it, but it seems to be active.
Otherwise you will need to create Java Native Bindings (JNA or JNI).

How can I use Android with Java and a core made with Scala?

I made a small project using Scala (SBT + IntellijIDEA) that provides me a set of classes and other functions that I want to use in Android. I will call this project $core.
So, keeping that in mind I tried to first only use scala. I tried to create an Android Project using android-plugin and I got it.
But what I really want is to use my $core in an Android Project AND expand the $core classes using Java. $core provides an API that I would like more people to use and they probably don't know Scala so Java would be perfect. Besides, I need to go into a safe route with Android. I saw some info that scala takes a lot of time to compile into Android and has some limitations (like with parceblles).
I already tried to use the classes in eclipse with the import class folder option. I even tried to generate a jar so at least I would have a way to run it and no success. Always the NoClassDef error when I try to use one class from the $core. I have tried to import also the scala compiler library, but didn't work out aswell...
Core isn't finished yet and I would like to develop on a single environment that allowed me to debug on the android device. How can I setup all of this?
PS: Changing to eclipse now maybe is better? Never tried android on intellijIDEA and In scala I can't debug over there, at least using ScalaCheck...
Is it possible that you are getting an noclassdeffound error when working with Scala code from java because you didn't add the Scala library to the java project or at least included the party of it that it's used in the Scala code in the jar?
Could you post the rest of the error?
You could package the core to .jar together with Scala library, use Proguard to remove all unused Scala library classes from it, and then use that jar as a regular library.

Google App Engine "repackaged" package

What is the purpose of the classes in this package?
I want to use Base64 encoding in my app. As I'm typing away in Eclipse, I am prompted if I want to import a class called "com.google.appengine.repackaged.com.google.common.util.Base64"
I can't find any documentation about what this class does. No javadoc, or no mention in the Google App Engine manual (that I can see). Is this some kind of "hidden" API that I'm not supposed to have access to?
Is this some kind of "hidden" API that I'm not supposed to have access to?
Yes.
The purpose of repackaging Java classes is to have a private copy of a library that otherwise might conflict with another version of that some library (that the application developer adds to his project as a jar file).
It is one possible answer to JAR-hell.
Even the JDK makes use of this mechanism, e.g. with com.sun.org.apache.xerces which is an XML parsing library developed by the Apache Project that Sun choose to include (repackaged).
Do not call these classes directly. (You could, and they would probably work okay, but as they are not part of the official API, they could disappear in the next version).

Categories