On Jan 14, 2013, at 6:43 PM, Summers Pittman <supittma(a)redhat.com> wrote:
On 01/14/2013 04:26 PM, Douglas Campos wrote:
> On 14/01/2013, at 18:11, Summers Pittman <supittma(a)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(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev