[aerogear-dev] AEROGEAR-299 - Android persistence library

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

[aerogear-dev] AEROGEAR-299 - Android persistence library

Daniel Passos-2
Hey Guys,

may I take a stab at AEROGEAR-299?

-- 
Daniel Passos


_______________________________________________
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] AEROGEAR-299 - Android persistence library

Bruno Oliveira
That would be awesome, is just a matter of wait a reply from Glen and Marko.


-- 
"The measure of a man is what he does with power" - Plato
-
@abstractj
-
Volenti Nihil Difficile

On Thursday, October 11, 2012 at 10:05 AM, Daniel Passos wrote:

Hey Guys,

may I take a stab at AEROGEAR-299?

-- 
Daniel Passos

_______________________________________________
aerogear-dev mailing list


_______________________________________________
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] AEROGEAR-299 - Android persistence library

Marko Strukelj
I agree, that would be awesome.

The issue needs some more describing though, so maybe we should first define it better.

I suppose it's Android local persistence that we're talking about here, not remote persistence - which is what Pipes API covers?

It would be good to outline any requirements that we might envision. For example this layer will take part in synchronization - well, I suppose synchronization will use it, maybe listen to some events at this layer, do inserts ...

Implementation-wise Android comes with OOTB SQLite, but we like to work with objects / entities. There are some existing ORM libraries specifically for Android ... Maybe we want to use some of those projects, or maybe we want to do something of our own. Maybe something that looks more like JPA. Or not, it all depends on our requirements.

Therefore I think, that before we start developing something new, we really should put down some features we want of this library. I.e.:

1) Fast, and small
2) Ergonomic, small, and simple API
3) Thin wraper around SQLite with easy access to all the native SQL that SQLite supports
4) ORM
...


- marko


----- Original Message -----

>
>
> That would be awesome, is just a matter of wait a reply from Glen and
> Marko.
>
>
>
>
>
>
> --
> "The measure of a man is what he does with power" - Plato
> -
> @abstractj
> -
> Volenti Nihil Difficile
>
> On Thursday, October 11, 2012 at 10:05 AM, Daniel Passos wrote:
>
>
>
>
> Hey Guys,
>
>
> may I take a stab at AEROGEAR-299?
>
>
>
> --
> Daniel Passos
>
>
>
> _______________________________________________
> 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
>
_______________________________________________
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] AEROGEAR-299 - Android persistence library

Marko Strukelj

Ok ... I just noticed that this issue relates to API documentation.

So what I wrote below is completely out of context for this issue, maybe for another debate ...

Just go ahead Passos, and feel free to comment the code, as you review it.

Thanks,

- marko


----- Original Message -----

> I agree, that would be awesome.
>
> The issue needs some more describing though, so maybe we should first
> define it better.
>
> I suppose it's Android local persistence that we're talking about
> here, not remote persistence - which is what Pipes API covers?
>
> It would be good to outline any requirements that we might envision.
> For example this layer will take part in synchronization - well, I
> suppose synchronization will use it, maybe listen to some events at
> this layer, do inserts ...
>
> Implementation-wise Android comes with OOTB SQLite, but we like to
> work with objects / entities. There are some existing ORM libraries
> specifically for Android ... Maybe we want to use some of those
> projects, or maybe we want to do something of our own. Maybe
> something that looks more like JPA. Or not, it all depends on our
> requirements.
>
> Therefore I think, that before we start developing something new, we
> really should put down some features we want of this library. I.e.:
>
> 1) Fast, and small
> 2) Ergonomic, small, and simple API
> 3) Thin wraper around SQLite with easy access to all the native SQL
> that SQLite supports
> 4) ORM
> ...
>
>
> - marko
>
>
> ----- Original Message -----
> >
> >
> > That would be awesome, is just a matter of wait a reply from Glen
> > and
> > Marko.
> >
> >
> >
> >
> >
> >
> > --
> > "The measure of a man is what he does with power" - Plato
> > -
> > @abstractj
> > -
> > Volenti Nihil Difficile
> >
> > On Thursday, October 11, 2012 at 10:05 AM, Daniel Passos wrote:
> >
> >
> >
> >
> > Hey Guys,
> >
> >
> > may I take a stab at AEROGEAR-299?
> >
> >
> >
> > --
> > Daniel Passos
> >
> >
> >
> > _______________________________________________
> > 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
> >
> _______________________________________________
> 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] AEROGEAR-299 - Android persistence library

Matthias Wessendorf
Marko,

On Fri, Oct 12, 2012 at 12:43 AM, Marko Strukelj <[hidden email]> wrote:
>
> Ok ... I just noticed that this issue relates to API documentation.
>
> So what I wrote below is completely out of context for this issue, maybe for another debate ...


there were some good comments in, regarding what JS and iOS call 'DataManager'.

Right now the APIs are pretty simple there and they use 'in memory' storage.
Christos is playing with the AGDataManager, also regarding 'data sync'.

Regarding adding 'real' persistent technologies, I also agree to
reventing the wheel,
that's what the iOS roadmap dedicates a good amount of work to Core
Data (for the December
timeframe release).

.M

> Just go ahead Passos, and feel free to comment the code, as you review it.
>
> Thanks,
>
> - marko
>
>
> ----- Original Message -----
>> I agree, that would be awesome.
>>
>> The issue needs some more describing though, so maybe we should first
>> define it better.
>>
>> I suppose it's Android local persistence that we're talking about
>> here, not remote persistence - which is what Pipes API covers?
>>
>> It would be good to outline any requirements that we might envision.
>> For example this layer will take part in synchronization - well, I
>> suppose synchronization will use it, maybe listen to some events at
>> this layer, do inserts ...
>>
>> Implementation-wise Android comes with OOTB SQLite, but we like to
>> work with objects / entities. There are some existing ORM libraries
>> specifically for Android ... Maybe we want to use some of those
>> projects, or maybe we want to do something of our own. Maybe
>> something that looks more like JPA. Or not, it all depends on our
>> requirements.
>>
>> Therefore I think, that before we start developing something new, we
>> really should put down some features we want of this library. I.e.:
>>
>> 1) Fast, and small
>> 2) Ergonomic, small, and simple API
>> 3) Thin wraper around SQLite with easy access to all the native SQL
>> that SQLite supports
>> 4) ORM
>> ...
>>
>>
>> - marko
>>
>>
>> ----- Original Message -----
>> >
>> >
>> > That would be awesome, is just a matter of wait a reply from Glen
>> > and
>> > Marko.
>> >
>> >
>> >
>> >
>> >
>> >
>> > --
>> > "The measure of a man is what he does with power" - Plato
>> > -
>> > @abstractj
>> > -
>> > Volenti Nihil Difficile
>> >
>> > On Thursday, October 11, 2012 at 10:05 AM, Daniel Passos wrote:
>> >
>> >
>> >
>> >
>> > Hey Guys,
>> >
>> >
>> > may I take a stab at AEROGEAR-299?
>> >
>> >
>> >
>> > --
>> > Daniel Passos
>> >
>> >
>> >
>> > _______________________________________________
>> > 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
>> >
>> _______________________________________________
>> 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] AEROGEAR-299 - Android persistence library

Matthias Wessendorf


On Friday, October 12, 2012, Matthias Wessendorf wrote:
Marko,

On Fri, Oct 12, 2012 at 12:43 AM, Marko Strukelj <<a href="javascript:;" onclick="_e(event, &#39;cvml&#39;, &#39;mstrukel@redhat.com&#39;)">mstrukel@...> wrote:
>
> Ok ... I just noticed that this issue relates to API documentation.
>
> So what I wrote below is completely out of context for this issue, maybe for another debate ...


there were some good comments in, regarding what JS and iOS call 'DataManager'.

Right now the APIs are pretty simple there and they use 'in memory' storage.
Christos is playing with the AGDataManager, also regarding 'data sync'.

Regarding adding 'real' persistent technologies, I also agree to

not.... lol
 
reventing the wheel,
that's what the iOS roadmap dedicates a good amount of work to Core
Data (for the December
timeframe release).

.M

> Just go ahead Passos, and feel free to comment the code, as you review it.
>
> Thanks,
>
> - marko
>
>
> ----- Original Message -----
>> I agree, that would be awesome.
>>
>> The issue needs some more describing though, so maybe we should first
>> define it better.
>>
>> I suppose it's Android local persistence that we're talking about
>> here, not remote persistence - which is what Pipes API covers?
>>
>> It would be good to outline any requirements that we might envision.
>> For example this layer will take part in synchronization - well, I
>> suppose synchronization will use it, maybe listen to some events at
>> this layer, do inserts ...
>>
>> Implementation-wise Android comes with OOTB SQLite, but we like to
>> work with objects / entities. There are some existing ORM libraries
>> specifically for Android ... Maybe we want to use some of those
>> projects, or maybe we want to do something of our own. Maybe
>> something that looks more like JPA. Or not, it all depends on our
>> requirements.
>>
>> Therefore I think, that before we start developing something new, we
>> really should put down some features we want of this library. I.e.:
>>
>> 1) Fast, and small
>> 2) Ergonomic, small, and simple API
>> 3) Thin wraper around SQLite with easy access to all the native SQL
>> that SQLite supports
>> 4) ORM
>> ...
>>
>>
>> - marko
>>
>>
>> ----- Original Message -----
>> >
>> >
>> > That would be awesome, is just a matter of wait a reply from Glen
>> > and
>> > Marko.
>> >
>> >
>> >
>> >
>> >
>> >
>> > --
>> > "The measure of a man is what he does with power" - Plato
>> > -
>> > @abstractj
>> > -
>> > Volenti Nihil Difficile
>> >
>> > On Thursday, October 11, 2012 at 10:05 AM, Daniel Passos wrote:
>> >
>> >
>> >
>> >
>> > Hey Guys,
>> >
>> >
>> > may I take a stab at AEROGEAR-299?
>> >
>> >
>> >
>> > --
>> > Daniel Passos
>> >
>> >
>> >
>> > _______________________________________________
>> > 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
>> >
>> _______________________________________________
>> 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



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