[aerogear-dev] Client Paging Strawman

[Kris Borchers]

On Jan 14, 2013, at 6:43 PM, Summers Pittman <supittma at redhat.com> wrote:

> On 01/14/2013 04:26 PM, Douglas Campos wrote:
>> On 14/01/2013, at 18:11, Summers Pittman <supittma at redhat.com> wrote:
>> 
>>>> Hmm, so you only create the pipes at app initialization? Looks like I was missing the android lifecycle.
>>> You can create one any time you like, but either a) each configuration
>>> would overwrite the old pipe in Pipeline or b) you would have obnoxious
>>> naming conventions.
>> I'm not following the naming conventions part, mind to elaborate?
> I suppose it just means you have to supply a name attribute to your 
> PipeConfig.  What this means is that the name of the pipe stops being 
> the type of the pipe(which is our default) and starts being the role of 
> the pipe (which is a rather new concept).

JS, and I believe iOS, both supply a name attribute in our configs so this would bring Android in line with the other libs in that area.

>> 
>>> As a less contrived example, you may have a background process updating
>>> cached data and a foreground process querying data.  For instance your
>>> background thread was downloading all of the cars but you only want to
>>> see five red cards.  It makes sense for Pipeline.get("car") to be used
>>> by both threads.
>> And this is the place where we disagree - I would go straight to make sure that background stuff have its own pipe instances ;)
> I've been trying to keep the pipe's methods threadsafe by minimizing 
> mutable and shared state.  (PageContext is an exception, but WeakHashMap 
> explicitly uses the instance of the object for lookups and not the hash 
> code).  While I do this there is (as far as my biased POV can see) no 
> good reason to have a single endpoint serviced by multiple RestAdapter 
> instances.  I would like to keep doing things this way, but if it really 
> breaks the feel of a different language I can be flexible.

I think this harkens back to the beginning of the Android library and the confusion over Pipeline vs pipe. Again, I'm using JS as an example but I believe iOS is the same way but in JS, a Pipeline is little more than a factory for pipes. A single Pipeline can have multiple pipes and in fact, in the JS lib, it is encouraged. That way all of your pipes (read interactions with a single endpoint) are contained in the same Pipeline. This does not mean that a single endpoint would be serviced by multiple adapter instances, what this means is that a single Pipeline would contain every pipe to each endpoint of a particular service. This way, you could have one Pipeline containing all of the pipes to your app's backend, and in the same app, another Pipeline with a set of pipes meant to interact with Twitter and another for pulling in an RSS feed of blog posts. It gives some logical organization to the app. Does that make sense? Does Android work that way at all? Am I just way off here and rambling? :)

> 
>> 
>> -- qmx
>> 
>> 
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> 
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev