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

2012/10/2 Glen Daniels <glen@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@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>

_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev

_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev