Newbie Architecture questions

[Sam Duke]

Hi there,

I've only just come across RoboSpice in the last day or so excuse any misunderstanding I may have but I had a couple of questions for the developers.

First off, I *really* like the architecture with the sound service idea. In fact, I recently explored this idea myself: https://github.com/samskiter/BoundServiceTest

You'll see I implemented a priority queue and dealt with the rotation problem too, but rather than reconnecting to existing requests when my Activity is recreated, I used a retained fragment to receive and buffer the completed results. The idea being that the bound service is only kept open whilst there is an interested party to receive results (I noticed methods like `stopIfNotBoundAndHasNoPendingRequests` that provide that functionality in RS) - basically, Android's binding system acts as a reference counter for this. It also decouples the Android Activity lifecycle from the network requests via the retained fragment.

As far as I can tell, the nature of the Activity lifecycle permeates right down into the queue manager and the cache, to the point that if my activity rotates, my listeners are first discarded from requests in the queue and if I later use addListenerIfPending, RS would issue a new request that uses aggregation with the old one to complete (I'm interested in how a race condition is dealt with where the old request finished before the new activity manages to call addListenerIfPending).

When it comes to reconnecting after a rotate, the 'tag' used to retrieve the retained fragment performs a similar function to the LinkedHashmap in the RequestProcessor.

Could a retained fragment approach potentially be applied to RoboSpice? I'm curious what difficulties this causes and what your considerations were (as I may or may not use the pattern in future). The advantages as I see it:

* cancellation after parties lose interest. I know that one of the important features of RS is to keep the request running even if I hit the back button, but sometimes this persistence may not be required. If I'm building the next youtube or chrome, I actually want to stop network IO when leaving an activity/fragment. Maybe if I care about the result after I leave, I actually use some model object to make the request and become a listener for its updates.

* related to the race condition above, if the answer is that RS relies on the cache to solve that problem then how can I retain a result across a rotation if i choose not to use the RS cache? Using a retained fragment as a buffer solves that. Its existence represents the 'unwritten' wider activity lifecycle.

* A minor point about habbits - as you are well aware, it's so easy to leak contexts through inner classes. RS uses this as it's core way to get information back into an activity and this might lead to users thinking its ok to start passing inner classes everywhere and then get into a real mess. Why is listener A (a subclass of RequestListener) OK, but listener B isn't? Why can't I reuse listener A?

I'm really interested to hear your thoughts on the pattern of retained fragments and I hope I didn't sound too critical - again, I think RS is awesome and I will very probably be using it in my next project and refactoring old projects to use it. Thanks for all your hard work!

Sam