4 ms·
And then there are nested fragments and all the caveats associated with them, but it's all good, it just requires some simple fixes everyone could come up off t
by V-2 10y ago
And then there are nested fragments and all the caveats associated with them, but it's all good, it just requires some simple fixes everyone could come up off the top of their head, like http://stackoverflow.com/a/23276145/168719 http://stackoverflow.com/a/23276145/168719 (the top voted answer)
It's good, because it doesn't require you to use the workaround of deluding the user with a SCREENSHOT of your layout (sic; see the accepted answer above).
- nodamage 10y agoGood lord. How absurd that this is even necessary in the first place.
- BoorishBears 10y agoSupport fragments "fixed" nested fragments a little while back, or so they claimed in a change log.
- V-2 10y agoI don't even know; I imagine at that point there wasn't many developers left around still willing to go down that route. As an Android dev I'm in the camp that steers clear of Fragments out of principle, if only possible.
- BoorishBears 10y agoI'm pragmatic about them and they work out. It takes some discipline, but in exchange you get to use a standard back stack manager with more mindshare than any 3rd party replacement like Flow will have. My personal guidelines are: Only use them in a single form. FragmentTransaction add/remove/replace, no fragment tags in xml to cause inconsistent behavior Represent state with single AutoValue + Auto Parcel object and save it with Icepick so they work with process death automatically Implement all interactions with other threads via RxJava so I can unsubscribe and avoid "after onInstanceState exceptions" Use custom view groups instead of nested fragments since nested fragments tend to not be using the backstack anyways
- V-2 10y agoMakes sense, that's a solid approach. No nesting or any other nonsense. But clearly it takes quite some bootstrapping in order to make this functionality solid (as it should be out of the box)...
- BoorishBears 10y agoFragments follow the general story of Android Framework: tried to be too flexible, introduced unneeded complexity for everyone, suddenly flexibility is of questionable usefulness
- BoorishBears 10y agoI'm pragmatic about them and they work out. It takes some discipline, but in exchange you get to use a standard back stack manager with more mindshare than any 3rd party replacement like Flow will have. My personal guidelines are: Only use them in a single form. FragmentTransaction add/remove/replace, no fragment tags in xml to cause inconsistent behavior Represent state with single AutoValue + Auto Parcel object and save it with Icepick so they work with process death automatically Implement all interactions with other threads via RxJava so I can unsubscribe and avoid "after onInstanceState exceptions" Use custom view groups instead of nested fragments since nested fragments tend to not be using the backstack anyways