Develop Reference

When and how to prevent a god activity in Android

I know this question might not be one which has just one correct answer. But letting me know, that there are several solutions with good reasons for each of them, would already help a lot. So here we go:
I have designed an app which manages persons along with measurement data for each person. The data can be displayed in a chart. Generally this leads to the following tasks:
Person: Add
Person: View
Person: Edit
Person: Delete (more an option with a security dialog than a real screen)
Measurements: View (List)
Measurement: Add
Measurement: Delete (again more an option with a security dialog)
Measurements: Plot (in a large graph view)
The app will run on a phone at first. I have read that an activity is supposed to serve a very limited purpose, so the scenario would lead to one activity for each task.
However, when the app is displayed on a tablet in landscape mode, I can imagine to have three sections on the screen at once:
One section in the top right cornern managing persons
One section below that listing the values for the selected person
One larger section on the right part of the screen to plot measurements
I often read that I should avoid to create god activities. On the other hand I read that fragments is the way to go, so that each screen can easily be displayed as a subscreen on a tablet, as it is planned here.
I started off with creating the app for mobile phones, so I created one activity, which juggles all fragments (almost one for each task) in a single fragment container.
Is this the way to go, when I want to do it by the book?
I was wondering whether I should create a separate activity for each task. For the phone this makes things easier. But on a tablet I would have to control the fragments from one single activity anyway, correct? So in that case a god activity it needs to be?

You are definitely on the right track, but there are some things you may want to look into.
In my opinion Activities should only be used to host Fragments and transfer events between Fragments. Basically, the only logic that you should have in your Activity is handling the navigation. The logic stays in the Fragments (or some other layer, used by your Fragments) and it is not exposed to the Activity at all. In that way there will be no need to duplicate any logic and make some Activity a "God" Activity.

Good that you started thinking about it. You should always prevent god activity. Read about MVC, MVP & android architecture patterns which help you avoid creating a god object.

Proper usage for Activities in Android

From what I understand, and activity is equivalent to a "page" in a web app.
For example, the list view would be one activity, edit view another activity, and add view a third activity.
While this works as expected, android activities seem to operate as individual apps--the action bar is different for each activity and so are the menus.
Is my usage of activities above correct or should I be using some other mechanism such as swapping out layouts and views?

Fragments are a core part of activities - not that much different. The use of fragments comes since Honeycomb 3.0 and the idea is an option to split the screen in several fragments at once. For example if you look at the gmail app for a tablet - you have one fragment on the left dealing with navigation and then the next fragment on the right is the list of emails.
On a mobile device, viewing area is limited, so you it could be said that fragments sort of behave like an activity - you interact with one fragment, which triggers another and so on and so fort. But in the end you always reference a super activity of each of these fragments - for example when you want to access the context.
So if you just want to wrap web pages in WebViews, stick with activities. If your scenario might involve developing for both tablets and phones, then go for the fragments.
Alternatively, you can read about the design philosophies of both here:
http://developer.android.com/guide/components/fragments.html
Good luck!

Fragments are to be used when you have common feature across multiple activities. From my perspective you should use individual activities as there will be back-end code to support (fetch and validate data, i.e. business logic). This way you have more modular code. Fragments is a new feature from v3.0.

From what I know, Fragments would be a good option to be able use different configurations/real estates on different devices. For example, if you are on a device with big real estate like Tablets or TVs you can display more content in a single activity, on the other hand for a devices with smaller real estate you can show content based on a progressive manner.
See this: http://developer.android.com/training/multiscreen/adaptui.html
Note that Fragments are supported only on devices running Android 3.0, so you might have to use Support Fragments (See: https://stackoverflow.com/a/6528757/713778)
But Again it depends on your specific needs. I am not sure what your exact use case is, but I would suggest you to watch some Android design in Action for some examples to improve your design and make your app "User Centric" (See: https://www.youtube.com/playlist?list=PLWz5rJ2EKKc8j2B95zGMb8muZvrIy-wcF)
I recently came across this https://www.youtube.com/playlist?list=PLWz5rJ2EKKc-riD21lnOjVYBqSkNII3_k seems provide an in-depth analysis on User Experience.

I would recommend using fragment for web like views. Fragments are pretty snappy compared to activities and reusable.
But before you start, make sure to fragments are good fit for your requirements since they are supported from android 3.0.
You can declare fragments from xml itself or you can create frame layout and add that view in the code itself.
http://www.c-sharpcorner.com/UploadFile/2fd686/fragments/
The above link has a good example tabhost.

Activities and fragments for Android Tablets and Handsets

I’m in the process of implementing a new version of an app and want it to move towards using fragments and thereby enabling it to be used on tablet devices.
I have read several approaches (e.g. How many Activities vs Fragments?) and the guidelines on developer.android.com (http://developer.android.com/guide/practices/tablets-and-handsets.html).
The Android Guide aims for one monolithic Activity for Tablets that deals with replacing fragments as needed whereas the handheld version does it by using multiple activities.
See example: http://developer.android.com/images/fundamentals/fragments.png
Why are these two approaches not combined?
Let’s say FragmentA from the above image is the menu of my application where I can select a different aspect and FragmentB is the corresponding Content for the selected item.
Tablet devices
If my application can be separated into different aspects that correspond to the items in the menu, wouldn’t it make more sense to encapsulate the functionality behind each menu item inside a different Activity instead of using one monolithic one?
Selecting an item in the menu would exchange Activity A by ActivityB/C/D/E. Whereas those are configured in the same way, in the sense that is has a menuFragment on the left and its content fragment on the right. Interactions in the contentFragment would replace it with different fragments and so on. But the functionality would be covered by the specific Activity that holds it. So I would not have one monolithic Activity, but smaller and more specific ones.
Handheld devices
Similar to the above, instead of using a different activity per ”screen” I could reuse ActivityA/B/C/D/E and their contentFragment in a singlePane-Layout by replacing it accordingly by specifying the singlePane-layout for handheld devices. One Activity manages one task with several fragments.
So I would end up with the same number of Activities for tablets and handheld devices that are configured the way to handle both cases a bit different. Activities would be neither gigantic and full of logic nor totally dumbed down, but somewhere in between.
Is there something wrong with this approach?
I’m currently thinking about how to move forward and this approach seems reasonable to me, but maybe there are things I have not considered that make it not the best choice.

Why should I use fragment in Android?

For very long time, I think what is the reason of using fragment in Android if I just develop the application for Android Phone only but not 10.1.
Is it necessary to use fragment? Also, what is the usage of fragment,
I found that it may use for 'tab' and 'separate view'...
I really think it is very confusing. Can anyone explain briefly and give example?

From documentation
You can think of a fragment as a modular section of an activity, which
has its own lifecycle, receives its own input events, and which you
can add or remove while the activity is running (sort of like a "sub
activity" that you can reuse in different activities).
Some advantages are..
A particular UI part, once done in fragment, can be reused in
same/different activities.
You can separate different sections of UI, hence code will be neat,
and easy readable.
The ability of fragment to be able to reuse is very helpful when you are creating applications for different kind of android devices (phones, tablets). A well designed fragment can be just plugged into your UI hierarchy.

Fragments is a new concept introduced in 3.0 version.
The basic purpose of fragments is:
Fragments are designed to use the device UI space efficiently.
When you are writing an application in android, then some people can download it into phone, some into tablets. If you see the space in tablets it will be little bigger than phones. You should be able to use that space efficiently. But you can't keep writing different applications one targeting for phone, and other targeting for tablets. In order to do it efficiently, i.e writing only application that can fit well with all screen sizes, we use fragments concept.
fragments are designed as a reusable UI components between more than one activity.
Once you design a fragment, you can view it as a detachable independent unit, so that you can plug it into any activity where ever there is a space. That means you can reuse the code designed for a fragment.
Fragment you can think of it like a sub activity, which sits with in an activity and which contributes its own UI to the activity screen.
Fragments are always part of an activity. With out an activity, a fragment will not exist. So your fragment life cycle will always be affected by activity life cycle.
An activity can contain more than one fragment. Similarly a fragment can be re used in multiple activities.

If you use Fragment in your application, your apps will support all the device like small device, tablet and even google TV. In one .apk file, we will have different design for various devices.
This is the best Android tutorial that I've ever found. Section 21 covers fragments
Refer Here

What is the fundamental difference between Activities and simple forms in Android?

I'm pretty much new to Android, but over the last two or three weeks I've managed to figure out most of its innards and how things work.
However, one thing is still bothering me - what's the basic difference between Activities and simple forms? Well, I know Android doesn't have such thing as a 'form', but by that I mean a fullscreen layout of elements that has an underlying class and all its functionality is executed in it, rather than in a process-wide class (Activity, to be precise).
As long as I understand, Activity is a separate process that's instantiated by OS to perform some actions that are basicly independent of the whole application. That also means that we can run only one of the application's activities, and it will still perform all of its functions without needing the whole application to be loaded. For example, if we have a movie player that can also convert movies from one codec to another, we can implement that functionality as a separate Activity so that other applications, like file managers, will also be able to convert movies between codecs using only that Activity, and not the whole application.
And that seems perfectly straightforward. The question is - why is everybody using separate Activities for functionality that cannot be separated from the application? In other words, people generally use Activities where I think simple forms within the same process would be more appropriate. For instance, I've seen people using a separate Activity for things like application settings, which obviously wouldn't be be launched outside the app itself, or editing application-specific data, which wouldn't be done outside the app as well, since the data to be edited should be selected from a list only known to the application.
Another example right from my experience - a unit converter application. It has a main menu with a GridView of units' categories, in each category there is a list of units and by clicking any unit we have a 'calculator' form for entering value that we want to convert. If I'd been doing that like everyone suggests I'd have three Activities - one for the main menu, one for the list of units and one for entering the value. But why? Why would I want to launch any of those three Activities separate from the application? If I'd want to launch main menu Activity - well, why not launch the whole application then? If I want just a list of units - again, just launch the whole application, it's not like some Facebook client is going to convert values between pressure units (since the list of units covers only one category at a time). And launching an activity for the calculator simply would not work, since it should return to the list to perform conversions and you'd have no list activity launched.
And anyway, even if I'm wrong and people use it wisely there's still an issue that Android SDK doesn't really provide any support for forms as I'm used to. Yes, there are things like ViewAnimator, ViewSwitcher etc. But all they do is switch layouts in their place, and that is hardly switching between forms as such. So the only choice to get close to that functionality at least is to use Activities. And we're back to the square one.
So to put it simply - am I missing something from the Android philosophy? Because I'm pretty sure that using a separate Activity (and a separate process as a result) for every single form in the application is an overkill. And if it really is and everybody knows that - why doesn't Android have any substantial form switching mechanism?
Thanks in advance for any clarification on this issue.

An activity isn't spawned in a separate process (unless you explicitly tell it to). Everything in your APK will be spawned in your process. Even if another application is using your Activity for whatever reason.
You can make your Activity "effectively" private to your application by not assigning any intent-filter to it in your manifest.
For the examples given, a form is equal to an activity. That isn't a universal statement as you delve deeper into Android, but for a beginner that's a decent analogy to make. Another common analogy is that Activities are more like web pages than traditional forms based UI.