fix (bottom-navigation-bar): pick the correct activity for checking lifecycle

[mukaschultze]

This PR fixes an issue where the bottom navigation tabs are not correctly instantiated when returning to the application if the foreground activity is not an AppCompatActivity.

[farfromrefug]

@mukaschultze good idea. But would be best to use || with foreground first( current activity so should be first). Could you change it ?

[edusperoni]

@farfromrefug I believe the issue is that foregroundActivity isn't necessarily an AppCompatActivity, so it may not have the getLifecycle method. If you're in a modal, for example, which has it's own activity, it'll be set as the foregroundActivity, so using the code as is will and switching apps with a modal open will break the BottomNavigation.

Maybe we can add some other feature on core to track the foregroundAppActivity (or you could listen to activityResumed events).

Looking at this issue I even found a potential issue on core even (still have to test this scenario). On activity resume it will set the activity as foregroundActivity. On destroy it'll check if it's the foregroundActivity/startActivity and set them to undefined if it is. So opening a modal and closing leaves no foregroundActivity, and opening a modal inside a modal then closing the topmost one leaves no foregroundActivity (but it should). Although I think this might be fine because it might trigger a resume on the background activity as it gets to the foreground.

In any case, I believe you should probably use foregroundActivity || startActivity for almost every case, but on this case you probably need startActivity otherwise you can't guarantee it has the getLifecycle method.

[farfromrefug]

@edusperoni you are right and we already test getLifecycle with the ?.

[edusperoni]

@farfromrefug !activity.getLifecycle?.().getCurrentState().isAtLeast(androidx.lifecycle.Lifecycle.State.STARTED). If getLifecycle is null, then it's the same as the whole condition evaluating to true, which means if you resume the app from a modal this method will return instead of attaching to the window, which is the incorrect behavior because clearly the activity's lifecycle is at least STARTED.

[edusperoni]

@farfromrefug to give you some context, we're using bottom nav with google play billing, which detaches and then attaches the activities. If we use the plugin in the current form, this is what happens on some flows (mainly switching apps during the play billing flow, like tapping to view the google play policies):

If you're uncomfortable with changing it to startActivity, you could save the activity reference for the bottom-nav somewhere during the lifecycle (maybe createnativeview and disposenativeview). Or you could fallback to startActivity if activity.getLifecycle is null, but treating activity.getLifecycle being null as a false statement is causing issues.

[farfromrefug]

@edusperoni good catch! will fix

[mukaschultze]

Just tested and commit ffa38ab also fixes the issues we were having, thanks!