[aerogear-dev] New Android Pipeline

[Kris Borchers]

On Oct 3, 2012, at 7:29 AM, Daniel Passos <daniel at passos.me> wrote:

> 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.

Sorry if I wasn't clear in my examples or usage but in JS, it is completely possible to create a pipeline without an initial pipe and then add them when you need them.

Ex.

// Create pipeline
var x = aerogear.pipeline();
// Add Pipe
x.add( "test" );

// Use the pipe
var testPipe = x.pipes.test;
testPipe.read(…);

OR

x.pipes.test.read(…);

> 
> ...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
> 
> _______________________________________________
> 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/905a12bf/attachment.html