Develop Reference

Android: Reduce BackStack memory usage

I'm creating an app that takes the user through a fairly long, linear, process of data capturing. Each activity leads to a new one for a new topic for which the data needs to be entered. The problem is that some of the activities have many or large bitmaps, or many imageButtons. When the user goes to the next activity, the current one is placed one the backstack and the memory does not get cleaned up.
I am considering calling 'finish()' when the user goes to the next activity and then overriding 'onBackPressed()' to recreate the previous activity if the user needs to go back and change a value there. Is there any better suggestions than to do this?

The solution you consider is certainly on the right track.
My only addition to that (recreating the activities when you need to go back to them) is that you don't necessarily need many activities.
From what I understand you need many layouts, each with its relevant resources. What I'd do is:
create your Stage data class, holing a layout, bitmap id's, etc
create a List<Stage> with the full story
create one activity that knows how to display a stage from the list, and traverse to other stages. Here you can override the back button to act as stage traversal.
Check out The Transitions Framework to see how you can animate views when traversing between the above stages. If you use the same id for at least some of your views - they will move around independently, while other views will fade out or in.

Multiple instances of an Activity - is this bad practice?

I am creating an app which will have multiple 'grids' containing a title and image thumbnails in each grid square.
Each Grid will have different content stored in it.
I have so far created one activity that initialises an instance of GridView, and uses a custom GridAdapter. (See photo for what it currently looks like) I was planning to swipe left to create a new empty grid in which the user can upload content. There may be anywhere up to 50 grids.
I'm just learning how to implement the gesture, and how to create a new instance of the activity, but from what I've read, I am thinking I have designed it badly.
I was planning for each grid to be an Activity (each takes up the full screen).
I envisaged an Activity as being like a Class in java that you can create instances from a blueprint. I thought if I created one 'Grid' I could create a new instance of it each time. Fragments didn't seem appropriate at the time, as the android tutorials often described them as being purposed to add components to activities.
I'm starting to think though that I am using the wrong methodology here and I need to change it? Can someone guide me in the right direction? I have written all the code already - if I need to change it, do Fragments and Activities share any methods, meaning I can retain some work?

Like you mentioned, using activities for holding content in your use case where switching may be triggered using gestures will definitely be resource heavy and cumbersome. Since, you mentioned swipe gestures, I believe fragments would be much lightweight in this situation. In fact, I would suggest you even look at ViewPager which even recycles fragments for you and optimizes user experience by loading the next fragment for a smoother experience. It will also handle swipe gestures for you!
[UPDATE]
Based on your updated explanation of the user flow, I'm certain that the ViewPager would fare as a better option mainly because it allows for a much better control and user navigation. It will also take care of handling swipe gestures and memory issues that come with these types of flows. Moreover, it will even allow for a page titles and bottom tab indicators in case you need them.
It will require each of its pages to be a fragment (your ViewPager will itself reside in an Activity). Once the user clicks on a grid cell, you can show a dialog window from where user input can be captured. This setup should be optimal for you resource wise in my opinion.

Android Fragments: Sharing Code with Dual UIs (stack-of-cards phone and side-by-side tablet)

I have a typical dual UI scenario - a list of categories, which when one is clicked, loads a category detail fragment containing a list of items in that category. On the phone, it's implemented as a stack-of-cards UI, opening up the details in a separate activity on top of the category list. On a tablet, it's the category list on the left, with the details on the right.
In the details pane, there's a button to add an item. The details fragment has an interface, required of Activities, with an onClickAddItem method, which should bring up a DialogFragment to ask you for the details of the item and add it when it returns.
The problem: both the tablet version's all-in-one Activity and the phone's standalone details Activity need the same onClickAddItem logic. There's a sinking feeling deep in my gut that the proper solution for this is to pull that logic out into yet another class, but the need to create several million files to do simple things in Android is slowly driving me insane, so I'm hoping there's another best practice I'm overlooking here. Thanks!

If your "add" button is in the detail fragment, there is no reason to handle the click event in the activity.
I think you should put the click event handling in your detail fragment.
Why do you want to keep all database access in the activity ? Make sure you're properly abstracting database access ( using a ContentProvider for example ) and don't be shy to use your abstraction wherever it makes sense. Adding an item using a ContentProvider should be as simple as:
getContentResolver().insert(myUri, myNewItemContentValues);
It you need to display a dialog, just get a reference to the current activity from the detail fragment, and use it to display your dialog.
If several fragments share the same functionality, you may need to write a simple helper class with some methods like:
public void showAddItemDialog(Activity activity)

What parts of an Android app should be fragments?

I am going to develop an app with the following structure:
Search: Lets user search for articles and displays search results in a list
Article: Displays an article
UserList: Displays a list of articles the user has chosen to add to the list
UserListItem: An item that represents an article in the list mentioned above, and lets the user add custom information via some EditText-fields.
The Search, Article and UserList seem like they could be implemented as fragments. But what about the UserListItem? There will of course be multiple UserListItems on the screen at the same time, could it still be implemented as a fragment? If not, how should it be implemented?
I'm having some trouble grasping the whole fragment concept. It seems obvious how to use it in the standard scenario, i.e. Search-pane and Article-pane. But it's a bit unclear to me if it should/could be used in a scenario where you will have multiple instances of the same fragment displaying at the same time.
I haven't yet written any code, because I want to have the overall structure clear before I start, so I don't have to go back and change everything.

This might be a bit much if you are a beginner, but if you want to add searching capabilities in your application, consider creating a search interface.
From the documentation on Fragments:
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).
That being said, there is a huge difference between incorporating a behavior in your screen's layout and wrapping that behavior in a Fragment. In your case, it really wouldn't make sense to wrap each list item in a Fragment as it would be ridiculously inefficient to instantiate a new Fragment for each item in your ListView. Representing each list item as a Fragment would give each row its own lifecycle, which is obviously not what you want. What you probably want to do instead is represent each list item in XML, and have the Fragment (or Activity) that holds your ListView manage these list items as necessary.

Converting Multiple Activites into a Single Fragment

I've recently decided to update my app to support the new fragments feature in honeycomb 3.0.
My Application currently works on a list view that opens different activities depending on which list item is clicked.
Using an adaptation of the code in this tutorial I have created an app that consists of only two activities, but depending on which list item is clicked the second "viewer" activity launches using a different layout xml.
Unfortunately I haven't been able to figure out how to call the old methods that had all the functionality. Should I Import all of my old activities and then call the methods into the viewer activity (I may need some advice on how exactly to do this) or should I just put all the methods directly into the same viewer activity (please consider the size of these methods(which is very large by the way)).
Once everything is working with two activities upfront then it will be a pretty simple task of "fragmenting" the app as demonstrated here
Although I haven't considered that there might be a way to allow multiple fragments to occupy the same space in an activity(If this is the case then please let me know how it's done)
Thanks

As James has pointed out you will have to move the business logic from your Activities to your Fragments.
To handle events you can create a listener Interface. The CONTAINER activity/ies will implement this interface. As fragments has access to the container activity you will be able to delegate to the container Activity the "logic" for the desired events. For this events the activity will decide whether to launch a new activity, show/hide new fragments or whatever.
I had a similar question, take a look to the question and answer: here
Although I haven't considered that there might be a way to allow multiple fragments to occupy the same space in an activity(If this is the case then please let me know how it's done)
I think its possible to allow multiple fragments to occupy the same space in an activity. Again, take a look to the answer here ... I think the concept/scope of Activity has change a bit and now an Activity can contain different Fragments which every one will allow user to do a single focused thing.

I'm not sure what you mean by "call the old methods that had all the functionality". You'll want to rewrite all of your activity classes as fragments. Check out this tutorial here (it's very concise). Basically, you'll want an activity that consists of a ListFragment and a FrameLayout. Your ListFragment will update the FrameLayout by changing to the appropriate Fragment based on which row was selected.