[aerogear-dev] Android: some questions

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

[aerogear-dev] Android: some questions

Matthias Wessendorf
Howdy!

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)
- 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'.

* 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.
- the 'delete' is public; the others (e.g. post) not...

* 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_).

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).

Cheers,
Matthias

--
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|

Re: [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


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|

Re: [aerogear-dev] Android: some questions

Kris Borchers

On Sep 15, 2012, at 10:53 AM, Glen Daniels <[hidden email]> 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.

>
>> 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
>
>
> _______________________________________________
> aerogear-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|

Re: [aerogear-dev] Android: some questions

Matthias Wessendorf


On Saturday, September 15, 2012, Kris Borchers wrote:

On Sep 15, 2012, at 10:53 AM, Glen Daniels <<a href="javascript:;" onclick="_e(event, &#39;cvml&#39;, &#39;glen@thoughtcraft.com&#39;)">glen@...> 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?

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
>
>
> _______________________________________________
> aerogear-dev mailing list
> <a href="javascript:;" onclick="_e(event, &#39;cvml&#39;, &#39;aerogear-dev@lists.jboss.org&#39;)">aerogear-dev@...
> https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
<a href="javascript:;" onclick="_e(event, &#39;cvml&#39;, &#39;aerogear-dev@lists.jboss.org&#39;)">aerogear-dev@...
https://lists.jboss.org/mailman/listinfo/aerogear-dev


--
Sent from Gmail Mobile

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|

Re: [aerogear-dev] Android: some questions

Kris Borchers

On Sep 15, 2012, at 12:13 PM, Matthias Wessendorf <[hidden email]> wrote:



On Saturday, September 15, 2012, Kris Borchers wrote:

On Sep 15, 2012, at 10:53 AM, Glen Daniels <<a href="javascript:;" onclick="_e(event, 'cvml', 'glen@thoughtcraft.com')">glen@...> 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
>
>
> _______________________________________________
> aerogear-dev mailing list
> <a href="javascript:;" onclick="_e(event, 'cvml', 'aerogear-dev@lists.jboss.org')">aerogear-dev@...
> https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
<a href="javascript:;" onclick="_e(event, 'cvml', 'aerogear-dev@lists.jboss.org')">aerogear-dev@...
https://lists.jboss.org/mailman/listinfo/aerogear-dev


--
Sent from Gmail Mobile
_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|

Re: [aerogear-dev] Android: some questions

Matthias Wessendorf
Thx!

On Sat, Sep 15, 2012 at 8:27 PM, Kris Borchers <[hidden email]> wrote:

>
> On Sep 15, 2012, at 12:13 PM, Matthias Wessendorf <[hidden email]> wrote:
>
>
>
> On Saturday, September 15, 2012, Kris Borchers wrote:
>>
>>
>> On Sep 15, 2012, at 10:53 AM, Glen Daniels <[hidden email]> 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
>> >
>> >
>> > _______________________________________________
>> > aerogear-dev mailing list
>> > [hidden email]
>> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
>
> --
> Sent from Gmail Mobile
> _______________________________________________
> aerogear-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
>
> _______________________________________________
> aerogear-dev mailing list
> [hidden email]
> 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|

Re: [aerogear-dev] Android: some questions

Matthias Wessendorf
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 <[hidden email]> wrote:
>
> On Sep 15, 2012, at 12:13 PM, Matthias Wessendorf <[hidden email]> wrote:
>
>
>
> On Saturday, September 15, 2012, Kris Borchers wrote:
>>
>>
>> On Sep 15, 2012, at 10:53 AM, Glen Daniels <[hidden email]> 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|

Re: [aerogear-dev] Android: some questions

Kris Borchers
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 <[hidden email]> 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 <[hidden email]> wrote:
>
> On Sep 15, 2012, at 12:13 PM, Matthias Wessendorf <[hidden email]> wrote:
>
>
>
> On Saturday, September 15, 2012, Kris Borchers wrote:
>>
>>
>> On Sep 15, 2012, at 10:53 AM, Glen Daniels <[hidden email]> 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|

Re: [aerogear-dev] Android: some questions

Matthias Wessendorf
:) I think there is no 'ideal' name for that value :)

On Mon, Sep 17, 2012 at 1:24 PM, Kris Borchers <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
>> >
>> > On Sep 15, 2012, at 12:13 PM, Matthias Wessendorf <[hidden email]>
>> > wrote:
>> >
>> >
>> >
>> > On Saturday, September 15, 2012, Kris Borchers wrote:
>> >>
>> >>
>> >> On Sep 15, 2012, at 10:53 AM, Glen Daniels <[hidden email]>
>> >> 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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
>
> _______________________________________________
> aerogear-dev mailing list
> [hidden email]
> 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|

Re: [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 <[hidden email]> wrote:

> :) I think there is no 'ideal' name for that value :)
>
> On Mon, Sep 17, 2012 at 1:24 PM, Kris Borchers <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
>>>>
>>>> On Sep 15, 2012, at 12:13 PM, Matthias Wessendorf <[hidden email]>
>>>> wrote:
>>>>
>>>>
>>>>
>>>> On Saturday, September 15, 2012, Kris Borchers wrote:
>>>>>
>>>>>
>>>>> On Sep 15, 2012, at 10:53 AM, Glen Daniels <[hidden email]>
>>>>> 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
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>>
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> [hidden email]
>> 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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev