Develop Reference

How to model cross fragment transaction (ongoing process) in Android MVVM application?

I am developing an app that has some ongoing process that almost all screens depend on.
Let's call it ActiveTransaction. So, one fragment prepares items, the other fragment prepares payment, another adds discounts, etc... If one part fails, everything needs to rollback.
So, basically, I need to achieve atomicity across multiple fragments. I've tried to use shared ViewModel for this, but since each fragment adds its own stuff, that shared ViewModel has become too big.
So, I wonder what would be the best way to handle those processes that stretch over multiple fragments.
Should I have perhaps a singleton object ActiveTransaction that is injected in each viewModel?
Is this maybe what other technologies call the app State?
I haven't found anything in the MVVM architecture guidelines.

You can create Tabbed Activity - blank Activity with tabs. New project -> Tabbed Activity.
You will have one activity and multiple fragments.
So all functionality will be in MainActivity. Your fragments will contain views, which will call methods from MainActivity. All objects and calculations will be in main activity, so if it fails (because of memory lack), everything will collapse too.
For Example:
You have one Tabbed activity MainActivity and 3 fragments: Item Fragment, PaymentFragment and DiscountFragment. MainActivity contains multiple methods, let's say prepareItems(), preparePayment(), addDiscount(). User can go through Tabs, opening fragments. MainActivity methods can be called only via fragments. So if MainActivity collapses, the whole process will collapse.
So you will achieve atomicity and user can see changes by going through tabs. You can replace Tabs Activity by other scenario with single activity and multiple fragments which don't have functionality but contain views which will call methods from MainActivity

Android ViewPager with Fragments

I have an App using ViewPager which has 3 tabs. I need each tab to contain a navigation stack of fragments e.g. I have a list on the first fragment which will then display a detail fragment based on clicking an item. What is the best way to design this? At the moment, I have one MainActivity which replaces the Fragments within each tab but as I'm adding more fragments within each tab, the MainActivity will just become huge. Can I handle all of this within the fragments themselves?

I think what you are looking for is a tabhost with backstack. This makes use of a TabHost, and is not the same as using a ViewPager with tabs. But that solution on Github is a very good one.
Also, this will not make your MainActivity "huge", because all the Fragments can be defined as separate classes in their own class files. Fragments are supposed to represent more modular UI blocks.

What are the advantages of creating a Fragment vs Extending a View or ViewGroup?

We recently converted an app from a multiple activity based one, to one with a single activity with multiple fragments. The activities that became Fragments used to contain fragments themselves, so we use child fragment managers to host the Fragments in the Fragments (these child fragments I should add, are small and there can be 4 or 5 these on the screen at one time).
This has caused a few issues, namely having to create, and keep track of Unique IDs for the Fragment holders. (Which cause headaches when dealing with the Backstack as well as if any are in any sort of AdapterViews).
We're thinking of just rewriting these components to extend some sort of ViewGroup, likely FrameLayout or LinearLayout. We already do that anyway in some cases, but I was wondering if there are any disadvantages to doing it that way? (I must admit, I don't really see the big deal about Fragments... anything you can do with Fragments, you can do by creating a Custom View. Is this wrong?).

This is a bit of a reverse answer, explaining fragment use. In general you can do most things with Activities, but as the SDK supports fragments, many things will become more cumbersome (ViewPager is an example where fragment use is great).
The advantages (of fragments): code encapsulation, reusable chunks of UI.
The disadvantages (of fragments): more code (e.g. FragmentManager, FragmentTransaction).
Your original use of activities was good, it's not a case where I would have switched to fragments.
Let's say I designed a mobile phone app with two activities: ContactList and ContactDetails. So far so good, no reason to use fragments yet. If I wanted to support a larger device, it would behoove me to display both screens side by side. This is where fragments come in handy. In terms of exactly how to structure your activities/fragments, there's some good advice here:
https://developer.android.com/guide/practices/tablets-and-handsets.html#Fragments
Here are the important bits:
Multiple fragments, one activity:
Use one activity regardless of the
device size, but decide at runtime whether to combine fragments in the
layout (to create a multiple-pane design) or swap fragments (to create
a single-pane design).
Or...
Multiple fragments, multiple activities:
On a tablet, place multiple fragments in one activity; on a handset,
use separate activities to host each fragment. For example, when the
tablet design uses two fragments in an activity, use the same activity
for handsets, but supply an alternative layout that includes just the
first fragment. When running on a handset and you need to switch
fragments (such as when the user selects an item), start another
activity that hosts the second fragment.
.
The approach you choose
depends on your design and personal preferences. The first option (one
activity; swapping fragments) requires that you determine the screen
size at runtime and dynamically add each fragment as
appropriate—rather than declare the fragments in your activity's XML
layout—because you cannot remove a fragment from an activity if it's
been declared in the XML layout. When using the first technique, you
might also need to update the action bar each time the fragments
change, depending on what actions or navigation modes are available
for each fragment. In some cases, these factors might not affect your
design, so using one activity and swapping fragments might work well
(especially if your tablet design requires that you add fragments
dynamically anyway). Other times, however, dynamically swapping
fragments for your handset design can make your code more complicated,
because you must manage all the fragment combinations in the
activity's code (rather than use alternative layout resources to
define fragment combinations) and manage the back stack of fragments
yourself (rather than allow the normal activity stack to handle
back-navigation).

When to use activities or fragments

My App (minimum API 14) uses an ActionBar with 3 tabs.
The tabs are:
i. enter data (approx 10 fragments)
ii. manage data (15 fragments)
iii. view data (8 fragments).
Each tab has a default fragment, but then has multiple fragments depending on user choices.
I would like the user to be able to swipe between the 3 tabs (by swiping the content) hence I need to use ViewPager and the compatibility library v4.
The advice I have picked up (after much research) is to use a MainActivity which hosts the ActionBar and tabs with fragments for the tab contents. But I'm worried about the number of fragments. Also some of the fragments need to use date and time pickers which means DialogFragments coming out of fragments. It's starting to get very complicated.
Does anyone see any problem with my using Activities instead of fragments for the tab contents?

Fragments act on the UI side just like activities except you can combine multiple together. So you don't need to create a different fragment based on user choices, you just need to change the fragment just like how you would change an activity dynamically.
Also if you want to use ViewPager, you are basically forced into using fragments.
The nice thing about fragments is that they are reusable, so most likely you only need a few fragments and then you can combine them in different ways for the different use cases. This also makes your tablet UI a lot easier to create.
For reference: http://developer.android.com/guide/components/fragments.html

Using Fragments to switch activities

I'm trying to create a layout that has a stationary footer with activities that slide behind it. I've been told to use Fragments, but that would mean that I would have to convert my already existing Activities to Fragments - right? Here is a diagram of what I'm trying to achieve: http://i.imgur.com/K8Iao.jpg

What I think #TarunMaheshwari is trying to say is that instead of having 3 activities (eg. classes with extends activity), replace it with extends fragment (obviously there are other minor changes you might have to make for the code to work) and then create a main activity (with extends FragmentActivity) that has the static footer you want which can call on the 3 different fragments.
Recommended readings:
http://developer.android.com/guide/topics/fundamentals/fragments.html
http://android-developers.blogspot.ca/2011/02/android-30-fragments-api.html

I believe using fragments is the right solution for your app. However, from what I understand from your question and comments, you really want to avoid using them. To use activities instead of fragments, implement a Tab Layout with a Tab Host and Tab Widget as explained in this tutorial. This solution allows you to use the tabs to switch between activities.
To align the Tab Host to the bottom of the screen, have a look at this tutorial.