I am working on providing a data store on Android (one that does not use SQLite), starting with a single-app desktop version of our Java Library. The ideal solution will be:
- executed in its own process, providing access to other applications by some form of IPC
- persistent, and therefore the application using it will not lose data upon phone shutdown
- reasonably responsive
Using my client-server architecture background, my initial attempt was to use a Service
, with whi开发者_运维问答ch the other applications can communicate using bindService
and other calls. The resulting had quality #1 (and #3 to some extent) above, but it was not clear to me as to when to write all this data back to the filesystem, especially since it turns out that the onDestroy()
method is not guaranteed to be called, especially during machine shutdown. Using Alarms to periodically save data is not a good solution either, since it might lead to uncommitted changes when the process is killed.
Now, I am thinking of using a ContentProvider
, which I believe is also the philosophically best way. However problem #2 still remains: how can I guarantee that uncommitted changes are not remaining when the system shuts down, while not sacrificing on performance by using naive techniques such as writing to filesystem on each operation? I wonder how the native SQLite implementation achieves it?
Please suggest the proper way to go about doing this. This should not be as hard as I am finding it to be :).
Thanks.
精彩评论