4 ms·

I used to think Activity lifecycle management is complex. Then I learned about Fragments and I started to loathe every moment I have to work with them. What a b

I used to think Activity lifecycle management is complex. Then I learned about Fragments and I started to loathe every moment I have to work with them. What a bloated mess: http://staticfree.info/~steve/complete_android_fragment_lifecycle.png http://staticfree.info/~steve/complete_android_fragment_life...

sgc 10y ago
I started making a semi-complex android app as my first project. Saw the recommendation to use fragments, and I have never looked back because I am way, way too far down the rabbit whole. It's main advantage to me is perhaps nothing. I have no idea and no real way of knowing. But is has tripled my code base, so that is a good thing!
m_fayer 10y ago
Otherwise known as the "lolcycle".
tigershark 10y ago
They must have been using some seriously good drug when "designing" this mess..
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 ago
  Good lord. How absurd that this is even necessary in the first place.
- BoorishBears 10y ago
  Support fragments "fixed" nested fragments a little while back, or so they claimed in a change log.
  - V-2 10y ago
    I 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 ago
      I'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 ago
        Makes 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 ago
        Fragments 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 ago

sgc 10y ago

I started making a semi-complex android app as my first project. Saw the recommendation to use fragments, and I have never looked back because I am way, way too far down the rabbit whole. It's main advantage to me is perhaps nothing. I have no idea and no real way of knowing. But is has tripled my code base, so that is a good thing!

m_fayer 10y ago

Otherwise known as the "lolcycle".

tigershark 10y ago

They must have been using some seriously good drug when "designing" this mess..

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 ago
Good lord. How absurd that this is even necessary in the first place.
BoorishBears 10y ago
Support fragments "fixed" nested fragments a little while back, or so they claimed in a change log.
- V-2 10y ago
  I 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 ago
    I'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 ago
      Makes 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 ago
        Fragments 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 ago