[aerogear-dev] Android: some questions

[Kris Borchers]

Agreed, which is why I tried to stay general with recordID. :)

On Sep 17, 2012, at 6:26 AM, Matthias Wessendorf <matzew at apache.org> wrote:

> :) I think there is no 'ideal' name for that value :)
> 
> On Mon, Sep 17, 2012 at 1:24 PM, Kris Borchers <kris at redhat.com> wrote:
>> Because not all data storage refers to this as a primary key, right? I'm
>> thinking of MongoDB for example.
>> 
>> On Sep 16, 2012, at 2:58 PM, Matthias Wessendorf <matzew at apache.org> wrote:
>> 
>> Hi Kris!
>> 
>> One more question,
>> 
>> why 'recordId' instead of 'primaryKey'?
>> 
>> On Sunday, September 16, 2012, Matthias Wessendorf wrote:
>>> 
>>> Thx!
>>> 
>>> On Sat, Sep 15, 2012 at 8:27 PM, Kris Borchers <kris at redhat.com> wrote:
>>>> 
>>>> On Sep 15, 2012, at 12:13 PM, Matthias Wessendorf <matzew at apache.org>
>>>> wrote:
>>>> 
>>>> 
>>>> 
>>>> On Saturday, September 15, 2012, Kris Borchers wrote:
>>>>> 
>>>>> 
>>>>> On Sep 15, 2012, at 10:53 AM, Glen Daniels <glen at thoughtcraft.com>
>>>>> wrote:
>>>>> 
>>>>>> 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 ;) )
>>>>> I don't think it does. In JS, I have made it so that what ever name you
>>>>> use on the server to denote an "id", you can tell the client lib what
>>>>> that
>>>>> name is. So whether the id field is named id or recordId, or blahblah,
>>>>> that
>>>>> is configurable when a pipe is created.
>>>> 
>>>> 
>>>> Can you post a snippet for that?
>>>> 
>>>> Not exactly sure what you want to see and iOS/Android are probably going
>>>> to
>>>> have to be different but hope this helps a little.
>>>> https://gist.github.com/3729174
>>>> 
>>>> 
>>>> Thx,
>>>> Matthias
>>>> 
>>>> 
>>>> 
>>>>> 
>>>>> 
>>>>>> 
>>>>>>> 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
>>>>>> 
>>>>>> 
>>>>>> ___Matthias Wessendorf
>>> 
>>> blog: http://matthiaswessendorf.wordpress.com/
>>> sessions: http://www.slideshare.net/mwessendorf
>>> twitter: http://twitter.com/mwessendorf
>> 
>> 
>> 
>> --
>> Sent from Gmail Mobile
>> _______________________________________________
>> 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
>> 
> 
> 
> 
> -- 
> Matthias Wessendorf
> 
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev