Amazing. Moar?

[rjrjr]

Have you tried at all to connect the two graphs? The real excitement is when you try to understand how a Fragment's lifecycle interweaves with its Activity's.

[xxv]

They actually do interconnect, but clearly in a way that's a bit too subtle for a number of folks (you're not the first to suggest this). They line up temporally in the vertical axis (which is why there are big gaps between some callbacks). Any thoughts on what kind of subtle hint(s) would have helped you better see the relationship between the two?

[madisp]

It would be awesome if there would be any indication of atomicity regarding the mainlooper - e.g. show when two callbacks are guaranteed to come from a single message in the mainloop?

[xxv]

@madisp are there any guarantees about that? I don't recall seeing any in the documentation.

While I'd say it may be good to dig through the source and see which ones come from that same message, Android proper doesn't state that there are any guarantees about that, which means you can't rely on it across Android versions. I did try to indicate which of the fragment callbacks were called from the a given callback's super by having them overlap a little vertically, but even that isn't guaranteed.

[madisp]

I know there's a guarantee of activity's onDestroy and onCreate callbacks being in a single message if a config change occurred, but I'm not sure if its been documented. See answer in this stackoverflow thread by hackbod:

(And when a config changes, the previous activity's onDestroy() is called and the next one's
onCreate() run without any messages on the main loop processed between them so the
AsyncTask will never see an inconsistent state.)

This is pretty much the only way one can do callbacks from async stuff in Android sanely.

[xxv]

Interesting. Though to be more precise: she doesn't say that they occur in a single message, but rather that there are no messages on the main loop processed between them.

Personally, I prefer to use Loaders or Fragments to manage background threads and retain state across activity configuration changes. They both have slightly more sane retention systems than what you're provided with just straight AsyncTasks.