-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 [I reordered your message in my response]
On 02/03/12 08:59, Rose, John B wrote: > I had assumed we just moved the .db file back and forth between our > desktop and Android and the simplicity is part of the "coolness" of > SQLite. Yes, Android includes a version of the SQLite library as standard and you can move the files between platforms just fine. The only minor thing to watch out for is that newer Android versions have WAL turned on by default while SQLite versions older than 3.7.0 (released mid-2010) cannot access WAL databases. The major thing to watch out for is that Android (like all mobile platforms) can and does terminate processes abruptly and routinely. Consequently there is a far higher probability that there will be a WAL or journal file lying around. If you are copying databases around then your must also copy the journal/WAL file too. See 1.3 of http://www.sqlite.org/howtocorrupt.html > Someone else in our group came across something called > "ContentProvider" If that person posted to this group earlier then the response came from me and a lot has been lost in translation. Assuming not. Android uses Java as the normal programming language so you will use a different API than the normal SQLite C API. (There is a native development kit and you can use the C api plus cross compilers, but that approach is not normal or recommended.) This is the normal Java API on Android for SQLite. It is also rarely used: http://developer.android.com/reference/android/database/sqlite/package-summary.html > Frankly we are not understanding it. It is to do with how Android applications are structured. The idea is that applications are broken into components including Activities (a full screen UI), Services (background work), Content Providers (data access) and Broadcast Receivers (cross-process event dispatch). These components are composed into the user experience and the components used can come from multiple different applications. It is trivial to add Google Maps (or Bing Maps for that matter) into your app as though it was part of the app, or a barcode reader, or contacts access, or nyan cat icons, or battery drain notification. http://developer.android.com/guide/topics/fundamentals.html ContentProvider is a way for some code to export and allow manipulation of data and it decouples the consumer of that data from how it is actually stored under the hood. The consumer can be a component within the same application or at your option other apps on the system. If you are writing a ContentProvider and do want to store the data in a SQLite database then you'll find a lot of helper classes on Android to do most of the work for you. You'll also note that some aspects of the ContentProvider API have a SQLite flavour (eg the query interface). > A step-by-step example taking a .db file created with some data on a > desktop and putting it on Android and using/adding data to it there, > then putting it back on the desktop with the new data while it was on > Android would be good to see. Android is a red herring in this and your approach is not a good one. How would you do this using two different regular computers? How would you deal with changes being made on both machines at the same time? How would you copy databases ensuring you picked up the journals? The reality is that Android devices have intermittent connectivity and you should allow the user to work with data even when the connectivity is not present. Your best practises are as follows: - - Make the data available to the app or other apps using a ContentProvider - - Your ContentProvider can store the data behind the scenes in a SQLite database - - You need to provide a way of synchronizing data (pushing and pulling changes) which requires a networked server front ending the master copy of the data The best way of doing this is to expose your data from a server using a REST API. This will then allow Android apps, web apps and anything else to work with the data. http://en.wikipedia.org/wiki/Representational_state_transfer Here is a deep tech presentation about best practises for Android REST applications. Note that a lot of the complexity is because apps can be killed at any point, the user interface comes and goes, networks are flaky and have unpredictable latency etc: http://www.youtube.com/watch?v=xHXn3Kg2IQE You don't have to use SyncAdaptors, but if you do here is some more doc and example code: http://developer.android.com/resources/samples/SampleSyncAdapter/index.html If you want to ignore all that then you can use adb push/adb pull from the Android dev kit to transfer files between a computer and an Android device. Make sure you also transfer the journals. Roger -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk9RCOYACgkQmOOfHg372QT/igCgvjniTOllolwtiwFfXXOtUc+a ovkAoIOfIRVt36PM3ms0Y2CKljVoghv/ =abD0 -----END PGP SIGNATURE----- _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
