Switching back and forth between 2 Custom Views

[raskasa]

Is there any possibility of adding to this app an example of how you switch back and forth between 2 custom views?

I've heard someone mention that Square doesn't use Fragments in their apps -- it would be nice to see an example in this app of how to handle multiple screens without Fragments.

[JakeWharton]

The approach is no different than how fragments behave:

1. inflate the new screen's view using the container view and attach=false (inflate(layoutId, container, false))
2. add the new view to the container at an index after the current view (container.addView(view))
3. start an animation on the current view to animate it out (e.g., from 0 to translationX offscreen left)
4. start an animation on the new view to animate it in (e.g., from translationX offscreen right to 0)
5. at the end of the animation, remove the current view from the container (container.removeView)

When going backwards, do the same thing except add the view as the 0th element in the container so that it appears "behind" the current view.

Then it's just a matter of figuring out how to keep a backstack (we use a Deque<Entry> where entry is a location indicator and SparseArray<Parcelable> of view state), exposing an API for navigation ("go to this screen"), and hooking into the onBackPressed callback of the activity.

[JakeWharton]

The approach is no different than how fragments behave:

1. inflate the new screen's view using the container view and attach=false (inflate(layoutId, container, false))
2. add the new view to the container at an index after the current view (container.addView(view))
3. start an animation on the current view to animate it out (e.g., from 0 to translationX offscreen left)
4. start an animation on the new view to animate it in (e.g., from translationX offscreen right to 0)
5. at the end of the animation, remove the current view from the container (container.removeView)

When going backwards, do the same thing except add the view as the 0th element in the container so that it appears "behind" the current view.

Then it's just a matter of figuring out how to keep a backstack (we use a Deque<Entry> where entry is a location indicator and SparseArray<Parcelable> of view state), exposing an API for navigation ("go to this screen"), and hooking into the onBackPressed callback of the activity.

[JakeWharton]

If we add multiple screens to this app it will likely be done with fragments as there's no open source non-fragment libraries that I would use at this time.

[JakeWharton]

If we add multiple screens to this app it will likely be done with fragments as there's no open source non-fragment libraries that I would use at this time.

[raskasa]

Ahhh, thanks for the steps - they are clear enough to replicate on my own.

Makes sense about wanting to stick with open-source libraries.

[raskasa]

Ahhh, thanks for the steps - they are clear enough to replicate on my own.

Makes sense about wanting to stick with open-source libraries.

[JakeWharton]

I would remiss without mentioning Flow, but in having written the original, pre-open source version of that library which is now surely a distant cousin than what's currently in the library I found it to be flawed in design. I haven't looked at it since then because the app that I work on at Square has a solution which I find to be designed in a way that I prefer more. Hopefully someday a form of it will see the light of open source.

[JakeWharton]

I would remiss without mentioning Flow, but in having written the original, pre-open source version of that library which is now surely a distant cousin than what's currently in the library I found it to be flawed in design. I haven't looked at it since then because the app that I work on at Square has a solution which I find to be designed in a way that I prefer more. Hopefully someday a form of it will see the light of open source.

[Zhuinden]

@JakeWharton Flow has changed shape twice since, and is essentially a backstack managed and kept alive by a retained fragment (lifecycle listener), that supports reentrance and asynchronous transitions. Also featuring view state persistence to a given state, and even automatic setup / teardown of services that are supposedly hierarchical using TreeKey, mimicking the behavior of MortarScopes.

Personally I found that it's limited in describing nested navigation, and the creation of multiple stacks (you need to flatten it in one).

Apart from Conductor, is there any navigation pattern that you consider to be a valid option? Not necessarily my Flow-variant either, it's just as bad at describing nesting :D

[Zhuinden]

@JakeWharton Flow has changed shape twice since, and is essentially a backstack managed and kept alive by a retained fragment (lifecycle listener), that supports reentrance and asynchronous transitions. Also featuring view state persistence to a given state, and even automatic setup / teardown of services that are supposedly hierarchical using TreeKey, mimicking the behavior of MortarScopes.

Personally I found that it's limited in describing nested navigation, and the creation of multiple stacks (you need to flatten it in one).

Apart from Conductor, is there any navigation pattern that you consider to be a valid option? Not necessarily my Flow-variant either, it's just as bad at describing nesting :D

[JakeWharton]

No. Nor Conductor.

…

On Wed, Jul 19, 2017, 4:10 AM Gabor Varadi ***@***.***> wrote: @JakeWharton <https://github.com/jakewharton> Flow has changed shape twice since, and is essentially a backstack managed and kept alive by a retained fragment (lifecycle listener), that supports reentrance and asynchronous transitions. Also featuring view state persistence to a given state, and even automatic setup / teardown of services that are supposedly hierarchical using TreeKey, mimicking the behavior of MortarScopes. Personally I found that it's limited in describing nested navigation, and the creation of multiple stacks (you need to flatten it in one). Apart from Conductor, is there any navigation pattern that you consider to be a valid option? Not necessarily my Flow-variant either, it's just as bad at describing nesting :D — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#169 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAEEETv9chBuiAA37R16S5bZvUDuw4xqks5sPbncgaJpZM4FKbVm> .

[JakeWharton]

No. Nor Conductor.

…

On Wed, Jul 19, 2017, 4:10 AM Gabor Varadi ***@***.***> wrote: @JakeWharton <https://github.com/jakewharton> Flow has changed shape twice since, and is essentially a backstack managed and kept alive by a retained fragment (lifecycle listener), that supports reentrance and asynchronous transitions. Also featuring view state persistence to a given state, and even automatic setup / teardown of services that are supposedly hierarchical using TreeKey, mimicking the behavior of MortarScopes. Personally I found that it's limited in describing nested navigation, and the creation of multiple stacks (you need to flatten it in one). Apart from Conductor, is there any navigation pattern that you consider to be a valid option? Not necessarily my Flow-variant either, it's just as bad at describing nesting :D — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#169 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAEEETv9chBuiAA37R16S5bZvUDuw4xqks5sPbncgaJpZM4FKbVm> .

[Zhuinden]

I see, thank you 🙂 one day I'll see the right solution and think "gah how did we not think of this earlier"

[Zhuinden]

I see, thank you 🙂 one day I'll see the right solution and think "gah how did we not think of this earlier"