SQLite with Android NDK - c++

Is it somehow possible to use SQLite with C++ on an Android phone? I haven't found any documentation around how this could be possible.

Just download the SQLite3 amalgamation source file from:
http://www.sqlite.org/download.html
And then add sqlite3.c to your LOCAL_SRC_FILES variable in Android.mk.

It isn't possible to use the built-in SQLite via NDK (or it wasn't six months ago when I looked into this), that can only be accessed with Java. However it may be possible to link in your own completely separate C++ build of SQLite.

See SQLite Android Bindings http://www.sqlite.org/android/doc/trunk/www/index.wiki which describes how to include sqlite3 for Android targets 15 (4.0.3) and greater. It's copied below.
SQLite Android Bindings
The SQLite library is a core part of the Android environment. Java
applications and content providers access SQLite using the interface
in the android.database.sqlite namespace.
One disadvantage of using Android's built-in SQLite support is that
the application is forced to use the version of SQLite that the
current version of Android happened to ship with. If your application
happens to require a newer version of SQLite, or a build with a custom
extension or VFS installed, you're out of luck.
The code in this project allows an application to use the Android NDK
to build a custom version of SQLite to be shipped with the application
while still continuing to use the standard Java interface.
Normal Usage
Installation
Android API levels 15 (Android 4.0.3) and greater are supported. If
targetting API level 16 or greater, use the default "trunk" branch of
this project. Or, for API level 15, use the "api-level-15" branch. It
is not possible to target an API level lower than 15.
Copy the following files from this project into the equivalent
locations in the application project.
jni/Android.mk
jni/Application.mk
jni/sqlite/* (copy contents of directory recursively)
src/org/sqlite/database/* (copy contents of directory recursively)
Following this, the directory structures should contain
these files.
For API level 15 only, also copy the following:
src/org/sqlite/os/* (copy contents of directory recursively)
Directory "jni/sqlite/" contains copies of the sqlite3.h
and sqlite3.c source files. Between them, they contain the source code
for the SQLite library. If necessary, replace these with the source
for the specific version of SQLite required. If SQLite is to be
compiled with any special pre-processor macros defined, add them to
the "jni/sqlite/Android.mk" file (not jni/Android.mk).
Once the files have been added to the project, run the command
"ndk-build" in the root directory of the project. This compiles the
native code in the jni/ directory (including the custom SQLite
version) to shared libraries that will be deployed to the device along
with the application. Assuming it is successful, unless you modify the
sources or makefiles within the jni/ directory structure, you should
not need to run "ndk-build" again.
Application Programming
The classes that make up the built-in Android SQLite interface reside
in the "android.database.sqlite" namespace. This interface provides
all of the same classes, except within the
"org.sqlite.database.sqlite" namespace. This means that to modify an
application to use the custom version of SQLite, all that is usually
required is to replace all occurrences "android.database.sqlite"
within the source code with "org.sqlite.database.sqlite".
For example,the following:
import android.database.sqlite.SQLiteDatabase;
should be replaced with:
import org.sqlite.database.sqlite.SQLiteDatabase;
As well as replacing all uses of the classes in the android.database.sqlite.*
namespace, the application must also be sure to use the following two:
org.sqlite.database.SQLException
org.sqlite.database.DatabaseErrorHandler
instead of:
android.database.SQLException
android.database.DatabaseErrorHandler
Aside from namespace changes,
there are other differences from the stock Android interface that
applications need to be aware of:
The SQLiteStatement.simpleQueryForBlobFileDescriptor() API is not
available.
The collation sequence "UNICODE" is not available.
The collation sequence "LOCALIZED", which normally changes with the
system's current locale, is always equivalent to SQLite's built in
collation BINARY.

Disclaimer: i have only used this method for standalone executables, not libraries that implement JNI functions. It may work for a .so or not. Also, i'm working with a custom Android device not a phone.
You can use the built in SQLite via NDK but it's more of a hack than something supported. You need to nick sqlite3.h and libsqlite.so from an android source distribution and compile using them. Put sqlite3.h in your application source directory and you need to put the .so somewhere under the out/yourapp directory or build/platform/android-x/arch-arm/usr/lib for the linking step to finish. I have it in both places but i'm not sure which one is really needed.
You will end up linking to the libsqlite.so you provided but the binary will run fine using the system libsqlite.so on a target device.

Related

Is it possible to edit the hardcoded path in a Windows (custom built) installation of Qt 5?

We are building Qt 5.10 internally, and installing it to a given prefix on the build environments.
We would like to be able to relocate the installation (notably, but not only for, distribution). We are aware of qt.conf, as pointed out by this answer.
Yet, is there a maintained way to directly edit the values of those hardcoded paths in the installed files?
EDIT:
More rationale behind why we thing qt.conf is inferior to directly patching the binaries.
On development machines, it means that instead of simply patching the installed binaries once, we have to provide a configuration file in each folder containing an application depending on Qt.
Even worse than that, we discovered through failures (and the help of this post) that qtwebengineprocess.exe, in qtprefix/bin, expects its own qt.conf file, otherwise it will use the paths hardcoded in the libraries. This means that we have to touch the the library folder anyway, in otder to edit the configuration file to make it match the folder location on each development machine.

Qt Application : How to create standalone executable file for Windows (& Mac) from Mac?

I developed a Qt application in MacBook (El-Capitan 10.11.2) and it is ready now to be released.
What i want now, is to create the standalone executable file for both Mac and Windows OS.
But I don't know how !
I found this link but I am unable to follow it is guidance, it looks different from what my system is showing me.
If you have any idea, please help me.
Thank you
Well, to compile an application for windows, you will need a windows machine (or at least a virtual machine). You can't compile for windows on mac.
Regarding the "standalone": The easy way is to deploy your application together with all the required dlls/frameworks and ship them as one "package". To to this, there are the tools windeployqt and macdeployqt. However, those will not be "single file" applications, but rather a collection of files.
If you want to have one single file, you will have to build Qt statically! You can to this, but you will have to do it on your own. And if you do, please notice that the LGPL-license (the one for the free version of Qt) requires you to make the source-code of your program public! That's not the case if you just link to the dynamic libraries.
EDIT:
Deployment
Deployment can be really hard, because you have to do it differently for each platform. Most times you will have 3 steps
Dependency resolving: In this step, you collect all the exectuables/lirabries/translations/... your application requires and collect them somewhere they can find each other. For windows and mac, this can be done using the tools I mentioned above.
Installation: Here you will have to create some kind of "installer". The easiest way is to create a zip-file that contains everyhing you need. But if you want to have a "nice" installation, you will have to create proper "installers" for each platform. (One of many possibilities is the Qt Installer Framework. Best thing about it: It's cross platform.)
Distribution: Distribution is how to get your program to the user. On Mac, you will have the App-Store, for windows you don't. Best way is to provide the download on a website created for this (like sourceforge, github, ...)
I can help you with the first step, but for the second step you will have to research the possibilities and decide for a way to do it.
Dependencies
Resolving the dependencies can be done by either building Qt statically (this way you will have only one single file, but gain additional work because you will have to compile Qt) or using the dynamic build. For the dynamic build, Qt will help you to resolve the dependencies:
macdeployqt is rather easy to use. Compile your app in release mode and call <qt_install_dir>/bin/macdeployqt <path_to_your_bundle>/<bundle>.app. After thats done, all Qt libraries are stored inside the <bundle>.app folder.
For windeployqt is basically the same: <qt_install_dir>\bin\windeployqt --release <path_to_your_build>\<application>.exe. All dependencies will be inside the build folder. (Hint: copy the <application>.exe in an empty directoy and run windeployqt on that path instead. This way you get rid of all the build-files).
Regarding the static build: Just google it, you will find hundreds of explanations for any platform. But unless you have no other choice but to use one single file (for whatever reason) it would recommend you to use dynamic builds. And regarding the user experience: On mac, they won't notice a difference, since in both cases everything will be hidden inside the app bundle. On windows, it's normal to have multiple files, so no one will bother. (And if you create an installer for windows, just make sure to add a desktop shortcut. This way the user will to have "a single file" to click.)

How to build and install google-url as a shared library on Mac OS/Linux

I want to use google-url in my project as a shared library on Linux\Mac OS, but can not figure out the right way to build it...
Question: what is the way you suggest to build it from scratch form official sources?
Requirements - be able to stay in sync with official repo and use standard(make) tools.
As far as i can see, right now there are few ways to build it:
in the official repo itself only Visual Studio 2005 build files are included
it is in use at Chromium and so there is .gyp available for it but looks like it is tight integrated with Chromium build structure, so there is no easy way to generate Makefile for the standalone library build.
Although it has a comment inside "TODO(mark): Upstream this file to googleurl."
So at list this considered to be possible.
Googleurl is also integrated with PageSpeed project in .gyp form (thought no the same one as above) and so it is somehow built there
third-party bindings for python are available and also contain some build instructions, but with SCons this time, and AFAIK it is kind of obsolete system to rely on.
Looks like i'm not the only one with this trouble, so other people i found both just implemented their own build files using autotools:
https://github.com/artemg/Googleurl-separate-library
https://github.com/commoncrawl/commoncrawl-crawler/blob/master/src/native/src/libGoogleURL/googleurl/README.google
It could work but the filesystem layout is not the same as in official repo/they have local modification so there are no easy way to downstream changes and stay in sync.
The most tempting way would be to use GYP to generate platform-specific build files for the oficial repo once: make/xcode/visual studio, then just save and use them later as needed..but i have no idea how to approach this and where to start from.

wxSqlLite3 in wxWidgets

I have a question how can I use wxSqlLite in my wxWidgets applications? I downloaded wxSqlite3 for wxWidgets 2.9x and build it but only static win32 debug win32 and static win32 release win32 compiled without errors. How can I add wxSqllite to my project? My ide is visual c++ 2008.
You don't NEED to use wxSQLite. You can simply call the SQLite API directly from your code. It takes an hour or two to get familiar with the API, but then it does everything you need without worrying about linking your build to yet another package.
The SQLite API is a library. There are several ways you can 'install' it. I have noticed that the SQLite site is a bit vague on this question. Here is what I do.
Download the zip containing the prebuilt DLL from http://sqlite.org/sqlite-dll-win32-x86-3071000.zip
This will give you the DLL, which should go in the folder where your executable runs.
This will also give the the export deefinition file ( .def ). This has to be converted to a .lib file so that it can be linked to. You do this using the lib utility.
You also need the sqlite3.h header file, which is included in the amalgamation downloaded from http://sqlite.org/sqlite-amalgamation-3071000.zip
If all this seems like a lot of trouble, you can alternatively use the amalgamation. Simply download the amalgamation and add the two files to your project. The downside with this is that you will have to build the SQLite code over and over again,slowing your build process, and the entire code will be statically linked to every executable. Nowadays builds run on modern computers so quickly that the cost of using the amalgamation is well worth the gain in simplicity. These days, I never use the DLL.
Of course one could use the SQLite API directly as ravenspoint pointed out, but wxSQLite3 makes it easier to integrate SQLite databases with wxWidgets-based C++ applications. The wxSQLite3 API is similar to JDBC and ODBC. wxSQLite3 takes care of converting wxString objects to and from UTF-8, one of the 2 encodings (UTF-8 or UTF-16) expected by SQLite; wxSQLite3 supports creating user defined functions as C++ classes; and adds several other features like backup and restore of databases, value collections, support for different date and time value representations and so on. wxSQLite3 can load the SQLite DLL at runtime without requiring a link library if you prefer, it's just setting a compile time flag.
Adding wxSQLite3 to a project is simple: either create a DLL or static library using the build files (including VC++ 2008 solution) coming with wxSQLite3, or just add the single C++ source file and few header files to your own project.
In case of difficulties ask your questions on the wxWidgets developer forum.

Are there Windows API binaries for Subversion or do I have to build SVN to call the API from Windows C++?

I want to call a Subversion API from a Visual Studio 2003 C++ project.
I know there are threads here, here, here, and here that tell how to get started with C#.NET on Windows (the consensus seems to be SharpSvn, which I've used easily and successfully on another project) but that's not what I want.
I've read the chapter on using APIs in the red-bean book which says:
Subversion is primarily a set of C libraries, with header (.h) files that live in the subversion/include directory of the source tree. These headers are copied into your system locations (e.g., /usr/local/include) when you build and install Subversion itself from source. These headers represent the entirety of the functions and types meant to be accessible by users of the Subversion libraries.
I'd like to use CollabNet Subversion but there doesn't seem to be API binary downloads, and I'd just as soon not build the whole thing if I can avoid it.
Considering another approach, I found RapidSVN's C++ API, but it doesn't appear to offer Windows API binaries either and seems to require building SVN (which I would be willing to do as a last choice if RapidSVN's API is higher-level than the stock SVN offering.)
Does calling the API from C++ in Windows have to be this much more work compared to using SharpSvn under .NET, or is there something I haven't found that would help me achieve my goal?
You need the dev (e.g. svn-win32-1.6.16_dev.zip) package from here. Probably download also the binaries (e.g. svn-win32-1.6.16.zip) of the tools (DLLs are there).