AuthUI.signOut(Activity) deprecation

[pushbit]

Just a question to ask why AuthUI.signOut(Activity) is deprecated. In the context of this library, is there a technical reason that we're being asked to use FragmentActivity? I only use Activity, so I'm concerned that this deprecated signOut method might be removed in the future.

[SUPERCILEX]

@pushbit You use plain old Activity??? What's your min sdk version? I'm curious: why aren't you using AppCompatActivity?

Yeah, the plan was to remove those old methods in #609. As for why they were deprecated, we've noticed memory leaks when using the old methods. In addition, their logic was much harder to understand because we were trying to manage our own GoogleApiClient instead of using enableAutoManage which abstracts that logic away from us.

[pushbit]

I use minSdkVersion 21. I don't use FragmentActivity or descendants because I haven't had a need for their backported functionality and I trust the framework classes more. Perhaps it's much less of an issue today, but over the years I've seen too many bizarre issues and bugs with the support library versions of classes.

Thanks for pointing out the GoogleApiClient auto manage thing. I can understand the benefit of letting them deal with the lifecycle details and I see that unfortunately they only provide that for FragmentActivity, for some reason. So I understand if you want to follow their lead, but it would be a pity for those of us who would prefer to stick with framework classes.

[samtstern]

@pushbit thanks for explaining. I think you'll find no downside of moving to AppCompatActivity and a lot of upside. It's the general recommendation for Android apps that target multiple SDK versions.

The reason that enableAutoManage requires a FragmentActivity is because it attaches an invisible Fragment to the activity to track the lifecycle and start/stop the service connection to Google Play services when appropriate. Since auto-management also requires starting Activities for result and receiving the results (in some cases) there's no other way to do this that will be reliable.

For the forseeable future FirebaseUI will rely heavily on the support libraries, I hope you can find a way to make them work for you too.

I am going to close this issue since moving back to Framework classes is not on our roadmap.