Thanks for the very thorough reply. > 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? >
In this particular example, a particular researcher would be creating the initial version of the database on their own computer, but once they got out in the field they may update the copy they have on their mobile device and take that copy back to replace the original on their desktop. Thanks On 3/2/12 12:52 PM, "Roger Binns" <rog...@rogerbinns.com> wrote: > -----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 > _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
