View Lifecycle

[blundell]

any chance? onFinishInflate onDraw onSaveInstanceState etc

[blundell]

This guy http://ndquangr.blogspot.co.uk/2013/04/android-view-lifecycle.html

[blundell]

But note from the discussion here https://plus.google.com/+ArpitMathur/posts/cT1EuBbxEgN :

That's interesting, but it's also not entirely accurate. Views have a lot less of a formal lifecycle than activities or fragments do. Activities and fragments are more or less the C in MVC and are what provide an idea of what most developers consider lifecycle in the first place. This diagram projects an idea of android.app component-style lifecycle onto a slightly different process.

What's diagrammed here mostly is the flow of what's called a "traversal" by the UI toolkit. It happens at the ViewRoot, and in Jellybean and above it specifically happens on vsync with the display. A requestLayout() or invalidate() anywhere in the active view hierarchy will schedule a traversal, and the layout part might be skipped if it's not required. One guarantee about traversals is that a pending layout request will always happen before a pending drawing request. (There are a few ways to break this guarantee when writing custom views and Bad Things(TM) happen.)

The measure() and layout() methods are what dispatch the onMeasure() and onLayout() calls in the first place - the former pair shouldn't be overridden by apps as they perform a bunch of internal required bookkeeping that apps are unable to replicate. There are also some internal optimizations that will skip calls to onMeasure() or onLayout() if the underlying conditions would produce the same results.

The thing about measurement and layout is that there's no guarantee or requirement that a view be attached to a window when it happens. ListView in particular performs measurement of item views before attaching them, and it's often quite useful to perform this sort of speculative measurement of detached views when calculating things like the ideal size of something. Sometimes apps even do things like using a detached view's draw() method to software render into a Bitmap Canvas for use elsewhere. (Depending on the view this may or may not be a safe thing to do.)

If you assume that a view will always receive a call to onAttachedToWindow() before it's ever measured you're probably in for a nasty surprise down the road. It's best to assume as little as possible about when various View methods will be called, but there are a few things you can count on.

It stands to reason that a View won't be able to draw itself until it's been through measurement and layout, otherwise it would have no idea what to draw. Similarly a view isn't going to be able to do much with touch events without measurement and layout since the coordinates within the MotionEvent will have no relative meaning to the view yet.

Beyond that, onAttachedToWindow() and onDetachedFromWindow() are the only real elements of "lifecycle" present on views. onAttached is when you need to begin monitoring info about whatever the view is presenting, (e.g. this is when a ListView starts listening for adapter changed events,) and onDetached is when you need to clean up, e.g. remove any Runnables the view may have posted for later that are no longer relevant.

If you start wanting more sophisticated lifecycle events than this in your views it's likely that you're writing a view that is getting too smart for its own good. Factor some of that logic out into a fragment or something instead.

Need some way to explain this in a diagram

[xxv]

@blundell at least for the purpose of the Activity/Fragment lifecycle diagram, I won't be adding a View lifecycle.

In terms of a second diagram, unfortunately there's not enough of a lifecycle to really do for a View, as discussed in your comment.