1

While there are countless resources on Application, Activity etc lifecycle seen from an API perspective (onCreate/Destroy/Whatnot() methods) there is scarcely any information on the actual object's lifecycle for these components from the Java perspective. So for instance I saw (on a YouTube marakana video) that services are basically singletons - and this left me wondering on the state of an IntentService - can it be shared ? Or is this a singleton too ?

I guess initially a process is created (by Zygote ?), along with a DalvikVM instance and then the classes for all components that are declared in the manifest are loaded (?) and then instantiated as needed - but these are guesses. I can't at all answer questions like :

  • are BroadcastReceivers instantiated only once or once each time a broadcast is received ?
  • is Application a singleton ? Guaranteed ?
  • is MyApplication.class loaded before all other components ? Instantiated always ? Even when only a manifest registered BR of mine runs ?
  • when is a particular Application.class of mine (likely to be) unloaded (so I should check if its static fields need initialization (in the case caller initializes them))

You see I am in the dark here. I would like some analysis of the class loading, instantiation and garbage collection of basic android application components - links to docs and/or source welcome. The more technical the better.

Refs : this post by @inazaruk.
Also Static references are cleared--does Android unload classes at runtime if unused?

Community
  • 1
  • 1
Mr_and_Mrs_D
  • 32,208
  • 39
  • 178
  • 361
  • One part of the answer: http://stackoverflow.com/questions/18840093/is-it-still-the-case-that-android-never-unloads-classes/18929394#18929394 – fadden Oct 15 '13 at 16:34
  • @fadden: oh thanks :) Will go through this. If you find some time to give a detailed answer (here or elsewhere) you will fill a quite annoying gap). One point that leads to much much much confusion is the handling of static (class) fields by android - there's a rumor floating that they are reset - for instance : [the static variables instances are bound to the class loader of the class that first initialized them](http://www.devahead.com/blog/2011/06/extending-the-android-application-class-and-dealing-with-singleton/) - which is quoted as a fact here in SO – Mr_and_Mrs_D Oct 15 '13 at 16:43
  • Static fields don't get any special treatment in Android. There is no reset mechanism. The only way they get reset is if the app is killed and restarted, which can happen at appropriate points in the app lifecycle. (This often surprises people -- the app gets restarted in a "deep" activity, and the code doesn't expect all the static fields to be NULL.) – fadden Oct 15 '13 at 18:27
  • @fadden: I guessed so - but this notion of not being able to trust static fields lingers. People think they apparently do initialize them :http://stackoverflow.com/questions/5105097/static-references-are-cleared-does-android-unload-classes-at-runtime-if-unused. Anyway - the questions in my question more or less are still unanswered - especially the ones concerning the Application instance. Thanks for input :) – Mr_and_Mrs_D Oct 15 '13 at 18:55
  • @fadden but in case the reset occurs, wouldn't it mean that the whole app will be restarted, meaning that if the user has left it on activity2 and caused it to reset, it will start on the lancher-activity instead, and also call the onCreate of the application class ? – android developer Nov 09 '13 at 11:19

0 Answers0