Agreed, which is why I tried to stay general with recordID. :)
On Sep 17, 2012, at 6:26 AM, Matthias Wessendorf <matzew(a)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(a)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(a)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(a)redhat.com> wrote:
>>>
>>> On Sep 15, 2012, at 12:13 PM, Matthias Wessendorf <matzew(a)apache.org>
>>> wrote:
>>>
>>>
>>>
>>> On Saturday, September 15, 2012, Kris Borchers wrote:
>>>>
>>>>
>>>> On Sep 15, 2012, at 10:53 AM, Glen Daniels <glen(a)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(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev