[aerogear-dev] Client Paging Strawman
Summers Pittman
supittma at redhat.com
Mon Jan 14 20:02:36 EST 2013
On 01/14/2013 07:54 PM, Kris Borchers wrote:
> 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.
You've always been able to supply a name, just the name defaulted to the
class type if it wasn't supplied.
>
>>>> 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.
Correct, it is this way in Android as well
> 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.
Which is what I am arguing for. The system should encourage a Pipeline
to service a base URL and each Pipe to be a endpoint on that URL. By
keeping the paging config off of the Pipe itself you end up much closer
to this ideal (as I understand the ideal).
> 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 her!
> e and rambling? :)
Nope makes sense and it works this way. My concern is when you have a
pipe("cars"), pipe("redCars"), pipe("atMost10RedCars"), and
pipe("buildFromALinkToThe3rdPageOfRedCars").
>
>>> -- 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
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
More information about the aerogear-dev
mailing list