3 ms·
> First is the stupidity of Activities. The basic idea was that 1 screen = 1 activity and we can remove all non-active activities from memory and restart them a
by konschubert 11y ago
> First is the stupidity of Activities. The basic idea was that 1 screen = 1 activity and we can remove all non-active activities from memory and restart them as needed. This was clearly designed with an eye on memory constrained systems. Nowadays even the cheapest phones have shitloads of RAM but we're still stuck with this retarded model. Worse, now we have support for tablets and phones with big screens the 1 activity per screen no longer makes any sense anymore either.
Shouldn't fragments solve this?[0]
[0] https://developer.android.com/guide/components/fragments.html https://developer.android.com/guide/components/fragments.htm...
- izacus 11y agoSadly fragment API is pretty terrible - it adds a heapload of complexity due to it's async nature (see https://i.stack.imgur.com/fRxIQ.png https://i.stack.imgur.com/fRxIQ.png which is NOT an exagerration), it's very buggy and filled with hard to debug device-specific issues. Most developers have opted for one of the more popular MVVM / MVP patters that help manage UIs without use of Fragments, but pain when designing tablet interfaces is still there.
- thecupisblue 11y agoUh, fragments introduced just more of the same problems. A fragment in an activity has an insane, confusing lifecycle, then if you nest them, you basically summon Cthulhu. The more experienced part of the Android dev community is slowly transitioning into using views instead of fragments.
- HillaryBriss 10y ago<rant> IMHO, Fragments didn't simplify my work or make it more manageable. Fragments mostly added new weird things to remember, and, for all that complication, I don't seem to reuse them all that much. Fragments have their own lifecycle events which are like those of an Activity, but not exactly. They also interact with the Activity lifecycle in ways that I found a bit confusing, personally. To get access to your Fragment instances, you're supposed to rely on the FragmentManager (and/or FragmentManagerCompat, depending on what minimum version of Android you support), which puts you at arm's length from them, making life a bit awkward. Fragments also exist in another flavor, from the compat library, so that sometimes results in mismatched types which can be confusing. Then you have to get used to the idea that you're only supposed to create trivial constructors for your Fragments. If a Fragment needs to know something interesting, you're supposed to pass parameters to it, not through a constructor, but, with setArguments. That way the system can resupply those arguments if it has to destroy and recreate your Fragment on your behalf in certain circumstances. This could be better documented, IMHO. But wait, there's also a lifecycle callback named "onViewStateRestored" which supplies a savedInstanceState Bundle to your Fragment which it can use to bring itself back to the desired state. This is more like what Activities do, kind of. But it doesn't seem to interact usefully with Activity state restoration, which I found counterintuitive. And when I think about how smart these Android SDK programmers are (and I have no doubt that they are super bright people), I wonder why this is what they came up with. It makes me feel dumb. And if your goal is to create a product your customers will love, maybe you should avoid making them feel dumb. </rant>