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:
- 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
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.
- 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.
- 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.
- 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
Yep, will do that. (although note that "_id_" or "_id" or whatever
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
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).