Conductor: Why LifecycleHandler extended android.app.Fragment?

[MkhytarMkhoian]

Why LifecycleHandler not extended android.support.v4.app.Fragment?
Why you do not use onRetainCustomNonConfigurationInstance?

[IVIanuu]

It's not required to use support fragments. This would add an extra dependency.

onRetainCustomNonConfigurationInstance is not used because the fragment approach requires less boilerplate on the consumer side. The LifecycleHandler delegates all options menu stuff, permission requests, activity results and so on to the routers. In the end it would be a boilerplate fest without it.

Another point is that the onRetainCustomNonConfigurationInstance is deprecated in newer AppCompat versions.

[MkhytarMkhoian]

@IVIanuu onRetainCustomNonConfigurationInstance is not deprecated
android.app.Fragment is deprecated

All Fragment bug fix is made only in support lib

For my point of view, we can write all this functionality without Fragment

[PaulWoitaschek]

For my point of view, we can write all this functionality without Fragment

How would you do that without requiring error prone manual callback delegation?

[IVIanuu]

It is check the update from the 5. november

https://developer.android.com/jetpack/androidx/androidx-rn#2018-nov

Yes you could do that but like i said it will require alot of boilerplate.

Personally i have no problem with the androidx fragment dependency but it's up to the maintainers of the library.

[IVIanuu]

A ConductorActivity base class would also be a possibility. But base classes provided by libraries are a bad thing most of the times.

I think the fragment approach is definitely the best solution.

[PaulWoitaschek]

What advantages do you see @MkhytarMkhoian ?

Following composition-over-inheritance the current solution is quite perfect.
For AndroidX there is also this branch:
https://github.com/bluelinelabs/Conductor/tree/feature/androidx_backing

[MkhytarMkhoian]

@IVIanuu

onRetainCustomNonConfigurationInstance has been deprecated. Use a ViewModel for storing objects that need to survive configuration changes.

I Android history this method was deprecated the second time:) It's just for pushing to use architecture components. This method is using in Fragment and maybe ViewModel also. There is no new mechanism in Android SDK for surviving configuration changes. So I think we still can use this method.

@PaulWoitaschek I think that using Fragment like a middle layer between Activity and Controller is unnecessary and overhead. For me, performance is important and I think this is an issue.
So I definitely will use android.support.v4.app.Fragment to avoid some bugs. Then I will be considering to rewrite LifecycleHandler for my project.

[dimsuz]

For me, performance is important and I think this is an issue.

Do you have some measurements to back this up? No offense, but assumptions about performance without actual measurements often turn up to be wrong. You'd need to actually run profiler and check if Fragment methods would show up as taking a lot of time to execute or a lot of memory.

[EricKuck]

@MkhytarMkhoian each activity gets 1 and only 1 fragment, no matter how many controllers you push. You're not going to get a perf boost from ditching fragments. In addition to not being able to accomplish everything LifecycleHandler does without a gross BaseActivity of some kind, there's just no benefit to doing it this way.

[MkhytarMkhoian]

@dimsuz I don't have any performance measurements for now. Maybe I should do.

@EricKuck I think we need to add an extension to support module, where LifecycleHandler using android.support.v4.app.Fragment

[EricKuck]

That extension already exists in the androidx branch. I'll be doing some
final testing with that and will probably bundle it into the 3.0.0 beta.

On Thu, Nov 22, 2018 at 2:37 AM Mkhytar Mkhoian [e-mail]
wrote:

@dimsuz https://github.com/dimsuz I don't have any performance
measurements for now. Maybe I should do.

@EricKuck https://github.com/EricKuck I think we need to add an
extension to support module, where LifecycleHandler using
android.support.v4.app.Fragment

—
You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub
https://github.com/bluelinelabs/Conductor/issues/503#issuecomment-440952793,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AB8c8mnFDKtu9myd7GurBw4swm7kXkFVks5uxmJCgaJpZM4Yoyfc
.

>