I maintain an open source Flickr app Glimmr for Android.  There is currently an architectural issue around pagination that I've been trying to solve for quite a while, and would appreciate ideas.Here are the components involved:Tasks - various subclasses of AsyncTask that fetch photos from sources such as a users photostream (LoadPhotoStreamTask), photoset (LoadPhotoSetTask), etc.PhotoGridFragment - a fragment that displays photos fetched by the Tasks in a grid.  Subclasses of this exist matching each task, e.g. PhotoStreamGridFragment, PhotoSetGridFragment, etc.  The grid is paginated, so that when the user scrolls to the end of the photos, the task is triggered to go and fetch the next page of photos.PhotoViewerActivity - responsible for displaying a list of photos from the grid in fullscreen.  This is started from the PhotoGridFragments with two pieces of info, a) the list of photos currently in the grid, and b) an index at which to start viewing at.The issue arises when the user reaches the end of the list from within the PhotoViewerActivity.  This activity does not have the info required to start the correct task and update the list of photo's it has been passed.I want to figure out a way of doing this while keeping the coupling between the PhotoGridFragment and PhotoViewerActivity as low as possible.  People who are familiar with Android will know that because we're dealing with two separate Activities, all communication between them must take place via Intents with data having to be persisted or serialised.  Afaik the PhotoViewerActivity can not easily call back to the Grid and ask for more photos.Things are complicated by the fact that each task requires different pieces of state and info to do it's work. e.g. a LoadPhotosetTask requires the set id, LoadPhotoStreamTask requires a specific userbut doesn't care about sets, etc.  So just passing the task name required to fetch more photos to the viewer activity isn't enough.Another solution could be to abstract the common pieces of functionality from the PhotoViewer into an abstract class, and then create specific photo viewers for each source, similar to the way we have specific PhotoGridFragments for each source.  This feels overkill, but is probably the solution at the front of my mind right now.How would you solve this?
Architectural problem for Activity communication in an Android app
java;architecture;android;coupling
Do you have a model/businscomponent/service that is responsible for managing the data? for me your description sounds as if your gui elements (activity/fragment) are doing the work.The usual way would be to have a model/businscomponent/service that handles the data and is used by different gui components.