There are a lot of discussions about whether you should use Activities
or Fragments
.
For example:
You are right. One could do alot with fragments alone. However, according to the Activity class, an activity is a single, focused thing that the user can do. I always tend to compartmentalize my application into activities at the top level and furthermore into fragments.
For example, here is a situation where multiple activities make sense. Our applications has a certain functionality that can be extended if the user logs in. However, the user might still use this limited functionality before signing in. Say, you can not comment on items except when you are logged in. In this case, our MainActivity might show the whole functionality. If the user wants to comment, we ask him to login by saving his request and starting an activity LoginActivity that handles login/registration and sets the right result when he is done. In our calling Fragment or Activity, we check if the result is LOGIN_SUCCESS or if the user is currently logged in and serve the pending request. What I am trying to say is that the action flow of Login should be a separate activity. Otherwise, handling would probably be messed up. In this way, any action that requires login can call startActivityForResult(LOGIN) and saves itself as a pendingAction. Then the after setting the result we could implement the handling in the super.onActivityResult. This is all theoretical of course, one could implement Login in a fragment with no trouble. However, the code will definitely turn up to be FUed.
Another situation where you need an Activity is when your activity provides an exported Service. For example, say you are a developer of a "File Uploader" and you receive intents to upload files. It is very convenient in this case to create an Activity that can consume requests of uploading a file.
Yet, with the current updates, Fragments' functionality span most of the features of android apps and therefore can be used alone with a single host activity to fulfill the requirements of an app.
However, your whole "a single activity host" with data there is rather a weak defense. Activities and closely Fragments has the whole lifecycle that include the save/restore instance via bundles. A single host activity can be long lasting and host multiple fragments that might be recycled multiple times in a single lifetime of their activity. It is therefore highly probable that an activity holding all these instances over time to exceed its budget of resources. It is the responsibility of the developer to keep data in a shared context when they are really shared among multiple objects. This is a drawback of this approach. It does not make sense in our example for the MainActivity to consume an extra byte of data because it hosted the Login fragments when it could have slept and freed its memory if needed.
In the end, a good programmer can manage to do the same task likewise.