Investigate integration with Android's own ActivityLifeCycleCallback mechanism

[mttkay]

Since we're now minSdkLevel 14, we should spend some time investigating if there's an opportunity to get rid of the forced inheritance from LightCycle base Activities. These only exist to forward life-cycle callbacks.

Android already has a mechanism for this, added in ICS:
http://developer.android.com/reference/android/app/Application.ActivityLifecycleCallbacks.html
http://developer.android.com/reference/android/app/Application.html#registerActivityLifecycleCallbacks(android.app.Application.ActivityLifecycleCallbacks)

However, no such thing exists for fragments to the best of my knowledge.

[glung]

Oh it was introduced with ICS ! I thought it was later. It is a very fair
point. Especially that we ate mentioning those callbacks in the README as
being similar.
On May 22, 2015 4:04 AM, "Matthias Käppler" notifications@github.com
wrote:

Since we're now minSdkLevel 14, we should spend some time investigating if
there's an opportunity to get rid of the forced inheritance from LightCycle
base Activities. These only exist to forward life-cycle callbacks.

Android already has a mechanism for this, added in ICS:

http://developer.android.com/reference/android/app/Application.ActivityLifecycleCallbacks.html

http://developer.android.com/reference/android/app/Application.html#registerActivityLifecycleCallbacks(android.app.Application.ActivityLifecycleCallbacks)

However, no such thing exists for fragments to the best of my knowledge.

—
Reply to this email directly or view it on GitHub
#19.

[simonpercic]

Hi mttkay and glung,

I'm not sure if this issue is still relevant to you, since it was opened a long time ago and you have probably solved it already, but I wanted to contribute anyway.

I've recently published a library of my own, inspired by LightCycle, without the constraint of having to extend the Activity from a specific base class. Additionally, the bound listener fields don't have to implement any interfaces or inherit from any class. That enables some more flexibility by not forcing any inheritance. Also, it's completely reflection-less by design and compatible with ProGuard.

All of that is possible since the lib is using the approach mentioned in this issue, i.e. Android's ActivityLifecycleCallbacks.

However, the downside of this flexibility is only being able to bind to Activity lifecycle callbacks, with no support for Fragment lifecycles.

If it's still relevant or if it might be useful to you, feel free to check it out at: https://github.com/simonpercic/AirCycle

Again, kudos to your work on LightCycle!

[mttkay]

Yeah I agree that is much nicer. The problem for us was that we use fragments extensively (for better or worse), so using ActivityLifeCycleCallbacks alone doesn't buy us anything. If we want to fix this, we should fix it for both activities and fragments simultaneously.

[glung]

Thx for sharing. Good job.

To add on @mttkay comment. Initially, we thought we could go away with only those callbacks but it turned out that more callbacks out of the ActivityLifeCycleCallback were needed. Also, people added and asked for more and more callbacks (cf open PRs https://github.com/soundcloud/lightcycle/pulls).

I think AirCycle is complementary to LightCycle, when one only needs ActivityLifecycleCallbacks callback, AirCycle sounds like the best option.

[simonpercic]

@mttkay, true, ActivityLifecycleCallbacks can't cover fragments, so in that case this is unfortunately not an option.

@glung, I completely agree, AirCycle should be regarded as a complementary lib to LightCycle, since your library already covers more callbacks (and as per your open PRs will cover even more in future versions).

Thanks for the compliments, guys!
Keep up the good work!