Comments (4)
@jacobtabak I agree 100%.
This section sounded like it was written by the dev who wrote the Android Plugins for Eclipse.
Fragments are powerful and flexible no doubt. But they should not be seen as a silver bullet for every UI.
from android-best-practices.
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.
from android-best-practices.
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.
Many Android classes expect fragments. The API for tabs on the ActionBar expects the tab contents to be fragments. Also, if using Google Maps API v2, the recommended solution is MapFragment, even though MapView exists.
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.
Easy to implement swiping transitions between screens. If a UI screen is a fragment in your application, you can use FragmentPagerAdapter to contain a collection of fragments and implement smooth and interactive transitioning between them. For instance, horizontal swiping of screens.
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.
Intelligent behavior for "back". The FragmentManager allows you to perform transactions to change the fragments inside an activity. Hence, the FragmentManager manages the "state" of fragments. The back button/action will be handled by the FragmentManager to go back to the previous "fragments state". This is more advanced than the activity stack.
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.
Even the ActionBar can be managed from within fragments. You can choose to have one Fragment without a UI with the sole purpose of managing the ActionBar, or you can choose to have each currently visible Fragment add its own action items to the parent Activity's ActionBar. Read more here.
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.
from android-best-practices.
The part about Fragments was a "surprise" for me.
So for an app that has a couple of screens (list of products, product details, product search, checkout, profile) I should consider having one, big MainActivity with lots of Fragments?
Doesn't this activity become a God class really fast? Am I not going to have problems when the activity gets killed, recreated, etc? I know, a non-ui fragment can be used - but what about activity-kill situations not related to configuration changes?
If every screen I see is a Fragment, aren't nested fragments going to be something very common, for any non-trivial layout(consider having a gallery in the product page or having a screen with multiple tabs)? And after telling us to use fragments for everything you tell us to avoid nesting fragments; that is just funny.
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.
from android-best-practices.
Related Issues (20)
- Recommend sharing your **debug** signing key HOT 1
- Recommend sharing your IDE code formatters HOT 4
- Simplify Gradle recommendations
- Simplify Android Studio recommendation HOT 2
- Add minSdk recommendation new projects HOT 1
- Encourage sensible use of Android Support Annotations
- Add RxJava testing guidance HOT 1
- Revise our recommendations for persistence storage HOT 2
- Add reference to Spice program in summary HOT 2
- Investigate different format for README HOT 3
- Recommend using MVP as application Architecture HOT 1
- Adding an Android logo and Futurice label below it HOT 1
- Colors.xml: use two levels of color definition HOT 4
- Always use Proguard (in debug too!) HOT 2
- Jackson link is dead :)
- Managing dependencies
- Лучшие практики на Андроид
- Can I learn Android Development in Java as a beginner? HOT 2
- Andrpid
- A
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from android-best-practices.