I’ll do my best to describe the problem, but I’m still very new to several concepts that I think this problem requires to be solved (namely interfaces and threads). I should preface this by saying that I’m obviously not a Comp Sci major (as you’ll see). I’ve learned as I’ve built my App, therefore my theory is terrible.

My App works as follows: I have a Workout object which is contained in an Activity, which also contains a few UI Fragments. The UI Fragments accept input from the user, Then call methods in the Activity, which then manipulate the object.

After the user finishes inputting their details, the Workout object (Which is a HashMap), gets serialized and passed to the next Activity via Bundle, then deserialized. This generally loses the order in which the user adds exercises to the Workout Object, which is important to maintain. Using LinkedHashMap doesn’t work either, as it is bugged when it comes to serialization (It deserializes as a normal HashMap, verified with Eclipse debugger). This whole process happens again when the user wants to save the Workout, as the Workout gets Bundled once again and passed to a Fragment. In other words, the Object is stored, manipulated, and accessed, in the same place as where I handle user input events. This strikes me as terrible practice.

Here’s what I think I should do:
Have one Fragment, which contains the Workout Object and runs in the background. It would also be accessible by every Activity which requires the Workout Object, and would communicate with the Fragments and activities via Interface, as follows:

                                [Background Fragment]
                                /                   
                               /                     
                      (Activity 1)                (Activity 2)
                        /                        /        
                 [UI Frag]     [UI Frag]    [UI Frag]    [UI Frag]

This solves the issue of having to pass the Workout object around like the only Joint at a Ziggi Marley concert, and the only time it will need to be serialized is when onSaveInstanceState() is called, if I’m not mistaken. This strikes me as better practice.

Does this sound like a reasonable approach for the Data flow of my App?

Although every extra detail you can give me will save me a lot of time, a Yes or No followed by a brief Why would definitely help.

This is more of a bonus question, as I’m fully willing to sort this out through the brute force method, (try things until something works), but:

Given Android’s penchant for killing background processes, what implementation would work best for maintaining and manipulating the proposed Background Fragment?

I have a hunch that having this Fragment running on a separate thread might be a good idea, but I know very little about them as of yet. Again, this Fragment needs to be accessible by more than one Activity, pretty much at any time.