Office Hours — Today, August 14

← Thursday, August 10

Mark M.
has entered the room
Mark M.
turned on guest access
Steve S.
has entered the room
Mark M.
hello, Steve!
how can I help you today?
Steve S.
Hi, Mark!
Let me paste my question:
View paste 
I am working on a strategy to save and restore the state of a complex user interface of an activity. I am wondering about using the following strategy:
1. In onStop(), send a representation of the UI state to an IntentService.
2. The IntentService persists the state representation and also puts it in a singleton cache.
3. In onStart(), the activity attempts to retrieve the state representation from the cache. If the cache is empty, it sends a request to the IntentService to retrieve the persisted state representation and put it in the cache.

Is this reasonable?
Mark M.
a service seems like overkill, unless you think that it'll take 1+ seconds to persist the data
Steve S.
ok
Mark M.
(and similarly on the return path, loading it in)
Steve S.
ok
Mark M.
otherwise, this seems OK
I mean, I am assuming that this is some unusual activity
Steve S.
Would the need for the service depend on whether I use SharedPreferences or a database?
Aug 14
7:30 PM
Mark M.
probably not
7:30 PM
Steve S.
So I could write to a database from the UI thread?
Mark M.
no, you would need a background thread
but not all background threads are managed by services
Steve S.
ok
what would be a better way to do that?
Mark M.
um, a regular thread
or, get into reactive stuff and use something in the RxJava realm
Steve S.
i see. so just spawn a thread rather than use a service?
Mark M.
right
a service is specifically needed when you're doing work when you might not be in the foreground from a UI standpoint, and so you're worried that your process will be terminated before the work is done
Steve S.
ok. i think i understand the basic idea. but are there any examples you could point me to?
Mark M.
examples of... what?
Steve S.
ok
writing to a database using a spawned thread
Mark M.
the EmPubLite tutorials use a plain thread for saving notes to the database
Steve S.
perfect. i'll check that out
Mark M.
pretty much all of my book examples that use databases use plain threads or AsyncTask
Steve S.
i see
so i should still use a cache, i take it?
Mark M.
well, I'm not quite certain what "the UI state" is
usually, we aren't persisting "UI state", but rather model data
I am assuming that you have some crazy-strange activity where there is UI state that the user cares about enough to persist
Steve S.
this is a complex UI with a lot of views, so it is a bit involved
7:35 PM
Steve S.
exactly!
Mark M.
personally, I would tend to consider that to be part of my model data
Steve S.
ok
Mark M.
regardless, you would treat it more or less as if were part of your model data
Steve S.
ok
Mark M.
and so caching -- assuming that you watch for memory leaks -- is fine
Steve S.
ok
a couple of questions about this strategy:
i saw a google developer blog that mentioned that the only surefire way not to miss any UI changes would be to persist them as they are made rather than waiting until onStop(). what could I miss if i wait to persist until onStop()?
Mark M.
I don't quite know the context of all of this
so I cannot really comment
Steve S.
ok. it may have been referring to cases like a batter running down
*battery
Mark M.
that epitomizes the phrase "edge case"
if you're worried about that, then yes, saving as you go may be a good idea
Steve S.
so it sounds like there wouldn't be a lot of cases...
7:40 PM
Mark M.
basically, the difference between "as you go" and "in onStop()" is whether your process goes away before onStop()
crashing would be the most likely cause of this, for some bug in your code
Steve S.
i see
so if everything is working properly, it would be unlikely to end the activity without calling onStop
Mark M.
if we assume bug-free code (the way physics teachers assume frictionless pool tables), then the only ways your process will go away before onStop() are pretty esoteric
Steve S.
ok
Mark M.
battery running dead, multi-window and the user revoking a runtime permission, and I can't think of anything else off the top of my head
Steve S.
another question: as things stand, i would be writing to the database after every rotation. would it be better to avoid that by using e.g. a model fragment?
Mark M.
well, I can't really answer that too well either
with model data, we update when we get clear confirmation that it is time to update
such as the user clicking the "save" button
onStop() sometimes is used for that, particularly if you don't want a positive user action (e.g., BACK implies saving)
but you are correct, you will wind up saving on configuration changes
Steve S.
i'm just wondering if the cost in terms of performance is too severe to be writing to the database on every configuration change - i have no idea
Mark M.
well, configuration changes are fairly uncommon events and usually only happen one at a time
Steve S.
ok
Mark M.
unless they put their phone in the dryer, in which case they have bigger problems
Steve S.
that's an edge case i hadn't thought of
7:45 PM
Mark M.
don't test using your "daily driver" phone
and if saving your data is a performance problem, that needs to be addressed in general
Steve S.
ok
Mark M.
configuration changes would not somehow make fast-saving code slow
Steve S.
great. very helpful
Mark M.
by the end of the year, I hope to get more into this sort of stuff, in the context of the "Android's Application Components" book
Steve S.
wonderful! i look forward to that
i'm also wondering if you have any suggestions on how to store some pretty messy data in the database. would gson be something to consider?
Mark M.
if you don't need to query on it, or sort by it, or do any other SQL operations on it (beyond straight CRUD), that works
Steve S.
ok
no more questions today. very helpful as always! i'll look at the EmPubLite example you mentioned
thank you, mark, and have a good rest of the day!
Mark M.
you too!
8:00 PM
Steve S.
has left the room
8:25 PM
Mark M.
turned off guest access

← Thursday, August 10

 

Office Hours

People in this transcript

  • Mark Murphy
  • Steve S