The last time I wrote Android apps was years ago, starting with the ADP1 and Android 1.0. Back then, the big deal was the Activity lifecycle. Mind the life cycle events! To reclaim memory, Android may kill your app or your activities at any time, they said. Being economical with resources was the big concern. There was even an onMemoryLow event you could implement to help the system manage memory.

At the very beginning, there wasn’t even AsyncTask, never mind retained Fragments.

I was always trying my damnedest to fit everything properly into the activity lifecycle. Like rotating my Async tasks along with with the activity. And it was always such a pain. I never quite understood why it had to be such a pain, and I guess in my subconsciousness I always realized I was not understanding something. I was never sure how global state fit into the whole concept, and was uncomfortable using it. I only saw the activity lifecycle. As in, how can there be background thread dangling around outside of an onCreate/onDestroy cycle?

Coming back to Android now, and seeing people use neat things like event buses finally caused be to think it through, and I believe I had a personal epiphany.

Android is killing your process, but the documentation claims even today that Android may destroy activities to save memory (“the system might destroy that activity completely if it needs to recover system memory”). Is Android “killing” your Java objects? How would it even do that? Is the Android SDK in your process doing some kind of object management when instructed by the system? The idea seems strange, and apparently it isn’t really the case.

The trick for me was to forget about the Activity lifecycle as being memory-related. I think of it now as an implementation detail of the UI framework you are using, possible helpful in terms of resetting state, and both useful and cumbersome in terms of configuration/layout loading.

I had to stop thinking of my app as merely a bunch of Android primitives (activities, services, broadcast receivers) into which I have to fit everything. While these primitives admittedly are actual concepts within Android itself, the specific implementation, including the lifecycle stuff, is technically up to your process.

Instead, if I consider my app a holistic, proper process, simply running on a device where it may be regularly killed, then I’m no longer afraid of using global state, background threads, an event bus, or anything else outside of the framework primitives. I just have to remember: The app may be killed once in the background, so for important things, tell the system you are doing service-stuff right now.

Here are some resources I found helpful:

A Recipe for writing responsive REST clients on Android – How to write a modern Android app.

AsyncTask is bad and you should feel bad – Using AsyncTask outside of activities. Why not just use a thread? The AsyncTask will return in the main thread, and cannot return between in-between a configuration change. Still, a sticky event in EventBus, or a producer in otto might make more sense.

Android Priority Job Queue – If you have a lot of background jobs.

Other things I realized: It is time to upgrade to a 100 character right margin. And the right way to use a SQLite database.