Provide a way to handle navigating back and forth between NavHostFragments embedded within other NavHostFragments (or if it's already available, document how to do) [120690961]

Fixed

Feature Request

Status Update

No update yet.

Description

je...@23andme.com

created issue #1

Dec 9, 2018 03:07AM

Component used: Navigation
Version used: 1.0.0-alpha08
Devices/Android versions reproduced on:

Assuming:
- Main Activity has a NavHostFragment, which navigates between Fragment A & Fragment B
- Main activity handles going back with onSupportNavigateUp
- Fragment B has it's own NavHostFragment, which navigated between InnerFragmentB1 & InnerFragmentB2
- Parent NavHostFragment navigates from A -> B (which starts with B1)
- Sub NavHostFragment navigates from B1 -> B2
- Press up: Sub NavHostFragment returns to B1
- Press up: Parent NavHostFragment returns from B to A

What's the proper way of handling these types of situations where we'd like the back button to handle backing out of Inner Fragments first and then Outer Fragments after?

Details here:

https://stackoverflow.com/q/53688934/1229936
Sample Code:

https://github.com/jeffreyfhow/NestedNavFragmentsTest

Comments

so...@gmail.com <so...@gmail.com> #2Dec 9, 2018 07:33AM

For one of observables (single, maybe) we don't specify a subscvription thread so that developer can control where the action happens.
For flowables / observables; we always use the Room IO thread fo rthe actual query since we may repeat the work.

For LiveData, ti si always the Room IO Thread.

Until we can extend Room Query methods to receive non-query parameter (e.g. a Scheduler) we cannot do this.
At least room catches this instantly since it will crash w/ db access on main thread exception.

il...@google.com <il...@google.com> #3Dec 10, 2018 05:58PM

Hello Yigit, nice to meet you here! :)
Probably I should have described the problem more clearly.

I'm using Flowable, and hopefully it executes queries in background thread (at least, app does not crash with IllegalStateException, as with Single).

But nevertheless subscribing and disposing(!) does cause StrictMode violations. Stack trace examples:

D/StrictMode: StrictMode policy violation; ~duration=17 ms: android.os.StrictMode$StrictModeDiskWriteViolation: policy=31 violation=1
at android.os.StrictMode$AndroidBlockGuardPolicy.onWriteToDisk(StrictMode.java:1111)
at android.database.sqlite.SQLiteConnection.applyBlockGuardPolicy(SQLiteConnection.java:1043)
at android.database.sqlite.SQLiteConnection.execute(SQLiteConnection.java:552)
at android.database.sqlite.SQLiteSession.beginTransactionUnchecked(SQLiteSession.java:323)
at android.database.sqlite.SQLiteSession.beginTransaction(SQLiteSession.java:298)
at android.database.sqlite.SQLiteDatabase.beginTransaction(SQLiteDatabase.java:505)
at android.database.sqlite.SQLiteDatabase.beginTransaction(SQLiteDatabase.java:416)
at androidx.sqlite.db.framework.FrameworkSQLiteDatabase.beginTransaction(FrameworkSQLiteDatabase.java:69)
at androidx.room.InvalidationTracker.syncTriggers(InvalidationTracker.java:426)
at androidx.room.InvalidationTracker.syncTriggers(InvalidationTracker.java:465)
at androidx.room.InvalidationTracker.addObserver(InvalidationTracker.java:249)
at androidx.room.RxRoom$1.subscribe(RxRoom.java:79)
at io.reactivex.internal.operators.flowable.FlowableCreate.subscribeActual(FlowableCreate.java:71)
at io.reactivex.Flowable.subscribe(Flowable.java:14479)
at io.reactivex.internal.operators.flowable.FlowableObserveOn.subscribeActual(FlowableObserveOn.java:56)
at io.reactivex.Flowable.subscribe(Flowable.java:14479)
at io.reactivex.internal.operators.flowable.FlowableFlatMapMaybe.subscribeActual(FlowableFlatMapMaybe.java:54)
at io.reactivex.Flowable.subscribe(Flowable.java:14479)
at io.reactivex.Flowable.subscribe(Flowable.java:14416)
at io.reactivex.Flowable.subscribe(Flowable.java:14306)
at gmk57.strictroom.MainActivity.onCreate(MainActivity.java:30)

StrictMode policy violation; ~duration=108 ms: android.os.StrictMode$StrictModeDiskWriteViolation: policy=31 violation=1
at android.os.StrictMode$AndroidBlockGuardPolicy.onWriteToDisk(StrictMode.java:1111)
at android.database.sqlite.SQLiteConnection.applyBlockGuardPolicy(SQLiteConnection.java:1043)
at android.database.sqlite.SQLiteConnection.execute(SQLiteConnection.java:552)
at android.database.sqlite.SQLiteSession.beginTransactionUnchecked(SQLiteSession.java:323)
at android.database.sqlite.SQLiteSession.beginTransaction(SQLiteSession.java:298)
at android.database.sqlite.SQLiteDatabase.beginTransaction(SQLiteDatabase.java:505)
at android.database.sqlite.SQLiteDatabase.beginTransaction(SQLiteDatabase.java:416)
at androidx.sqlite.db.framework.FrameworkSQLiteDatabase.beginTransaction(FrameworkSQLiteDatabase.java:69)
at androidx.room.InvalidationTracker.syncTriggers(InvalidationTracker.java:426)
at androidx.room.InvalidationTracker.syncTriggers(InvalidationTracker.java:465)
at androidx.room.InvalidationTracker.removeObserver(InvalidationTracker.java:281)
at androidx.room.RxRoom$1$2.run(RxRoom.java:83)
at io.reactivex.disposables.ActionDisposable.onDisposed(ActionDisposable.java:30)
at io.reactivex.disposables.ActionDisposable.onDisposed(ActionDisposable.java:19)
at io.reactivex.disposables.ReferenceDisposable.dispose(ReferenceDisposable.java:43)
at io.reactivex.internal.disposables.DisposableHelper.dispose(DisposableHelper.java:124)
at io.reactivex.internal.disposables.SequentialDisposable.dispose(SequentialDisposable.java:72)
at io.reactivex.internal.operators.flowable.FlowableCreate$BaseEmitter.cancel(FlowableCreate.java:301)
at io.reactivex.internal.operators.flowable.FlowableObserveOn$BaseObserveOnSubscriber.cancel(FlowableObserveOn.java:154)
at io.reactivex.internal.operators.flowable.FlowableFlatMapMaybe$FlatMapMaybeSubscriber.cancel(FlowableFlatMapMaybe.java:158)
at io.reactivex.internal.subscriptions.SubscriptionHelper.cancel(SubscriptionHelper.java:189)
at io.reactivex.internal.subscribers.LambdaSubscriber.cancel(LambdaSubscriber.java:119)
at io.reactivex.internal.subscribers.LambdaSubscriber.dispose(LambdaSubscriber.java:104)
at gmk57.strictroom.MainActivity.onDestroy(MainActivity.java:37)

il...@google.com <il...@google.com> Dec 10, 2018 09:55PM

Accepted by il...@google.com.

il...@google.com <il...@google.com> #4Dec 14, 2018 12:05AM

Marked as fixed.

oh this is bad :/ we should fix it, thanks!

ka...@gmail.com <ka...@gmail.com> #5Dec 27, 2018 05:06PM

Looks like it is broken for both add observer and remove observer since both are sync.
We need to investigate this better because these methods were not @WorkerThread before and we had to change them to fix some invalidation problems (see internal bug

b/73592149

).
Luckily this is not an issue for LiveData since it uses ComputableLiveData and always calls observe on a background thread.

Issue 120690961