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:

  1. Tasks - various subclasses of AsyncTask that fetch photos from sources such as a users photostream (LoadPhotoStreamTask), photoset (LoadPhotoSetTask), etc.

  2. 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.

  3. 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 user but 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?

  • 1
    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. – k3b Mar 17 '14 at 17:51
  • You could either put you data and task referrence in the custom application which will be callable from fragment and activity or (but not so good) create a singleton which manages it – A.S. Mar 17 '14 at 22:00
  • @k3b Not a bad observation. I'll try moving my data into a dedicated model component and see if that eases communication between the grid(s) and viewer. – brk3 Mar 18 '14 at 19:56
  • @k3b I'm actually reasonably happy your tip has put me on the right track so if you want to put it below as an answer I'll mark the question solved. Thanks also A.S. for similar input, much appreciated. – brk3 Mar 20 '14 at 21:28
  • @brk3: would you post an answer with a little more detailed information about the architectural design you ended up using? – outis Jan 11 '19 at 23:48

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.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.