Notes on ADOs (Activity Dependent Objects) and how they bolster activity life cycle

I am not entirely happy how objects, especially worker objects, that are dependent on an activity needs to behave and the framework that is available for them to detect the activity availability.

Yes #Android #Fragments are good. yes #AndroidFragments are helpful. May be fragments will solve all of it. Even with fragments I believe there is a case to be made for something called "Activity Dependent Objects" or ADOs in Android.

These are some notes from my thought process here. Mainly as a reminders to myself so that when it is time for me to aggregate them into a framework I would have remembered them.

As I have worked with this idea in the last few months, I think it is mildly helpful. For me it clarified the lifecycle of fragments and activities really well.

The early illustrations below are mainly my brain gibberish and they coalesce more as you scroll down. Also the key conclusions are towards the end. If "Activity Dependent Objects" intrigues you read on. 


Activity Dependent Object (ADO)
DefaultADO
  RecreatedADO
  IRetainedADO
  RetainedADO
MonitoredActivity
MonitoredActivityWithADOSupport
AsyncTaskADO

Much like fragments it is possible to stitch together a number of objects that are retained with an activity as it goes through its life changes and being aware when it is down and when it is up.

By implementing an "Activity Dependent Object" protocol (by implementing the IRetainedADO interface) these objects can become aware of their reflecting their parent activity and hence behave better.

Of course fragments behave very similar and fill that need as well. But my suspicion is that they do it only to one level deep.

I just did this as an exercise to see what it takes. For me the trigger is the onRetained... callback from the activity. I suppose I can extend it by tying it to a retained fragment

One benefit I foresee even if I were to use retained fragments is to extend the activity awareness to any level deep and have those deep object to quickly behave as if they are part of the activity

Using this approach I have implemented an asynctask that also behaves like a retained object and correctly address the problem of showing its progress on a fragment dialog and handle all test cases well.

So this works in theory. This is too early to form an opinion how useful this is.

Good or bad, you should take a step and see where it leads...it has been fun at least understanding the activity really well....

Usually a worker object that wants to encapsulate both work and its UI may need only to know when the activity and fragments are fully populated and their state restored.

However there is a catch that might force us to take a look and respond to the onCreate() of the activity.

Usually you want to rely on the activity and fragment to restore the states of the views. To get this right you may need to initialize the UI properly by the end of the onCreate() of the activity. Otherwise restoring state may not work depending on what happened in onCreate. For example whether a view is GONE or visible when it started. Or the initial expected state of a progress bar!

  1. Don't hold on to an activity object, but instead get it from someone that holds it and knows how to work with it: such as a fragment
  2. If you are holding an activity object, a weak reference won't do you much good as you need to know much earlier before the object actually goes away or just hidden. So you will need to know the explicit case when you should set that pointer to null.
  3. You should know the states of activity clearly and explicitly set the activity to null to release it

I haven't flushed out, or refactored, the IActivityDependentObject so that it works well for both Activity and a Fragment but it is quite easily doable...

You can see the complete source code and implementation of ADOs here