[aerogear-dev] Android: some questions

[Glen Daniels]

Hey Matthias,

Thanks for taking a look at the prototype!

On 9/15/12 6:12 AM, Matthias Wessendorf wrote:
> I took a quick look at the Android API. Below are a few questions:
> 
> * AeroGear.java
> - Is the class 'just' a util, that offers static methods? If so,
> should have a private ctor and be final (since a private default ctor
> prevents inheritance anyways)

Yup, that's the intent, but since it's just a "sketch" I didn't put that
in - will do.

> - is the API_KEY really needed? Not sure, but I think that (the
> API_KEY) is _perhaps_ something on-top of a networking client lib,
> needed when entering the real 'BaaS' market, where our lib. is used
> against a (specific) 'backend provider'.

Right, I was pretty much following the common BaaS pattern.  It's
certainly not necessary immediately, but once we start supporting OAuth
we'll want something like that anyway, so I put it in as a placeholder.
 Easy to remove if we decide we don't want it for now.

> * Utils.java
> - related to the API_key, I think the X-AeroGear-Client header needs
> to be defined/discussed - but IMO the AeroGear client lib should work
> also without such a key, when accessing a simple JAX-RS (read:
> RestEasy) service; Of course, when 'cloud provider' start using our
> bits, something like API_KEY is a must.

+1

> - the 'delete' is public; the others (e.g. post) not...

No semantic significance there.  Should probably all be package access,
since AeroGear is the user-facing class.

> * Pipe.java
> - how to update an existing item?
> For instance in JS/iOS we use save which does an 'add' if there is no
> _id_ or issues an 'update' if the entity already exisits (e.g. has an
> _id_).

Yep, will do that.  (although note that "_id_" or "_id" or whatever we
use is another point of coupling ;) )

> There is no concept of a 'pipeline', but I guess (at least for now) on
> "Java" (aka Android) a typed list (e.g. List<Pipe> pipeline;) is good
> enough, right?
> But on the other hand, than it's up to the user of the api to 'manage'
> all the pipes (server connections).

Right.  What sort of "management" do you imagine, other than
factory-style creation?  Pipes as they stand are extremely "cheap"
objects (no db connections, network connections, threads, etc).

Best,
--Glen