[aerogear-dev] New Android Pipeline

[Daniel Passos]

2012/10/2 Glen Daniels <glen at thoughtcraft.com>

> Hi Passos,
>
> A few comments below.  I recognize that some of these things are derived
> from the JS implementation, which was the source for the iOS
> implementation - so some of these are questions about the the API in
> general as opposed to Android in particular.
>
> * I'm not sure I like creating an initial Pipe at Pipeline-creation
> time.  I guess this is meant as a shortcut, but in fact I think it
> confuses things.  Since we need a line of code to get the Pipe anyway,
> I'd rather it be consistent and look like this:
>
> Pipeline pipeline = new Pipeline(baseURL);
> Pipe<Task> tasks = pipeline.add("tasks", Task[].class);
> Pipe<Tag> tags = pipeline.add("tags", Tag[].class);
>

I'm not sure too, If create a pipe with a pipeline is the best option for
this. If you consider the legibility, is an ugly way to search for a thing
you' ve created, but i thinking if make sense create a pipeline without
pipe.

...rather than special-casing the first "tasks" pipe and using
> pipeline.get("tasks") to retrieve it.
>
> * Another consistency/symmetry issue (ah, I just read Marko's comments
> and I see he mentions the same thing): I think it's odd that get() and
> post() in HttpRestProvider can't take id arguments, and therefore must
> always work at the collection, as opposed to the individual resource
> level.  Simply adding overloads with an id argument would solve this I
> think, but maybe better to always require the id argument and allow null
> to access the collection.
>
> * HttpRestProvider again: the post() method at least (and perhaps also
> put/delete) should probably return a value so we can get server data
> back to the caller if appropriate.
>

I see your point and is a good idea.


> * I'm not quite sure I understand why we need the HttpProvider interface
> at all.  What other implementations of this (that aren't
> HttpRestProvider) are there going to be?  We could get rid of it and
> just bake HTTP functionality into RestAdapter directly, no?
>

I create that imagining a decloupe for in the future, test the adapter with
mock/stubs provider

* We should discuss testing + mocking and write down some common tools +
> patterns.
>
> That's it for the moment...  I'm in Chicago on the way home to Boston
> right now, and will be tuned back in on Wednesday afternoon.  I'll try
> to write up some more Android thoughts at that point, specifically about
> the Android-specific surface area of AeroGear.
>
> Time to catch my last plane!
>
> Best,
> --Glen
>
> On 10/2/12 7:12 AM, Daniel Passos wrote:
> > Hi guys
> >
> > I did some changes in the android library based on iOS stuff, it's
> > closer to the pipeline adapter implementation. I would appreciate
> > feedback and review.
> >
> > https://github.com/aerogear/aerogear-android/pull/1
> > https://github.com/aerogear/aerogear-android-todo/pull/1
> >
> > Thanks,
> > Passos
> >
> >
> > _______________________________________________
> > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20121003/3850ca20/attachment.html