labas.blogg.se

This is exceedingly important in large apps. Take a look at the Email app source for example.

We also see activities being used as a way to add logical flow to an application. This may be a good idea if you have more than one Fragment which is supposed to display the same data. We also see a lot of code for retrieving data and manipulating data before it is handed over to a Fragment. The reason for this is that having a central point to control those will save you a lot of headache later. Everyone knows that Fragments are supposed to communicate with each other through the Activity. We also see that a lot of logic for managing the menu items and the action bar is in the Activity. So, what are some of the insights? The first thing we see is that Activities are still alive and well and not just a zombie container for Fragments. The reason for this is that Fragments were introduced in API 11 and there is a lot of code that was added before that or soon after that which may not use Fragments. The second area where we can get an idea of what Android best practices are, is by looking at some of the code templates generated code by the Android Studio IDE. Do look at the date when you look at some of this example code. The best insights we have as to what Google recommends is firstly, by looking at Android code samples by Google. However, I'm pretty sure that's not really how it's meant to read. If you read the " Design Philosophy" behind a Fragment, it certainly seems to imply that unless you want to create a bad app, you should be using a fragment. That begs the question: When should we use Fragments and when should we not? That being said, those same IDE's can also create blank projects without Fragments so it is largely the programmer's choice what they want. Some out there would point out that this may be because IDE's now generate a lot of this code for you, so you can start with an empty project that the IDE sets up for you with a Fragment. Yet, people go through the trouble of creating a Fragment or conversely, do not create a Fragment when there is a lot of code. Mostly because when making a demo app, nothing really matters other than showing how the library or feature works. Demo apps are a rather interesting barometer for these things. Indeed this is reflected in the code I see out there, not just professionally, but also in various open source libraries and their demo apps. Fragments are awesome and I use them blindly.This seems like a rather simple topic to talk about, however, in general, people seem to fall into one of two camps.