cookpad/bottomnavwatson

Bottom navigation bar library that allows multiple back stacks and one single navigation graph

bottomnavwatson's Issues

Showcase crashes with orientation changes

Current Behaviour 😢

Changing orientation causes showcases crash.

Expected behavior 😃

Watson should handle properly config changes.

Additional information 🗒️

Stacktrace:

java.lang.IllegalStateException: FragmentManager has been destroyed
at androidx.fragment.app.FragmentManager.ensureExecReady(FragmentManager.java:1783)
at androidx.fragment.app.FragmentManager.execSingleAction(FragmentManager.java:1814)
at androidx.fragment.app.BackStackRecord.commitNow(BackStackRecord.java:297)
at watson.MultipleBackStacksViewModel.obtainNavHostFragment(MultipleBackStacksViewModel.kt:198)
at watson.MultipleBackStacksViewModel.onBottomNavigationView(MultipleBackStacksViewModel.kt:64)
at watson.BottomNavWatsonKt.setupWithNavController(BottomNavWatson.kt:44)
at watson.BottomNavWatsonKt.setupWithNavController$default(BottomNavWatson.kt:21)
at cookpad.com.bottomnavwatson.HomeActivity.onCreate(HomeActivity.kt:12)
at android.app.Activity.performCreate(Activity.java:7989)
at android.app.Activity.performCreate(Activity.java:7978)
at android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1309)
at androidx.test.runner.MonitoringInstrumentation.callActivityOnCreate(MonitoringInstrumentation.java:702)
at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:3315)
at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:3484)
at android.app.ActivityThread.handleRelaunchActivityInner(ActivityThread.java:5358)
at android.app.ActivityThread.handleRelaunchActivity(ActivityThread.java:5266)
at android.app.servertransaction.ActivityRelaunchItem.execute(ActivityRelaunchItem.java:69)
at android.app.servertransaction.TransactionExecutor.executeCallbacks(TransactionExecutor.java:135)
at android.app.servertransaction.TransactionExecutor.execute(TransactionExecutor.java:95)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:2044)
at android.os.Handler.dispatchMessage(Handler.java:106)
at android.os.Looper.loop(Looper.java:223)
at android.app.ActivityThread.main(ActivityThread.java:7476)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:549)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:939)

there is a way to avoid fragment recreation using bottomNavWatson?

Specification 📓

Research and motivation 🔍

[Describe the reason for implementing this featurel, add clear and complete requirements.]

Improve infrastructure to make of Watson a showcase for our open source guidelines

When creating the docs for our open-source guidelines, we thought that having a showcase would make things easier to understand. We will improve the Watson library to be that showcase and for that, it needs to match the next requirements:

• Provide tests for the main use cases
• Add Cookpad code-base code style
• Add Cookpad code-base Detekt config
• Create a new Bitrise app from the admin panel selecting the Github repo via a webhook. The .yml config file should be added to the sources on the Github repository as a backup file.
• Setup Bitrise CI with a pull-request workflow to run Detekt, Lint, Unit, and UI tests.
• Protect master branch with "Require pull request reviews before merging: 1" and "Require status checks to pass before merging" checks.
• Add MIT license
• Add contributions guidelines

Stop initialising all navbar fragments at start

Description of the problem

Currently, the setupWithNavController initialisation method of BottomNavWatson class loops through enabled destinations and initialises host fragments using obtainNavHostFragment extension method.

Few lines later, it detaches all these initialised host fragments (along with their start destination fragments in stack) but the one selected.

This seems inefficient as at the start of the application, all the main fragments get initialised, views created and potentially HTTP calls or other code executed, just to be detached moments later.

Proposal pf solution

The proposal of this ticket is to make the obtainNavHostFragment method "on-demand", potentially lazily evaluated, so that the costly initialisation of all main fragments is delayed until needed.

Fix IllegalStateException does not have a NavController set

After bumping the navigation lib version to 2.3.0 our deep links stoped to work: when the user left the app on the background (by clicking the home button for instance) and a deep link was launched, the app crashed:

java.lang.RuntimeException: Unable to destroy activity {com.mufumbo.android.recipe.search.debug/com.cookpad.android.home.home.HomeActivity}: java.lang.IllegalStateException: View androidx.fragment.app.FragmentContainerView{3ef6e7d V.E...... ......ID 0,0-1080,1584 #7f0903e8 app:id/navigationHostFragment} does not have a NavController set
        at android.app.ActivityThread.performDestroyActivity(ActivityThread.java:5020)
        at android.app.ActivityThread.handleDestroyActivity(ActivityThread.java:5049)
        at android.app.servertransaction.DestroyActivityItem.execute(DestroyActivityItem.java:44)
        at android.app.servertransaction.TransactionExecutor.executeLifecycleState(TransactionExecutor.java:176)
        at android.app.servertransaction.TransactionExecutor.execute(TransactionExecutor.java:97)
        at android.app.ActivityThread$H.handleMessage(ActivityThread.java:2044)
        at android.os.Handler.dispatchMessage(Handler.java:106)
        at android.os.Looper.loop(Looper.java:223)
        at android.app.ActivityThread.main(ActivityThread.java:7476)
        at java.lang.reflect.Method.invoke(Native Method)
        at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:549)
        at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:939)
     Caused by: java.lang.IllegalStateException: View androidx.fragment.app.FragmentContainerView{3ef6e7d V.E...... ......ID 0,0-1080,1584 #7f0903e8 app:id/navigationHostFragment} does not have a NavController set
        at androidx.navigation.Navigation.findNavController(Navigation.java:84)
        at androidx.navigation.fragment.NavHostFragment.onDestroyView(NavHostFragment.java:388)
        at androidx.fragment.app.Fragment.performDestroyView(Fragment.java:2908)
        at androidx.fragment.app.FragmentManager.destroyFragmentView(FragmentManager.java:1344)
        at androidx.fragment.app.FragmentManager.moveToState(FragmentManager.java:1264)
        at androidx.fragment.app.FragmentManager.moveToState(FragmentManager.java:1356)
        at androidx.fragment.app.FragmentManager.moveFragmentToExpectedState(FragmentManager.java:1434)
        at androidx.fragment.app.FragmentManager.moveToState(FragmentManager.java:1497)
        at androidx.fragment.app.FragmentManager.dispatchStateChange(FragmentManager.java:2625)
        at androidx.fragment.app.FragmentManager.dispatchDestroy(FragmentManager.java:2609)
        at androidx.fragment.app.FragmentController.dispatchDestroy(FragmentController.java:330)
        at androidx.fragment.app.FragmentActivity.onDestroy(FragmentActivity.java:365)
        at androidx.appcompat.app.AppCompatActivity.onDestroy(AppCompatActivity.java:233)
        at android.app.Activity.performDestroy(Activity.java:8234)
        at android.app.Instrumentation.callActivityOnDestroy(Instrumentation.java:1344)
        at android.app.ActivityThread.performDestroyActivity(ActivityThread.java:5005)
        at android.app.ActivityThread.handleDestroyActivity(ActivityThread.java:5049) 
        at android.app.servertransaction.DestroyActivityItem.execute(DestroyActivityItem.java:44) 
        at android.app.servertransaction.TransactionExecutor.executeLifecycleState(TransactionExecutor.java:176) 
        at android.app.servertransaction.TransactionExecutor.execute(TransactionExecutor.java:97) 
        at android.app.ActivityThread$H.handleMessage(ActivityThread.java:2044) 
        at android.os.Handler.dispatchMessage(Handler.java:106) 
        at android.os.Looper.loop(Looper.java:223) 
        at android.app.ActivityThread.main(ActivityThread.java:7476) 
        at java.lang.reflect.Method.invoke(Native Method) 
        at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:549) 
        at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:939) 

We were not able to find the actual issue and the only way we found to bypass this limitation has been subclassing NavHostFragment to try/catch the call to super::onDestroyView and sallow this particular exception. We will keep this issue open to keep track of it hoping that future versions of the navigation library fix the issue in the same way it appeared: without knowing how.

Avoid adding new fragments after a process death

Current Behaviour 😢

After a process death, new fragments are stacked on top of old ones.

Expected behavior 😃

New fragments should be not added on top of the old ones after a process death.

Screenshots, video 🖼️

Incorrect package for library classes

Current Behaviour 😢

The package for library classes is currently watson.

Android studio shows the package as incorrect (but compiles), while automatic import imports the wrong one (doesn't compile).

vs.

Expected behavior 😃

The package should reflect the full path: e.g. com.cookpad.watson, etc.

Environment information 🌍

• OS and version: all
• Device model: all
• Library version: 0.0.5