-
Notifications
You must be signed in to change notification settings - Fork 3.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fragment advice is misleading. #10
Comments
@jacobtabak I agree 100%. This section sounded like it was written by the dev who wrote the Android Plugins for Eclipse. |
Thanks @jacobtabak for the "other side of the coin" type of feedback. A couple of developers from our company gathered to discuss how a typical app should be structured, and we converged on a Fragment-based architecture. This is not to mean it's a silver bullet for every situation, and it's true the advice can be misleading. The whole Activities vs Fragments vs custom is a hot debatable issue in the Android community, so we try to give a "good enough" starting point for new developers. We'll talk about this internally in our company, but we're open for PRs and suggestions on what to advise. |
There's certainly a benefit to having a consistent architecture in your application, and the fragment approach is not a bad one, but I take issue with many of the points you've listed for the reasons above. I feel like the only two points that stand up to scrutiny. I'm not suggesting that you withdraw your recommendation for the fragment approach, but I think you should prune your list to only the arguments that stand under scrutiny. Specifically, I'd revise or remove the following, and I'll differentiate this from my criticism above with more specific feedback about what I believe should be changed and why.
Definitely remove the comment about ActionBar Tabs since it's been deprecated and perhaps find another example that's more relevant. Maybe go into detail about why the MapFragment solution is easier to use than MapView - with MapFragment, you don't need to explicitly invoke the lifecycle methods (onCreate, onResume, onPause, etc), but there's no advantage other than that.
What you're describing is the ViewPager class which has no dependency or relationship to fragments other than that there are Fragment pager adapter. I object because it's perpetuating beginners' misconception that ViewPagers only work with fragments.
What specifically makes it "more advanced" than the activity back stack? In my opinion, the activity back stack is much more flexible with different activity launch modes. I personally haven't found a use case for the fragment back stack, it is way too inflexible, and works very poorly when replacing fragments.
I don't believe this is an advantage, managing the action bar with fragments doesn't provide you with anything that managing the action bar from an activity does not. |
The part about Fragments was a "surprise" for me. I would dial it down to the point where this is a good idea, just to keep the code DRY; but to have a single activity for the whole app is a bit of a stretch. Why not just use the Application class for the POJOs if having them available across the app was the problem? Anyway, the rest of the document is really good and I just ate it up, but I'm quite sure that the part about fragments is at best an opinion - and not even a very popular one, according to all the StackOverflow disputes on the subject. Sorry if my opinion upsets you in any way. |
I use Activities, Fragments, and custom views, depending on the context. I don't think it's wise to recommend the Fragment approach as a catch-all solution.
If you're relying on non-parcelable/serializable POJOs, how do you retain instance state if the user switches to another application? Speaking of that, there's no mention of instance state, parcelable, or serializable in the doc.
The ActionBar Tabs API is now deprecated. There's no benefit to use MapFragment over MapView.
ViewPager has nothing to do with Fragments. It's trivial to implement your own PagerAdapter, the only reason why one is provided in the support lib for fragments is because fragments have such a complex lifecycle.
Also, Fragments don't support some complex transitions. "The Z adjustment only works for window animations. I thought this was documented, but apparently not." This means you can't do things like fade out one fragment and slide in the other from the right, because the outgoing fragment might be rendered above the incoming one.
The fragment back stack is far from intelligent. You can't remove an item from the back stack unless it's on top, you can't pop the back stack without triggering an animation without hackish workarounds.
The text was updated successfully, but these errors were encountered: