I need to retain a complex object in my service, so I can reliably come back to it (it holds updates). Initially I coded it just as a class filed in my Service implementation but I'm observing that the updates object is periodically reset to null which tells me that server class itself is recreated. Can someone recommend lightweight reliable strategy to save and recreate such updates object (I can make it serializable)
+2
A:
When your service is restarted, the onStop() and onStart() methods are called. You can use the onStop() method to save your data to a persistent location, e.g. an application sqlite database. You can restore the data when onStart() is called.
You can read about using an sqlite database on the android developer website: http://developer.android.com
Scharrels
2009-08-06 16:24:29
I think the problem is not with onStop and onStart but with fact that to serve these methods Android may create a new instance of the class. I really don't want to go sqlite db route since that would be another expense in already expensive processing. I'm looking into serialization/deserialization for lighter alternative
DroidIn.net
2009-08-06 16:57:39
After onStop() is called, your service instance will be killed. That's why the method is called: one way or another, you need to save your data here. If you don't want to use a database, you can save a file using Context.openFileOutput(). You can read it later on (e.g. when onStart() is called) using Context.openFileInput()
Scharrels
2009-08-06 21:09:51
So following this route: if I have a String filed in my Service class then it seem more efficient to read/write that on onStart/onStop and otherwise use it as a class field rather than read/write it to the SharedProperties each time the variable is needed
DroidIn.net
2009-08-07 03:11:21
+1
A:
If I was doing it, I would use SharedPreferences. If it's too complex for that, I agree with @Scharrels about using a sqlite DB (which would, most likely, be the Google recommendation since their examples use sqlite in the smallest of cases, which implies it has a reasonable level of performance).
I've found SharedPreferences to be useful in a number of cases. First, being a key-value pairing store, a variety of different data can easily be stored, plus you could encode your objects into a string, if need be, and store them in a single field. Second, you can use multiple SharedPreference stores by simply retrieving ones under a different name (while still keeping them private). Finally, I find them easy to use since getting data and storing data is literally only a couple of lines of code (not counting any data munging or serialization you might need).
lilbyrdie
2009-08-06 22:26:30
Bear in mind that SharedPreferences are stored in an XML file and, therefore, are not transactionally guaranteed.
CommonsWare
2009-08-06 22:46:45
Sure. And, depending on the real complexity of the objects that need to be persisted, may be less efficient than a small sqlite db. Coding-wise, though, would be very fast to get something in place for persistence, compared to the existing solution of nothing. On the plus side, persistence within onDestroy() will finish, as that is allowed to finish before the process can be killed.
lilbyrdie
2009-08-07 00:37:01
Mark. To be compeltely hones what I'm trying to persist is instance of HtmlClient and possibly some derived objects. THese are fairly complex and may not be serializable. Why? For example, HttpClient gets initialized with some numbers of cookies that I need to retain to succesfully proceeed with session that is created for me on some application server out there. What do I do?
DroidIn.net
2009-08-07 03:02:56