[GSoc] XDroid Platform

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

[GSoc] XDroid Platform

sasinda
Hi all,
I am starting this thread for my XWiki Android Platform Project.

Please check whether following are OK.
[1] INFO
I tried to start my new modules with the de.akquinet.android.archetypes:
android-quickstart:1.0.8.  (added eclipse plugins m2e,
m2e-android[a.k.a  *Android
Configurator* ]). But this seems buggy in eclipse.
Any way the earlier project has not followed the above archtype either. So
I am going to write pom.xml manually for my each module.

[2] ADVICE NEEDED
xwiki-rest-model module contains 2 submodules
  |-- xwiki-rest-model-gson  ( gson should be corrected to json)
  |-- xwiki-rest-model-simplexml
I think the xwiki-rest-model-gson is redundant. The classes
in xwiki-rest-model-simplexml is added with simple xml annotations,
otherwise both modules have same classes. There is no problem with the
added annotations for using the same model objects for Json REST web
services. And I intend to add my JPA (ORMLite library for persistence)
annotations on top of it.
Shall I re-factor them to a single module xwiki-rest-model.

[3] INFO
 I had to change some pom.xml s. As the current project at:
https://github.com/xwiki-contrib/android-client.git does not build. Error
with parent pom.xml coordinates.


Thank you
Best Regards.
Sasinda Rukshan
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [GSoc] XDroid Platform

Thomas Mortagne
Administrator
On Thu, May 24, 2012 at 5:52 PM, sasinda rukshan
<[hidden email]> wrote:

> Hi all,
> I am starting this thread for my XWiki Android Platform Project.
>
> Please check whether following are OK.
> [1] INFO
> I tried to start my new modules with the de.akquinet.android.archetypes:
> android-quickstart:1.0.8.  (added eclipse plugins m2e,
> m2e-android[a.k.a  *Android
> Configurator* ]). But this seems buggy in eclipse.
> Any way the earlier project has not followed the above archtype either. So
> I am going to write pom.xml manually for my each module.
>
> [2] ADVICE NEEDED
> xwiki-rest-model module contains 2 submodules
>  |-- xwiki-rest-model-gson  ( gson should be corrected to json)

No the g is not a mistake, it's a model to be used with the gson
library (http://code.google.com/p/google-gson/). See
http://extensions.xwiki.org/xwiki/bin/view/Extension/Google+Android+Client#HXWikiAndroidDevelopmentAPIsandResources.

>  |-- xwiki-rest-model-simplexml
> I think the xwiki-rest-model-gson is redundant. The classes
> in xwiki-rest-model-simplexml is added with simple xml annotations,
> otherwise both modules have same classes. There is no problem with the
> added annotations for using the same model objects for Json REST web
> services. And I intend to add my JPA (ORMLite library for persistence)
> annotations on top of it.
> Shall I re-factor them to a single module xwiki-rest-model.

No keep them separated, the idea is that both are useful tool to be
used by someone else that might be moved to xwiki-platform at some
point along with the current xwiki-rest-model (to be renamed to
xwiki-rest-model-jaxb).

Chamika initially started with gson and since XWiki REST JSON
representation had some limitation he moved to XML representation.
Maybe at some point Android will have native support for jaxb which
would obviously be the easier for us (embedding jaxb is not an option
in mobile world where size it still pretty important especially on
phones). Maybe it's already the case on most recent versions like 4.0
I don't know.

>
> [3] INFO
>  I had to change some pom.xml s. As the current project at:
> https://github.com/xwiki-contrib/android-client.git does not build. Error
> with parent pom.xml coordinates.

You probably did not setup you maven install properly since what's on
https://github.com/xwiki-contrib/android-client.git build perfectly as
you can see on http://ci.xwiki.org/view/All/job/xwiki-android-client/
which run a build every time something changes on the git repository..
You should look at
http://dev.xwiki.org/xwiki/bin/view/Community/Building.

>
>
> Thank you
> Best Regards.
> Sasinda Rukshan
> _______________________________________________
> devs mailing list
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs



--
Thomas Mortagne
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [GSoc] XDroid Platform

Jerome Velociter-4
On Thu, May 24, 2012 at 6:09 PM, Thomas Mortagne
<[hidden email]> wrote:

> On Thu, May 24, 2012 at 5:52 PM, sasinda rukshan
> <[hidden email]> wrote:
>> Hi all,
>> I am starting this thread for my XWiki Android Platform Project.
>>
>> Please check whether following are OK.
>> [1] INFO
>> I tried to start my new modules with the de.akquinet.android.archetypes:
>> android-quickstart:1.0.8.  (added eclipse plugins m2e,
>> m2e-android[a.k.a  *Android
>> Configurator* ]). But this seems buggy in eclipse.
>> Any way the earlier project has not followed the above archtype either. So
>> I am going to write pom.xml manually for my each module.
>>
>> [2] ADVICE NEEDED
>> xwiki-rest-model module contains 2 submodules
>>  |-- xwiki-rest-model-gson  ( gson should be corrected to json)
>
> No the g is not a mistake, it's a model to be used with the gson
> library (http://code.google.com/p/google-gson/). See
> http://extensions.xwiki.org/xwiki/bin/view/Extension/Google+Android+Client#HXWikiAndroidDevelopmentAPIsandResources.
>
>>  |-- xwiki-rest-model-simplexml
>> I think the xwiki-rest-model-gson is redundant. The classes
>> in xwiki-rest-model-simplexml is added with simple xml annotations,
>> otherwise both modules have same classes. There is no problem with the
>> added annotations for using the same model objects for Json REST web
>> services. And I intend to add my JPA (ORMLite library for persistence)
>> annotations on top of it.
>> Shall I re-factor them to a single module xwiki-rest-model.
>
> No keep them separated, the idea is that both are useful tool to be
> used by someone else that might be moved to xwiki-platform at some
> point along with the current xwiki-rest-model (to be renamed to
> xwiki-rest-model-jaxb).
>
> Chamika initially started with gson and since XWiki REST JSON
> representation had some limitation he moved to XML representation.
> Maybe at some point Android will have native support for jaxb which
> would obviously be the easier for us (embedding jaxb is not an option
> in mobile world where size it still pretty important especially on
> phones). Maybe it's already the case on most recent versions like 4.0
> I don't know.

There's also Jackson that could be tried for JSON deserialization, if
said limitations are actually GSON limitations.

Having full JAXB support sound a bit overweight for such an "embedded
API", even if one day it is natively supported by Android. What's
important is to have an easy and fast deserialization, IMO.
The only advantage I can see of going JAXB would be in re-using the
exact representations and body readers/writers from XWiki core. But
you probably don't even want to do that since it would mean dragging
XWiki core with you :)

Jerome

>
>>
>> [3] INFO
>>  I had to change some pom.xml s. As the current project at:
>> https://github.com/xwiki-contrib/android-client.git does not build. Error
>> with parent pom.xml coordinates.
>
> You probably did not setup you maven install properly since what's on
> https://github.com/xwiki-contrib/android-client.git build perfectly as
> you can see on http://ci.xwiki.org/view/All/job/xwiki-android-client/
> which run a build every time something changes on the git repository..
> You should look at
> http://dev.xwiki.org/xwiki/bin/view/Community/Building.
>
>>
>>
>> Thank you
>> Best Regards.
>> Sasinda Rukshan
>> _______________________________________________
>> devs mailing list
>> [hidden email]
>> http://lists.xwiki.org/mailman/listinfo/devs
>
>
>
> --
> Thomas Mortagne
> _______________________________________________
> devs mailing list
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs



--
Jérôme Velociter
Winesquare
http://www.winesquare.net/
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [GSoc] XDroid Platform

Thomas Mortagne
Administrator
On Thu, May 24, 2012 at 9:55 PM, Jerome Velociter <[hidden email]> wrote:

> On Thu, May 24, 2012 at 6:09 PM, Thomas Mortagne
> <[hidden email]> wrote:
>> On Thu, May 24, 2012 at 5:52 PM, sasinda rukshan
>> <[hidden email]> wrote:
>>> Hi all,
>>> I am starting this thread for my XWiki Android Platform Project.
>>>
>>> Please check whether following are OK.
>>> [1] INFO
>>> I tried to start my new modules with the de.akquinet.android.archetypes:
>>> android-quickstart:1.0.8.  (added eclipse plugins m2e,
>>> m2e-android[a.k.a  *Android
>>> Configurator* ]). But this seems buggy in eclipse.
>>> Any way the earlier project has not followed the above archtype either. So
>>> I am going to write pom.xml manually for my each module.
>>>
>>> [2] ADVICE NEEDED
>>> xwiki-rest-model module contains 2 submodules
>>>  |-- xwiki-rest-model-gson  ( gson should be corrected to json)
>>
>> No the g is not a mistake, it's a model to be used with the gson
>> library (http://code.google.com/p/google-gson/). See
>> http://extensions.xwiki.org/xwiki/bin/view/Extension/Google+Android+Client#HXWikiAndroidDevelopmentAPIsandResources.
>>
>>>  |-- xwiki-rest-model-simplexml
>>> I think the xwiki-rest-model-gson is redundant. The classes
>>> in xwiki-rest-model-simplexml is added with simple xml annotations,
>>> otherwise both modules have same classes. There is no problem with the
>>> added annotations for using the same model objects for Json REST web
>>> services. And I intend to add my JPA (ORMLite library for persistence)
>>> annotations on top of it.
>>> Shall I re-factor them to a single module xwiki-rest-model.
>>
>> No keep them separated, the idea is that both are useful tool to be
>> used by someone else that might be moved to xwiki-platform at some
>> point along with the current xwiki-rest-model (to be renamed to
>> xwiki-rest-model-jaxb).
>>
>> Chamika initially started with gson and since XWiki REST JSON
>> representation had some limitation he moved to XML representation.
>> Maybe at some point Android will have native support for jaxb which
>> would obviously be the easier for us (embedding jaxb is not an option
>> in mobile world where size it still pretty important especially on
>> phones). Maybe it's already the case on most recent versions like 4.0
>> I don't know.
>
> There's also Jackson that could be tried for JSON deserialization, if
> said limitations are actually GSON limitations.
>
> Having full JAXB support sound a bit overweight for such an "embedded
> API", even if one day it is natively supported by Android. What's
> important is to have an easy and fast deserialization, IMO.
> The only advantage I can see of going JAXB would be in re-using the
> exact representations and body readers/writers from XWiki core. But
> you probably don't even want to do that since it would mean dragging
> XWiki core with you :)

JAXB is not only about representation. Actually the only and real
advantage in having native JAXB support is that you can reuse the
various always in sync models modules you can find on platform (base
XWiki rest model module, extension model module, annotations model
module, etc.) which does not have any dependency on anything but JAXB
instead of having to maintain your own model module which is what we
are talking about here.

>
> Jerome
>
>>
>>>
>>> [3] INFO
>>>  I had to change some pom.xml s. As the current project at:
>>> https://github.com/xwiki-contrib/android-client.git does not build. Error
>>> with parent pom.xml coordinates.
>>
>> You probably did not setup you maven install properly since what's on
>> https://github.com/xwiki-contrib/android-client.git build perfectly as
>> you can see on http://ci.xwiki.org/view/All/job/xwiki-android-client/
>> which run a build every time something changes on the git repository..
>> You should look at
>> http://dev.xwiki.org/xwiki/bin/view/Community/Building.
>>
>>>
>>>
>>> Thank you
>>> Best Regards.
>>> Sasinda Rukshan
>>> _______________________________________________
>>> devs mailing list
>>> [hidden email]
>>> http://lists.xwiki.org/mailman/listinfo/devs
>>
>>
>>
>> --
>> Thomas Mortagne
>> _______________________________________________
>> devs mailing list
>> [hidden email]
>> http://lists.xwiki.org/mailman/listinfo/devs
>
>
>
> --
> Jérôme Velociter
> Winesquare
> http://www.winesquare.net/
> _______________________________________________
> devs mailing list
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs



--
Thomas Mortagne
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [GSoc] XDroid Platform

Chamika Weerasinghe
In reply to this post by Jerome Velociter-4
On Fri, May 25, 2012 at 1:25 AM, Jerome Velociter <[hidden email]>wrote:

> On Thu, May 24, 2012 at 6:09 PM, Thomas Mortagne
> <[hidden email]> wrote:
> > On Thu, May 24, 2012 at 5:52 PM, sasinda rukshan
> > <[hidden email]> wrote:
> >> Hi all,
> >> I am starting this thread for my XWiki Android Platform Project.
> >>
> >> Please check whether following are OK.
> >> [1] INFO
> >> I tried to start my new modules with the de.akquinet.android.archetypes:
> >> android-quickstart:1.0.8.  (added eclipse plugins m2e,
> >> m2e-android[a.k.a  *Android
> >> Configurator* ]). But this seems buggy in eclipse.
> >> Any way the earlier project has not followed the above archtype either.
> So
> >> I am going to write pom.xml manually for my each module.
> >>
> >> [2] ADVICE NEEDED
> >> xwiki-rest-model module contains 2 submodules
> >>  |-- xwiki-rest-model-gson  ( gson should be corrected to json)
> >
> > No the g is not a mistake, it's a model to be used with the gson
> > library (http://code.google.com/p/google-gson/). See
> >
> http://extensions.xwiki.org/xwiki/bin/view/Extension/Google+Android+Client#HXWikiAndroidDevelopmentAPIsandResources
> .
> >
> >>  |-- xwiki-rest-model-simplexml
> >> I think the xwiki-rest-model-gson is redundant. The classes
> >> in xwiki-rest-model-simplexml is added with simple xml annotations,
> >> otherwise both modules have same classes. There is no problem with the
> >> added annotations for using the same model objects for Json REST web
> >> services. And I intend to add my JPA (ORMLite library for persistence)
> >> annotations on top of it.
> >> Shall I re-factor them to a single module xwiki-rest-model.
> >
> > No keep them separated, the idea is that both are useful tool to be
> > used by someone else that might be moved to xwiki-platform at some
> > point along with the current xwiki-rest-model (to be renamed to
> > xwiki-rest-model-jaxb).
> >
> > Chamika initially started with gson and since XWiki REST JSON
> > representation had some limitation he moved to XML representation.
> > Maybe at some point Android will have native support for jaxb which
> > would obviously be the easier for us (embedding jaxb is not an option
> > in mobile world where size it still pretty important especially on
> > phones). Maybe it's already the case on most recent versions like 4.0
> > I don't know.
>
> There's also Jackson that could be tried for JSON deserialization, if
> said limitations are actually GSON limitations.
>
GSON wasn't the limitation.
It was XWiki RESTful API which doesn't support JSON in some cases. So it's
safe to go with xml.

>
> Having full JAXB support sound a bit overweight for such an "embedded
> API", even if one day it is natively supported by Android. What's
> important is to have an easy and fast deserialization, IMO.
> The only advantage I can see of going JAXB would be in re-using the
> exact representations and body readers/writers from XWiki core. But
> you probably don't even want to do that since it would mean dragging
> XWiki core with you :)
>
> Jerome
>
> >
> >>
> >> [3] INFO
> >>  I had to change some pom.xml s. As the current project at:
> >> https://github.com/xwiki-contrib/android-client.git does not build.
> Error
> >> with parent pom.xml coordinates.
> >
> > You probably did not setup you maven install properly since what's on
> > https://github.com/xwiki-contrib/android-client.git build perfectly as
> > you can see on http://ci.xwiki.org/view/All/job/xwiki-android-client/
> > which run a build every time something changes on the git repository..
> > You should look at
> > http://dev.xwiki.org/xwiki/bin/view/Community/Building.
> >
> >>
> >>
> >> Thank you
> >> Best Regards.
> >> Sasinda Rukshan
> >> _______________________________________________
> >> devs mailing list
> >> [hidden email]
> >> http://lists.xwiki.org/mailman/listinfo/devs
> >
> >
> >
> > --
> > Thomas Mortagne
> > _______________________________________________
> > devs mailing list
> > [hidden email]
> > http://lists.xwiki.org/mailman/listinfo/devs
>
>
>
> --
> Jérôme Velociter
> Winesquare
> http://www.winesquare.net/
> _______________________________________________
> devs mailing list
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs
>
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [GSoc] XDroid Platform

sasinda
Hi,

I am commiting my work to my fork https://github.com/sasinda/android-client.
I ll request to pull it to xwiki-contrib later.

I was running in a wrong path these days. Wanted to save login history and
suggest login. I was going to do it using an xml file (login attempts.xml).
Now it seems database is better.
Any way before I go wrong again I will say what I am going to do.
I am going to enforce following conventions.These are not yet needed,
considered the small scale.But when the system grows it would be nice to
have them to avoid confusions.
*Database prefixes for:*
*Platform tables (can begin with appropriate prefix)*
AD_ //application dictionary : don't know when it will be needed ;-)
C_ //core functionality
*Client Applications.*
X<App name prefix>  ex: XBLOG_   for Blog app// All client add in modules
must begin with table prefix X(for xwiki and ordering) + App name.  This is
for my blog.

I will create
C_User for user data.
C_LoginAttempt  for saving login attempts.

From C_LoginAttempt I can filter uniqe login combinations and give
suggestions in the login UI component. Also save the history.

All saved data for blog app will be linked to a perticular login : User,
XWiki server.
But only a single user will be most probably using his personal device. So
above will be relevant only when he has multiple wikis.

Best Regards,
Sasinda Rukshan.





On Sun, May 27, 2012 at 5:43 PM, Chamika Weerasinghe <[hidden email]>wrote:

> On Fri, May 25, 2012 at 1:25 AM, Jerome Velociter <[hidden email]
> >wrote:
>
> > On Thu, May 24, 2012 at 6:09 PM, Thomas Mortagne
> > <[hidden email]> wrote:
> > > On Thu, May 24, 2012 at 5:52 PM, sasinda rukshan
> > > <[hidden email]> wrote:
> > >> Hi all,
> > >> I am starting this thread for my XWiki Android Platform Project.
> > >>
> > >> Please check whether following are OK.
> > >> [1] INFO
> > >> I tried to start my new modules with the
> de.akquinet.android.archetypes:
> > >> android-quickstart:1.0.8.  (added eclipse plugins m2e,
> > >> m2e-android[a.k.a  *Android
> > >> Configurator* ]). But this seems buggy in eclipse.
> > >> Any way the earlier project has not followed the above archtype
> either.
> > So
> > >> I am going to write pom.xml manually for my each module.
> > >>
> > >> [2] ADVICE NEEDED
> > >> xwiki-rest-model module contains 2 submodules
> > >>  |-- xwiki-rest-model-gson  ( gson should be corrected to json)
> > >
> > > No the g is not a mistake, it's a model to be used with the gson
> > > library (http://code.google.com/p/google-gson/). See
> > >
> >
> http://extensions.xwiki.org/xwiki/bin/view/Extension/Google+Android+Client#HXWikiAndroidDevelopmentAPIsandResources
> > .
> > >
> > >>  |-- xwiki-rest-model-simplexml
> > >> I think the xwiki-rest-model-gson is redundant. The classes
> > >> in xwiki-rest-model-simplexml is added with simple xml annotations,
> > >> otherwise both modules have same classes. There is no problem with the
> > >> added annotations for using the same model objects for Json REST web
> > >> services. And I intend to add my JPA (ORMLite library for persistence)
> > >> annotations on top of it.
> > >> Shall I re-factor them to a single module xwiki-rest-model.
> > >
> > > No keep them separated, the idea is that both are useful tool to be
> > > used by someone else that might be moved to xwiki-platform at some
> > > point along with the current xwiki-rest-model (to be renamed to
> > > xwiki-rest-model-jaxb).
> > >
> > > Chamika initially started with gson and since XWiki REST JSON
> > > representation had some limitation he moved to XML representation.
> > > Maybe at some point Android will have native support for jaxb which
> > > would obviously be the easier for us (embedding jaxb is not an option
> > > in mobile world where size it still pretty important especially on
> > > phones). Maybe it's already the case on most recent versions like 4.0
> > > I don't know.
> >
> > There's also Jackson that could be tried for JSON deserialization, if
> > said limitations are actually GSON limitations.
> >
> GSON wasn't the limitation.
> It was XWiki RESTful API which doesn't support JSON in some cases. So it's
> safe to go with xml.
>
> >
> > Having full JAXB support sound a bit overweight for such an "embedded
> > API", even if one day it is natively supported by Android. What's
> > important is to have an easy and fast deserialization, IMO.
> > The only advantage I can see of going JAXB would be in re-using the
> > exact representations and body readers/writers from XWiki core. But
> > you probably don't even want to do that since it would mean dragging
> > XWiki core with you :)
> >
> > Jerome
> >
> > >
> > >>
> > >> [3] INFO
> > >>  I had to change some pom.xml s. As the current project at:
> > >> https://github.com/xwiki-contrib/android-client.git does not build.
> > Error
> > >> with parent pom.xml coordinates.
> > >
> > > You probably did not setup you maven install properly since what's on
> > > https://github.com/xwiki-contrib/android-client.git build perfectly as
> > > you can see on http://ci.xwiki.org/view/All/job/xwiki-android-client/
> > > which run a build every time something changes on the git repository..
> > > You should look at
> > > http://dev.xwiki.org/xwiki/bin/view/Community/Building.
> > >
> > >>
> > >>
> > >> Thank you
> > >> Best Regards.
> > >> Sasinda Rukshan
> > >> _______________________________________________
> > >> devs mailing list
> > >> [hidden email]
> > >> http://lists.xwiki.org/mailman/listinfo/devs
> > >
> > >
> > >
> > > --
> > > Thomas Mortagne
> > > _______________________________________________
> > > devs mailing list
> > > [hidden email]
> > > http://lists.xwiki.org/mailman/listinfo/devs
> >
> >
> >
> > --
> > Jérôme Velociter
> > Winesquare
> > http://www.winesquare.net/
> > _______________________________________________
> > devs mailing list
> > [hidden email]
> > http://lists.xwiki.org/mailman/listinfo/devs
> >
> _______________________________________________
> devs mailing list
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs
>
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [GSoc] XDroid Platform

sasinda
Hi,
I am studying ORM Lite these days.
Please It would be comforting if you can confirm whether it is worth the
overhead to use ORM Lite.
http://logic-explained.blogspot.com/2011/12/using-ormlite-in-android-projects.html
http://ormlite.com/
ORM Lite features:
Automatically Creates standard DAOs for an annotated entity.
Coding will be lot easier.

Can you suggest how to name the entities.
I am going to go with,
<entity>  org.xwiki.xdroid.data.User  --> <table> C_USER

Thanks,
Best Regards

Sasinda.





On Wed, May 30, 2012 at 7:42 AM, sasinda rukshan
<[hidden email]>wrote:

> Hi,
>
> I am commiting my work to my fork
> https://github.com/sasinda/android-client.
> I ll request to pull it to xwiki-contrib later.
>
> I was running in a wrong path these days. Wanted to save login history and
> suggest login. I was going to do it using an xml file (login attempts.xml).
> Now it seems database is better.
> Any way before I go wrong again I will say what I am going to do.
> I am going to enforce following conventions.These are not yet needed,
> considered the small scale.But when the system grows it would be nice to
> have them to avoid confusions.
> *Database prefixes for:*
> *Platform tables (can begin with appropriate prefix)*
> AD_ //application dictionary : don't know when it will be needed ;-)
> C_ //core functionality
> *Client Applications.*
> X<App name prefix>  ex: XBLOG_   for Blog app// All client add in modules
> must begin with table prefix X(for xwiki and ordering) + App name.  This is
> for my blog.
>
> I will create
> C_User for user data.
> C_LoginAttempt  for saving login attempts.
>
> From C_LoginAttempt I can filter uniqe login combinations and give
> suggestions in the login UI component. Also save the history.
>
> All saved data for blog app will be linked to a perticular login : User,
> XWiki server.
> But only a single user will be most probably using his personal device. So
> above will be relevant only when he has multiple wikis.
>
> Best Regards,
> Sasinda Rukshan.
>
>
>
>
>
> On Sun, May 27, 2012 at 5:43 PM, Chamika Weerasinghe <[hidden email]>wrote:
>
>> On Fri, May 25, 2012 at 1:25 AM, Jerome Velociter <[hidden email]
>> >wrote:
>>
>> > On Thu, May 24, 2012 at 6:09 PM, Thomas Mortagne
>> > <[hidden email]> wrote:
>> > > On Thu, May 24, 2012 at 5:52 PM, sasinda rukshan
>> > > <[hidden email]> wrote:
>> > >> Hi all,
>> > >> I am starting this thread for my XWiki Android Platform Project.
>> > >>
>> > >> Please check whether following are OK.
>> > >> [1] INFO
>> > >> I tried to start my new modules with the
>> de.akquinet.android.archetypes:
>> > >> android-quickstart:1.0.8.  (added eclipse plugins m2e,
>> > >> m2e-android[a.k.a  *Android
>> > >> Configurator* ]). But this seems buggy in eclipse.
>> > >> Any way the earlier project has not followed the above archtype
>> either.
>> > So
>> > >> I am going to write pom.xml manually for my each module.
>> > >>
>> > >> [2] ADVICE NEEDED
>> > >> xwiki-rest-model module contains 2 submodules
>> > >>  |-- xwiki-rest-model-gson  ( gson should be corrected to json)
>> > >
>> > > No the g is not a mistake, it's a model to be used with the gson
>> > > library (http://code.google.com/p/google-gson/). See
>> > >
>> >
>> http://extensions.xwiki.org/xwiki/bin/view/Extension/Google+Android+Client#HXWikiAndroidDevelopmentAPIsandResources
>> > .
>> > >
>> > >>  |-- xwiki-rest-model-simplexml
>> > >> I think the xwiki-rest-model-gson is redundant. The classes
>> > >> in xwiki-rest-model-simplexml is added with simple xml annotations,
>> > >> otherwise both modules have same classes. There is no problem with
>> the
>> > >> added annotations for using the same model objects for Json REST web
>> > >> services. And I intend to add my JPA (ORMLite library for
>> persistence)
>> > >> annotations on top of it.
>> > >> Shall I re-factor them to a single module xwiki-rest-model.
>> > >
>> > > No keep them separated, the idea is that both are useful tool to be
>> > > used by someone else that might be moved to xwiki-platform at some
>> > > point along with the current xwiki-rest-model (to be renamed to
>> > > xwiki-rest-model-jaxb).
>> > >
>> > > Chamika initially started with gson and since XWiki REST JSON
>> > > representation had some limitation he moved to XML representation.
>> > > Maybe at some point Android will have native support for jaxb which
>> > > would obviously be the easier for us (embedding jaxb is not an option
>> > > in mobile world where size it still pretty important especially on
>> > > phones). Maybe it's already the case on most recent versions like 4.0
>> > > I don't know.
>> >
>> > There's also Jackson that could be tried for JSON deserialization, if
>> > said limitations are actually GSON limitations.
>> >
>> GSON wasn't the limitation.
>> It was XWiki RESTful API which doesn't support JSON in some cases. So it's
>> safe to go with xml.
>>
>> >
>> > Having full JAXB support sound a bit overweight for such an "embedded
>> > API", even if one day it is natively supported by Android. What's
>> > important is to have an easy and fast deserialization, IMO.
>> > The only advantage I can see of going JAXB would be in re-using the
>> > exact representations and body readers/writers from XWiki core. But
>> > you probably don't even want to do that since it would mean dragging
>> > XWiki core with you :)
>> >
>> > Jerome
>> >
>> > >
>> > >>
>> > >> [3] INFO
>> > >>  I had to change some pom.xml s. As the current project at:
>> > >> https://github.com/xwiki-contrib/android-client.git does not build.
>> > Error
>> > >> with parent pom.xml coordinates.
>> > >
>> > > You probably did not setup you maven install properly since what's on
>> > > https://github.com/xwiki-contrib/android-client.git build perfectly
>> as
>> > > you can see on http://ci.xwiki.org/view/All/job/xwiki-android-client/
>> > > which run a build every time something changes on the git repository..
>> > > You should look at
>> > > http://dev.xwiki.org/xwiki/bin/view/Community/Building.
>> > >
>> > >>
>> > >>
>> > >> Thank you
>> > >> Best Regards.
>> > >> Sasinda Rukshan
>> > >> _______________________________________________
>> > >> devs mailing list
>> > >> [hidden email]
>> > >> http://lists.xwiki.org/mailman/listinfo/devs
>> > >
>> > >
>> > >
>> > > --
>> > > Thomas Mortagne
>> > > _______________________________________________
>> > > devs mailing list
>> > > [hidden email]
>> > > http://lists.xwiki.org/mailman/listinfo/devs
>> >
>> >
>> >
>> > --
>> > Jérôme Velociter
>> > Winesquare
>> > http://www.winesquare.net/
>> > _______________________________________________
>> > devs mailing list
>> > [hidden email]
>> > http://lists.xwiki.org/mailman/listinfo/devs
>> >
>> _______________________________________________
>> devs mailing list
>> [hidden email]
>> http://lists.xwiki.org/mailman/listinfo/devs
>>
>
>
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [GSoc] XDroid Platform

Thomas Mortagne
Administrator
In reply to this post by sasinda
On Wed, May 30, 2012 at 4:12 AM, sasinda rukshan
<[hidden email]> wrote:
> Hi,
>
> I am commiting my work to my fork https://github.com/sasinda/android-client.
> I ll request to pull it to xwiki-contrib later.

IMO you should directly work on
https://github.com/sasinda/android-client since you are the only one
working on it you are not going to disturb too much others and it will
be better to follow your work. I just gave you push right on it.

>
> I was running in a wrong path these days. Wanted to save login history and
> suggest login. I was going to do it using an xml file (login attempts.xml).
> Now it seems database is better.
> Any way before I go wrong again I will say what I am going to do.

Yes you should do that as much as possible even when you are sure of
what you are doing.

Also don't forget to announce any new testable thing to get suggestion
and bugreport. Everything you commit on
https://github.com/xwiki-contrib/android-client is automatically built
and deployed (if the build succeed) on
http://maven.xwiki.org/snapshots/org/xwiki/android/ so it's verry easy
to test for anyone.

> I am going to enforce following conventions.These are not yet needed,
> considered the small scale.But when the system grows it would be nice to
> have them to avoid confusions.
> *Database prefixes for:*
> *Platform tables (can begin with appropriate prefix)*
> AD_ //application dictionary : don't know when it will be needed ;-)

Not sure I understand what this is.

> C_ //core functionality
> *Client Applications.*
> X<App name prefix>  ex: XBLOG_   for Blog app// All client add in modules
> must begin with table prefix X(for xwiki and ordering) + App name.  This is
> for my blog.

Convention is always good.

>
> I will create
> C_User for user data.
> C_LoginAttempt  for saving login attempts.
>
> From C_LoginAttempt I can filter uniqe login combinations and give
> suggestions in the login UI component. Also save the history.
>
> All saved data for blog app will be linked to a perticular login : User,
> XWiki server.

What do you plan to use as server identifier ? Note that when a wiki
is path based all the wikis have the same host. See
http://platform.xwiki.org/xwiki/bin/view/AdminGuide/AccessWiki.

> But only a single user will be most probably using his personal device. So
> above will be relevant only when he has multiple wikis.
>
> Best Regards,
> Sasinda Rukshan.
>
>
>
>
>
> On Sun, May 27, 2012 at 5:43 PM, Chamika Weerasinghe <[hidden email]>wrote:
>
>> On Fri, May 25, 2012 at 1:25 AM, Jerome Velociter <[hidden email]
>> >wrote:
>>
>> > On Thu, May 24, 2012 at 6:09 PM, Thomas Mortagne
>> > <[hidden email]> wrote:
>> > > On Thu, May 24, 2012 at 5:52 PM, sasinda rukshan
>> > > <[hidden email]> wrote:
>> > >> Hi all,
>> > >> I am starting this thread for my XWiki Android Platform Project.
>> > >>
>> > >> Please check whether following are OK.
>> > >> [1] INFO
>> > >> I tried to start my new modules with the
>> de.akquinet.android.archetypes:
>> > >> android-quickstart:1.0.8.  (added eclipse plugins m2e,
>> > >> m2e-android[a.k.a  *Android
>> > >> Configurator* ]). But this seems buggy in eclipse.
>> > >> Any way the earlier project has not followed the above archtype
>> either.
>> > So
>> > >> I am going to write pom.xml manually for my each module.
>> > >>
>> > >> [2] ADVICE NEEDED
>> > >> xwiki-rest-model module contains 2 submodules
>> > >>  |-- xwiki-rest-model-gson  ( gson should be corrected to json)
>> > >
>> > > No the g is not a mistake, it's a model to be used with the gson
>> > > library (http://code.google.com/p/google-gson/). See
>> > >
>> >
>> http://extensions.xwiki.org/xwiki/bin/view/Extension/Google+Android+Client#HXWikiAndroidDevelopmentAPIsandResources
>> > .
>> > >
>> > >>  |-- xwiki-rest-model-simplexml
>> > >> I think the xwiki-rest-model-gson is redundant. The classes
>> > >> in xwiki-rest-model-simplexml is added with simple xml annotations,
>> > >> otherwise both modules have same classes. There is no problem with the
>> > >> added annotations for using the same model objects for Json REST web
>> > >> services. And I intend to add my JPA (ORMLite library for persistence)
>> > >> annotations on top of it.
>> > >> Shall I re-factor them to a single module xwiki-rest-model.
>> > >
>> > > No keep them separated, the idea is that both are useful tool to be
>> > > used by someone else that might be moved to xwiki-platform at some
>> > > point along with the current xwiki-rest-model (to be renamed to
>> > > xwiki-rest-model-jaxb).
>> > >
>> > > Chamika initially started with gson and since XWiki REST JSON
>> > > representation had some limitation he moved to XML representation.
>> > > Maybe at some point Android will have native support for jaxb which
>> > > would obviously be the easier for us (embedding jaxb is not an option
>> > > in mobile world where size it still pretty important especially on
>> > > phones). Maybe it's already the case on most recent versions like 4.0
>> > > I don't know.
>> >
>> > There's also Jackson that could be tried for JSON deserialization, if
>> > said limitations are actually GSON limitations.
>> >
>> GSON wasn't the limitation.
>> It was XWiki RESTful API which doesn't support JSON in some cases. So it's
>> safe to go with xml.
>>
>> >
>> > Having full JAXB support sound a bit overweight for such an "embedded
>> > API", even if one day it is natively supported by Android. What's
>> > important is to have an easy and fast deserialization, IMO.
>> > The only advantage I can see of going JAXB would be in re-using the
>> > exact representations and body readers/writers from XWiki core. But
>> > you probably don't even want to do that since it would mean dragging
>> > XWiki core with you :)
>> >
>> > Jerome
>> >
>> > >
>> > >>
>> > >> [3] INFO
>> > >>  I had to change some pom.xml s. As the current project at:
>> > >> https://github.com/xwiki-contrib/android-client.git does not build.
>> > Error
>> > >> with parent pom.xml coordinates.
>> > >
>> > > You probably did not setup you maven install properly since what's on
>> > > https://github.com/xwiki-contrib/android-client.git build perfectly as
>> > > you can see on http://ci.xwiki.org/view/All/job/xwiki-android-client/
>> > > which run a build every time something changes on the git repository..
>> > > You should look at
>> > > http://dev.xwiki.org/xwiki/bin/view/Community/Building.
>> > >
>> > >>
>> > >>
>> > >> Thank you
>> > >> Best Regards.
>> > >> Sasinda Rukshan
>> > >> _______________________________________________
>> > >> devs mailing list
>> > >> [hidden email]
>> > >> http://lists.xwiki.org/mailman/listinfo/devs
>> > >
>> > >
>> > >
>> > > --
>> > > Thomas Mortagne
>> > > _______________________________________________
>> > > devs mailing list
>> > > [hidden email]
>> > > http://lists.xwiki.org/mailman/listinfo/devs
>> >
>> >
>> >
>> > --
>> > Jérôme Velociter
>> > Winesquare
>> > http://www.winesquare.net/
>> > _______________________________________________
>> > devs mailing list
>> > [hidden email]
>> > http://lists.xwiki.org/mailman/listinfo/devs
>> >
>> _______________________________________________
>> devs mailing list
>> [hidden email]
>> http://lists.xwiki.org/mailman/listinfo/devs
>>
> _______________________________________________
> devs mailing list
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs



--
Thomas Mortagne
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [GSoc] XDroid Platform

Thomas Mortagne
Administrator
In reply to this post by sasinda
On Wed, May 30, 2012 at 4:28 AM, sasinda rukshan
<[hidden email]> wrote:
> Hi,
> I am studying ORM Lite these days.
> Please It would be comforting if you can confirm whether it is worth the
> overhead to use ORM Lite.
> http://logic-explained.blogspot.com/2011/12/using-ormlite-in-android-projects.html
> http://ormlite.com/
> ORM Lite features:
> Automatically Creates standard DAOs for an annotated entity.
> Coding will be lot easier.

Remember it's a framework for a mobile platform so it has to remain
light and have good performances. I can see that Android version of
ormlite is very small but I never used it so I don't know if it's good
or not. At least it seems petty active which is a good point so I
don't have anything against it.

>
> Can you suggest how to name the entities.
> I am going to go with,
> <entity>  org.xwiki.xdroid.data.User  --> <table> C_USER

Note that there is already a package name prefix and group id defined
for the framework and it's org.xwiki.android as you can see on
https://github.com/xwiki-contrib/android-client. Why do you want to
change it ? It's more consistent with
org.xwiki.commons/org.xwiki.rendering/org.xwiki.platform so I would
prefer to keep it that way unless you can give arguments. The goal is
not to redo something completely but complete and improve the existing
framework.

Also as far as I can see there is already several things called
"xdroid" on Google play among which an application developer
(https://play.google.com/store/apps/developer?id=x-droid) and an
application (https://play.google.com/store/apps/details?id=com.gurudigitalsolutions.xdroid).

>
> Thanks,
> Best Regards
>
> Sasinda.
>
>
>
>
>
> On Wed, May 30, 2012 at 7:42 AM, sasinda rukshan
> <[hidden email]>wrote:
>
>> Hi,
>>
>> I am commiting my work to my fork
>> https://github.com/sasinda/android-client.
>> I ll request to pull it to xwiki-contrib later.
>>
>> I was running in a wrong path these days. Wanted to save login history and
>> suggest login. I was going to do it using an xml file (login attempts.xml).
>> Now it seems database is better.
>> Any way before I go wrong again I will say what I am going to do.
>> I am going to enforce following conventions.These are not yet needed,
>> considered the small scale.But when the system grows it would be nice to
>> have them to avoid confusions.
>> *Database prefixes for:*
>> *Platform tables (can begin with appropriate prefix)*
>> AD_ //application dictionary : don't know when it will be needed ;-)
>> C_ //core functionality
>> *Client Applications.*
>> X<App name prefix>  ex: XBLOG_   for Blog app// All client add in modules
>> must begin with table prefix X(for xwiki and ordering) + App name.  This is
>> for my blog.
>>
>> I will create
>> C_User for user data.
>> C_LoginAttempt  for saving login attempts.
>>
>> From C_LoginAttempt I can filter uniqe login combinations and give
>> suggestions in the login UI component. Also save the history.
>>
>> All saved data for blog app will be linked to a perticular login : User,
>> XWiki server.
>> But only a single user will be most probably using his personal device. So
>> above will be relevant only when he has multiple wikis.
>>
>> Best Regards,
>> Sasinda Rukshan.
>>
>>
>>
>>
>>
>> On Sun, May 27, 2012 at 5:43 PM, Chamika Weerasinghe <[hidden email]>wrote:
>>
>>> On Fri, May 25, 2012 at 1:25 AM, Jerome Velociter <[hidden email]
>>> >wrote:
>>>
>>> > On Thu, May 24, 2012 at 6:09 PM, Thomas Mortagne
>>> > <[hidden email]> wrote:
>>> > > On Thu, May 24, 2012 at 5:52 PM, sasinda rukshan
>>> > > <[hidden email]> wrote:
>>> > >> Hi all,
>>> > >> I am starting this thread for my XWiki Android Platform Project.
>>> > >>
>>> > >> Please check whether following are OK.
>>> > >> [1] INFO
>>> > >> I tried to start my new modules with the
>>> de.akquinet.android.archetypes:
>>> > >> android-quickstart:1.0.8.  (added eclipse plugins m2e,
>>> > >> m2e-android[a.k.a  *Android
>>> > >> Configurator* ]). But this seems buggy in eclipse.
>>> > >> Any way the earlier project has not followed the above archtype
>>> either.
>>> > So
>>> > >> I am going to write pom.xml manually for my each module.
>>> > >>
>>> > >> [2] ADVICE NEEDED
>>> > >> xwiki-rest-model module contains 2 submodules
>>> > >>  |-- xwiki-rest-model-gson  ( gson should be corrected to json)
>>> > >
>>> > > No the g is not a mistake, it's a model to be used with the gson
>>> > > library (http://code.google.com/p/google-gson/). See
>>> > >
>>> >
>>> http://extensions.xwiki.org/xwiki/bin/view/Extension/Google+Android+Client#HXWikiAndroidDevelopmentAPIsandResources
>>> > .
>>> > >
>>> > >>  |-- xwiki-rest-model-simplexml
>>> > >> I think the xwiki-rest-model-gson is redundant. The classes
>>> > >> in xwiki-rest-model-simplexml is added with simple xml annotations,
>>> > >> otherwise both modules have same classes. There is no problem with
>>> the
>>> > >> added annotations for using the same model objects for Json REST web
>>> > >> services. And I intend to add my JPA (ORMLite library for
>>> persistence)
>>> > >> annotations on top of it.
>>> > >> Shall I re-factor them to a single module xwiki-rest-model.
>>> > >
>>> > > No keep them separated, the idea is that both are useful tool to be
>>> > > used by someone else that might be moved to xwiki-platform at some
>>> > > point along with the current xwiki-rest-model (to be renamed to
>>> > > xwiki-rest-model-jaxb).
>>> > >
>>> > > Chamika initially started with gson and since XWiki REST JSON
>>> > > representation had some limitation he moved to XML representation.
>>> > > Maybe at some point Android will have native support for jaxb which
>>> > > would obviously be the easier for us (embedding jaxb is not an option
>>> > > in mobile world where size it still pretty important especially on
>>> > > phones). Maybe it's already the case on most recent versions like 4.0
>>> > > I don't know.
>>> >
>>> > There's also Jackson that could be tried for JSON deserialization, if
>>> > said limitations are actually GSON limitations.
>>> >
>>> GSON wasn't the limitation.
>>> It was XWiki RESTful API which doesn't support JSON in some cases. So it's
>>> safe to go with xml.
>>>
>>> >
>>> > Having full JAXB support sound a bit overweight for such an "embedded
>>> > API", even if one day it is natively supported by Android. What's
>>> > important is to have an easy and fast deserialization, IMO.
>>> > The only advantage I can see of going JAXB would be in re-using the
>>> > exact representations and body readers/writers from XWiki core. But
>>> > you probably don't even want to do that since it would mean dragging
>>> > XWiki core with you :)
>>> >
>>> > Jerome
>>> >
>>> > >
>>> > >>
>>> > >> [3] INFO
>>> > >>  I had to change some pom.xml s. As the current project at:
>>> > >> https://github.com/xwiki-contrib/android-client.git does not build.
>>> > Error
>>> > >> with parent pom.xml coordinates.
>>> > >
>>> > > You probably did not setup you maven install properly since what's on
>>> > > https://github.com/xwiki-contrib/android-client.git build perfectly
>>> as
>>> > > you can see on http://ci.xwiki.org/view/All/job/xwiki-android-client/
>>> > > which run a build every time something changes on the git repository..
>>> > > You should look at
>>> > > http://dev.xwiki.org/xwiki/bin/view/Community/Building.
>>> > >
>>> > >>
>>> > >>
>>> > >> Thank you
>>> > >> Best Regards.
>>> > >> Sasinda Rukshan
>>> > >> _______________________________________________
>>> > >> devs mailing list
>>> > >> [hidden email]
>>> > >> http://lists.xwiki.org/mailman/listinfo/devs
>>> > >
>>> > >
>>> > >
>>> > > --
>>> > > Thomas Mortagne
>>> > > _______________________________________________
>>> > > devs mailing list
>>> > > [hidden email]
>>> > > http://lists.xwiki.org/mailman/listinfo/devs
>>> >
>>> >
>>> >
>>> > --
>>> > Jérôme Velociter
>>> > Winesquare
>>> > http://www.winesquare.net/
>>> > _______________________________________________
>>> > devs mailing list
>>> > [hidden email]
>>> > http://lists.xwiki.org/mailman/listinfo/devs
>>> >
>>> _______________________________________________
>>> devs mailing list
>>> [hidden email]
>>> http://lists.xwiki.org/mailman/listinfo/devs
>>>
>>
>>
> _______________________________________________
> devs mailing list
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs



--
Thomas Mortagne
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [GSoc] XDroid Platform

sasinda
Hi,
*1: User Config Saving*
*
*
Xwiki android can now save user login data.
I refered http://platform.xwiki.org/xwiki/bin/view/AdminGuide/AccessWiki.
Currently assuming the authority
part(platform.xwiki.org<http://platform.xwiki.org/xwiki/bin/view/AdminGuide/AccessWiki>)
only
as a unique wiki identifier. But in the org.xwiki.android.entity.User I
have the method
setXWikiRealm(String url);:
Here I have intended the meaning realm as the url root path for a unique
wiki instance.
i.e. it should identify a wiki using path upto
http://host/xwiki/wiki/wikialias/
But that functionality is not implemented.I just mailed this asking for the
opinion wether the usage of word realm was right here.
Also do you have seperate users for  wikis for path based wiki access.Or
are they the same with the main wiki *http://<host>/xwiki*.
*2: Entity model*
*
*
About the convention for using C_ prefix for core entity tables. I
was referring to make the android versions of these entities
http://platform.xwiki.org/xwiki/bin/view/DevGuide/DatabaseSchema and start
there db prefixes with C_
This is because other apps may need to store some specific tables needed
for them. Rather than having a seperate DB schema for them we can put those
tables here as well prefixing them with <appname>_ .
I added more entities like User as well to the core entities(table
C_User).Also will implement a Log Entity(C_Log table) for logging some
important application activities(such as login attempts) But the Log may be
a little additional weight to the space and performance.I may implement a
generic DBCleaning service to clean the tables like Log, if I have time.
(Perhaps this description will resolve the confusion about the DB
conventions. Sorry I was not very clear in that earlier mail. ;-).)

I am sorry to say I am somewhat confused with all those entities in
http://platform.xwiki.org/xwiki/bin/view/DevGuide/DatabaseSchema.

Any way to reduce my confusion
I refered
1)  XWiki Data Model<http://platform.xwiki.org/xwiki/bin/view/DevGuide/DataModel>
:
   can you give me a link to a documentation that explains the workflow of
how a normal request is converted in to the requested page by the
bin View action . So I can get a better understanding of how classes ,
objects are used.
2)  package com.xpn.xwiki.api: I don't need to consider this, do I?
3)  Cache<http://extensions.xwiki.org/xwiki/bin/view/Extension/Cache+Module>
 : Need not implement similar component. Android OS does it nicely for the
REST responses
but still don't have a clear picture on this.
To save a blog doc
option 1)Seems like I have to convert a document entity to relevent
xwiki-model-simplexml entities and send to server.
option 2) We also can edit the relevent simplexml model object fields
directly. (Looks a bad option to me.It does not hide the complexity of
lower levels for the client layer.Anyway my work load  is reduced with
opt:2 ;-))


*3: Development/architectural approach Change*
*
*
I was first thinking for a addon like architecture for the XWiki android
app. We have the client.Main app (with all platfrom libs included) and Blog
app as a seperate apk.
But here Blog app will need to have the platform lib also. That would be a
complete waste of space. But dynamically extending the app is lot easier.
The client.Main app can add the activities defined in other apks in to its
launcher interface using android PackageManager class.
http://stackoverflow.com/questions/9236803/android-build-an-application-that-supports-add-ons
But with this approach rises additional complexities. For example naming
conflicts in the Components library module when two apps have the same
library with same activities defined. Sync issues etc etc....
So we will go with single .apk approach.
When going with single .apk we dont need a content provider to share
config/ preferences data. So sharing module is now not needed. The client
applications now can directly access the Configuration.java class to
get/put configuration entries.
Also since I am having a User entity a configuration like
defaultUser(currently the admin user , hard coded in login.xml layout file)
will only be needed for the first use of the app. Otherwise users need not
configure a default user as the application now suggests the user names and
automatically fill the rest.

*4: Plan for this week*
*
*
Make a launch pad .We can launch XWiki Navigator, blog etc from this. The
launch pad is shown when we launch XWiki main client.
Consider adding the WYSIWYG to my blog. It will be useless without the
ability to convert text formatting to xwiki syntax.So I may just integrate
it and ignore the uselessness for now.
We currently don't have any config to save( Other than default user)
config. I will add some demo config data and have a developer tools app
added to the above mentioned XWiki launch pad that can view/edit the config
file.

That will complete milestone 1. But it is not the Sharing module(intended
to share data with other .apks).That is the configuration component does
not have a ContentProvider to share config data with other apks. Also I
will define a seperate class to have preferences which will be edited by
users. Config files are for configuration stuff and will be edited by
developers. Users have preferences files(natively supported by android) to
change app preferences. For example users will add the default login
username as a preference.(This will invalidate the use of default User
entry in the config file which is used until the user edits his preferences)

Beg your pardon if the mail is too lengthy.;-)
Thank you.
Best Regards.

Sasinda Rukshan.


Best Regards.


On Wed, May 30, 2012 at 1:11 PM, Thomas Mortagne
<[hidden email]>wrote:

> On Wed, May 30, 2012 at 4:28 AM, sasinda rukshan
> <[hidden email]> wrote:
> > Hi,
> > I am studying ORM Lite these days.
> > Please It would be comforting if you can confirm whether it is worth the
> > overhead to use ORM Lite.
> >
> http://logic-explained.blogspot.com/2011/12/using-ormlite-in-android-projects.html
> > http://ormlite.com/
> > ORM Lite features:
> > Automatically Creates standard DAOs for an annotated entity.
> > Coding will be lot easier.
>
> Remember it's a framework for a mobile platform so it has to remain
> light and have good performances. I can see that Android version of
> ormlite is very small but I never used it so I don't know if it's good
> or not. At least it seems petty active which is a good point so I
> don't have anything against it.
>
> >
> > Can you suggest how to name the entities.
> > I am going to go with,
> > <entity>  org.xwiki.xdroid.data.User  --> <table> C_USER
>
> Note that there is already a package name prefix and group id defined
> for the framework and it's org.xwiki.android as you can see on
> https://github.com/xwiki-contrib/android-client. Why do you want to
> change it ? It's more consistent with
> org.xwiki.commons/org.xwiki.rendering/org.xwiki.platform so I would
> prefer to keep it that way unless you can give arguments. The goal is
> not to redo something completely but complete and improve the existing
> framework.
>
> Also as far as I can see there is already several things called
> "xdroid" on Google play among which an application developer
> (https://play.google.com/store/apps/developer?id=x-droid) and an
> application (
> https://play.google.com/store/apps/details?id=com.gurudigitalsolutions.xdroid
> ).
>
> >
> > Thanks,
> > Best Regards
> >
> > Sasinda.
> >
> >
> >
> >
> >
> > On Wed, May 30, 2012 at 7:42 AM, sasinda rukshan
> > <[hidden email]>wrote:
> >
> >> Hi,
> >>
> >> I am commiting my work to my fork
> >> https://github.com/sasinda/android-client.
> >> I ll request to pull it to xwiki-contrib later.
> >>
> >> I was running in a wrong path these days. Wanted to save login history
> and
> >> suggest login. I was going to do it using an xml file (login
> attempts.xml).
> >> Now it seems database is better.
> >> Any way before I go wrong again I will say what I am going to do.
> >> I am going to enforce following conventions.These are not yet needed,
> >> considered the small scale.But when the system grows it would be nice to
> >> have them to avoid confusions.
> >> *Database prefixes for:*
> >> *Platform tables (can begin with appropriate prefix)*
> >> AD_ //application dictionary : don't know when it will be needed ;-)
> >> C_ //core functionality
> >> *Client Applications.*
> >> X<App name prefix>  ex: XBLOG_   for Blog app// All client add in
> modules
> >> must begin with table prefix X(for xwiki and ordering) + App name.
>  This is
> >> for my blog.
> >>
> >> I will create
> >> C_User for user data.
> >> C_LoginAttempt  for saving login attempts.
> >>
> >> From C_LoginAttempt I can filter uniqe login combinations and give
> >> suggestions in the login UI component. Also save the history.
> >>
> >> All saved data for blog app will be linked to a perticular login : User,
> >> XWiki server.
> >> But only a single user will be most probably using his personal device.
> So
> >> above will be relevant only when he has multiple wikis.
> >>
> >> Best Regards,
> >> Sasinda Rukshan.
> >>
> >>
> >>
> >>
> >>
> >> On Sun, May 27, 2012 at 5:43 PM, Chamika Weerasinghe <
> [hidden email]>wrote:
> >>
> >>> On Fri, May 25, 2012 at 1:25 AM, Jerome Velociter <
> [hidden email]
> >>> >wrote:
> >>>
> >>> > On Thu, May 24, 2012 at 6:09 PM, Thomas Mortagne
> >>> > <[hidden email]> wrote:
> >>> > > On Thu, May 24, 2012 at 5:52 PM, sasinda rukshan
> >>> > > <[hidden email]> wrote:
> >>> > >> Hi all,
> >>> > >> I am starting this thread for my XWiki Android Platform Project.
> >>> > >>
> >>> > >> Please check whether following are OK.
> >>> > >> [1] INFO
> >>> > >> I tried to start my new modules with the
> >>> de.akquinet.android.archetypes:
> >>> > >> android-quickstart:1.0.8.  (added eclipse plugins m2e,
> >>> > >> m2e-android[a.k.a  *Android
> >>> > >> Configurator* ]). But this seems buggy in eclipse.
> >>> > >> Any way the earlier project has not followed the above archtype
> >>> either.
> >>> > So
> >>> > >> I am going to write pom.xml manually for my each module.
> >>> > >>
> >>> > >> [2] ADVICE NEEDED
> >>> > >> xwiki-rest-model module contains 2 submodules
> >>> > >>  |-- xwiki-rest-model-gson  ( gson should be corrected to json)
> >>> > >
> >>> > > No the g is not a mistake, it's a model to be used with the gson
> >>> > > library (http://code.google.com/p/google-gson/). See
> >>> > >
> >>> >
> >>>
> http://extensions.xwiki.org/xwiki/bin/view/Extension/Google+Android+Client#HXWikiAndroidDevelopmentAPIsandResources
> >>> > .
> >>> > >
> >>> > >>  |-- xwiki-rest-model-simplexml
> >>> > >> I think the xwiki-rest-model-gson is redundant. The classes
> >>> > >> in xwiki-rest-model-simplexml is added with simple xml
> annotations,
> >>> > >> otherwise both modules have same classes. There is no problem with
> >>> the
> >>> > >> added annotations for using the same model objects for Json REST
> web
> >>> > >> services. And I intend to add my JPA (ORMLite library for
> >>> persistence)
> >>> > >> annotations on top of it.
> >>> > >> Shall I re-factor them to a single module xwiki-rest-model.
> >>> > >
> >>> > > No keep them separated, the idea is that both are useful tool to be
> >>> > > used by someone else that might be moved to xwiki-platform at some
> >>> > > point along with the current xwiki-rest-model (to be renamed to
> >>> > > xwiki-rest-model-jaxb).
> >>> > >
> >>> > > Chamika initially started with gson and since XWiki REST JSON
> >>> > > representation had some limitation he moved to XML representation.
> >>> > > Maybe at some point Android will have native support for jaxb which
> >>> > > would obviously be the easier for us (embedding jaxb is not an
> option
> >>> > > in mobile world where size it still pretty important especially on
> >>> > > phones). Maybe it's already the case on most recent versions like
> 4.0
> >>> > > I don't know.
> >>> >
> >>> > There's also Jackson that could be tried for JSON deserialization, if
> >>> > said limitations are actually GSON limitations.
> >>> >
> >>> GSON wasn't the limitation.
> >>> It was XWiki RESTful API which doesn't support JSON in some cases. So
> it's
> >>> safe to go with xml.
> >>>
> >>> >
> >>> > Having full JAXB support sound a bit overweight for such an "embedded
> >>> > API", even if one day it is natively supported by Android. What's
> >>> > important is to have an easy and fast deserialization, IMO.
> >>> > The only advantage I can see of going JAXB would be in re-using the
> >>> > exact representations and body readers/writers from XWiki core. But
> >>> > you probably don't even want to do that since it would mean dragging
> >>> > XWiki core with you :)
> >>> >
> >>> > Jerome
> >>> >
> >>> > >
> >>> > >>
> >>> > >> [3] INFO
> >>> > >>  I had to change some pom.xml s. As the current project at:
> >>> > >> https://github.com/xwiki-contrib/android-client.git does not
> build.
> >>> > Error
> >>> > >> with parent pom.xml coordinates.
> >>> > >
> >>> > > You probably did not setup you maven install properly since what's
> on
> >>> > > https://github.com/xwiki-contrib/android-client.git build
> perfectly
> >>> as
> >>> > > you can see on
> http://ci.xwiki.org/view/All/job/xwiki-android-client/
> >>> > > which run a build every time something changes on the git
> repository..
> >>> > > You should look at
> >>> > > http://dev.xwiki.org/xwiki/bin/view/Community/Building.
> >>> > >
> >>> > >>
> >>> > >>
> >>> > >> Thank you
> >>> > >> Best Regards.
> >>> > >> Sasinda Rukshan
> >>> > >> _______________________________________________
> >>> > >> devs mailing list
> >>> > >> [hidden email]
> >>> > >> http://lists.xwiki.org/mailman/listinfo/devs
> >>> > >
> >>> > >
> >>> > >
> >>> > > --
> >>> > > Thomas Mortagne
> >>> > > _______________________________________________
> >>> > > devs mailing list
> >>> > > [hidden email]
> >>> > > http://lists.xwiki.org/mailman/listinfo/devs
> >>> >
> >>> >
> >>> >
> >>> > --
> >>> > Jérôme Velociter
> >>> > Winesquare
> >>> > http://www.winesquare.net/
> >>> > _______________________________________________
> >>> > devs mailing list
> >>> > [hidden email]
> >>> > http://lists.xwiki.org/mailman/listinfo/devs
> >>> >
> >>> _______________________________________________
> >>> devs mailing list
> >>> [hidden email]
> >>> http://lists.xwiki.org/mailman/listinfo/devs
> >>>
> >>
> >>
> > _______________________________________________
> > devs mailing list
> > [hidden email]
> > http://lists.xwiki.org/mailman/listinfo/devs
>
>
>
> --
> Thomas Mortagne
> _______________________________________________
> devs mailing list
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs
>
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [GSoc] XDroid Platform

Thomas Mortagne
Administrator
On Tue, Jun 5, 2012 at 7:07 PM, sasinda rukshan
<[hidden email]> wrote:

> Hi,
> *1: User Config Saving*
> *
> *
> Xwiki android can now save user login data.
> I refered http://platform.xwiki.org/xwiki/bin/view/AdminGuide/AccessWiki.
> Currently assuming the authority
> part(platform.xwiki.org<http://platform.xwiki.org/xwiki/bin/view/AdminGuide/AccessWiki>)
> only
> as a unique wiki identifier. But in the org.xwiki.android.entity.User I
> have the method
> setXWikiRealm(String url);:
> Here I have intended the meaning realm as the url root path for a unique
> wiki instance.
> i.e. it should identify a wiki using path upto
> http://host/xwiki/wiki/wikialias/
> But that functionality is not implemented.I just mailed this asking for the
> opinion wether the usage of word realm was right here.
> Also do you have seperate users for  wikis for path based wiki access.Or
> are they the same with the main wiki *http://<host>/xwiki*.

Both actually, you can have global users (which are the one on main
wiki) and local users.

> *2: Entity model*
> *
> *
> About the convention for using C_ prefix for core entity tables. I
> was referring to make the android versions of these entities
> http://platform.xwiki.org/xwiki/bin/view/DevGuide/DatabaseSchema and start
> there db prefixes with C_
> This is because other apps may need to store some specific tables needed
> for them. Rather than having a seperate DB schema for them we can put those
> tables here as well prefixing them with <appname>_ .
> I added more entities like User as well to the core entities(table
> C_User).Also will implement a Log Entity(C_Log table) for logging some
> important application activities(such as login attempts) But the Log may be
> a little additional weight to the space and performance.I may implement a
> generic DBCleaning service to clean the tables like Log, if I have time.
> (Perhaps this description will resolve the confusion about the DB
> conventions. Sorry I was not very clear in that earlier mail. ;-).)
>
> I am sorry to say I am somewhat confused with all those entities in
> http://platform.xwiki.org/xwiki/bin/view/DevGuide/DatabaseSchema.

The XWiki model is based on generic classes and objects wich is why
you see lots of tables (class properties, object properties , etc.).
There is no table for users for example, its an object of class
XWiki.XWikiUsers.

>
> Any way to reduce my confusion
> I refered
> 1)  XWiki Data Model<http://platform.xwiki.org/xwiki/bin/view/DevGuide/DataModel>
> :
>   can you give me a link to a documentation that explains the workflow of
> how a normal request is converted in to the requested page by the
> bin View action . So I can get a better understanding of how classes ,
> objects are used.

Not sure there is one. but basically you get either:
* document content executed
* if a class sheet is defined for one of the document objects classes,
the class sheet is executed
* if a document sheet is defined for the documment, the document sheet
is executed

That's pretty much all, then is a matter of free script and wiki
syntax to actually display the content.

> 2)  package com.xpn.xwiki.api: I don't need to consider this, do I?

That's limited scripting API so you should not consider this.

> 3)  Cache<http://extensions.xwiki.org/xwiki/bin/view/Extension/Cache+Module>
>  : Need not implement similar component. Android OS does it nicely for the
> REST responses
> but still don't have a clear picture on this.
> To save a blog doc
> option 1)Seems like I have to convert a document entity to relevent
> xwiki-model-simplexml entities and send to server.
> option 2) We also can edit the relevent simplexml model object fields
> directly. (Looks a bad option to me.It does not hide the complexity of
> lower levels for the client layer.Anyway my work load  is reduced with
> opt:2 ;-))

IMO you should not even look at
http://extensions.xwiki.org/xwiki/bin/view/Extension/Cache+Module and
instead look at how caching is usually done in Android. The idea is
not to port the xwiki-platform to Android IMO but to follow Android
standards to provide a library to manipulate XWiki model.

You can set the annotation you want to the simplexml model but the
classes/methods should remain an exact copy of what's on
xwiki-platform-rest-model. The idea being that we could decide to
change the implementation from simplexml to anything (JAXB, gson,
etc.) without breaking anything.

>
>
> *3: Development/architectural approach Change*
> *
> *
> I was first thinking for a addon like architecture for the XWiki android
> app. We have the client.Main app (with all platfrom libs included) and Blog
> app as a seperate apk.
> But here Blog app will need to have the platform lib also. That would be a
> complete waste of space. But dynamically extending the app is lot easier.
> The client.Main app can add the activities defined in other apks in to its
> launcher interface using android PackageManager class.
> http://stackoverflow.com/questions/9236803/android-build-an-application-that-supports-add-ons
> But with this approach rises additional complexities. For example naming
> conflicts in the Components library module when two apps have the same
> library with same activities defined. Sync issues etc etc....
> So we will go with single .apk approach.
> When going with single .apk we dont need a content provider to share
> config/ preferences data. So sharing module is now not needed. The client
> applications now can directly access the Configuration.java class to
> get/put configuration entries.
> Also since I am having a User entity a configuration like
> defaultUser(currently the admin user , hard coded in login.xml layout file)
> will only be needed for the first use of the app. Otherwise users need not
> configure a default user as the application now suggests the user names and
> automatically fill the rest.

Keep in mind that the main goal of this project is to provide tools
for any application to access an XWiki instance and manipulate its
datas easily an improving those libraries should always be the first
goal. Your blog application is here as a good demo and because it's
hard to design a library without using it.

I really don't understand why you talk about naming conflict. Of
course a library should never provide a complete final activity but
only interface components (View), fragments or base activities to
extend. Putting those elements in an activity is each application job.
An activity is by definition unique so it has nothing to do in a
library. The complete activities in
https://github.com/xwiki-contrib/android-client/tree/master/xwiki-android-components/
should have never been there, it's actually a mistake.

>
> *4: Plan for this week*

As a priority you should really merge your branch as soon as you have
something building fine. So that it goes through Jenkins and deploy
snapshot build of what you do. Jenkins will tells you in live when
your project does not build anymore or if there is any test failing
and it allows anyone to very easily test the current test of the
client just by installing the apks on
http://maven.xwiki.org/snapshots/org/xwiki/android/. You need to have
something working and in good shape to succeed the GSOC so fixing when
you break something in your build should be your priority over adding
more features.

Also as I commented in your commit you should be more careful on what
you commit. There is many binaries and Eclipse stuff in your branch.

> *
> *
> Make a launch pad .We can launch XWiki Navigator, blog etc from this. The
> launch pad is shown when we launch XWiki main client.
> Consider adding the WYSIWYG to my blog. It will be useless without the
> ability to convert text formatting to xwiki syntax.So I may just integrate
> it and ignore the uselessness for now.

Not exactly, you could actually reuse WYSIWYG service to send html and
let it convert it to wiki syntax. Note that you are not limited to
what you can find in the current Android library. This is just what
Chamika had the time to do. There is others REST (or not REST) server
interfaces you can use in your client or even add more if its generic
enough and make sense for something else than just Android client.

> We currently don't have any config to save( Other than default user)
> config. I will add some demo config data and have a developer tools app
> added to the above mentioned XWiki launch pad that can view/edit the config
> file.
>
> That will complete milestone 1. But it is not the Sharing module(intended
> to share data with other .apks).That is the configuration component does
> not have a ContentProvider to share config data with other apks. Also I
> will define a seperate class to have preferences which will be edited by
> users. Config files are for configuration stuff and will be edited by
> developers. Users have preferences files(natively supported by android) to
> change app preferences. For example users will add the default login
> username as a preference.(This will invalidate the use of default User
> entry in the config file which is used until the user edits his preferences)

I'm fine with not sharing datas between applications but it does not
prevent the libraries to  provide tools to manage those datas in a per
application basis.

>
> Beg your pardon if the mail is too lengthy.;-)

No problem, never too much information for this ;)

> Thank you.
> Best Regards.
>
> Sasinda Rukshan.
>
>
> Best Regards.
>
>
> On Wed, May 30, 2012 at 1:11 PM, Thomas Mortagne
> <[hidden email]>wrote:
>
>> On Wed, May 30, 2012 at 4:28 AM, sasinda rukshan
>> <[hidden email]> wrote:
>> > Hi,
>> > I am studying ORM Lite these days.
>> > Please It would be comforting if you can confirm whether it is worth the
>> > overhead to use ORM Lite.
>> >
>> http://logic-explained.blogspot.com/2011/12/using-ormlite-in-android-projects.html
>> > http://ormlite.com/
>> > ORM Lite features:
>> > Automatically Creates standard DAOs for an annotated entity.
>> > Coding will be lot easier.
>>
>> Remember it's a framework for a mobile platform so it has to remain
>> light and have good performances. I can see that Android version of
>> ormlite is very small but I never used it so I don't know if it's good
>> or not. At least it seems petty active which is a good point so I
>> don't have anything against it.
>>
>> >
>> > Can you suggest how to name the entities.
>> > I am going to go with,
>> > <entity>  org.xwiki.xdroid.data.User  --> <table> C_USER
>>
>> Note that there is already a package name prefix and group id defined
>> for the framework and it's org.xwiki.android as you can see on
>> https://github.com/xwiki-contrib/android-client. Why do you want to
>> change it ? It's more consistent with
>> org.xwiki.commons/org.xwiki.rendering/org.xwiki.platform so I would
>> prefer to keep it that way unless you can give arguments. The goal is
>> not to redo something completely but complete and improve the existing
>> framework.
>>
>> Also as far as I can see there is already several things called
>> "xdroid" on Google play among which an application developer
>> (https://play.google.com/store/apps/developer?id=x-droid) and an
>> application (
>> https://play.google.com/store/apps/details?id=com.gurudigitalsolutions.xdroid
>> ).
>>
>> >
>> > Thanks,
>> > Best Regards
>> >
>> > Sasinda.
>> >
>> >
>> >
>> >
>> >
>> > On Wed, May 30, 2012 at 7:42 AM, sasinda rukshan
>> > <[hidden email]>wrote:
>> >
>> >> Hi,
>> >>
>> >> I am commiting my work to my fork
>> >> https://github.com/sasinda/android-client.
>> >> I ll request to pull it to xwiki-contrib later.
>> >>
>> >> I was running in a wrong path these days. Wanted to save login history
>> and
>> >> suggest login. I was going to do it using an xml file (login
>> attempts.xml).
>> >> Now it seems database is better.
>> >> Any way before I go wrong again I will say what I am going to do.
>> >> I am going to enforce following conventions.These are not yet needed,
>> >> considered the small scale.But when the system grows it would be nice to
>> >> have them to avoid confusions.
>> >> *Database prefixes for:*
>> >> *Platform tables (can begin with appropriate prefix)*
>> >> AD_ //application dictionary : don't know when it will be needed ;-)
>> >> C_ //core functionality
>> >> *Client Applications.*
>> >> X<App name prefix>  ex: XBLOG_   for Blog app// All client add in
>> modules
>> >> must begin with table prefix X(for xwiki and ordering) + App name.
>>  This is
>> >> for my blog.
>> >>
>> >> I will create
>> >> C_User for user data.
>> >> C_LoginAttempt  for saving login attempts.
>> >>
>> >> From C_LoginAttempt I can filter uniqe login combinations and give
>> >> suggestions in the login UI component. Also save the history.
>> >>
>> >> All saved data for blog app will be linked to a perticular login : User,
>> >> XWiki server.
>> >> But only a single user will be most probably using his personal device.
>> So
>> >> above will be relevant only when he has multiple wikis.
>> >>
>> >> Best Regards,
>> >> Sasinda Rukshan.
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> On Sun, May 27, 2012 at 5:43 PM, Chamika Weerasinghe <
>> [hidden email]>wrote:
>> >>
>> >>> On Fri, May 25, 2012 at 1:25 AM, Jerome Velociter <
>> [hidden email]
>> >>> >wrote:
>> >>>
>> >>> > On Thu, May 24, 2012 at 6:09 PM, Thomas Mortagne
>> >>> > <[hidden email]> wrote:
>> >>> > > On Thu, May 24, 2012 at 5:52 PM, sasinda rukshan
>> >>> > > <[hidden email]> wrote:
>> >>> > >> Hi all,
>> >>> > >> I am starting this thread for my XWiki Android Platform Project.
>> >>> > >>
>> >>> > >> Please check whether following are OK.
>> >>> > >> [1] INFO
>> >>> > >> I tried to start my new modules with the
>> >>> de.akquinet.android.archetypes:
>> >>> > >> android-quickstart:1.0.8.  (added eclipse plugins m2e,
>> >>> > >> m2e-android[a.k.a  *Android
>> >>> > >> Configurator* ]). But this seems buggy in eclipse.
>> >>> > >> Any way the earlier project has not followed the above archtype
>> >>> either.
>> >>> > So
>> >>> > >> I am going to write pom.xml manually for my each module.
>> >>> > >>
>> >>> > >> [2] ADVICE NEEDED
>> >>> > >> xwiki-rest-model module contains 2 submodules
>> >>> > >>  |-- xwiki-rest-model-gson  ( gson should be corrected to json)
>> >>> > >
>> >>> > > No the g is not a mistake, it's a model to be used with the gson
>> >>> > > library (http://code.google.com/p/google-gson/). See
>> >>> > >
>> >>> >
>> >>>
>> http://extensions.xwiki.org/xwiki/bin/view/Extension/Google+Android+Client#HXWikiAndroidDevelopmentAPIsandResources
>> >>> > .
>> >>> > >
>> >>> > >>  |-- xwiki-rest-model-simplexml
>> >>> > >> I think the xwiki-rest-model-gson is redundant. The classes
>> >>> > >> in xwiki-rest-model-simplexml is added with simple xml
>> annotations,
>> >>> > >> otherwise both modules have same classes. There is no problem with
>> >>> the
>> >>> > >> added annotations for using the same model objects for Json REST
>> web
>> >>> > >> services. And I intend to add my JPA (ORMLite library for
>> >>> persistence)
>> >>> > >> annotations on top of it.
>> >>> > >> Shall I re-factor them to a single module xwiki-rest-model.
>> >>> > >
>> >>> > > No keep them separated, the idea is that both are useful tool to be
>> >>> > > used by someone else that might be moved to xwiki-platform at some
>> >>> > > point along with the current xwiki-rest-model (to be renamed to
>> >>> > > xwiki-rest-model-jaxb).
>> >>> > >
>> >>> > > Chamika initially started with gson and since XWiki REST JSON
>> >>> > > representation had some limitation he moved to XML representation.
>> >>> > > Maybe at some point Android will have native support for jaxb which
>> >>> > > would obviously be the easier for us (embedding jaxb is not an
>> option
>> >>> > > in mobile world where size it still pretty important especially on
>> >>> > > phones). Maybe it's already the case on most recent versions like
>> 4.0
>> >>> > > I don't know.
>> >>> >
>> >>> > There's also Jackson that could be tried for JSON deserialization, if
>> >>> > said limitations are actually GSON limitations.
>> >>> >
>> >>> GSON wasn't the limitation.
>> >>> It was XWiki RESTful API which doesn't support JSON in some cases. So
>> it's
>> >>> safe to go with xml.
>> >>>
>> >>> >
>> >>> > Having full JAXB support sound a bit overweight for such an "embedded
>> >>> > API", even if one day it is natively supported by Android. What's
>> >>> > important is to have an easy and fast deserialization, IMO.
>> >>> > The only advantage I can see of going JAXB would be in re-using the
>> >>> > exact representations and body readers/writers from XWiki core. But
>> >>> > you probably don't even want to do that since it would mean dragging
>> >>> > XWiki core with you :)
>> >>> >
>> >>> > Jerome
>> >>> >
>> >>> > >
>> >>> > >>
>> >>> > >> [3] INFO
>> >>> > >>  I had to change some pom.xml s. As the current project at:
>> >>> > >> https://github.com/xwiki-contrib/android-client.git does not
>> build.
>> >>> > Error
>> >>> > >> with parent pom.xml coordinates.
>> >>> > >
>> >>> > > You probably did not setup you maven install properly since what's
>> on
>> >>> > > https://github.com/xwiki-contrib/android-client.git build
>> perfectly
>> >>> as
>> >>> > > you can see on
>> http://ci.xwiki.org/view/All/job/xwiki-android-client/
>> >>> > > which run a build every time something changes on the git
>> repository..
>> >>> > > You should look at
>> >>> > > http://dev.xwiki.org/xwiki/bin/view/Community/Building.
>> >>> > >
>> >>> > >>
>> >>> > >>
>> >>> > >> Thank you
>> >>> > >> Best Regards.
>> >>> > >> Sasinda Rukshan
>> >>> > >> _______________________________________________
>> >>> > >> devs mailing list
>> >>> > >> [hidden email]
>> >>> > >> http://lists.xwiki.org/mailman/listinfo/devs
>> >>> > >
>> >>> > >
>> >>> > >
>> >>> > > --
>> >>> > > Thomas Mortagne
>> >>> > > _______________________________________________
>> >>> > > devs mailing list
>> >>> > > [hidden email]
>> >>> > > http://lists.xwiki.org/mailman/listinfo/devs
>> >>> >
>> >>> >
>> >>> >
>> >>> > --
>> >>> > Jérôme Velociter
>> >>> > Winesquare
>> >>> > http://www.winesquare.net/
>> >>> > _______________________________________________
>> >>> > devs mailing list
>> >>> > [hidden email]
>> >>> > http://lists.xwiki.org/mailman/listinfo/devs
>> >>> >
>> >>> _______________________________________________
>> >>> devs mailing list
>> >>> [hidden email]
>> >>> http://lists.xwiki.org/mailman/listinfo/devs
>> >>>
>> >>
>> >>
>> > _______________________________________________
>> > devs mailing list
>> > [hidden email]
>> > http://lists.xwiki.org/mailman/listinfo/devs
>>
>>
>>
>> --
>> Thomas Mortagne
>> _______________________________________________
>> devs mailing list
>> [hidden email]
>> http://lists.xwiki.org/mailman/listinfo/devs
>>
> _______________________________________________
> devs mailing list
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs



--
Thomas Mortagne
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [GSoc] XDroid Platform

sasinda
Thanks very much for the help on maven build.

*About making a object from Blog.BlogPostClass  and toXML()*

A blog object is having properties of type other xobject classes. So to
make the things general can we do a stripped down replication or make
something similer to the java classes in com.xpn.xwiki.objects and its 2
sub packages .classes, .meta .
 We can make a document object representing a page and put a
Blog.BlogPostClass object to its list of objects.We can convert them to
simple xml model directly.If we want to post blog object we can post the
Blog object.If the page does not exist we can put the page by getting the
xml from the Document object.
Then the things will be general not only for blog client app. Also we can
have Type checking when we don't directly manipulate simplexml objects.
i.e. XStringClass will define the attributes for it and likewise.

I don't have a good idea on the above packages and classes. Specially why
there are three classes for each XType ex: StringProperty, StringClass,
StringMeta.
It will be helpful if you can give an explanation.

My draft solution is to do some simple thing as,
XObject
 |____ XBoolean

XObject
|____XString

XString has methods,
toEmbedXML  gives a <property><attribute/>...</property> string/ simpleXML
objects
toXML  gives <object><id><ClassName>.......</object> for the same thing.

Also
XObject
|_____ XBlogPost       for(BlogPostClass and other 2 Meta,Property classes)

I don't yet have a clear idea on this. May be I am wrong on this.
Can you give me your idea here as well. How to approach the problem and
what should the design be like?

Thanks.
Best Regards
Sasinda.



On Thu, Jun 7, 2012 at 9:28 PM, Thomas Mortagne
<[hidden email]>wrote:

> As just did a commit with last version of android plugin and some
> cleanup. Seems to work well.
>
> On Thu, Jun 7, 2012 at 12:19 PM, Thomas Mortagne
> <[hidden email]> wrote:
> > BTW if you have quick questions it's probaly better to use IRC (I'm
> > tmortgane on the channel and I'm on GMT+2 tome zone but you can ask
> > anyone when I'm not around). See
> > http://dev.xwiki.org/xwiki/bin/view/Community/IRC.
> >
> > On Thu, Jun 7, 2012 at 12:17 PM, Thomas Mortagne
> > <[hidden email]> wrote:
> >> Not need to send this kind of mail privately to me.
> >>
> >> On Thu, Jun 7, 2012 at 5:33 AM, sasinda rukshan
> >> <[hidden email]> wrote:
> >>> Thanks,
> >>> The project is building perfectly well in eclipse (and runs well too)
> [I
> >>> configured the build paths for eclipse opening each module as a
> project and
> >>> giving project dependencies and etc.]. This is because android facet
> and
> >>> maven-android plugin for eclipse [m2e-android] (not the jayway  androi
> maven
> >>> plugin)does not work together well.
> >>> Maven build does not work with newer jayway android maven plugins
> because of
> >>> the simplexml library. I checked with another helloworld app that does
> not
> >>> have simplexml dependancy and have simplexml dependancy. When we have
> the
> >>> dependancy it does not work. Also when packaged with the beta version
> maven
> >>> plugin I get runtime error logs notifying that the exact classes
> informed
> >>> missed in the compile time for newer maven plugin are missing. But the
> app
> >>> is running ok.
> >>> I will try with it some more and if I can't can you help me with it a
> >>> little.
> >>
> >> Sure If it's just related to simplexml it's probably not much. I will
> >> try to take a look today. At worst the version we are using right now
> >> is working fine so you can continue with it anyway.
> >>
> >>>
> >>> I looked at the Enterprise platform apis just to make my apis similar
> when
> >>> possible.Source code is not at all relevant to me. But as you say It
> will be
> >>> imperfect if I use its style heavily for the mobile version as well.
> >>
> >> Yes there is several issues here:
> >> * most APIs in oldcore module are old and bad and we are trying to get
> >> rif of them so better not getting too much attached to it ;)
> >> * they are designed to run in an enironment with lots of resources and
> >> don't care as much as a mobile API should about memory, etc.
> >>
> >>>
> >>>
> >>> Thank you.
> >>> Best Regards.
> >>> Sasinda.
> >>>
> >>>
> >>> On Wed, Jun 6, 2012 at 1:03 PM, Thomas Mortagne <
> [hidden email]>
> >>> wrote:
> >>>>
> >>>> On Tue, Jun 5, 2012 at 7:07 PM, sasinda rukshan
> >>>> <[hidden email]> wrote:
> >>>> > Hi,
> >>>> > *1: User Config Saving*
> >>>> > *
> >>>> > *
> >>>> > Xwiki android can now save user login data.
> >>>> > I refered
> >>>> > http://platform.xwiki.org/xwiki/bin/view/AdminGuide/AccessWiki.
> >>>> > Currently assuming the authority
> >>>> >
> >>>> > part(platform.xwiki.org<
> http://platform.xwiki.org/xwiki/bin/view/AdminGuide/AccessWiki>)
> >>>> > only
> >>>> > as a unique wiki identifier. But in the
> org.xwiki.android.entity.User I
> >>>> > have the method
> >>>> > setXWikiRealm(String url);:
> >>>> > Here I have intended the meaning realm as the url root path for a
> unique
> >>>> > wiki instance.
> >>>> > i.e. it should identify a wiki using path upto
> >>>> > http://host/xwiki/wiki/wikialias/
> >>>> > But that functionality is not implemented.I just mailed this asking
> for
> >>>> > the
> >>>> > opinion wether the usage of word realm was right here.
> >>>> > Also do you have seperate users for  wikis for path based wiki
> access.Or
> >>>> > are they the same with the main wiki *http://<host>/xwiki*.
> >>>>
> >>>> Both actually, you can have global users (which are the one on main
> >>>> wiki) and local users.
> >>>>
> >>>> > *2: Entity model*
> >>>> > *
> >>>> > *
> >>>> > About the convention for using C_ prefix for core entity tables. I
> >>>> > was referring to make the android versions of these entities
> >>>> > http://platform.xwiki.org/xwiki/bin/view/DevGuide/DatabaseSchemaand
> >>>> > start
> >>>> > there db prefixes with C_
> >>>> > This is because other apps may need to store some specific tables
> needed
> >>>> > for them. Rather than having a seperate DB schema for them we can
> put
> >>>> > those
> >>>> > tables here as well prefixing them with <appname>_ .
> >>>> > I added more entities like User as well to the core entities(table
> >>>> > C_User).Also will implement a Log Entity(C_Log table) for logging
> some
> >>>> > important application activities(such as login attempts) But the
> Log may
> >>>> > be
> >>>> > a little additional weight to the space and performance.I may
> implement
> >>>> > a
> >>>> > generic DBCleaning service to clean the tables like Log, if I have
> time.
> >>>> > (Perhaps this description will resolve the confusion about the DB
> >>>> > conventions. Sorry I was not very clear in that earlier mail. ;-).)
> >>>> >
> >>>> > I am sorry to say I am somewhat confused with all those entities in
> >>>> > http://platform.xwiki.org/xwiki/bin/view/DevGuide/DatabaseSchema.
> >>>>
> >>>> The XWiki model is based on generic classes and objects wich is why
> >>>> you see lots of tables (class properties, object properties , etc.).
> >>>> There is no table for users for example, its an object of class
> >>>> XWiki.XWikiUsers.
> >>>>
> >>>> >
> >>>> > Any way to reduce my confusion
> >>>> > I refered
> >>>> > 1)  XWiki Data
> >>>> > Model<http://platform.xwiki.org/xwiki/bin/view/DevGuide/DataModel>
> >>>> > :
> >>>> >   can you give me a link to a documentation that explains the
> workflow
> >>>> > of
> >>>> > how a normal request is converted in to the requested page by the
> >>>> > bin View action . So I can get a better understanding of how
> classes ,
> >>>> > objects are used.
> >>>>
> >>>> Not sure there is one. but basically you get either:
> >>>> * document content executed
> >>>> * if a class sheet is defined for one of the document objects classes,
> >>>> the class sheet is executed
> >>>> * if a document sheet is defined for the documment, the document sheet
> >>>> is executed
> >>>>
> >>>> That's pretty much all, then is a matter of free script and wiki
> >>>> syntax to actually display the content.
> >>>>
> >>>> > 2)  package com.xpn.xwiki.api: I don't need to consider this, do I?
> >>>>
> >>>> That's limited scripting API so you should not consider this.
> >>>>
> >>>> > 3)
> >>>> >  Cache<
> http://extensions.xwiki.org/xwiki/bin/view/Extension/Cache+Module>
> >>>> >  : Need not implement similar component. Android OS does it nicely
> for
> >>>> > the
> >>>> > REST responses
> >>>> > but still don't have a clear picture on this.
> >>>> > To save a blog doc
> >>>> > option 1)Seems like I have to convert a document entity to relevent
> >>>> > xwiki-model-simplexml entities and send to server.
> >>>> > option 2) We also can edit the relevent simplexml model object
> fields
> >>>> > directly. (Looks a bad option to me.It does not hide the complexity
> of
> >>>> > lower levels for the client layer.Anyway my work load  is reduced
> with
> >>>> > opt:2 ;-))
> >>>>
> >>>> IMO you should not even look at
> >>>> http://extensions.xwiki.org/xwiki/bin/view/Extension/Cache+Module and
> >>>> instead look at how caching is usually done in Android. The idea is
> >>>> not to port the xwiki-platform to Android IMO but to follow Android
> >>>> standards to provide a library to manipulate XWiki model.
> >>>>
> >>>> You can set the annotation you want to the simplexml model but the
> >>>> classes/methods should remain an exact copy of what's on
> >>>> xwiki-platform-rest-model. The idea being that we could decide to
> >>>> change the implementation from simplexml to anything (JAXB, gson,
> >>>> etc.) without breaking anything.
> >>>>
> >>>> >
> >>>> >
> >>>> > *3: Development/architectural approach Change*
> >>>> > *
> >>>> > *
> >>>> > I was first thinking for a addon like architecture for the XWiki
> android
> >>>> > app. We have the client.Main app (with all platfrom libs included)
> and
> >>>> > Blog
> >>>> > app as a seperate apk.
> >>>> > But here Blog app will need to have the platform lib also. That
> would be
> >>>> > a
> >>>> > complete waste of space. But dynamically extending the app is lot
> >>>> > easier.
> >>>> > The client.Main app can add the activities defined in other apks in
> to
> >>>> > its
> >>>> > launcher interface using android PackageManager class.
> >>>> >
> >>>> >
> http://stackoverflow.com/questions/9236803/android-build-an-application-that-supports-add-ons
> >>>> > But with this approach rises additional complexities. For example
> naming
> >>>> > conflicts in the Components library module when two apps have the
> same
> >>>> > library with same activities defined. Sync issues etc etc....
> >>>> > So we will go with single .apk approach.
> >>>> > When going with single .apk we dont need a content provider to share
> >>>> > config/ preferences data. So sharing module is now not needed. The
> >>>> > client
> >>>> > applications now can directly access the Configuration.java class to
> >>>> > get/put configuration entries.
> >>>> > Also since I am having a User entity a configuration like
> >>>> > defaultUser(currently the admin user , hard coded in login.xml
> layout
> >>>> > file)
> >>>> > will only be needed for the first use of the app. Otherwise users
> need
> >>>> > not
> >>>> > configure a default user as the application now suggests the user
> names
> >>>> > and
> >>>> > automatically fill the rest.
> >>>>
> >>>> Keep in mind that the main goal of this project is to provide tools
> >>>> for any application to access an XWiki instance and manipulate its
> >>>> datas easily an improving those libraries should always be the first
> >>>> goal. Your blog application is here as a good demo and because it's
> >>>> hard to design a library without using it.
> >>>>
> >>>> I really don't understand why you talk about naming conflict. Of
> >>>> course a library should never provide a complete final activity but
> >>>> only interface components (View), fragments or base activities to
> >>>> extend. Putting those elements in an activity is each application job.
> >>>> An activity is by definition unique so it has nothing to do in a
> >>>> library. The complete activities in
> >>>>
> >>>>
> https://github.com/xwiki-contrib/android-client/tree/master/xwiki-android-components/
> >>>> should have never been there, it's actually a mistake.
> >>>>
> >>>> >
> >>>> > *4: Plan for this week*
> >>>>
> >>>> As a priority you should really merge your branch as soon as you have
> >>>> something building fine. So that it goes through Jenkins and deploy
> >>>> snapshot build of what you do. Jenkins will tells you in live when
> >>>> your project does not build anymore or if there is any test failing
> >>>> and it allows anyone to very easily test the current test of the
> >>>> client just by installing the apks on
> >>>> http://maven.xwiki.org/snapshots/org/xwiki/android/. You need to have
> >>>> something working and in good shape to succeed the GSOC so fixing when
> >>>> you break something in your build should be your priority over adding
> >>>> more features.
> >>>>
> >>>> Also as I commented in your commit you should be more careful on what
> >>>> you commit. There is many binaries and Eclipse stuff in your branch.
> >>>>
> >>>> > *
> >>>> > *
> >>>> > Make a launch pad .We can launch XWiki Navigator, blog etc from
> this.
> >>>> > The
> >>>> > launch pad is shown when we launch XWiki main client.
> >>>> > Consider adding the WYSIWYG to my blog. It will be useless without
> the
> >>>> > ability to convert text formatting to xwiki syntax.So I may just
> >>>> > integrate
> >>>> > it and ignore the uselessness for now.
> >>>>
> >>>> Not exactly, you could actually reuse WYSIWYG service to send html and
> >>>> let it convert it to wiki syntax. Note that you are not limited to
> >>>> what you can find in the current Android library. This is just what
> >>>> Chamika had the time to do. There is others REST (or not REST) server
> >>>> interfaces you can use in your client or even add more if its generic
> >>>> enough and make sense for something else than just Android client.
> >>>>
> >>>> > We currently don't have any config to save( Other than default user)
> >>>> > config. I will add some demo config data and have a developer tools
> app
> >>>> > added to the above mentioned XWiki launch pad that can view/edit the
> >>>> > config
> >>>> > file.
> >>>> >
> >>>> > That will complete milestone 1. But it is not the Sharing
> >>>> > module(intended
> >>>> > to share data with other .apks).That is the configuration component
> does
> >>>> > not have a ContentProvider to share config data with other apks.
> Also I
> >>>> > will define a seperate class to have preferences which will be
> edited by
> >>>> > users. Config files are for configuration stuff and will be edited
> by
> >>>> > developers. Users have preferences files(natively supported by
> android)
> >>>> > to
> >>>> > change app preferences. For example users will add the default login
> >>>> > username as a preference.(This will invalidate the use of default
> User
> >>>> > entry in the config file which is used until the user edits his
> >>>> > preferences)
> >>>>
> >>>> I'm fine with not sharing datas between applications but it does not
> >>>> prevent the libraries to  provide tools to manage those datas in a per
> >>>> application basis.
> >>>>
> >>>> >
> >>>> > Beg your pardon if the mail is too lengthy.;-)
> >>>>
> >>>> No problem, never too much information for this ;)
> >>>>
> >>>> > Thank you.
> >>>> > Best Regards.
> >>>> >
> >>>> > Sasinda Rukshan.
> >>>> >
> >>>> >
> >>>> > Best Regards.
> >>>> >
> >>>> >
> >>>> > On Wed, May 30, 2012 at 1:11 PM, Thomas Mortagne
> >>>> > <[hidden email]>wrote:
> >>>> >
> >>>> >> On Wed, May 30, 2012 at 4:28 AM, sasinda rukshan
> >>>> >> <[hidden email]> wrote:
> >>>> >> > Hi,
> >>>> >> > I am studying ORM Lite these days.
> >>>> >> > Please It would be comforting if you can confirm whether it is
> worth
> >>>> >> > the
> >>>> >> > overhead to use ORM Lite.
> >>>> >> >
> >>>> >>
> >>>> >>
> http://logic-explained.blogspot.com/2011/12/using-ormlite-in-android-projects.html
> >>>> >> > http://ormlite.com/
> >>>> >> > ORM Lite features:
> >>>> >> > Automatically Creates standard DAOs for an annotated entity.
> >>>> >> > Coding will be lot easier.
> >>>> >>
> >>>> >> Remember it's a framework for a mobile platform so it has to remain
> >>>> >> light and have good performances. I can see that Android version of
> >>>> >> ormlite is very small but I never used it so I don't know if it's
> good
> >>>> >> or not. At least it seems petty active which is a good point so I
> >>>> >> don't have anything against it.
> >>>> >>
> >>>> >> >
> >>>> >> > Can you suggest how to name the entities.
> >>>> >> > I am going to go with,
> >>>> >> > <entity>  org.xwiki.xdroid.data.User  --> <table> C_USER
> >>>> >>
> >>>> >> Note that there is already a package name prefix and group id
> defined
> >>>> >> for the framework and it's org.xwiki.android as you can see on
> >>>> >> https://github.com/xwiki-contrib/android-client. Why do you want
> to
> >>>> >> change it ? It's more consistent with
> >>>> >> org.xwiki.commons/org.xwiki.rendering/org.xwiki.platform so I would
> >>>> >> prefer to keep it that way unless you can give arguments. The goal
> is
> >>>> >> not to redo something completely but complete and improve the
> existing
> >>>> >> framework.
> >>>> >>
> >>>> >> Also as far as I can see there is already several things called
> >>>> >> "xdroid" on Google play among which an application developer
> >>>> >> (https://play.google.com/store/apps/developer?id=x-droid) and an
> >>>> >> application (
> >>>> >>
> >>>> >>
> https://play.google.com/store/apps/details?id=com.gurudigitalsolutions.xdroid
> >>>> >> ).
> >>>> >>
> >>>> >> >
> >>>> >> > Thanks,
> >>>> >> > Best Regards
> >>>> >> >
> >>>> >> > Sasinda.
> >>>> >> >
> >>>> >> >
> >>>> >> >
> >>>> >> >
> >>>> >> >
> >>>> >> > On Wed, May 30, 2012 at 7:42 AM, sasinda rukshan
> >>>> >> > <[hidden email]>wrote:
> >>>> >> >
> >>>> >> >> Hi,
> >>>> >> >>
> >>>> >> >> I am commiting my work to my fork
> >>>> >> >> https://github.com/sasinda/android-client.
> >>>> >> >> I ll request to pull it to xwiki-contrib later.
> >>>> >> >>
> >>>> >> >> I was running in a wrong path these days. Wanted to save login
> >>>> >> >> history
> >>>> >> and
> >>>> >> >> suggest login. I was going to do it using an xml file (login
> >>>> >> attempts.xml).
> >>>> >> >> Now it seems database is better.
> >>>> >> >> Any way before I go wrong again I will say what I am going to
> do.
> >>>> >> >> I am going to enforce following conventions.These are not yet
> >>>> >> >> needed,
> >>>> >> >> considered the small scale.But when the system grows it would be
> >>>> >> >> nice to
> >>>> >> >> have them to avoid confusions.
> >>>> >> >> *Database prefixes for:*
> >>>> >> >> *Platform tables (can begin with appropriate prefix)*
> >>>> >> >> AD_ //application dictionary : don't know when it will be
> needed ;-)
> >>>> >> >> C_ //core functionality
> >>>> >> >> *Client Applications.*
> >>>> >> >> X<App name prefix>  ex: XBLOG_   for Blog app// All client add
> in
> >>>> >> modules
> >>>> >> >> must begin with table prefix X(for xwiki and ordering) + App
> name.
> >>>> >>  This is
> >>>> >> >> for my blog.
> >>>> >> >>
> >>>> >> >> I will create
> >>>> >> >> C_User for user data.
> >>>> >> >> C_LoginAttempt  for saving login attempts.
> >>>> >> >>
> >>>> >> >> From C_LoginAttempt I can filter uniqe login combinations and
> give
> >>>> >> >> suggestions in the login UI component. Also save the history.
> >>>> >> >>
> >>>> >> >> All saved data for blog app will be linked to a perticular
> login :
> >>>> >> >> User,
> >>>> >> >> XWiki server.
> >>>> >> >> But only a single user will be most probably using his personal
> >>>> >> >> device.
> >>>> >> So
> >>>> >> >> above will be relevant only when he has multiple wikis.
> >>>> >> >>
> >>>> >> >> Best Regards,
> >>>> >> >> Sasinda Rukshan.
> >>>> >> >>
> >>>> >> >>
> >>>> >> >>
> >>>> >> >>
> >>>> >> >>
> >>>> >> >> On Sun, May 27, 2012 at 5:43 PM, Chamika Weerasinghe <
> >>>> >> [hidden email]>wrote:
> >>>> >> >>
> >>>> >> >>> On Fri, May 25, 2012 at 1:25 AM, Jerome Velociter <
> >>>> >> [hidden email]
> >>>> >> >>> >wrote:
> >>>> >> >>>
> >>>> >> >>> > On Thu, May 24, 2012 at 6:09 PM, Thomas Mortagne
> >>>> >> >>> > <[hidden email]> wrote:
> >>>> >> >>> > > On Thu, May 24, 2012 at 5:52 PM, sasinda rukshan
> >>>> >> >>> > > <[hidden email]> wrote:
> >>>> >> >>> > >> Hi all,
> >>>> >> >>> > >> I am starting this thread for my XWiki Android Platform
> >>>> >> >>> > >> Project.
> >>>> >> >>> > >>
> >>>> >> >>> > >> Please check whether following are OK.
> >>>> >> >>> > >> [1] INFO
> >>>> >> >>> > >> I tried to start my new modules with the
> >>>> >> >>> de.akquinet.android.archetypes:
> >>>> >> >>> > >> android-quickstart:1.0.8.  (added eclipse plugins m2e,
> >>>> >> >>> > >> m2e-android[a.k.a  *Android
> >>>> >> >>> > >> Configurator* ]). But this seems buggy in eclipse.
> >>>> >> >>> > >> Any way the earlier project has not followed the above
> >>>> >> >>> > >> archtype
> >>>> >> >>> either.
> >>>> >> >>> > So
> >>>> >> >>> > >> I am going to write pom.xml manually for my each module.
> >>>> >> >>> > >>
> >>>> >> >>> > >> [2] ADVICE NEEDED
> >>>> >> >>> > >> xwiki-rest-model module contains 2 submodules
> >>>> >> >>> > >>  |-- xwiki-rest-model-gson  ( gson should be corrected to
> >>>> >> >>> > >> json)
> >>>> >> >>> > >
> >>>> >> >>> > > No the g is not a mistake, it's a model to be used with the
> >>>> >> >>> > > gson
> >>>> >> >>> > > library (http://code.google.com/p/google-gson/). See
> >>>> >> >>> > >
> >>>> >> >>> >
> >>>> >> >>>
> >>>> >>
> >>>> >>
> http://extensions.xwiki.org/xwiki/bin/view/Extension/Google+Android+Client#HXWikiAndroidDevelopmentAPIsandResources
> >>>> >> >>> > .
> >>>> >> >>> > >
> >>>> >> >>> > >>  |-- xwiki-rest-model-simplexml
> >>>> >> >>> > >> I think the xwiki-rest-model-gson is redundant. The
> classes
> >>>> >> >>> > >> in xwiki-rest-model-simplexml is added with simple xml
> >>>> >> annotations,
> >>>> >> >>> > >> otherwise both modules have same classes. There is no
> problem
> >>>> >> >>> > >> with
> >>>> >> >>> the
> >>>> >> >>> > >> added annotations for using the same model objects for
> Json
> >>>> >> >>> > >> REST
> >>>> >> web
> >>>> >> >>> > >> services. And I intend to add my JPA (ORMLite library for
> >>>> >> >>> persistence)
> >>>> >> >>> > >> annotations on top of it.
> >>>> >> >>> > >> Shall I re-factor them to a single module
> xwiki-rest-model.
> >>>> >> >>> > >
> >>>> >> >>> > > No keep them separated, the idea is that both are useful
> tool
> >>>> >> >>> > > to be
> >>>> >> >>> > > used by someone else that might be moved to xwiki-platform
> at
> >>>> >> >>> > > some
> >>>> >> >>> > > point along with the current xwiki-rest-model (to be
> renamed to
> >>>> >> >>> > > xwiki-rest-model-jaxb).
> >>>> >> >>> > >
> >>>> >> >>> > > Chamika initially started with gson and since XWiki REST
> JSON
> >>>> >> >>> > > representation had some limitation he moved to XML
> >>>> >> >>> > > representation.
> >>>> >> >>> > > Maybe at some point Android will have native support for
> jaxb
> >>>> >> >>> > > which
> >>>> >> >>> > > would obviously be the easier for us (embedding jaxb is
> not an
> >>>> >> option
> >>>> >> >>> > > in mobile world where size it still pretty important
> especially
> >>>> >> >>> > > on
> >>>> >> >>> > > phones). Maybe it's already the case on most recent
> versions
> >>>> >> >>> > > like
> >>>> >> 4.0
> >>>> >> >>> > > I don't know.
> >>>> >> >>> >
> >>>> >> >>> > There's also Jackson that could be tried for JSON
> >>>> >> >>> > deserialization, if
> >>>> >> >>> > said limitations are actually GSON limitations.
> >>>> >> >>> >
> >>>> >> >>> GSON wasn't the limitation.
> >>>> >> >>> It was XWiki RESTful API which doesn't support JSON in some
> cases.
> >>>> >> >>> So
> >>>> >> it's
> >>>> >> >>> safe to go with xml.
> >>>> >> >>>
> >>>> >> >>> >
> >>>> >> >>> > Having full JAXB support sound a bit overweight for such an
> >>>> >> >>> > "embedded
> >>>> >> >>> > API", even if one day it is natively supported by Android.
> What's
> >>>> >> >>> > important is to have an easy and fast deserialization, IMO.
> >>>> >> >>> > The only advantage I can see of going JAXB would be in
> re-using
> >>>> >> >>> > the
> >>>> >> >>> > exact representations and body readers/writers from XWiki
> core.
> >>>> >> >>> > But
> >>>> >> >>> > you probably don't even want to do that since it would mean
> >>>> >> >>> > dragging
> >>>> >> >>> > XWiki core with you :)
> >>>> >> >>> >
> >>>> >> >>> > Jerome
> >>>> >> >>> >
> >>>> >> >>> > >
> >>>> >> >>> > >>
> >>>> >> >>> > >> [3] INFO
> >>>> >> >>> > >>  I had to change some pom.xml s. As the current project
> at:
> >>>> >> >>> > >> https://github.com/xwiki-contrib/android-client.git does
> not
> >>>> >> build.
> >>>> >> >>> > Error
> >>>> >> >>> > >> with parent pom.xml coordinates.
> >>>> >> >>> > >
> >>>> >> >>> > > You probably did not setup you maven install properly since
> >>>> >> >>> > > what's
> >>>> >> on
> >>>> >> >>> > > https://github.com/xwiki-contrib/android-client.git build
> >>>> >> perfectly
> >>>> >> >>> as
> >>>> >> >>> > > you can see on
> >>>> >> http://ci.xwiki.org/view/All/job/xwiki-android-client/
> >>>> >> >>> > > which run a build every time something changes on the git
> >>>> >> repository..
> >>>> >> >>> > > You should look at
> >>>> >> >>> > > http://dev.xwiki.org/xwiki/bin/view/Community/Building.
> >>>> >> >>> > >
> >>>> >> >>> > >>
> >>>> >> >>> > >>
> >>>> >> >>> > >> Thank you
> >>>> >> >>> > >> Best Regards.
> >>>> >> >>> > >> Sasinda Rukshan
> >>>> >> >>> > >> _______________________________________________
> >>>> >> >>> > >> devs mailing list
> >>>> >> >>> > >> [hidden email]
> >>>> >> >>> > >> http://lists.xwiki.org/mailman/listinfo/devs
> >>>> >> >>> > >
> >>>> >> >>> > >
> >>>> >> >>> > >
> >>>> >> >>> > > --
> >>>> >> >>> > > Thomas Mortagne
> >>>> >> >>> > > _______________________________________________
> >>>> >> >>> > > devs mailing list
> >>>> >> >>> > > [hidden email]
> >>>> >> >>> > > http://lists.xwiki.org/mailman/listinfo/devs
> >>>> >> >>> >
> >>>> >> >>> >
> >>>> >> >>> >
> >>>> >> >>> > --
> >>>> >> >>> > Jérôme Velociter
> >>>> >> >>> > Winesquare
> >>>> >> >>> > http://www.winesquare.net/
> >>>> >> >>> > _______________________________________________
> >>>> >> >>> > devs mailing list
> >>>> >> >>> > [hidden email]
> >>>> >> >>> > http://lists.xwiki.org/mailman/listinfo/devs
> >>>> >> >>> >
> >>>> >> >>> _______________________________________________
> >>>> >> >>> devs mailing list
> >>>> >> >>> [hidden email]
> >>>> >> >>> http://lists.xwiki.org/mailman/listinfo/devs
> >>>> >> >>>
> >>>> >> >>
> >>>> >> >>
> >>>> >> > _______________________________________________
> >>>> >> > devs mailing list
> >>>> >> > [hidden email]
> >>>> >> > http://lists.xwiki.org/mailman/listinfo/devs
> >>>> >>
> >>>> >>
> >>>> >>
> >>>> >> --
> >>>> >> Thomas Mortagne
> >>>> >> _______________________________________________
> >>>> >> devs mailing list
> >>>> >> [hidden email]
> >>>> >> http://lists.xwiki.org/mailman/listinfo/devs
> >>>> >>
> >>>> > _______________________________________________
> >>>> > devs mailing list
> >>>> > [hidden email]
> >>>> > http://lists.xwiki.org/mailman/listinfo/devs
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> Thomas Mortagne
> >>>
> >>>
> >>
> >>
> >>
> >> --
> >> Thomas Mortagne
> >
> >
> >
> > --
> > Thomas Mortagne
>
>
>
> --
> Thomas Mortagne
>
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [GSoc] XDroid Platform

sasinda
Hi,
I checked the source code.(still it would be helpful if u cn explain)
I have  a little issue.
Say with the current model
Blog.BlogPostClass
  properties|__DBTreeList  category  {has a list of attributes}
                  |__TextAreaClass content   {has a list of attributes}
            |__ MYType  myComplexTypeProp {has a list of attributes  which
are all simple properties such as StringProperty etc}  [ for ex:TagClass
tagprop ]
                                   |__ StringClass mystring   {also have a
list of attributes.

The XML schema

<complexType name="Object">
   <complexContent>
     <extension base="{http://www.xwiki.org}ObjectSummary">
       <sequence>
         <element name="property"
type="{http://www.xwiki.org}Property" maxOccurs="unbounded"
minOccurs="0"/>
       </sequence>
     </extension>
   </complexContent>
 </complexType>

<complexType name="Property">
   <complexContent>
     <extension base="{http://www.xwiki.org}LinkCollection">
       <sequence>
         <element name="attribute"
type="{http://www.xwiki.org}Attribute" maxOccurs="unbounded"
minOccurs="0"/>
         <element name="value" type="{http://www.w3.org/2001/XMLSchema}string"/>
       </sequence>
       <attribute name="name" use="required"
type="{http://www.w3.org/2001/XMLSchema}string" />
       <attribute name="type" type="{http://www.w3.org/2001/XMLSchema}string" />
     </extension>
   </complexContent>
 </complexType>

 <complexType name="Attribute">
   <complexContent>
     <extension base="{http://www.xwiki.org}LinkCollection">
       <attribute name="name" use="required"
type="{http://www.w3.org/2001/XMLSchema}string" />
       <attribute name="value"
type="{http://www.w3.org/2001/XMLSchema}string" />
     </extension>
   </complexContent>
 </complexType>

does not seem to be addressing such an occasion where multiple levels of
nesting is happening. (May be I'm horribly wrong here)

Am I correct to think that any type of Object like BlogPostClass obj
will only have properties of simple types such as StringClass,
TextAreaClass and etc. It will not have a complex type for example
XWiki.TagClass in it.(I know it never happens in BlogPostClass, but
don't know if someone needs to do a weird class). ?

My findings and comprehension on the model:

I guess StringClass, TextAreaClass etc, carry most of those many
attributes for rendering purpose. I saw StaticListClass has attribute
(separators) for defining the list value delimeters as well.

Can you please post me a diagram taking a single class like DateClass. How
the aggregations and inheritance is done.
Ill send my design. I intend to do all that with just single definition for
each XWiki data type classes.For ex: XString extends XObject.XObject
contains the collection of fields.These can be converted to <attribute>
elements. A Document Object will contain a BlogPost (represent
BlobPostClass) object which contains XObject s as properties. (ideally if
multiple levels of nesting is supported BlogPost should also be a XObject).
The Document Object is an entity.(refer
https://docs.google.com/drawings/d/1hwfQMVgCvYKS6iHU060drcET3Aq3Vles2DQlJOOt3n8/edit<https://docs.google.com/drawings/d/1hwfQMVgCvYKS6iHU060drcET3Aq3Vles2DQlJOOt3n8/edit?pli=1>
 )
When we persist a document object it should serialize the BLogPost class
into its xml representation and save it on the filesystem. SQLite DB will
have a row with the URI for that file. So I am not going to persist
rest-model objects ( neither annotate them for persistence). Storing such
bulk objects may degrade DB performance. In the android dev guides it is
said a curser to a table should not exceed 2 MB of data otherwise the
performance will be low due to paging.
This makes the persistence a little complex. I will manage it. PLS tell if
my approach is wrong.

By the way I will merge my work to the master branch next week. Is it ok to
duplicate your maven work to a mvn branch and undo the commit in master and
merge my work with a fast forward merge, so that it will show  a linear
history.

Thanks
Best Regards.
Sasinda Rukshan.







On Sat, Jun 16, 2012 at 11:21 AM, sasinda rukshan
<[hidden email]>wrote:

> Thanks very much for the help on maven build.
>
> *About making a object from Blog.BlogPostClass  and toXML()*
>
> A blog object is having properties of type other xobject classes. So to
> make the things general can we do a stripped down replication or make
> something similer to the java classes in com.xpn.xwiki.objects and its 2
> sub packages .classes, .meta .
>  We can make a document object representing a page and put a
> Blog.BlogPostClass object to its list of objects.We can convert them to
> simple xml model directly.If we want to post blog object we can post the
> Blog object.If the page does not exist we can put the page by getting the
> xml from the Document object.
> Then the things will be general not only for blog client app. Also we can
> have Type checking when we don't directly manipulate simplexml objects.
> i.e. XStringClass will define the attributes for it and likewise.
>
> I don't have a good idea on the above packages and classes. Specially why
> there are three classes for each XType ex: StringProperty, StringClass,
> StringMeta.
> It will be helpful if you can give an explanation.
>
> My draft solution is to do some simple thing as,
> XObject
>  |____ XBoolean
>
> XObject
> |____XString
>
> XString has methods,
> toEmbedXML  gives a <property><attribute/>...</property> string/ simpleXML
> objects
> toXML  gives <object><id><ClassName>.......</object> for the same thing.
>
> Also
> XObject
> |_____ XBlogPost       for(BlogPostClass and other 2 Meta,Property classes)
>
> I don't yet have a clear idea on this. May be I am wrong on this.
> Can you give me your idea here as well. How to approach the problem and
> what should the design be like?
>
> Thanks.
> Best Regards
> Sasinda.
>
>
>
> On Thu, Jun 7, 2012 at 9:28 PM, Thomas Mortagne <[hidden email]
> > wrote:
>
>> As just did a commit with last version of android plugin and some
>> cleanup. Seems to work well.
>>
>> On Thu, Jun 7, 2012 at 12:19 PM, Thomas Mortagne
>> <[hidden email]> wrote:
>> > BTW if you have quick questions it's probaly better to use IRC (I'm
>> > tmortgane on the channel and I'm on GMT+2 tome zone but you can ask
>> > anyone when I'm not around). See
>> > http://dev.xwiki.org/xwiki/bin/view/Community/IRC.
>> >
>> > On Thu, Jun 7, 2012 at 12:17 PM, Thomas Mortagne
>> > <[hidden email]> wrote:
>> >> Not need to send this kind of mail privately to me.
>> >>
>> >> On Thu, Jun 7, 2012 at 5:33 AM, sasinda rukshan
>> >> <[hidden email]> wrote:
>> >>> Thanks,
>> >>> The project is building perfectly well in eclipse (and runs well too)
>> [I
>> >>> configured the build paths for eclipse opening each module as a
>> project and
>> >>> giving project dependencies and etc.]. This is because android facet
>> and
>> >>> maven-android plugin for eclipse [m2e-android] (not the jayway
>>  androi maven
>> >>> plugin)does not work together well.
>> >>> Maven build does not work with newer jayway android maven plugins
>> because of
>> >>> the simplexml library. I checked with another helloworld app that
>> does not
>> >>> have simplexml dependancy and have simplexml dependancy. When we have
>> the
>> >>> dependancy it does not work. Also when packaged with the beta version
>> maven
>> >>> plugin I get runtime error logs notifying that the exact classes
>> informed
>> >>> missed in the compile time for newer maven plugin are missing. But
>> the app
>> >>> is running ok.
>> >>> I will try with it some more and if I can't can you help me with it a
>> >>> little.
>> >>
>> >> Sure If it's just related to simplexml it's probably not much. I will
>> >> try to take a look today. At worst the version we are using right now
>> >> is working fine so you can continue with it anyway.
>> >>
>> >>>
>> >>> I looked at the Enterprise platform apis just to make my apis similar
>> when
>> >>> possible.Source code is not at all relevant to me. But as you say It
>> will be
>> >>> imperfect if I use its style heavily for the mobile version as well.
>> >>
>> >> Yes there is several issues here:
>> >> * most APIs in oldcore module are old and bad and we are trying to get
>> >> rif of them so better not getting too much attached to it ;)
>> >> * they are designed to run in an enironment with lots of resources and
>> >> don't care as much as a mobile API should about memory, etc.
>> >>
>> >>>
>> >>>
>> >>> Thank you.
>> >>> Best Regards.
>> >>> Sasinda.
>> >>>
>> >>>
>> >>> On Wed, Jun 6, 2012 at 1:03 PM, Thomas Mortagne <
>> [hidden email]>
>> >>> wrote:
>> >>>>
>> >>>> On Tue, Jun 5, 2012 at 7:07 PM, sasinda rukshan
>> >>>> <[hidden email]> wrote:
>> >>>> > Hi,
>> >>>> > *1: User Config Saving*
>> >>>> > *
>> >>>> > *
>> >>>> > Xwiki android can now save user login data.
>> >>>> > I refered
>> >>>> > http://platform.xwiki.org/xwiki/bin/view/AdminGuide/AccessWiki.
>> >>>> > Currently assuming the authority
>> >>>> >
>> >>>> > part(platform.xwiki.org<
>> http://platform.xwiki.org/xwiki/bin/view/AdminGuide/AccessWiki>)
>> >>>> > only
>> >>>> > as a unique wiki identifier. But in the
>> org.xwiki.android.entity.User I
>> >>>> > have the method
>> >>>> > setXWikiRealm(String url);:
>> >>>> > Here I have intended the meaning realm as the url root path for a
>> unique
>> >>>> > wiki instance.
>> >>>> > i.e. it should identify a wiki using path upto
>> >>>> > http://host/xwiki/wiki/wikialias/
>> >>>> > But that functionality is not implemented.I just mailed this
>> asking for
>> >>>> > the
>> >>>> > opinion wether the usage of word realm was right here.
>> >>>> > Also do you have seperate users for  wikis for path based wiki
>> access.Or
>> >>>> > are they the same with the main wiki *http://<host>/xwiki*.
>> >>>>
>> >>>> Both actually, you can have global users (which are the one on main
>> >>>> wiki) and local users.
>> >>>>
>> >>>> > *2: Entity model*
>> >>>> > *
>> >>>> > *
>> >>>> > About the convention for using C_ prefix for core entity tables. I
>> >>>> > was referring to make the android versions of these entities
>> >>>> > http://platform.xwiki.org/xwiki/bin/view/DevGuide/DatabaseSchemaand
>> >>>> > start
>> >>>> > there db prefixes with C_
>> >>>> > This is because other apps may need to store some specific tables
>> needed
>> >>>> > for them. Rather than having a seperate DB schema for them we can
>> put
>> >>>> > those
>> >>>> > tables here as well prefixing them with <appname>_ .
>> >>>> > I added more entities like User as well to the core entities(table
>> >>>> > C_User).Also will implement a Log Entity(C_Log table) for logging
>> some
>> >>>> > important application activities(such as login attempts) But the
>> Log may
>> >>>> > be
>> >>>> > a little additional weight to the space and performance.I may
>> implement
>> >>>> > a
>> >>>> > generic DBCleaning service to clean the tables like Log, if I have
>> time.
>> >>>> > (Perhaps this description will resolve the confusion about the DB
>> >>>> > conventions. Sorry I was not very clear in that earlier mail. ;-).)
>> >>>> >
>> >>>> > I am sorry to say I am somewhat confused with all those entities in
>> >>>> > http://platform.xwiki.org/xwiki/bin/view/DevGuide/DatabaseSchema.
>> >>>>
>> >>>> The XWiki model is based on generic classes and objects wich is why
>> >>>> you see lots of tables (class properties, object properties , etc.).
>> >>>> There is no table for users for example, its an object of class
>> >>>> XWiki.XWikiUsers.
>> >>>>
>> >>>> >
>> >>>> > Any way to reduce my confusion
>> >>>> > I refered
>> >>>> > 1)  XWiki Data
>> >>>> > Model<http://platform.xwiki.org/xwiki/bin/view/DevGuide/DataModel>
>> >>>> > :
>> >>>> >   can you give me a link to a documentation that explains the
>> workflow
>> >>>> > of
>> >>>> > how a normal request is converted in to the requested page by the
>> >>>> > bin View action . So I can get a better understanding of how
>> classes ,
>> >>>> > objects are used.
>> >>>>
>> >>>> Not sure there is one. but basically you get either:
>> >>>> * document content executed
>> >>>> * if a class sheet is defined for one of the document objects
>> classes,
>> >>>> the class sheet is executed
>> >>>> * if a document sheet is defined for the documment, the document
>> sheet
>> >>>> is executed
>> >>>>
>> >>>> That's pretty much all, then is a matter of free script and wiki
>> >>>> syntax to actually display the content.
>> >>>>
>> >>>> > 2)  package com.xpn.xwiki.api: I don't need to consider this, do I?
>> >>>>
>> >>>> That's limited scripting API so you should not consider this.
>> >>>>
>> >>>> > 3)
>> >>>> >  Cache<
>> http://extensions.xwiki.org/xwiki/bin/view/Extension/Cache+Module>
>> >>>> >  : Need not implement similar component. Android OS does it nicely
>> for
>> >>>> > the
>> >>>> > REST responses
>> >>>> > but still don't have a clear picture on this.
>> >>>> > To save a blog doc
>> >>>> > option 1)Seems like I have to convert a document entity to relevent
>> >>>> > xwiki-model-simplexml entities and send to server.
>> >>>> > option 2) We also can edit the relevent simplexml model object
>> fields
>> >>>> > directly. (Looks a bad option to me.It does not hide the
>> complexity of
>> >>>> > lower levels for the client layer.Anyway my work load  is reduced
>> with
>> >>>> > opt:2 ;-))
>> >>>>
>> >>>> IMO you should not even look at
>> >>>> http://extensions.xwiki.org/xwiki/bin/view/Extension/Cache+Moduleand
>> >>>> instead look at how caching is usually done in Android. The idea is
>> >>>> not to port the xwiki-platform to Android IMO but to follow Android
>> >>>> standards to provide a library to manipulate XWiki model.
>> >>>>
>> >>>> You can set the annotation you want to the simplexml model but the
>> >>>> classes/methods should remain an exact copy of what's on
>> >>>> xwiki-platform-rest-model. The idea being that we could decide to
>> >>>> change the implementation from simplexml to anything (JAXB, gson,
>> >>>> etc.) without breaking anything.
>> >>>>
>> >>>> >
>> >>>> >
>> >>>> > *3: Development/architectural approach Change*
>> >>>> > *
>> >>>> > *
>> >>>> > I was first thinking for a addon like architecture for the XWiki
>> android
>> >>>> > app. We have the client.Main app (with all platfrom libs included)
>> and
>> >>>> > Blog
>> >>>> > app as a seperate apk.
>> >>>> > But here Blog app will need to have the platform lib also. That
>> would be
>> >>>> > a
>> >>>> > complete waste of space. But dynamically extending the app is lot
>> >>>> > easier.
>> >>>> > The client.Main app can add the activities defined in other apks
>> in to
>> >>>> > its
>> >>>> > launcher interface using android PackageManager class.
>> >>>> >
>> >>>> >
>> http://stackoverflow.com/questions/9236803/android-build-an-application-that-supports-add-ons
>> >>>> > But with this approach rises additional complexities. For example
>> naming
>> >>>> > conflicts in the Components library module when two apps have the
>> same
>> >>>> > library with same activities defined. Sync issues etc etc....
>> >>>> > So we will go with single .apk approach.
>> >>>> > When going with single .apk we dont need a content provider to
>> share
>> >>>> > config/ preferences data. So sharing module is now not needed. The
>> >>>> > client
>> >>>> > applications now can directly access the Configuration.java class
>> to
>> >>>> > get/put configuration entries.
>> >>>> > Also since I am having a User entity a configuration like
>> >>>> > defaultUser(currently the admin user , hard coded in login.xml
>> layout
>> >>>> > file)
>> >>>> > will only be needed for the first use of the app. Otherwise users
>> need
>> >>>> > not
>> >>>> > configure a default user as the application now suggests the user
>> names
>> >>>> > and
>> >>>> > automatically fill the rest.
>> >>>>
>> >>>> Keep in mind that the main goal of this project is to provide tools
>> >>>> for any application to access an XWiki instance and manipulate its
>> >>>> datas easily an improving those libraries should always be the first
>> >>>> goal. Your blog application is here as a good demo and because it's
>> >>>> hard to design a library without using it.
>> >>>>
>> >>>> I really don't understand why you talk about naming conflict. Of
>> >>>> course a library should never provide a complete final activity but
>> >>>> only interface components (View), fragments or base activities to
>> >>>> extend. Putting those elements in an activity is each application
>> job.
>> >>>> An activity is by definition unique so it has nothing to do in a
>> >>>> library. The complete activities in
>> >>>>
>> >>>>
>> https://github.com/xwiki-contrib/android-client/tree/master/xwiki-android-components/
>> >>>> should have never been there, it's actually a mistake.
>> >>>>
>> >>>> >
>> >>>> > *4: Plan for this week*
>> >>>>
>> >>>> As a priority you should really merge your branch as soon as you have
>> >>>> something building fine. So that it goes through Jenkins and deploy
>> >>>> snapshot build of what you do. Jenkins will tells you in live when
>> >>>> your project does not build anymore or if there is any test failing
>> >>>> and it allows anyone to very easily test the current test of the
>> >>>> client just by installing the apks on
>> >>>> http://maven.xwiki.org/snapshots/org/xwiki/android/. You need to
>> have
>> >>>> something working and in good shape to succeed the GSOC so fixing
>> when
>> >>>> you break something in your build should be your priority over adding
>> >>>> more features.
>> >>>>
>> >>>> Also as I commented in your commit you should be more careful on what
>> >>>> you commit. There is many binaries and Eclipse stuff in your branch.
>> >>>>
>> >>>> > *
>> >>>> > *
>> >>>> > Make a launch pad .We can launch XWiki Navigator, blog etc from
>> this.
>> >>>> > The
>> >>>> > launch pad is shown when we launch XWiki main client.
>> >>>> > Consider adding the WYSIWYG to my blog. It will be useless without
>> the
>> >>>> > ability to convert text formatting to xwiki syntax.So I may just
>> >>>> > integrate
>> >>>> > it and ignore the uselessness for now.
>> >>>>
>> >>>> Not exactly, you could actually reuse WYSIWYG service to send html
>> and
>> >>>> let it convert it to wiki syntax. Note that you are not limited to
>> >>>> what you can find in the current Android library. This is just what
>> >>>> Chamika had the time to do. There is others REST (or not REST) server
>> >>>> interfaces you can use in your client or even add more if its generic
>> >>>> enough and make sense for something else than just Android client.
>> >>>>
>> >>>> > We currently don't have any config to save( Other than default
>> user)
>> >>>> > config. I will add some demo config data and have a developer
>> tools app
>> >>>> > added to the above mentioned XWiki launch pad that can view/edit
>> the
>> >>>> > config
>> >>>> > file.
>> >>>> >
>> >>>> > That will complete milestone 1. But it is not the Sharing
>> >>>> > module(intended
>> >>>> > to share data with other .apks).That is the configuration
>> component does
>> >>>> > not have a ContentProvider to share config data with other apks.
>> Also I
>> >>>> > will define a seperate class to have preferences which will be
>> edited by
>> >>>> > users. Config files are for configuration stuff and will be edited
>> by
>> >>>> > developers. Users have preferences files(natively supported by
>> android)
>> >>>> > to
>> >>>> > change app preferences. For example users will add the default
>> login
>> >>>> > username as a preference.(This will invalidate the use of default
>> User
>> >>>> > entry in the config file which is used until the user edits his
>> >>>> > preferences)
>> >>>>
>> >>>> I'm fine with not sharing datas between applications but it does not
>> >>>> prevent the libraries to  provide tools to manage those datas in a
>> per
>> >>>> application basis.
>> >>>>
>> >>>> >
>> >>>> > Beg your pardon if the mail is too lengthy.;-)
>> >>>>
>> >>>> No problem, never too much information for this ;)
>> >>>>
>> >>>> > Thank you.
>> >>>> > Best Regards.
>> >>>> >
>> >>>> > Sasinda Rukshan.
>> >>>> >
>> >>>> >
>> >>>> > Best Regards.
>> >>>> >
>> >>>> >
>> >>>> > On Wed, May 30, 2012 at 1:11 PM, Thomas Mortagne
>> >>>> > <[hidden email]>wrote:
>> >>>> >
>> >>>> >> On Wed, May 30, 2012 at 4:28 AM, sasinda rukshan
>> >>>> >> <[hidden email]> wrote:
>> >>>> >> > Hi,
>> >>>> >> > I am studying ORM Lite these days.
>> >>>> >> > Please It would be comforting if you can confirm whether it is
>> worth
>> >>>> >> > the
>> >>>> >> > overhead to use ORM Lite.
>> >>>> >> >
>> >>>> >>
>> >>>> >>
>> http://logic-explained.blogspot.com/2011/12/using-ormlite-in-android-projects.html
>> >>>> >> > http://ormlite.com/
>> >>>> >> > ORM Lite features:
>> >>>> >> > Automatically Creates standard DAOs for an annotated entity.
>> >>>> >> > Coding will be lot easier.
>> >>>> >>
>> >>>> >> Remember it's a framework for a mobile platform so it has to
>> remain
>> >>>> >> light and have good performances. I can see that Android version
>> of
>> >>>> >> ormlite is very small but I never used it so I don't know if it's
>> good
>> >>>> >> or not. At least it seems petty active which is a good point so I
>> >>>> >> don't have anything against it.
>> >>>> >>
>> >>>> >> >
>> >>>> >> > Can you suggest how to name the entities.
>> >>>> >> > I am going to go with,
>> >>>> >> > <entity>  org.xwiki.xdroid.data.User  --> <table> C_USER
>> >>>> >>
>> >>>> >> Note that there is already a package name prefix and group id
>> defined
>> >>>> >> for the framework and it's org.xwiki.android as you can see on
>> >>>> >> https://github.com/xwiki-contrib/android-client. Why do you want
>> to
>> >>>> >> change it ? It's more consistent with
>> >>>> >> org.xwiki.commons/org.xwiki.rendering/org.xwiki.platform so I
>> would
>> >>>> >> prefer to keep it that way unless you can give arguments. The
>> goal is
>> >>>> >> not to redo something completely but complete and improve the
>> existing
>> >>>> >> framework.
>> >>>> >>
>> >>>> >> Also as far as I can see there is already several things called
>> >>>> >> "xdroid" on Google play among which an application developer
>> >>>> >> (https://play.google.com/store/apps/developer?id=x-droid) and an
>> >>>> >> application (
>> >>>> >>
>> >>>> >>
>> https://play.google.com/store/apps/details?id=com.gurudigitalsolutions.xdroid
>> >>>> >> ).
>> >>>> >>
>> >>>> >> >
>> >>>> >> > Thanks,
>> >>>> >> > Best Regards
>> >>>> >> >
>> >>>> >> > Sasinda.
>> >>>> >> >
>> >>>> >> >
>> >>>> >> >
>> >>>> >> >
>> >>>> >> >
>> >>>> >> > On Wed, May 30, 2012 at 7:42 AM, sasinda rukshan
>> >>>> >> > <[hidden email]>wrote:
>> >>>> >> >
>> >>>> >> >> Hi,
>> >>>> >> >>
>> >>>> >> >> I am commiting my work to my fork
>> >>>> >> >> https://github.com/sasinda/android-client.
>> >>>> >> >> I ll request to pull it to xwiki-contrib later.
>> >>>> >> >>
>> >>>> >> >> I was running in a wrong path these days. Wanted to save login
>> >>>> >> >> history
>> >>>> >> and
>> >>>> >> >> suggest login. I was going to do it using an xml file (login
>> >>>> >> attempts.xml).
>> >>>> >> >> Now it seems database is better.
>> >>>> >> >> Any way before I go wrong again I will say what I am going to
>> do.
>> >>>> >> >> I am going to enforce following conventions.These are not yet
>> >>>> >> >> needed,
>> >>>> >> >> considered the small scale.But when the system grows it would
>> be
>> >>>> >> >> nice to
>> >>>> >> >> have them to avoid confusions.
>> >>>> >> >> *Database prefixes for:*
>> >>>> >> >> *Platform tables (can begin with appropriate prefix)*
>> >>>> >> >> AD_ //application dictionary : don't know when it will be
>> needed ;-)
>> >>>> >> >> C_ //core functionality
>> >>>> >> >> *Client Applications.*
>> >>>> >> >> X<App name prefix>  ex: XBLOG_   for Blog app// All client add
>> in
>> >>>> >> modules
>> >>>> >> >> must begin with table prefix X(for xwiki and ordering) + App
>> name.
>> >>>> >>  This is
>> >>>> >> >> for my blog.
>> >>>> >> >>
>> >>>> >> >> I will create
>> >>>> >> >> C_User for user data.
>> >>>> >> >> C_LoginAttempt  for saving login attempts.
>> >>>> >> >>
>> >>>> >> >> From C_LoginAttempt I can filter uniqe login combinations and
>> give
>> >>>> >> >> suggestions in the login UI component. Also save the history.
>> >>>> >> >>
>> >>>> >> >> All saved data for blog app will be linked to a perticular
>> login :
>> >>>> >> >> User,
>> >>>> >> >> XWiki server.
>> >>>> >> >> But only a single user will be most probably using his personal
>> >>>> >> >> device.
>> >>>> >> So
>> >>>> >> >> above will be relevant only when he has multiple wikis.
>> >>>> >> >>
>> >>>> >> >> Best Regards,
>> >>>> >> >> Sasinda Rukshan.
>> >>>> >> >>
>> >>>> >> >>
>> >>>> >> >>
>> >>>> >> >>
>> >>>> >> >>
>> >>>> >> >> On Sun, May 27, 2012 at 5:43 PM, Chamika Weerasinghe <
>> >>>> >> [hidden email]>wrote:
>> >>>> >> >>
>> >>>> >> >>> On Fri, May 25, 2012 at 1:25 AM, Jerome Velociter <
>> >>>> >> [hidden email]
>> >>>> >> >>> >wrote:
>> >>>> >> >>>
>> >>>> >> >>> > On Thu, May 24, 2012 at 6:09 PM, Thomas Mortagne
>> >>>> >> >>> > <[hidden email]> wrote:
>> >>>> >> >>> > > On Thu, May 24, 2012 at 5:52 PM, sasinda rukshan
>> >>>> >> >>> > > <[hidden email]> wrote:
>> >>>> >> >>> > >> Hi all,
>> >>>> >> >>> > >> I am starting this thread for my XWiki Android Platform
>> >>>> >> >>> > >> Project.
>> >>>> >> >>> > >>
>> >>>> >> >>> > >> Please check whether following are OK.
>> >>>> >> >>> > >> [1] INFO
>> >>>> >> >>> > >> I tried to start my new modules with the
>> >>>> >> >>> de.akquinet.android.archetypes:
>> >>>> >> >>> > >> android-quickstart:1.0.8.  (added eclipse plugins m2e,
>> >>>> >> >>> > >> m2e-android[a.k.a  *Android
>> >>>> >> >>> > >> Configurator* ]). But this seems buggy in eclipse.
>> >>>> >> >>> > >> Any way the earlier project has not followed the above
>> >>>> >> >>> > >> archtype
>> >>>> >> >>> either.
>> >>>> >> >>> > So
>> >>>> >> >>> > >> I am going to write pom.xml manually for my each module.
>> >>>> >> >>> > >>
>> >>>> >> >>> > >> [2] ADVICE NEEDED
>> >>>> >> >>> > >> xwiki-rest-model module contains 2 submodules
>> >>>> >> >>> > >>  |-- xwiki-rest-model-gson  ( gson should be corrected to
>> >>>> >> >>> > >> json)
>> >>>> >> >>> > >
>> >>>> >> >>> > > No the g is not a mistake, it's a model to be used with
>> the
>> >>>> >> >>> > > gson
>> >>>> >> >>> > > library (http://code.google.com/p/google-gson/). See
>> >>>> >> >>> > >
>> >>>> >> >>> >
>> >>>> >> >>>
>> >>>> >>
>> >>>> >>
>> http://extensions.xwiki.org/xwiki/bin/view/Extension/Google+Android+Client#HXWikiAndroidDevelopmentAPIsandResources
>> >>>> >> >>> > .
>> >>>> >> >>> > >
>> >>>> >> >>> > >>  |-- xwiki-rest-model-simplexml
>> >>>> >> >>> > >> I think the xwiki-rest-model-gson is redundant. The
>> classes
>> >>>> >> >>> > >> in xwiki-rest-model-simplexml is added with simple xml
>> >>>> >> annotations,
>> >>>> >> >>> > >> otherwise both modules have same classes. There is no
>> problem
>> >>>> >> >>> > >> with
>> >>>> >> >>> the
>> >>>> >> >>> > >> added annotations for using the same model objects for
>> Json
>> >>>> >> >>> > >> REST
>> >>>> >> web
>> >>>> >> >>> > >> services. And I intend to add my JPA (ORMLite library for
>> >>>> >> >>> persistence)
>> >>>> >> >>> > >> annotations on top of it.
>> >>>> >> >>> > >> Shall I re-factor them to a single module
>> xwiki-rest-model.
>> >>>> >> >>> > >
>> >>>> >> >>> > > No keep them separated, the idea is that both are useful
>> tool
>> >>>> >> >>> > > to be
>> >>>> >> >>> > > used by someone else that might be moved to
>> xwiki-platform at
>> >>>> >> >>> > > some
>> >>>> >> >>> > > point along with the current xwiki-rest-model (to be
>> renamed to
>> >>>> >> >>> > > xwiki-rest-model-jaxb).
>> >>>> >> >>> > >
>> >>>> >> >>> > > Chamika initially started with gson and since XWiki REST
>> JSON
>> >>>> >> >>> > > representation had some limitation he moved to XML
>> >>>> >> >>> > > representation.
>> >>>> >> >>> > > Maybe at some point Android will have native support for
>> jaxb
>> >>>> >> >>> > > which
>> >>>> >> >>> > > would obviously be the easier for us (embedding jaxb is
>> not an
>> >>>> >> option
>> >>>> >> >>> > > in mobile world where size it still pretty important
>> especially
>> >>>> >> >>> > > on
>> >>>> >> >>> > > phones). Maybe it's already the case on most recent
>> versions
>> >>>> >> >>> > > like
>> >>>> >> 4.0
>> >>>> >> >>> > > I don't know.
>> >>>> >> >>> >
>> >>>> >> >>> > There's also Jackson that could be tried for JSON
>> >>>> >> >>> > deserialization, if
>> >>>> >> >>> > said limitations are actually GSON limitations.
>> >>>> >> >>> >
>> >>>> >> >>> GSON wasn't the limitation.
>> >>>> >> >>> It was XWiki RESTful API which doesn't support JSON in some
>> cases.
>> >>>> >> >>> So
>> >>>> >> it's
>> >>>> >> >>> safe to go with xml.
>> >>>> >> >>>
>> >>>> >> >>> >
>> >>>> >> >>> > Having full JAXB support sound a bit overweight for such an
>> >>>> >> >>> > "embedded
>> >>>> >> >>> > API", even if one day it is natively supported by Android.
>> What's
>> >>>> >> >>> > important is to have an easy and fast deserialization, IMO.
>> >>>> >> >>> > The only advantage I can see of going JAXB would be in
>> re-using
>> >>>> >> >>> > the
>> >>>> >> >>> > exact representations and body readers/writers from XWiki
>> core.
>> >>>> >> >>> > But
>> >>>> >> >>> > you probably don't even want to do that since it would mean
>> >>>> >> >>> > dragging
>> >>>> >> >>> > XWiki core with you :)
>> >>>> >> >>> >
>> >>>> >> >>> > Jerome
>> >>>> >> >>> >
>> >>>> >> >>> > >
>> >>>> >> >>> > >>
>> >>>> >> >>> > >> [3] INFO
>> >>>> >> >>> > >>  I had to change some pom.xml s. As the current project
>> at:
>> >>>> >> >>> > >> https://github.com/xwiki-contrib/android-client.gitdoes not
>> >>>> >> build.
>> >>>> >> >>> > Error
>> >>>> >> >>> > >> with parent pom.xml coordinates.
>> >>>> >> >>> > >
>> >>>> >> >>> > > You probably did not setup you maven install properly
>> since
>> >>>> >> >>> > > what's
>> >>>> >> on
>> >>>> >> >>> > > https://github.com/xwiki-contrib/android-client.git build
>> >>>> >> perfectly
>> >>>> >> >>> as
>> >>>> >> >>> > > you can see on
>> >>>> >> http://ci.xwiki.org/view/All/job/xwiki-android-client/
>> >>>> >> >>> > > which run a build every time something changes on the git
>> >>>> >> repository..
>> >>>> >> >>> > > You should look at
>> >>>> >> >>> > > http://dev.xwiki.org/xwiki/bin/view/Community/Building.
>> >>>> >> >>> > >
>> >>>> >> >>> > >>
>> >>>> >> >>> > >>
>> >>>> >> >>> > >> Thank you
>> >>>> >> >>> > >> Best Regards.
>> >>>> >> >>> > >> Sasinda Rukshan
>> >>>> >> >>> > >> _______________________________________________
>> >>>> >> >>> > >> devs mailing list
>> >>>> >> >>> > >> [hidden email]
>> >>>> >> >>> > >> http://lists.xwiki.org/mailman/listinfo/devs
>> >>>> >> >>> > >
>> >>>> >> >>> > >
>> >>>> >> >>> > >
>> >>>> >> >>> > > --
>> >>>> >> >>> > > Thomas Mortagne
>> >>>> >> >>> > > _______________________________________________
>> >>>> >> >>> > > devs mailing list
>> >>>> >> >>> > > [hidden email]
>> >>>> >> >>> > > http://lists.xwiki.org/mailman/listinfo/devs
>> >>>> >> >>> >
>> >>>> >> >>> >
>> >>>> >> >>> >
>> >>>> >> >>> > --
>> >>>> >> >>> > Jérôme Velociter
>> >>>> >> >>> > Winesquare
>> >>>> >> >>> > http://www.winesquare.net/
>> >>>> >> >>> > _______________________________________________
>> >>>> >> >>> > devs mailing list
>> >>>> >> >>> > [hidden email]
>> >>>> >> >>> > http://lists.xwiki.org/mailman/listinfo/devs
>> >>>> >> >>> >
>> >>>> >> >>> _______________________________________________
>> >>>> >> >>> devs mailing list
>> >>>> >> >>> [hidden email]
>> >>>> >> >>> http://lists.xwiki.org/mailman/listinfo/devs
>> >>>> >> >>>
>> >>>> >> >>
>> >>>> >> >>
>> >>>> >> > _______________________________________________
>> >>>> >> > devs mailing list
>> >>>> >> > [hidden email]
>> >>>> >> > http://lists.xwiki.org/mailman/listinfo/devs
>> >>>> >>
>> >>>> >>
>> >>>> >>
>> >>>> >> --
>> >>>> >> Thomas Mortagne
>> >>>> >> _______________________________________________
>> >>>> >> devs mailing list
>> >>>> >> [hidden email]
>> >>>> >> http://lists.xwiki.org/mailman/listinfo/devs
>> >>>> >>
>> >>>> > _______________________________________________
>> >>>> > devs mailing list
>> >>>> > [hidden email]
>> >>>> > http://lists.xwiki.org/mailman/listinfo/devs
>> >>>>
>> >>>>
>> >>>>
>> >>>> --
>> >>>> Thomas Mortagne
>> >>>
>> >>>
>> >>
>> >>
>> >>
>> >> --
>> >> Thomas Mortagne
>> >
>> >
>> >
>> > --
>> > Thomas Mortagne
>>
>>
>>
>> --
>> Thomas Mortagne
>>
>
>
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [GSoc] XDroid Platform

sasinda
Hi,

Status Rept:
I reverse engineered the com.xpn.objects /.object.classes / .object.meta
packages. I think I understand it somewhat now.
I am making up my own simple design for the model classes.
I will soon post UML diagram with my design. Since XWiki ReST interfaces
are so robust I don't have to fill many of the attribute fields and
propertiest to post a blog post.
I will further experiment (Using Postman chrome plugin for ReST testing,
it's nice) before coming up with the class diagram.

Questions:
1) A page has its own class. When we make a new page a custom class gets
created. I checked the xml file for  Blog.BlogIntroduction. It looked more
of a representation of a document object. Not a class definition. (It had
values defined. So can it be considered as a class def) ?

2) Is this idea correct?
I make a new page named NEWPAGE1  in Blog space.
 page  :is of class type  Blog.NEWPAGE1.
 can have objects of any type.
I posted a BlogPostClass object. But there are no restrictions to post
another BlogPostClass object. But only the first BlogPostClass object is
rendered when viewing the page.

Shouldn't the page be of type BlogClass (extends BlogCode).?
So,
Shall I give a type for a document object. Something like
doc.setType(BlocClass.class); When this happens the document object
enforces type restrictions. Like only BlogPostClass objects should be in
the page and etc.

I'll be happy to provide with clarifications If I said things very briefly.
I will design a uml class diag for this part and send before implementation
starts.


Thanks
Best Regards
Sasinda.







Thank You


On Sat, Jun 16, 2012 at 10:31 PM, sasinda rukshan
<[hidden email]>wrote:

> Hi,
> I checked the source code.(still it would be helpful if u cn explain)
> I have  a little issue.
> Say with the current model
> Blog.BlogPostClass
>   properties|__DBTreeList  category  {has a list of attributes}
>                   |__TextAreaClass content   {has a list of attributes}
>             |__ MYType  myComplexTypeProp {has a list of attributes
>  which are all simple properties such as StringProperty etc}  [ for
> ex:TagClass tagprop ]
>                                    |__ StringClass mystring   {also have a
> list of attributes.
>
> The XML schema
>
> <complexType name="Object">
>    <complexContent>
>      <extension base="{http://www.xwiki.org}ObjectSummary">
>        <sequence>
>          <element name="property" type="{http://www.xwiki.org}Property" maxOccurs="unbounded" minOccurs="0"/>
>        </sequence>
>      </extension>
>    </complexContent>
>  </complexType>
>
> <complexType name="Property">
>    <complexContent>
>      <extension base="{http://www.xwiki.org}LinkCollection">
>        <sequence>
>          <element name="attribute" type="{http://www.xwiki.org}Attribute" maxOccurs="unbounded" minOccurs="0"/>
>          <element name="value" type="{http://www.w3.org/2001/XMLSchema}string"/>
>        </sequence>
>        <attribute name="name" use="required" type="{http://www.w3.org/2001/XMLSchema}string" />
>        <attribute name="type" type="{http://www.w3.org/2001/XMLSchema}string" />
>      </extension>
>    </complexContent>
>  </complexType>
>
>  <complexType name="Attribute">
>    <complexContent>
>      <extension base="{http://www.xwiki.org}LinkCollection">
>        <attribute name="name" use="required" type="{http://www.w3.org/2001/XMLSchema}string" />
>        <attribute name="value" type="{http://www.w3.org/2001/XMLSchema}string" />
>      </extension>
>    </complexContent>
>  </complexType>
>
> does not seem to be addressing such an occasion where multiple levels of
> nesting is happening. (May be I'm horribly wrong here)
>
> Am I correct to think that any type of Object like BlogPostClass obj will only have properties of simple types such as StringClass, TextAreaClass and etc. It will not have a complex type for example XWiki.TagClass in it.(I know it never happens in BlogPostClass, but don't know if someone needs to do a weird class). ?
>
> My findings and comprehension on the model:
>
> I guess StringClass, TextAreaClass etc, carry most of those many attributes for rendering purpose. I saw StaticListClass has attribute (separators) for defining the list value delimeters as well.
>
> Can you please post me a diagram taking a single class like DateClass. How
> the aggregations and inheritance is done.
> Ill send my design. I intend to do all that with just single definition
> for each XWiki data type classes.For ex: XString extends XObject.XObject
> contains the collection of fields.These can be converted to <attribute>
> elements. A Document Object will contain a BlogPost (represent
> BlobPostClass) object which contains XObject s as properties. (ideally if
> multiple levels of nesting is supported BlogPost should also be a XObject).
> The Document Object is an entity.(refer
> https://docs.google.com/drawings/d/1hwfQMVgCvYKS6iHU060drcET3Aq3Vles2DQlJOOt3n8/edit<https://docs.google.com/drawings/d/1hwfQMVgCvYKS6iHU060drcET3Aq3Vles2DQlJOOt3n8/edit?pli=1>
>  )
> When we persist a document object it should serialize the BLogPost class
> into its xml representation and save it on the filesystem. SQLite DB will
> have a row with the URI for that file. So I am not going to persist
> rest-model objects ( neither annotate them for persistence). Storing such
> bulk objects may degrade DB performance. In the android dev guides it is
> said a curser to a table should not exceed 2 MB of data otherwise the
> performance will be low due to paging.
> This makes the persistence a little complex. I will manage it. PLS tell if
> my approach is wrong.
>
> By the way I will merge my work to the master branch next week. Is it ok
> to duplicate your maven work to a mvn branch and undo the commit in master
> and merge my work with a fast forward merge, so that it will show  a linear
> history.
>
> Thanks
> Best Regards.
> Sasinda Rukshan.
>
>
>
>
>
>
>
> On Sat, Jun 16, 2012 at 11:21 AM, sasinda rukshan <
> [hidden email]> wrote:
>
>> Thanks very much for the help on maven build.
>>
>> *About making a object from Blog.BlogPostClass  and toXML()*
>>
>> A blog object is having properties of type other xobject classes. So to
>> make the things general can we do a stripped down replication or make
>> something similer to the java classes in com.xpn.xwiki.objects and its 2
>> sub packages .classes, .meta .
>>  We can make a document object representing a page and put a
>> Blog.BlogPostClass object to its list of objects.We can convert them to
>> simple xml model directly.If we want to post blog object we can post the
>> Blog object.If the page does not exist we can put the page by getting the
>> xml from the Document object.
>> Then the things will be general not only for blog client app. Also we can
>> have Type checking when we don't directly manipulate simplexml objects.
>> i.e. XStringClass will define the attributes for it and likewise.
>>
>> I don't have a good idea on the above packages and classes. Specially why
>> there are three classes for each XType ex: StringProperty, StringClass,
>> StringMeta.
>> It will be helpful if you can give an explanation.
>>
>> My draft solution is to do some simple thing as,
>> XObject
>>  |____ XBoolean
>>
>> XObject
>> |____XString
>>
>> XString has methods,
>> toEmbedXML  gives a <property><attribute/>...</property> string/
>> simpleXML objects
>> toXML  gives <object><id><ClassName>.......</object> for the same thing.
>>
>> Also
>> XObject
>> |_____ XBlogPost       for(BlogPostClass and other 2 Meta,Property
>> classes)
>>
>> I don't yet have a clear idea on this. May be I am wrong on this.
>> Can you give me your idea here as well. How to approach the problem and
>> what should the design be like?
>>
>> Thanks.
>> Best Regards
>> Sasinda.
>>
>>
>>
>> On Thu, Jun 7, 2012 at 9:28 PM, Thomas Mortagne <
>> [hidden email]> wrote:
>>
>>> As just did a commit with last version of android plugin and some
>>> cleanup. Seems to work well.
>>>
>>> On Thu, Jun 7, 2012 at 12:19 PM, Thomas Mortagne
>>> <[hidden email]> wrote:
>>> > BTW if you have quick questions it's probaly better to use IRC (I'm
>>> > tmortgane on the channel and I'm on GMT+2 tome zone but you can ask
>>> > anyone when I'm not around). See
>>> > http://dev.xwiki.org/xwiki/bin/view/Community/IRC.
>>> >
>>> > On Thu, Jun 7, 2012 at 12:17 PM, Thomas Mortagne
>>> > <[hidden email]> wrote:
>>> >> Not need to send this kind of mail privately to me.
>>> >>
>>> >> On Thu, Jun 7, 2012 at 5:33 AM, sasinda rukshan
>>> >> <[hidden email]> wrote:
>>> >>> Thanks,
>>> >>> The project is building perfectly well in eclipse (and runs well
>>> too) [I
>>> >>> configured the build paths for eclipse opening each module as a
>>> project and
>>> >>> giving project dependencies and etc.]. This is because android facet
>>> and
>>> >>> maven-android plugin for eclipse [m2e-android] (not the jayway
>>>  androi maven
>>> >>> plugin)does not work together well.
>>> >>> Maven build does not work with newer jayway android maven plugins
>>> because of
>>> >>> the simplexml library. I checked with another helloworld app that
>>> does not
>>> >>> have simplexml dependancy and have simplexml dependancy. When we
>>> have the
>>> >>> dependancy it does not work. Also when packaged with the beta
>>> version maven
>>> >>> plugin I get runtime error logs notifying that the exact classes
>>> informed
>>> >>> missed in the compile time for newer maven plugin are missing. But
>>> the app
>>> >>> is running ok.
>>> >>> I will try with it some more and if I can't can you help me with it a
>>> >>> little.
>>> >>
>>> >> Sure If it's just related to simplexml it's probably not much. I will
>>> >> try to take a look today. At worst the version we are using right now
>>> >> is working fine so you can continue with it anyway.
>>> >>
>>> >>>
>>> >>> I looked at the Enterprise platform apis just to make my apis
>>> similar when
>>> >>> possible.Source code is not at all relevant to me. But as you say It
>>> will be
>>> >>> imperfect if I use its style heavily for the mobile version as well.
>>> >>
>>> >> Yes there is several issues here:
>>> >> * most APIs in oldcore module are old and bad and we are trying to get
>>> >> rif of them so better not getting too much attached to it ;)
>>> >> * they are designed to run in an enironment with lots of resources and
>>> >> don't care as much as a mobile API should about memory, etc.
>>> >>
>>> >>>
>>> >>>
>>> >>> Thank you.
>>> >>> Best Regards.
>>> >>> Sasinda.
>>> >>>
>>> >>>
>>> >>> On Wed, Jun 6, 2012 at 1:03 PM, Thomas Mortagne <
>>> [hidden email]>
>>> >>> wrote:
>>> >>>>
>>> >>>> On Tue, Jun 5, 2012 at 7:07 PM, sasinda rukshan
>>> >>>> <[hidden email]> wrote:
>>> >>>> > Hi,
>>> >>>> > *1: User Config Saving*
>>> >>>> > *
>>> >>>> > *
>>> >>>> > Xwiki android can now save user login data.
>>> >>>> > I refered
>>> >>>> > http://platform.xwiki.org/xwiki/bin/view/AdminGuide/AccessWiki.
>>> >>>> > Currently assuming the authority
>>> >>>> >
>>> >>>> > part(platform.xwiki.org<
>>> http://platform.xwiki.org/xwiki/bin/view/AdminGuide/AccessWiki>)
>>> >>>> > only
>>> >>>> > as a unique wiki identifier. But in the
>>> org.xwiki.android.entity.User I
>>> >>>> > have the method
>>> >>>> > setXWikiRealm(String url);:
>>> >>>> > Here I have intended the meaning realm as the url root path for a
>>> unique
>>> >>>> > wiki instance.
>>> >>>> > i.e. it should identify a wiki using path upto
>>> >>>> > http://host/xwiki/wiki/wikialias/
>>> >>>> > But that functionality is not implemented.I just mailed this
>>> asking for
>>> >>>> > the
>>> >>>> > opinion wether the usage of word realm was right here.
>>> >>>> > Also do you have seperate users for  wikis for path based wiki
>>> access.Or
>>> >>>> > are they the same with the main wiki *http://<host>/xwiki*.
>>> >>>>
>>> >>>> Both actually, you can have global users (which are the one on main
>>> >>>> wiki) and local users.
>>> >>>>
>>> >>>> > *2: Entity model*
>>> >>>> > *
>>> >>>> > *
>>> >>>> > About the convention for using C_ prefix for core entity tables. I
>>> >>>> > was referring to make the android versions of these entities
>>> >>>> > http://platform.xwiki.org/xwiki/bin/view/DevGuide/DatabaseSchemaand
>>> >>>> > start
>>> >>>> > there db prefixes with C_
>>> >>>> > This is because other apps may need to store some specific tables
>>> needed
>>> >>>> > for them. Rather than having a seperate DB schema for them we can
>>> put
>>> >>>> > those
>>> >>>> > tables here as well prefixing them with <appname>_ .
>>> >>>> > I added more entities like User as well to the core entities(table
>>> >>>> > C_User).Also will implement a Log Entity(C_Log table) for logging
>>> some
>>> >>>> > important application activities(such as login attempts) But the
>>> Log may
>>> >>>> > be
>>> >>>> > a little additional weight to the space and performance.I may
>>> implement
>>> >>>> > a
>>> >>>> > generic DBCleaning service to clean the tables like Log, if I
>>> have time.
>>> >>>> > (Perhaps this description will resolve the confusion about the DB
>>> >>>> > conventions. Sorry I was not very clear in that earlier mail.
>>> ;-).)
>>> >>>> >
>>> >>>> > I am sorry to say I am somewhat confused with all those entities
>>> in
>>> >>>> > http://platform.xwiki.org/xwiki/bin/view/DevGuide/DatabaseSchema.
>>> >>>>
>>> >>>> The XWiki model is based on generic classes and objects wich is why
>>> >>>> you see lots of tables (class properties, object properties , etc.).
>>> >>>> There is no table for users for example, its an object of class
>>> >>>> XWiki.XWikiUsers.
>>> >>>>
>>> >>>> >
>>> >>>> > Any way to reduce my confusion
>>> >>>> > I refered
>>> >>>> > 1)  XWiki Data
>>> >>>> > Model<http://platform.xwiki.org/xwiki/bin/view/DevGuide/DataModel
>>> >
>>> >>>> > :
>>> >>>> >   can you give me a link to a documentation that explains the
>>> workflow
>>> >>>> > of
>>> >>>> > how a normal request is converted in to the requested page by the
>>> >>>> > bin View action . So I can get a better understanding of how
>>> classes ,
>>> >>>> > objects are used.
>>> >>>>
>>> >>>> Not sure there is one. but basically you get either:
>>> >>>> * document content executed
>>> >>>> * if a class sheet is defined for one of the document objects
>>> classes,
>>> >>>> the class sheet is executed
>>> >>>> * if a document sheet is defined for the documment, the document
>>> sheet
>>> >>>> is executed
>>> >>>>
>>> >>>> That's pretty much all, then is a matter of free script and wiki
>>> >>>> syntax to actually display the content.
>>> >>>>
>>> >>>> > 2)  package com.xpn.xwiki.api: I don't need to consider this, do
>>> I?
>>> >>>>
>>> >>>> That's limited scripting API so you should not consider this.
>>> >>>>
>>> >>>> > 3)
>>> >>>> >  Cache<
>>> http://extensions.xwiki.org/xwiki/bin/view/Extension/Cache+Module>
>>> >>>> >  : Need not implement similar component. Android OS does it
>>> nicely for
>>> >>>> > the
>>> >>>> > REST responses
>>> >>>> > but still don't have a clear picture on this.
>>> >>>> > To save a blog doc
>>> >>>> > option 1)Seems like I have to convert a document entity to
>>> relevent
>>> >>>> > xwiki-model-simplexml entities and send to server.
>>> >>>> > option 2) We also can edit the relevent simplexml model object
>>> fields
>>> >>>> > directly. (Looks a bad option to me.It does not hide the
>>> complexity of
>>> >>>> > lower levels for the client layer.Anyway my work load  is reduced
>>> with
>>> >>>> > opt:2 ;-))
>>> >>>>
>>> >>>> IMO you should not even look at
>>> >>>> http://extensions.xwiki.org/xwiki/bin/view/Extension/Cache+Moduleand
>>> >>>> instead look at how caching is usually done in Android. The idea is
>>> >>>> not to port the xwiki-platform to Android IMO but to follow Android
>>> >>>> standards to provide a library to manipulate XWiki model.
>>> >>>>
>>> >>>> You can set the annotation you want to the simplexml model but the
>>> >>>> classes/methods should remain an exact copy of what's on
>>> >>>> xwiki-platform-rest-model. The idea being that we could decide to
>>> >>>> change the implementation from simplexml to anything (JAXB, gson,
>>> >>>> etc.) without breaking anything.
>>> >>>>
>>> >>>> >
>>> >>>> >
>>> >>>> > *3: Development/architectural approach Change*
>>> >>>> > *
>>> >>>> > *
>>> >>>> > I was first thinking for a addon like architecture for the XWiki
>>> android
>>> >>>> > app. We have the client.Main app (with all platfrom libs
>>> included) and
>>> >>>> > Blog
>>> >>>> > app as a seperate apk.
>>> >>>> > But here Blog app will need to have the platform lib also. That
>>> would be
>>> >>>> > a
>>> >>>> > complete waste of space. But dynamically extending the app is lot
>>> >>>> > easier.
>>> >>>> > The client.Main app can add the activities defined in other apks
>>> in to
>>> >>>> > its
>>> >>>> > launcher interface using android PackageManager class.
>>> >>>> >
>>> >>>> >
>>> http://stackoverflow.com/questions/9236803/android-build-an-application-that-supports-add-ons
>>> >>>> > But with this approach rises additional complexities. For example
>>> naming
>>> >>>> > conflicts in the Components library module when two apps have the
>>> same
>>> >>>> > library with same activities defined. Sync issues etc etc....
>>> >>>> > So we will go with single .apk approach.
>>> >>>> > When going with single .apk we dont need a content provider to
>>> share
>>> >>>> > config/ preferences data. So sharing module is now not needed. The
>>> >>>> > client
>>> >>>> > applications now can directly access the Configuration.java class
>>> to
>>> >>>> > get/put configuration entries.
>>> >>>> > Also since I am having a User entity a configuration like
>>> >>>> > defaultUser(currently the admin user , hard coded in login.xml
>>> layout
>>> >>>> > file)
>>> >>>> > will only be needed for the first use of the app. Otherwise users
>>> need
>>> >>>> > not
>>> >>>> > configure a default user as the application now suggests the user
>>> names
>>> >>>> > and
>>> >>>> > automatically fill the rest.
>>> >>>>
>>> >>>> Keep in mind that the main goal of this project is to provide tools
>>> >>>> for any application to access an XWiki instance and manipulate its
>>> >>>> datas easily an improving those libraries should always be the first
>>> >>>> goal. Your blog application is here as a good demo and because it's
>>> >>>> hard to design a library without using it.
>>> >>>>
>>> >>>> I really don't understand why you talk about naming conflict. Of
>>> >>>> course a library should never provide a complete final activity but
>>> >>>> only interface components (View), fragments or base activities to
>>> >>>> extend. Putting those elements in an activity is each application
>>> job.
>>> >>>> An activity is by definition unique so it has nothing to do in a
>>> >>>> library. The complete activities in
>>> >>>>
>>> >>>>
>>> https://github.com/xwiki-contrib/android-client/tree/master/xwiki-android-components/
>>> >>>> should have never been there, it's actually a mistake.
>>> >>>>
>>> >>>> >
>>> >>>> > *4: Plan for this week*
>>> >>>>
>>> >>>> As a priority you should really merge your branch as soon as you
>>> have
>>> >>>> something building fine. So that it goes through Jenkins and deploy
>>> >>>> snapshot build of what you do. Jenkins will tells you in live when
>>> >>>> your project does not build anymore or if there is any test failing
>>> >>>> and it allows anyone to very easily test the current test of the
>>> >>>> client just by installing the apks on
>>> >>>> http://maven.xwiki.org/snapshots/org/xwiki/android/. You need to
>>> have
>>> >>>> something working and in good shape to succeed the GSOC so fixing
>>> when
>>> >>>> you break something in your build should be your priority over
>>> adding
>>> >>>> more features.
>>> >>>>
>>> >>>> Also as I commented in your commit you should be more careful on
>>> what
>>> >>>> you commit. There is many binaries and Eclipse stuff in your branch.
>>> >>>>
>>> >>>> > *
>>> >>>> > *
>>> >>>> > Make a launch pad .We can launch XWiki Navigator, blog etc from
>>> this.
>>> >>>> > The
>>> >>>> > launch pad is shown when we launch XWiki main client.
>>> >>>> > Consider adding the WYSIWYG to my blog. It will be useless
>>> without the
>>> >>>> > ability to convert text formatting to xwiki syntax.So I may just
>>> >>>> > integrate
>>> >>>> > it and ignore the uselessness for now.
>>> >>>>
>>> >>>> Not exactly, you could actually reuse WYSIWYG service to send html
>>> and
>>> >>>> let it convert it to wiki syntax. Note that you are not limited to
>>> >>>> what you can find in the current Android library. This is just what
>>> >>>> Chamika had the time to do. There is others REST (or not REST)
>>> server
>>> >>>> interfaces you can use in your client or even add more if its
>>> generic
>>> >>>> enough and make sense for something else than just Android client.
>>> >>>>
>>> >>>> > We currently don't have any config to save( Other than default
>>> user)
>>> >>>> > config. I will add some demo config data and have a developer
>>> tools app
>>> >>>> > added to the above mentioned XWiki launch pad that can view/edit
>>> the
>>> >>>> > config
>>> >>>> > file.
>>> >>>> >
>>> >>>> > That will complete milestone 1. But it is not the Sharing
>>> >>>> > module(intended
>>> >>>> > to share data with other .apks).That is the configuration
>>> component does
>>> >>>> > not have a ContentProvider to share config data with other apks.
>>> Also I
>>> >>>> > will define a seperate class to have preferences which will be
>>> edited by
>>> >>>> > users. Config files are for configuration stuff and will be
>>> edited by
>>> >>>> > developers. Users have preferences files(natively supported by
>>> android)
>>> >>>> > to
>>> >>>> > change app preferences. For example users will add the default
>>> login
>>> >>>> > username as a preference.(This will invalidate the use of default
>>> User
>>> >>>> > entry in the config file which is used until the user edits his
>>> >>>> > preferences)
>>> >>>>
>>> >>>> I'm fine with not sharing datas between applications but it does not
>>> >>>> prevent the libraries to  provide tools to manage those datas in a
>>> per
>>> >>>> application basis.
>>> >>>>
>>> >>>> >
>>> >>>> > Beg your pardon if the mail is too lengthy.;-)
>>> >>>>
>>> >>>> No problem, never too much information for this ;)
>>> >>>>
>>> >>>> > Thank you.
>>> >>>> > Best Regards.
>>> >>>> >
>>> >>>> > Sasinda Rukshan.
>>> >>>> >
>>> >>>> >
>>> >>>> > Best Regards.
>>> >>>> >
>>> >>>> >
>>> >>>> > On Wed, May 30, 2012 at 1:11 PM, Thomas Mortagne
>>> >>>> > <[hidden email]>wrote:
>>> >>>> >
>>> >>>> >> On Wed, May 30, 2012 at 4:28 AM, sasinda rukshan
>>> >>>> >> <[hidden email]> wrote:
>>> >>>> >> > Hi,
>>> >>>> >> > I am studying ORM Lite these days.
>>> >>>> >> > Please It would be comforting if you can confirm whether it is
>>> worth
>>> >>>> >> > the
>>> >>>> >> > overhead to use ORM Lite.
>>> >>>> >> >
>>> >>>> >>
>>> >>>> >>
>>> http://logic-explained.blogspot.com/2011/12/using-ormlite-in-android-projects.html
>>> >>>> >> > http://ormlite.com/
>>> >>>> >> > ORM Lite features:
>>> >>>> >> > Automatically Creates standard DAOs for an annotated entity.
>>> >>>> >> > Coding will be lot easier.
>>> >>>> >>
>>> >>>> >> Remember it's a framework for a mobile platform so it has to
>>> remain
>>> >>>> >> light and have good performances. I can see that Android version
>>> of
>>> >>>> >> ormlite is very small but I never used it so I don't know if
>>> it's good
>>> >>>> >> or not. At least it seems petty active which is a good point so I
>>> >>>> >> don't have anything against it.
>>> >>>> >>
>>> >>>> >> >
>>> >>>> >> > Can you suggest how to name the entities.
>>> >>>> >> > I am going to go with,
>>> >>>> >> > <entity>  org.xwiki.xdroid.data.User  --> <table> C_USER
>>> >>>> >>
>>> >>>> >> Note that there is already a package name prefix and group id
>>> defined
>>> >>>> >> for the framework and it's org.xwiki.android as you can see on
>>> >>>> >> https://github.com/xwiki-contrib/android-client. Why do you
>>> want to
>>> >>>> >> change it ? It's more consistent with
>>> >>>> >> org.xwiki.commons/org.xwiki.rendering/org.xwiki.platform so I
>>> would
>>> >>>> >> prefer to keep it that way unless you can give arguments. The
>>> goal is
>>> >>>> >> not to redo something completely but complete and improve the
>>> existing
>>> >>>> >> framework.
>>> >>>> >>
>>> >>>> >> Also as far as I can see there is already several things called
>>> >>>> >> "xdroid" on Google play among which an application developer
>>> >>>> >> (https://play.google.com/store/apps/developer?id=x-droid) and an
>>> >>>> >> application (
>>> >>>> >>
>>> >>>> >>
>>> https://play.google.com/store/apps/details?id=com.gurudigitalsolutions.xdroid
>>> >>>> >> ).
>>> >>>> >>
>>> >>>> >> >
>>> >>>> >> > Thanks,
>>> >>>> >> > Best Regards
>>> >>>> >> >
>>> >>>> >> > Sasinda.
>>> >>>> >> >
>>> >>>> >> >
>>> >>>> >> >
>>> >>>> >> >
>>> >>>> >> >
>>> >>>> >> > On Wed, May 30, 2012 at 7:42 AM, sasinda rukshan
>>> >>>> >> > <[hidden email]>wrote:
>>> >>>> >> >
>>> >>>> >> >> Hi,
>>> >>>> >> >>
>>> >>>> >> >> I am commiting my work to my fork
>>> >>>> >> >> https://github.com/sasinda/android-client.
>>> >>>> >> >> I ll request to pull it to xwiki-contrib later.
>>> >>>> >> >>
>>> >>>> >> >> I was running in a wrong path these days. Wanted to save login
>>> >>>> >> >> history
>>> >>>> >> and
>>> >>>> >> >> suggest login. I was going to do it using an xml file (login
>>> >>>> >> attempts.xml).
>>> >>>> >> >> Now it seems database is better.
>>> >>>> >> >> Any way before I go wrong again I will say what I am going to
>>> do.
>>> >>>> >> >> I am going to enforce following conventions.These are not yet
>>> >>>> >> >> needed,
>>> >>>> >> >> considered the small scale.But when the system grows it would
>>> be
>>> >>>> >> >> nice to
>>> >>>> >> >> have them to avoid confusions.
>>> >>>> >> >> *Database prefixes for:*
>>> >>>> >> >> *Platform tables (can begin with appropriate prefix)*
>>> >>>> >> >> AD_ //application dictionary : don't know when it will be
>>> needed ;-)
>>> >>>> >> >> C_ //core functionality
>>> >>>> >> >> *Client Applications.*
>>> >>>> >> >> X<App name prefix>  ex: XBLOG_   for Blog app// All client
>>> add in
>>> >>>> >> modules
>>> >>>> >> >> must begin with table prefix X(for xwiki and ordering) + App
>>> name.
>>> >>>> >>  This is
>>> >>>> >> >> for my blog.
>>> >>>> >> >>
>>> >>>> >> >> I will create
>>> >>>> >> >> C_User for user data.
>>> >>>> >> >> C_LoginAttempt  for saving login attempts.
>>> >>>> >> >>
>>> >>>> >> >> From C_LoginAttempt I can filter uniqe login combinations and
>>> give
>>> >>>> >> >> suggestions in the login UI component. Also save the history.
>>> >>>> >> >>
>>> >>>> >> >> All saved data for blog app will be linked to a perticular
>>> login :
>>> >>>> >> >> User,
>>> >>>> >> >> XWiki server.
>>> >>>> >> >> But only a single user will be most probably using his
>>> personal
>>> >>>> >> >> device.
>>> >>>> >> So
>>> >>>> >> >> above will be relevant only when he has multiple wikis.
>>> >>>> >> >>
>>> >>>> >> >> Best Regards,
>>> >>>> >> >> Sasinda Rukshan.
>>> >>>> >> >>
>>> >>>> >> >>
>>> >>>> >> >>
>>> >>>> >> >>
>>> >>>> >> >>
>>> >>>> >> >> On Sun, May 27, 2012 at 5:43 PM, Chamika Weerasinghe <
>>> >>>> >> [hidden email]>wrote:
>>> >>>> >> >>
>>> >>>> >> >>> On Fri, May 25, 2012 at 1:25 AM, Jerome Velociter <
>>> >>>> >> [hidden email]
>>> >>>> >> >>> >wrote:
>>> >>>> >> >>>
>>> >>>> >> >>> > On Thu, May 24, 2012 at 6:09 PM, Thomas Mortagne
>>> >>>> >> >>> > <[hidden email]> wrote:
>>> >>>> >> >>> > > On Thu, May 24, 2012 at 5:52 PM, sasinda rukshan
>>> >>>> >> >>> > > <[hidden email]> wrote:
>>> >>>> >> >>> > >> Hi all,
>>> >>>> >> >>> > >> I am starting this thread for my XWiki Android Platform
>>> >>>> >> >>> > >> Project.
>>> >>>> >> >>> > >>
>>> >>>> >> >>> > >> Please check whether following are OK.
>>> >>>> >> >>> > >> [1] INFO
>>> >>>> >> >>> > >> I tried to start my new modules with the
>>> >>>> >> >>> de.akquinet.android.archetypes:
>>> >>>> >> >>> > >> android-quickstart:1.0.8.  (added eclipse plugins m2e,
>>> >>>> >> >>> > >> m2e-android[a.k.a  *Android
>>> >>>> >> >>> > >> Configurator* ]). But this seems buggy in eclipse.
>>> >>>> >> >>> > >> Any way the earlier project has not followed the above
>>> >>>> >> >>> > >> archtype
>>> >>>> >> >>> either.
>>> >>>> >> >>> > So
>>> >>>> >> >>> > >> I am going to write pom.xml manually for my each module.
>>> >>>> >> >>> > >>
>>> >>>> >> >>> > >> [2] ADVICE NEEDED
>>> >>>> >> >>> > >> xwiki-rest-model module contains 2 submodules
>>> >>>> >> >>> > >>  |-- xwiki-rest-model-gson  ( gson should be corrected
>>> to
>>> >>>> >> >>> > >> json)
>>> >>>> >> >>> > >
>>> >>>> >> >>> > > No the g is not a mistake, it's a model to be used with
>>> the
>>> >>>> >> >>> > > gson
>>> >>>> >> >>> > > library (http://code.google.com/p/google-gson/). See
>>> >>>> >> >>> > >
>>> >>>> >> >>> >
>>> >>>> >> >>>
>>> >>>> >>
>>> >>>> >>
>>> http://extensions.xwiki.org/xwiki/bin/view/Extension/Google+Android+Client#HXWikiAndroidDevelopmentAPIsandResources
>>> >>>> >> >>> > .
>>> >>>> >> >>> > >
>>> >>>> >> >>> > >>  |-- xwiki-rest-model-simplexml
>>> >>>> >> >>> > >> I think the xwiki-rest-model-gson is redundant. The
>>> classes
>>> >>>> >> >>> > >> in xwiki-rest-model-simplexml is added with simple xml
>>> >>>> >> annotations,
>>> >>>> >> >>> > >> otherwise both modules have same classes. There is no
>>> problem
>>> >>>> >> >>> > >> with
>>> >>>> >> >>> the
>>> >>>> >> >>> > >> added annotations for using the same model objects for
>>> Json
>>> >>>> >> >>> > >> REST
>>> >>>> >> web
>>> >>>> >> >>> > >> services. And I intend to add my JPA (ORMLite library
>>> for
>>> >>>> >> >>> persistence)
>>> >>>> >> >>> > >> annotations on top of it.
>>> >>>> >> >>> > >> Shall I re-factor them to a single module
>>> xwiki-rest-model.
>>> >>>> >> >>> > >
>>> >>>> >> >>> > > No keep them separated, the idea is that both are useful
>>> tool
>>> >>>> >> >>> > > to be
>>> >>>> >> >>> > > used by someone else that might be moved to
>>> xwiki-platform at
>>> >>>> >> >>> > > some
>>> >>>> >> >>> > > point along with the current xwiki-rest-model (to be
>>> renamed to
>>> >>>> >> >>> > > xwiki-rest-model-jaxb).
>>> >>>> >> >>> > >
>>> >>>> >> >>> > > Chamika initially started with gson and since XWiki REST
>>> JSON
>>> >>>> >> >>> > > representation had some limitation he moved to XML
>>> >>>> >> >>> > > representation.
>>> >>>> >> >>> > > Maybe at some point Android will have native support for
>>> jaxb
>>> >>>> >> >>> > > which
>>> >>>> >> >>> > > would obviously be the easier for us (embedding jaxb is
>>> not an
>>> >>>> >> option
>>> >>>> >> >>> > > in mobile world where size it still pretty important
>>> especially
>>> >>>> >> >>> > > on
>>> >>>> >> >>> > > phones). Maybe it's already the case on most recent
>>> versions
>>> >>>> >> >>> > > like
>>> >>>> >> 4.0
>>> >>>> >> >>> > > I don't know.
>>> >>>> >> >>> >
>>> >>>> >> >>> > There's also Jackson that could be tried for JSON
>>> >>>> >> >>> > deserialization, if
>>> >>>> >> >>> > said limitations are actually GSON limitations.
>>> >>>> >> >>> >
>>> >>>> >> >>> GSON wasn't the limitation.
>>> >>>> >> >>> It was XWiki RESTful API which doesn't support JSON in some
>>> cases.
>>> >>>> >> >>> So
>>> >>>> >> it's
>>> >>>> >> >>> safe to go with xml.
>>> >>>> >> >>>
>>> >>>> >> >>> >
>>> >>>> >> >>> > Having full JAXB support sound a bit overweight for such an
>>> >>>> >> >>> > "embedded
>>> >>>> >> >>> > API", even if one day it is natively supported by Android.
>>> What's
>>> >>>> >> >>> > important is to have an easy and fast deserialization, IMO.
>>> >>>> >> >>> > The only advantage I can see of going JAXB would be in
>>> re-using
>>> >>>> >> >>> > the
>>> >>>> >> >>> > exact representations and body readers/writers from XWiki
>>> core.
>>> >>>> >> >>> > But
>>> >>>> >> >>> > you probably don't even want to do that since it would mean
>>> >>>> >> >>> > dragging
>>> >>>> >> >>> > XWiki core with you :)
>>> >>>> >> >>> >
>>> >>>> >> >>> > Jerome
>>> >>>> >> >>> >
>>> >>>> >> >>> > >
>>> >>>> >> >>> > >>
>>> >>>> >> >>> > >> [3] INFO
>>> >>>> >> >>> > >>  I had to change some pom.xml s. As the current project
>>> at:
>>> >>>> >> >>> > >> https://github.com/xwiki-contrib/android-client.gitdoes not
>>> >>>> >> build.
>>> >>>> >> >>> > Error
>>> >>>> >> >>> > >> with parent pom.xml coordinates.
>>> >>>> >> >>> > >
>>> >>>> >> >>> > > You probably did not setup you maven install properly
>>> since
>>> >>>> >> >>> > > what's
>>> >>>> >> on
>>> >>>> >> >>> > > https://github.com/xwiki-contrib/android-client.gitbuild
>>> >>>> >> perfectly
>>> >>>> >> >>> as
>>> >>>> >> >>> > > you can see on
>>> >>>> >> http://ci.xwiki.org/view/All/job/xwiki-android-client/
>>> >>>> >> >>> > > which run a build every time something changes on the git
>>> >>>> >> repository..
>>> >>>> >> >>> > > You should look at
>>> >>>> >> >>> > > http://dev.xwiki.org/xwiki/bin/view/Community/Building.
>>> >>>> >> >>> > >
>>> >>>> >> >>> > >>
>>> >>>> >> >>> > >>
>>> >>>> >> >>> > >> Thank you
>>> >>>> >> >>> > >> Best Regards.
>>> >>>> >> >>> > >> Sasinda Rukshan
>>> >>>> >> >>> > >> _______________________________________________
>>> >>>> >> >>> > >> devs mailing list
>>> >>>> >> >>> > >> [hidden email]
>>> >>>> >> >>> > >> http://lists.xwiki.org/mailman/listinfo/devs
>>> >>>> >> >>> > >
>>> >>>> >> >>> > >
>>> >>>> >> >>> > >
>>> >>>> >> >>> > > --
>>> >>>> >> >>> > > Thomas Mortagne
>>> >>>> >> >>> > > _______________________________________________
>>> >>>> >> >>> > > devs mailing list
>>> >>>> >> >>> > > [hidden email]
>>> >>>> >> >>> > > http://lists.xwiki.org/mailman/listinfo/devs
>>> >>>> >> >>> >
>>> >>>> >> >>> >
>>> >>>> >> >>> >
>>> >>>> >> >>> > --
>>> >>>> >> >>> > Jérôme Velociter
>>> >>>> >> >>> > Winesquare
>>> >>>> >> >>> > http://www.winesquare.net/
>>> >>>> >> >>> > _______________________________________________
>>> >>>> >> >>> > devs mailing list
>>> >>>> >> >>> > [hidden email]
>>> >>>> >> >>> > http://lists.xwiki.org/mailman/listinfo/devs
>>> >>>> >> >>> >
>>> >>>> >> >>> _______________________________________________
>>> >>>> >> >>> devs mailing list
>>> >>>> >> >>> [hidden email]
>>> >>>> >> >>> http://lists.xwiki.org/mailman/listinfo/devs
>>> >>>> >> >>>
>>> >>>> >> >>
>>> >>>> >> >>
>>> >>>> >> > _______________________________________________
>>> >>>> >> > devs mailing list
>>> >>>> >> > [hidden email]
>>> >>>> >> > http://lists.xwiki.org/mailman/listinfo/devs
>>> >>>> >>
>>> >>>> >>
>>> >>>> >>
>>> >>>> >> --
>>> >>>> >> Thomas Mortagne
>>> >>>> >> _______________________________________________
>>> >>>> >> devs mailing list
>>> >>>> >> [hidden email]
>>> >>>> >> http://lists.xwiki.org/mailman/listinfo/devs
>>> >>>> >>
>>> >>>> > _______________________________________________
>>> >>>> > devs mailing list
>>> >>>> > [hidden email]
>>> >>>> > http://lists.xwiki.org/mailman/listinfo/devs
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>> --
>>> >>>> Thomas Mortagne
>>> >>>
>>> >>>
>>> >>
>>> >>
>>> >>
>>> >> --
>>> >> Thomas Mortagne
>>> >
>>> >
>>> >
>>> > --
>>> > Thomas Mortagne
>>>
>>>
>>>
>>> --
>>> Thomas Mortagne
>>>
>>
>>
>
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [GSoc] XDroid Platform

Thomas Mortagne
Administrator
In reply to this post by sasinda
On Sat, Jun 16, 2012 at 7:51 AM, sasinda rukshan
<[hidden email]> wrote:

> Thanks very much for the help on maven build.
>
> *About making a object from Blog.BlogPostClass  and toXML()*
>
> A blog object is having properties of type other xobject classes. So to
> make the things general can we do a stripped down replication or make
> something similer to the java classes in com.xpn.xwiki.objects and its 2
> sub packages .classes, .meta .
>  We can make a document object representing a page and put a
> Blog.BlogPostClass object to its list of objects.We can convert them to
> simple xml model directly.If we want to post blog object we can post the
> Blog object.If the page does not exist we can put the page by getting the
> xml from the Document object.
> Then the things will be general not only for blog client app. Also we can
> have Type checking when we don't directly manipulate simplexml objects.
> i.e. XStringClass will define the attributes for it and likewise.
>
> I don't have a good idea on the above packages and classes. Specially why
> there are three classes for each XType ex: StringProperty, StringClass,
> StringMeta.

* StringClass: define the property at the class level (add some
display setup, etc.)
* StringProperty: the actual property stored in the object
* StringMeta: you could see this as the class of the class. You don't
have to worry about it in your case for now, just stick to simple
class/object organization for now with a known list of properties
types.

> It will be helpful if you can give an explanation.
>
> My draft solution is to do some simple thing as,
> XObject
>  |____ XBoolean
>
> XObject
> |____XString
>
> XString has methods,
> toEmbedXML  gives a <property><attribute/>...</property> string/ simpleXML
> objects
> toXML  gives <object><id><ClassName>.......</object> for the same thing.

I don't understand what toEmbedXML and toXML are doing here.
You are taking it the wrong way IMO, as I said already the format in
which the communication is done with XWiki (XML, JSON, etc.) is an
implementation detail of the low level connector. You are providing a
root Java object you want to send with proper annotations which will
be parsed and converted by simpleXML (or whatever other connector is
used) converted to XML, not the opposite.

As I said, you should NOT try to do a line by line mapping of what you
find in oldcore, the model there is just old and very badly designed.
What you should do is to do an Android version of the general concept.
Looking at the REST api is a way better inspiration since that's what
you are really communicating with, not the oldcore internal model.

It's very important that you don't see simpleXML as the hearth or the
framework, this is just a technical details that the user should not
really have to know about.

>
> Also
> XObject
> |_____ XBlogPost       for(BlogPostClass and other 2 Meta,Property classes)
>
> I don't yet have a clear idea on this. May be I am wrong on this.
> Can you give me your idea here as well. How to approach the problem and
> what should the design be like?
>
> Thanks.
> Best Regards
> Sasinda.
>
>
>
> On Thu, Jun 7, 2012 at 9:28 PM, Thomas Mortagne
> <[hidden email]>wrote:
>
>> As just did a commit with last version of android plugin and some
>> cleanup. Seems to work well.
>>
>> On Thu, Jun 7, 2012 at 12:19 PM, Thomas Mortagne
>> <[hidden email]> wrote:
>> > BTW if you have quick questions it's probaly better to use IRC (I'm
>> > tmortgane on the channel and I'm on GMT+2 tome zone but you can ask
>> > anyone when I'm not around). See
>> > http://dev.xwiki.org/xwiki/bin/view/Community/IRC.
>> >
>> > On Thu, Jun 7, 2012 at 12:17 PM, Thomas Mortagne
>> > <[hidden email]> wrote:
>> >> Not need to send this kind of mail privately to me.
>> >>
>> >> On Thu, Jun 7, 2012 at 5:33 AM, sasinda rukshan
>> >> <[hidden email]> wrote:
>> >>> Thanks,
>> >>> The project is building perfectly well in eclipse (and runs well too)
>> [I
>> >>> configured the build paths for eclipse opening each module as a
>> project and
>> >>> giving project dependencies and etc.]. This is because android facet
>> and
>> >>> maven-android plugin for eclipse [m2e-android] (not the jayway  androi
>> maven
>> >>> plugin)does not work together well.
>> >>> Maven build does not work with newer jayway android maven plugins
>> because of
>> >>> the simplexml library. I checked with another helloworld app that does
>> not
>> >>> have simplexml dependancy and have simplexml dependancy. When we have
>> the
>> >>> dependancy it does not work. Also when packaged with the beta version
>> maven
>> >>> plugin I get runtime error logs notifying that the exact classes
>> informed
>> >>> missed in the compile time for newer maven plugin are missing. But the
>> app
>> >>> is running ok.
>> >>> I will try with it some more and if I can't can you help me with it a
>> >>> little.
>> >>
>> >> Sure If it's just related to simplexml it's probably not much. I will
>> >> try to take a look today. At worst the version we are using right now
>> >> is working fine so you can continue with it anyway.
>> >>
>> >>>
>> >>> I looked at the Enterprise platform apis just to make my apis similar
>> when
>> >>> possible.Source code is not at all relevant to me. But as you say It
>> will be
>> >>> imperfect if I use its style heavily for the mobile version as well.
>> >>
>> >> Yes there is several issues here:
>> >> * most APIs in oldcore module are old and bad and we are trying to get
>> >> rif of them so better not getting too much attached to it ;)
>> >> * they are designed to run in an enironment with lots of resources and
>> >> don't care as much as a mobile API should about memory, etc.
>> >>
>> >>>
>> >>>
>> >>> Thank you.
>> >>> Best Regards.
>> >>> Sasinda.
>> >>>
>> >>>
>> >>> On Wed, Jun 6, 2012 at 1:03 PM, Thomas Mortagne <
>> [hidden email]>
>> >>> wrote:
>> >>>>
>> >>>> On Tue, Jun 5, 2012 at 7:07 PM, sasinda rukshan
>> >>>> <[hidden email]> wrote:
>> >>>> > Hi,
>> >>>> > *1: User Config Saving*
>> >>>> > *
>> >>>> > *
>> >>>> > Xwiki android can now save user login data.
>> >>>> > I refered
>> >>>> > http://platform.xwiki.org/xwiki/bin/view/AdminGuide/AccessWiki.
>> >>>> > Currently assuming the authority
>> >>>> >
>> >>>> > part(platform.xwiki.org<
>> http://platform.xwiki.org/xwiki/bin/view/AdminGuide/AccessWiki>)
>> >>>> > only
>> >>>> > as a unique wiki identifier. But in the
>> org.xwiki.android.entity.User I
>> >>>> > have the method
>> >>>> > setXWikiRealm(String url);:
>> >>>> > Here I have intended the meaning realm as the url root path for a
>> unique
>> >>>> > wiki instance.
>> >>>> > i.e. it should identify a wiki using path upto
>> >>>> > http://host/xwiki/wiki/wikialias/
>> >>>> > But that functionality is not implemented.I just mailed this asking
>> for
>> >>>> > the
>> >>>> > opinion wether the usage of word realm was right here.
>> >>>> > Also do you have seperate users for  wikis for path based wiki
>> access.Or
>> >>>> > are they the same with the main wiki *http://<host>/xwiki*.
>> >>>>
>> >>>> Both actually, you can have global users (which are the one on main
>> >>>> wiki) and local users.
>> >>>>
>> >>>> > *2: Entity model*
>> >>>> > *
>> >>>> > *
>> >>>> > About the convention for using C_ prefix for core entity tables. I
>> >>>> > was referring to make the android versions of these entities
>> >>>> > http://platform.xwiki.org/xwiki/bin/view/DevGuide/DatabaseSchemaand
>> >>>> > start
>> >>>> > there db prefixes with C_
>> >>>> > This is because other apps may need to store some specific tables
>> needed
>> >>>> > for them. Rather than having a seperate DB schema for them we can
>> put
>> >>>> > those
>> >>>> > tables here as well prefixing them with <appname>_ .
>> >>>> > I added more entities like User as well to the core entities(table
>> >>>> > C_User).Also will implement a Log Entity(C_Log table) for logging
>> some
>> >>>> > important application activities(such as login attempts) But the
>> Log may
>> >>>> > be
>> >>>> > a little additional weight to the space and performance.I may
>> implement
>> >>>> > a
>> >>>> > generic DBCleaning service to clean the tables like Log, if I have
>> time.
>> >>>> > (Perhaps this description will resolve the confusion about the DB
>> >>>> > conventions. Sorry I was not very clear in that earlier mail. ;-).)
>> >>>> >
>> >>>> > I am sorry to say I am somewhat confused with all those entities in
>> >>>> > http://platform.xwiki.org/xwiki/bin/view/DevGuide/DatabaseSchema.
>> >>>>
>> >>>> The XWiki model is based on generic classes and objects wich is why
>> >>>> you see lots of tables (class properties, object properties , etc.).
>> >>>> There is no table for users for example, its an object of class
>> >>>> XWiki.XWikiUsers.
>> >>>>
>> >>>> >
>> >>>> > Any way to reduce my confusion
>> >>>> > I refered
>> >>>> > 1)  XWiki Data
>> >>>> > Model<http://platform.xwiki.org/xwiki/bin/view/DevGuide/DataModel>
>> >>>> > :
>> >>>> >   can you give me a link to a documentation that explains the
>> workflow
>> >>>> > of
>> >>>> > how a normal request is converted in to the requested page by the
>> >>>> > bin View action . So I can get a better understanding of how
>> classes ,
>> >>>> > objects are used.
>> >>>>
>> >>>> Not sure there is one. but basically you get either:
>> >>>> * document content executed
>> >>>> * if a class sheet is defined for one of the document objects classes,
>> >>>> the class sheet is executed
>> >>>> * if a document sheet is defined for the documment, the document sheet
>> >>>> is executed
>> >>>>
>> >>>> That's pretty much all, then is a matter of free script and wiki
>> >>>> syntax to actually display the content.
>> >>>>
>> >>>> > 2)  package com.xpn.xwiki.api: I don't need to consider this, do I?
>> >>>>
>> >>>> That's limited scripting API so you should not consider this.
>> >>>>
>> >>>> > 3)
>> >>>> >  Cache<
>> http://extensions.xwiki.org/xwiki/bin/view/Extension/Cache+Module>
>> >>>> >  : Need not implement similar component. Android OS does it nicely
>> for
>> >>>> > the
>> >>>> > REST responses
>> >>>> > but still don't have a clear picture on this.
>> >>>> > To save a blog doc
>> >>>> > option 1)Seems like I have to convert a document entity to relevent
>> >>>> > xwiki-model-simplexml entities and send to server.
>> >>>> > option 2) We also can edit the relevent simplexml model object
>> fields
>> >>>> > directly. (Looks a bad option to me.It does not hide the complexity
>> of
>> >>>> > lower levels for the client layer.Anyway my work load  is reduced
>> with
>> >>>> > opt:2 ;-))
>> >>>>
>> >>>> IMO you should not even look at
>> >>>> http://extensions.xwiki.org/xwiki/bin/view/Extension/Cache+Module and
>> >>>> instead look at how caching is usually done in Android. The idea is
>> >>>> not to port the xwiki-platform to Android IMO but to follow Android
>> >>>> standards to provide a library to manipulate XWiki model.
>> >>>>
>> >>>> You can set the annotation you want to the simplexml model but the
>> >>>> classes/methods should remain an exact copy of what's on
>> >>>> xwiki-platform-rest-model. The idea being that we could decide to
>> >>>> change the implementation from simplexml to anything (JAXB, gson,
>> >>>> etc.) without breaking anything.
>> >>>>
>> >>>> >
>> >>>> >
>> >>>> > *3: Development/architectural approach Change*
>> >>>> > *
>> >>>> > *
>> >>>> > I was first thinking for a addon like architecture for the XWiki
>> android
>> >>>> > app. We have the client.Main app (with all platfrom libs included)
>> and
>> >>>> > Blog
>> >>>> > app as a seperate apk.
>> >>>> > But here Blog app will need to have the platform lib also. That
>> would be
>> >>>> > a
>> >>>> > complete waste of space. But dynamically extending the app is lot
>> >>>> > easier.
>> >>>> > The client.Main app can add the activities defined in other apks in
>> to
>> >>>> > its
>> >>>> > launcher interface using android PackageManager class.
>> >>>> >
>> >>>> >
>> http://stackoverflow.com/questions/9236803/android-build-an-application-that-supports-add-ons
>> >>>> > But with this approach rises additional complexities. For example
>> naming
>> >>>> > conflicts in the Components library module when two apps have the
>> same
>> >>>> > library with same activities defined. Sync issues etc etc....
>> >>>> > So we will go with single .apk approach.
>> >>>> > When going with single .apk we dont need a content provider to share
>> >>>> > config/ preferences data. So sharing module is now not needed. The
>> >>>> > client
>> >>>> > applications now can directly access the Configuration.java class to
>> >>>> > get/put configuration entries.
>> >>>> > Also since I am having a User entity a configuration like
>> >>>> > defaultUser(currently the admin user , hard coded in login.xml
>> layout
>> >>>> > file)
>> >>>> > will only be needed for the first use of the app. Otherwise users
>> need
>> >>>> > not
>> >>>> > configure a default user as the application now suggests the user
>> names
>> >>>> > and
>> >>>> > automatically fill the rest.
>> >>>>
>> >>>> Keep in mind that the main goal of this project is to provide tools
>> >>>> for any application to access an XWiki instance and manipulate its
>> >>>> datas easily an improving those libraries should always be the first
>> >>>> goal. Your blog application is here as a good demo and because it's
>> >>>> hard to design a library without using it.
>> >>>>
>> >>>> I really don't understand why you talk about naming conflict. Of
>> >>>> course a library should never provide a complete final activity but
>> >>>> only interface components (View), fragments or base activities to
>> >>>> extend. Putting those elements in an activity is each application job.
>> >>>> An activity is by definition unique so it has nothing to do in a
>> >>>> library. The complete activities in
>> >>>>
>> >>>>
>> https://github.com/xwiki-contrib/android-client/tree/master/xwiki-android-components/
>> >>>> should have never been there, it's actually a mistake.
>> >>>>
>> >>>> >
>> >>>> > *4: Plan for this week*
>> >>>>
>> >>>> As a priority you should really merge your branch as soon as you have
>> >>>> something building fine. So that it goes through Jenkins and deploy
>> >>>> snapshot build of what you do. Jenkins will tells you in live when
>> >>>> your project does not build anymore or if there is any test failing
>> >>>> and it allows anyone to very easily test the current test of the
>> >>>> client just by installing the apks on
>> >>>> http://maven.xwiki.org/snapshots/org/xwiki/android/. You need to have
>> >>>> something working and in good shape to succeed the GSOC so fixing when
>> >>>> you break something in your build should be your priority over adding
>> >>>> more features.
>> >>>>
>> >>>> Also as I commented in your commit you should be more careful on what
>> >>>> you commit. There is many binaries and Eclipse stuff in your branch.
>> >>>>
>> >>>> > *
>> >>>> > *
>> >>>> > Make a launch pad .We can launch XWiki Navigator, blog etc from
>> this.
>> >>>> > The
>> >>>> > launch pad is shown when we launch XWiki main client.
>> >>>> > Consider adding the WYSIWYG to my blog. It will be useless without
>> the
>> >>>> > ability to convert text formatting to xwiki syntax.So I may just
>> >>>> > integrate
>> >>>> > it and ignore the uselessness for now.
>> >>>>
>> >>>> Not exactly, you could actually reuse WYSIWYG service to send html and
>> >>>> let it convert it to wiki syntax. Note that you are not limited to
>> >>>> what you can find in the current Android library. This is just what
>> >>>> Chamika had the time to do. There is others REST (or not REST) server
>> >>>> interfaces you can use in your client or even add more if its generic
>> >>>> enough and make sense for something else than just Android client.
>> >>>>
>> >>>> > We currently don't have any config to save( Other than default user)
>> >>>> > config. I will add some demo config data and have a developer tools
>> app
>> >>>> > added to the above mentioned XWiki launch pad that can view/edit the
>> >>>> > config
>> >>>> > file.
>> >>>> >
>> >>>> > That will complete milestone 1. But it is not the Sharing
>> >>>> > module(intended
>> >>>> > to share data with other .apks).That is the configuration component
>> does
>> >>>> > not have a ContentProvider to share config data with other apks.
>> Also I
>> >>>> > will define a seperate class to have preferences which will be
>> edited by
>> >>>> > users. Config files are for configuration stuff and will be edited
>> by
>> >>>> > developers. Users have preferences files(natively supported by
>> android)
>> >>>> > to
>> >>>> > change app preferences. For example users will add the default login
>> >>>> > username as a preference.(This will invalidate the use of default
>> User
>> >>>> > entry in the config file which is used until the user edits his
>> >>>> > preferences)
>> >>>>
>> >>>> I'm fine with not sharing datas between applications but it does not
>> >>>> prevent the libraries to  provide tools to manage those datas in a per
>> >>>> application basis.
>> >>>>
>> >>>> >
>> >>>> > Beg your pardon if the mail is too lengthy.;-)
>> >>>>
>> >>>> No problem, never too much information for this ;)
>> >>>>
>> >>>> > Thank you.
>> >>>> > Best Regards.
>> >>>> >
>> >>>> > Sasinda Rukshan.
>> >>>> >
>> >>>> >
>> >>>> > Best Regards.
>> >>>> >
>> >>>> >
>> >>>> > On Wed, May 30, 2012 at 1:11 PM, Thomas Mortagne
>> >>>> > <[hidden email]>wrote:
>> >>>> >
>> >>>> >> On Wed, May 30, 2012 at 4:28 AM, sasinda rukshan
>> >>>> >> <[hidden email]> wrote:
>> >>>> >> > Hi,
>> >>>> >> > I am studying ORM Lite these days.
>> >>>> >> > Please It would be comforting if you can confirm whether it is
>> worth
>> >>>> >> > the
>> >>>> >> > overhead to use ORM Lite.
>> >>>> >> >
>> >>>> >>
>> >>>> >>
>> http://logic-explained.blogspot.com/2011/12/using-ormlite-in-android-projects.html
>> >>>> >> > http://ormlite.com/
>> >>>> >> > ORM Lite features:
>> >>>> >> > Automatically Creates standard DAOs for an annotated entity.
>> >>>> >> > Coding will be lot easier.
>> >>>> >>
>> >>>> >> Remember it's a framework for a mobile platform so it has to remain
>> >>>> >> light and have good performances. I can see that Android version of
>> >>>> >> ormlite is very small but I never used it so I don't know if it's
>> good
>> >>>> >> or not. At least it seems petty active which is a good point so I
>> >>>> >> don't have anything against it.
>> >>>> >>
>> >>>> >> >
>> >>>> >> > Can you suggest how to name the entities.
>> >>>> >> > I am going to go with,
>> >>>> >> > <entity>  org.xwiki.xdroid.data.User  --> <table> C_USER
>> >>>> >>
>> >>>> >> Note that there is already a package name prefix and group id
>> defined
>> >>>> >> for the framework and it's org.xwiki.android as you can see on
>> >>>> >> https://github.com/xwiki-contrib/android-client. Why do you want
>> to
>> >>>> >> change it ? It's more consistent with
>> >>>> >> org.xwiki.commons/org.xwiki.rendering/org.xwiki.platform so I would
>> >>>> >> prefer to keep it that way unless you can give arguments. The goal
>> is
>> >>>> >> not to redo something completely but complete and improve the
>> existing
>> >>>> >> framework.
>> >>>> >>
>> >>>> >> Also as far as I can see there is already several things called
>> >>>> >> "xdroid" on Google play among which an application developer
>> >>>> >> (https://play.google.com/store/apps/developer?id=x-droid) and an
>> >>>> >> application (
>> >>>> >>
>> >>>> >>
>> https://play.google.com/store/apps/details?id=com.gurudigitalsolutions.xdroid
>> >>>> >> ).
>> >>>> >>
>> >>>> >> >
>> >>>> >> > Thanks,
>> >>>> >> > Best Regards
>> >>>> >> >
>> >>>> >> > Sasinda.
>> >>>> >> >
>> >>>> >> >
>> >>>> >> >
>> >>>> >> >
>> >>>> >> >
>> >>>> >> > On Wed, May 30, 2012 at 7:42 AM, sasinda rukshan
>> >>>> >> > <[hidden email]>wrote:
>> >>>> >> >
>> >>>> >> >> Hi,
>> >>>> >> >>
>> >>>> >> >> I am commiting my work to my fork
>> >>>> >> >> https://github.com/sasinda/android-client.
>> >>>> >> >> I ll request to pull it to xwiki-contrib later.
>> >>>> >> >>
>> >>>> >> >> I was running in a wrong path these days. Wanted to save login
>> >>>> >> >> history
>> >>>> >> and
>> >>>> >> >> suggest login. I was going to do it using an xml file (login
>> >>>> >> attempts.xml).
>> >>>> >> >> Now it seems database is better.
>> >>>> >> >> Any way before I go wrong again I will say what I am going to
>> do.
>> >>>> >> >> I am going to enforce following conventions.These are not yet
>> >>>> >> >> needed,
>> >>>> >> >> considered the small scale.But when the system grows it would be
>> >>>> >> >> nice to
>> >>>> >> >> have them to avoid confusions.
>> >>>> >> >> *Database prefixes for:*
>> >>>> >> >> *Platform tables (can begin with appropriate prefix)*
>> >>>> >> >> AD_ //application dictionary : don't know when it will be
>> needed ;-)
>> >>>> >> >> C_ //core functionality
>> >>>> >> >> *Client Applications.*
>> >>>> >> >> X<App name prefix>  ex: XBLOG_   for Blog app// All client add
>> in
>> >>>> >> modules
>> >>>> >> >> must begin with table prefix X(for xwiki and ordering) + App
>> name.
>> >>>> >>  This is
>> >>>> >> >> for my blog.
>> >>>> >> >>
>> >>>> >> >> I will create
>> >>>> >> >> C_User for user data.
>> >>>> >> >> C_LoginAttempt  for saving login attempts.
>> >>>> >> >>
>> >>>> >> >> From C_LoginAttempt I can filter uniqe login combinations and
>> give
>> >>>> >> >> suggestions in the login UI component. Also save the history.
>> >>>> >> >>
>> >>>> >> >> All saved data for blog app will be linked to a perticular
>> login :
>> >>>> >> >> User,
>> >>>> >> >> XWiki server.
>> >>>> >> >> But only a single user will be most probably using his personal
>> >>>> >> >> device.
>> >>>> >> So
>> >>>> >> >> above will be relevant only when he has multiple wikis.
>> >>>> >> >>
>> >>>> >> >> Best Regards,
>> >>>> >> >> Sasinda Rukshan.
>> >>>> >> >>
>> >>>> >> >>
>> >>>> >> >>
>> >>>> >> >>
>> >>>> >> >>
>> >>>> >> >> On Sun, May 27, 2012 at 5:43 PM, Chamika Weerasinghe <
>> >>>> >> [hidden email]>wrote:
>> >>>> >> >>
>> >>>> >> >>> On Fri, May 25, 2012 at 1:25 AM, Jerome Velociter <
>> >>>> >> [hidden email]
>> >>>> >> >>> >wrote:
>> >>>> >> >>>
>> >>>> >> >>> > On Thu, May 24, 2012 at 6:09 PM, Thomas Mortagne
>> >>>> >> >>> > <[hidden email]> wrote:
>> >>>> >> >>> > > On Thu, May 24, 2012 at 5:52 PM, sasinda rukshan
>> >>>> >> >>> > > <[hidden email]> wrote:
>> >>>> >> >>> > >> Hi all,
>> >>>> >> >>> > >> I am starting this thread for my XWiki Android Platform
>> >>>> >> >>> > >> Project.
>> >>>> >> >>> > >>
>> >>>> >> >>> > >> Please check whether following are OK.
>> >>>> >> >>> > >> [1] INFO
>> >>>> >> >>> > >> I tried to start my new modules with the
>> >>>> >> >>> de.akquinet.android.archetypes:
>> >>>> >> >>> > >> android-quickstart:1.0.8.  (added eclipse plugins m2e,
>> >>>> >> >>> > >> m2e-android[a.k.a  *Android
>> >>>> >> >>> > >> Configurator* ]). But this seems buggy in eclipse.
>> >>>> >> >>> > >> Any way the earlier project has not followed the above
>> >>>> >> >>> > >> archtype
>> >>>> >> >>> either.
>> >>>> >> >>> > So
>> >>>> >> >>> > >> I am going to write pom.xml manually for my each module.
>> >>>> >> >>> > >>
>> >>>> >> >>> > >> [2] ADVICE NEEDED
>> >>>> >> >>> > >> xwiki-rest-model module contains 2 submodules
>> >>>> >> >>> > >>  |-- xwiki-rest-model-gson  ( gson should be corrected to
>> >>>> >> >>> > >> json)
>> >>>> >> >>> > >
>> >>>> >> >>> > > No the g is not a mistake, it's a model to be used with the
>> >>>> >> >>> > > gson
>> >>>> >> >>> > > library (http://code.google.com/p/google-gson/). See
>> >>>> >> >>> > >
>> >>>> >> >>> >
>> >>>> >> >>>
>> >>>> >>
>> >>>> >>
>> http://extensions.xwiki.org/xwiki/bin/view/Extension/Google+Android+Client#HXWikiAndroidDevelopmentAPIsandResources
>> >>>> >> >>> > .
>> >>>> >> >>> > >
>> >>>> >> >>> > >>  |-- xwiki-rest-model-simplexml
>> >>>> >> >>> > >> I think the xwiki-rest-model-gson is redundant. The
>> classes
>> >>>> >> >>> > >> in xwiki-rest-model-simplexml is added with simple xml
>> >>>> >> annotations,
>> >>>> >> >>> > >> otherwise both modules have same classes. There is no
>> problem
>> >>>> >> >>> > >> with
>> >>>> >> >>> the
>> >>>> >> >>> > >> added annotations for using the same model objects for
>> Json
>> >>>> >> >>> > >> REST
>> >>>> >> web
>> >>>> >> >>> > >> services. And I intend to add my JPA (ORMLite library for
>> >>>> >> >>> persistence)
>> >>>> >> >>> > >> annotations on top of it.
>> >>>> >> >>> > >> Shall I re-factor them to a single module
>> xwiki-rest-model.
>> >>>> >> >>> > >
>> >>>> >> >>> > > No keep them separated, the idea is that both are useful
>> tool
>> >>>> >> >>> > > to be
>> >>>> >> >>> > > used by someone else that might be moved to xwiki-platform
>> at
>> >>>> >> >>> > > some
>> >>>> >> >>> > > point along with the current xwiki-rest-model (to be
>> renamed to
>> >>>> >> >>> > > xwiki-rest-model-jaxb).
>> >>>> >> >>> > >
>> >>>> >> >>> > > Chamika initially started with gson and since XWiki REST
>> JSON
>> >>>> >> >>> > > representation had some limitation he moved to XML
>> >>>> >> >>> > > representation.
>> >>>> >> >>> > > Maybe at some point Android will have native support for
>> jaxb
>> >>>> >> >>> > > which
>> >>>> >> >>> > > would obviously be the easier for us (embedding jaxb is
>> not an
>> >>>> >> option
>> >>>> >> >>> > > in mobile world where size it still pretty important
>> especially
>> >>>> >> >>> > > on
>> >>>> >> >>> > > phones). Maybe it's already the case on most recent
>> versions
>> >>>> >> >>> > > like
>> >>>> >> 4.0
>> >>>> >> >>> > > I don't know.
>> >>>> >> >>> >
>> >>>> >> >>> > There's also Jackson that could be tried for JSON
>> >>>> >> >>> > deserialization, if
>> >>>> >> >>> > said limitations are actually GSON limitations.
>> >>>> >> >>> >
>> >>>> >> >>> GSON wasn't the limitation.
>> >>>> >> >>> It was XWiki RESTful API which doesn't support JSON in some
>> cases.
>> >>>> >> >>> So
>> >>>> >> it's
>> >>>> >> >>> safe to go with xml.
>> >>>> >> >>>
>> >>>> >> >>> >
>> >>>> >> >>> > Having full JAXB support sound a bit overweight for such an
>> >>>> >> >>> > "embedded
>> >>>> >> >>> > API", even if one day it is natively supported by Android.
>> What's
>> >>>> >> >>> > important is to have an easy and fast deserialization, IMO.
>> >>>> >> >>> > The only advantage I can see of going JAXB would be in
>> re-using
>> >>>> >> >>> > the
>> >>>> >> >>> > exact representations and body readers/writers from XWiki
>> core.
>> >>>> >> >>> > But
>> >>>> >> >>> > you probably don't even want to do that since it would mean
>> >>>> >> >>> > dragging
>> >>>> >> >>> > XWiki core with you :)
>> >>>> >> >>> >
>> >>>> >> >>> > Jerome
>> >>>> >> >>> >
>> >>>> >> >>> > >
>> >>>> >> >>> > >>
>> >>>> >> >>> > >> [3] INFO
>> >>>> >> >>> > >>  I had to change some pom.xml s. As the current project
>> at:
>> >>>> >> >>> > >> https://github.com/xwiki-contrib/android-client.git does
>> not
>> >>>> >> build.
>> >>>> >> >>> > Error
>> >>>> >> >>> > >> with parent pom.xml coordinates.
>> >>>> >> >>> > >
>> >>>> >> >>> > > You probably did not setup you maven install properly since
>> >>>> >> >>> > > what's
>> >>>> >> on
>> >>>> >> >>> > > https://github.com/xwiki-contrib/android-client.git build
>> >>>> >> perfectly
>> >>>> >> >>> as
>> >>>> >> >>> > > you can see on
>> >>>> >> http://ci.xwiki.org/view/All/job/xwiki-android-client/
>> >>>> >> >>> > > which run a build every time something changes on the git
>> >>>> >> repository..
>> >>>> >> >>> > > You should look at
>> >>>> >> >>> > > http://dev.xwiki.org/xwiki/bin/view/Community/Building.
>> >>>> >> >>> > >
>> >>>> >> >>> > >>
>> >>>> >> >>> > >>
>> >>>> >> >>> > >> Thank you
>> >>>> >> >>> > >> Best Regards.
>> >>>> >> >>> > >> Sasinda Rukshan
>> >>>> >> >>> > >> _______________________________________________
>> >>>> >> >>> > >> devs mailing list
>> >>>> >> >>> > >> [hidden email]
>> >>>> >> >>> > >> http://lists.xwiki.org/mailman/listinfo/devs
>> >>>> >> >>> > >
>> >>>> >> >>> > >
>> >>>> >> >>> > >
>> >>>> >> >>> > > --
>> >>>> >> >>> > > Thomas Mortagne
>> >>>> >> >>> > > _______________________________________________
>> >>>> >> >>> > > devs mailing list
>> >>>> >> >>> > > [hidden email]
>> >>>> >> >>> > > http://lists.xwiki.org/mailman/listinfo/devs
>> >>>> >> >>> >
>> >>>> >> >>> >
>> >>>> >> >>> >
>> >>>> >> >>> > --
>> >>>> >> >>> > Jérôme Velociter
>> >>>> >> >>> > Winesquare
>> >>>> >> >>> > http://www.winesquare.net/
>> >>>> >> >>> > _______________________________________________
>> >>>> >> >>> > devs mailing list
>> >>>> >> >>> > [hidden email]
>> >>>> >> >>> > http://lists.xwiki.org/mailman/listinfo/devs
>> >>>> >> >>> >
>> >>>> >> >>> _______________________________________________
>> >>>> >> >>> devs mailing list
>> >>>> >> >>> [hidden email]
>> >>>> >> >>> http://lists.xwiki.org/mailman/listinfo/devs
>> >>>> >> >>>
>> >>>> >> >>
>> >>>> >> >>
>> >>>> >> > _______________________________________________
>> >>>> >> > devs mailing list
>> >>>> >> > [hidden email]
>> >>>> >> > http://lists.xwiki.org/mailman/listinfo/devs
>> >>>> >>
>> >>>> >>
>> >>>> >>
>> >>>> >> --
>> >>>> >> Thomas Mortagne
>> >>>> >> _______________________________________________
>> >>>> >> devs mailing list
>> >>>> >> [hidden email]
>> >>>> >> http://lists.xwiki.org/mailman/listinfo/devs
>> >>>> >>
>> >>>> > _______________________________________________
>> >>>> > devs mailing list
>> >>>> > [hidden email]
>> >>>> > http://lists.xwiki.org/mailman/listinfo/devs
>> >>>>
>> >>>>
>> >>>>
>> >>>> --
>> >>>> Thomas Mortagne
>> >>>
>> >>>
>> >>
>> >>
>> >>
>> >> --
>> >> Thomas Mortagne
>> >
>> >
>> >
>> > --
>> > Thomas Mortagne
>>
>>
>>
>> --
>> Thomas Mortagne
>>
> _______________________________________________
> devs mailing list
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs



--
Thomas Mortagne
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [GSoc] XDroid Platform

Thomas Mortagne
Administrator
In reply to this post by sasinda
On Sat, Jun 16, 2012 at 7:01 PM, sasinda rukshan
<[hidden email]> wrote:

> Hi,
> I checked the source code.(still it would be helpful if u cn explain)
> I have  a little issue.
> Say with the current model
> Blog.BlogPostClass
>  properties|__DBTreeList  category  {has a list of attributes}
>                  |__TextAreaClass content   {has a list of attributes}
>            |__ MYType  myComplexTypeProp {has a list of attributes  which
> are all simple properties such as StringProperty etc}  [ for ex:TagClass
> tagprop ]
>                                   |__ StringClass mystring   {also have a
> list of attributes.
>
> The XML schema
>
> <complexType name="Object">
>   <complexContent>
>     <extension base="{http://www.xwiki.org}ObjectSummary">
>       <sequence>
>         <element name="property"
> type="{http://www.xwiki.org}Property" maxOccurs="unbounded"
> minOccurs="0"/>
>       </sequence>
>     </extension>
>   </complexContent>
>  </complexType>
>
> <complexType name="Property">
>   <complexContent>
>     <extension base="{http://www.xwiki.org}LinkCollection">
>       <sequence>
>         <element name="attribute"
> type="{http://www.xwiki.org}Attribute" maxOccurs="unbounded"
> minOccurs="0"/>
>         <element name="value" type="{http://www.w3.org/2001/XMLSchema}string"/>
>       </sequence>
>       <attribute name="name" use="required"
> type="{http://www.w3.org/2001/XMLSchema}string" />
>       <attribute name="type" type="{http://www.w3.org/2001/XMLSchema}string" />
>     </extension>
>   </complexContent>
>  </complexType>
>
>  <complexType name="Attribute">
>   <complexContent>
>     <extension base="{http://www.xwiki.org}LinkCollection">
>       <attribute name="name" use="required"
> type="{http://www.w3.org/2001/XMLSchema}string" />
>       <attribute name="value"
> type="{http://www.w3.org/2001/XMLSchema}string" />
>     </extension>
>   </complexContent>
>  </complexType>
>
> does not seem to be addressing such an occasion where multiple levels of
> nesting is happening. (May be I'm horribly wrong here)
>
> Am I correct to think that any type of Object like BlogPostClass obj
> will only have properties of simple types such as StringClass,
> TextAreaClass and etc. It will not have a complex type for example
> XWiki.TagClass in it.(I know it never happens in BlogPostClass, but
> don't know if someone needs to do a weird class). ?

Yes, right now the XWiki model does not allow to put an object in
another object.

>
> My findings and comprehension on the model:
>
> I guess StringClass, TextAreaClass etc, carry most of those many
> attributes for rendering purpose. I saw StaticListClass has attribute
> (separators) for defining the list value delimeters as well.
>
> Can you please post me a diagram taking a single class like DateClass. How
> the aggregations and inheritance is done.
> Ill send my design. I intend to do all that with just single definition for
> each XWiki data type classes.For ex: XString extends XObject.XObject
> contains the collection of fields.These can be converted to <attribute>
> elements. A Document Object will contain a BlogPost (represent
> BlobPostClass) object which contains XObject s as properties. (ideally if
> multiple levels of nesting is supported BlogPost should also be a XObject).
> The Document Object is an entity.(refer
> https://docs.google.com/drawings/d/1hwfQMVgCvYKS6iHU060drcET3Aq3Vles2DQlJOOt3n8/edit<https://docs.google.com/drawings/d/1hwfQMVgCvYKS6iHU060drcET3Aq3Vles2DQlJOOt3n8/edit?pli=1>
>  )
> When we persist a document object it should serialize the BLogPost class
> into its xml representation and save it on the filesystem. SQLite DB will
> have a row with the URI for that file. So I am not going to persist
> rest-model objects ( neither annotate them for persistence). Storing such
> bulk objects may degrade DB performance. In the android dev guides it is
> said a curser to a table should not exceed 2 MB of data otherwise the
> performance will be low due to paging.
> This makes the persistence a little complex. I will manage it. PLS tell if
> my approach is wrong.
>
> By the way I will merge my work to the master branch next week. Is it ok to
> duplicate your maven work to a mvn branch and undo the commit in master and
> merge my work with a fast forward merge, so that it will show  a linear
> history.

It's all yours, you can manage the branches the way you want as long
as the master is as up to date as possible.

>
> Thanks
> Best Regards.
> Sasinda Rukshan.
>
>
>
>
>
>
>
> On Sat, Jun 16, 2012 at 11:21 AM, sasinda rukshan
> <[hidden email]>wrote:
>
>> Thanks very much for the help on maven build.
>>
>> *About making a object from Blog.BlogPostClass  and toXML()*
>>
>> A blog object is having properties of type other xobject classes. So to
>> make the things general can we do a stripped down replication or make
>> something similer to the java classes in com.xpn.xwiki.objects and its 2
>> sub packages .classes, .meta .
>>  We can make a document object representing a page and put a
>> Blog.BlogPostClass object to its list of objects.We can convert them to
>> simple xml model directly.If we want to post blog object we can post the
>> Blog object.If the page does not exist we can put the page by getting the
>> xml from the Document object.
>> Then the things will be general not only for blog client app. Also we can
>> have Type checking when we don't directly manipulate simplexml objects.
>> i.e. XStringClass will define the attributes for it and likewise.
>>
>> I don't have a good idea on the above packages and classes. Specially why
>> there are three classes for each XType ex: StringProperty, StringClass,
>> StringMeta.
>> It will be helpful if you can give an explanation.
>>
>> My draft solution is to do some simple thing as,
>> XObject
>>  |____ XBoolean
>>
>> XObject
>> |____XString
>>
>> XString has methods,
>> toEmbedXML  gives a <property><attribute/>...</property> string/ simpleXML
>> objects
>> toXML  gives <object><id><ClassName>.......</object> for the same thing.
>>
>> Also
>> XObject
>> |_____ XBlogPost       for(BlogPostClass and other 2 Meta,Property classes)
>>
>> I don't yet have a clear idea on this. May be I am wrong on this.
>> Can you give me your idea here as well. How to approach the problem and
>> what should the design be like?
>>
>> Thanks.
>> Best Regards
>> Sasinda.
>>
>>
>>
>> On Thu, Jun 7, 2012 at 9:28 PM, Thomas Mortagne <[hidden email]
>> > wrote:
>>
>>> As just did a commit with last version of android plugin and some
>>> cleanup. Seems to work well.
>>>
>>> On Thu, Jun 7, 2012 at 12:19 PM, Thomas Mortagne
>>> <[hidden email]> wrote:
>>> > BTW if you have quick questions it's probaly better to use IRC (I'm
>>> > tmortgane on the channel and I'm on GMT+2 tome zone but you can ask
>>> > anyone when I'm not around). See
>>> > http://dev.xwiki.org/xwiki/bin/view/Community/IRC.
>>> >
>>> > On Thu, Jun 7, 2012 at 12:17 PM, Thomas Mortagne
>>> > <[hidden email]> wrote:
>>> >> Not need to send this kind of mail privately to me.
>>> >>
>>> >> On Thu, Jun 7, 2012 at 5:33 AM, sasinda rukshan
>>> >> <[hidden email]> wrote:
>>> >>> Thanks,
>>> >>> The project is building perfectly well in eclipse (and runs well too)
>>> [I
>>> >>> configured the build paths for eclipse opening each module as a
>>> project and
>>> >>> giving project dependencies and etc.]. This is because android facet
>>> and
>>> >>> maven-android plugin for eclipse [m2e-android] (not the jayway
>>>  androi maven
>>> >>> plugin)does not work together well.
>>> >>> Maven build does not work with newer jayway android maven plugins
>>> because of
>>> >>> the simplexml library. I checked with another helloworld app that
>>> does not
>>> >>> have simplexml dependancy and have simplexml dependancy. When we have
>>> the
>>> >>> dependancy it does not work. Also when packaged with the beta version
>>> maven
>>> >>> plugin I get runtime error logs notifying that the exact classes
>>> informed
>>> >>> missed in the compile time for newer maven plugin are missing. But
>>> the app
>>> >>> is running ok.
>>> >>> I will try with it some more and if I can't can you help me with it a
>>> >>> little.
>>> >>
>>> >> Sure If it's just related to simplexml it's probably not much. I will
>>> >> try to take a look today. At worst the version we are using right now
>>> >> is working fine so you can continue with it anyway.
>>> >>
>>> >>>
>>> >>> I looked at the Enterprise platform apis just to make my apis similar
>>> when
>>> >>> possible.Source code is not at all relevant to me. But as you say It
>>> will be
>>> >>> imperfect if I use its style heavily for the mobile version as well.
>>> >>
>>> >> Yes there is several issues here:
>>> >> * most APIs in oldcore module are old and bad and we are trying to get
>>> >> rif of them so better not getting too much attached to it ;)
>>> >> * they are designed to run in an enironment with lots of resources and
>>> >> don't care as much as a mobile API should about memory, etc.
>>> >>
>>> >>>
>>> >>>
>>> >>> Thank you.
>>> >>> Best Regards.
>>> >>> Sasinda.
>>> >>>
>>> >>>
>>> >>> On Wed, Jun 6, 2012 at 1:03 PM, Thomas Mortagne <
>>> [hidden email]>
>>> >>> wrote:
>>> >>>>
>>> >>>> On Tue, Jun 5, 2012 at 7:07 PM, sasinda rukshan
>>> >>>> <[hidden email]> wrote:
>>> >>>> > Hi,
>>> >>>> > *1: User Config Saving*
>>> >>>> > *
>>> >>>> > *
>>> >>>> > Xwiki android can now save user login data.
>>> >>>> > I refered
>>> >>>> > http://platform.xwiki.org/xwiki/bin/view/AdminGuide/AccessWiki.
>>> >>>> > Currently assuming the authority
>>> >>>> >
>>> >>>> > part(platform.xwiki.org<
>>> http://platform.xwiki.org/xwiki/bin/view/AdminGuide/AccessWiki>)
>>> >>>> > only
>>> >>>> > as a unique wiki identifier. But in the
>>> org.xwiki.android.entity.User I
>>> >>>> > have the method
>>> >>>> > setXWikiRealm(String url);:
>>> >>>> > Here I have intended the meaning realm as the url root path for a
>>> unique
>>> >>>> > wiki instance.
>>> >>>> > i.e. it should identify a wiki using path upto
>>> >>>> > http://host/xwiki/wiki/wikialias/
>>> >>>> > But that functionality is not implemented.I just mailed this
>>> asking for
>>> >>>> > the
>>> >>>> > opinion wether the usage of word realm was right here.
>>> >>>> > Also do you have seperate users for  wikis for path based wiki
>>> access.Or
>>> >>>> > are they the same with the main wiki *http://<host>/xwiki*.
>>> >>>>
>>> >>>> Both actually, you can have global users (which are the one on main
>>> >>>> wiki) and local users.
>>> >>>>
>>> >>>> > *2: Entity model*
>>> >>>> > *
>>> >>>> > *
>>> >>>> > About the convention for using C_ prefix for core entity tables. I
>>> >>>> > was referring to make the android versions of these entities
>>> >>>> > http://platform.xwiki.org/xwiki/bin/view/DevGuide/DatabaseSchemaand
>>> >>>> > start
>>> >>>> > there db prefixes with C_
>>> >>>> > This is because other apps may need to store some specific tables
>>> needed
>>> >>>> > for them. Rather than having a seperate DB schema for them we can
>>> put
>>> >>>> > those
>>> >>>> > tables here as well prefixing them with <appname>_ .
>>> >>>> > I added more entities like User as well to the core entities(table
>>> >>>> > C_User).Also will implement a Log Entity(C_Log table) for logging
>>> some
>>> >>>> > important application activities(such as login attempts) But the
>>> Log may
>>> >>>> > be
>>> >>>> > a little additional weight to the space and performance.I may
>>> implement
>>> >>>> > a
>>> >>>> > generic DBCleaning service to clean the tables like Log, if I have
>>> time.
>>> >>>> > (Perhaps this description will resolve the confusion about the DB
>>> >>>> > conventions. Sorry I was not very clear in that earlier mail. ;-).)
>>> >>>> >
>>> >>>> > I am sorry to say I am somewhat confused with all those entities in
>>> >>>> > http://platform.xwiki.org/xwiki/bin/view/DevGuide/DatabaseSchema.
>>> >>>>
>>> >>>> The XWiki model is based on generic classes and objects wich is why
>>> >>>> you see lots of tables (class properties, object properties , etc.).
>>> >>>> There is no table for users for example, its an object of class
>>> >>>> XWiki.XWikiUsers.
>>> >>>>
>>> >>>> >
>>> >>>> > Any way to reduce my confusion
>>> >>>> > I refered
>>> >>>> > 1)  XWiki Data
>>> >>>> > Model<http://platform.xwiki.org/xwiki/bin/view/DevGuide/DataModel>
>>> >>>> > :
>>> >>>> >   can you give me a link to a documentation that explains the
>>> workflow
>>> >>>> > of
>>> >>>> > how a normal request is converted in to the requested page by the
>>> >>>> > bin View action . So I can get a better understanding of how
>>> classes ,
>>> >>>> > objects are used.
>>> >>>>
>>> >>>> Not sure there is one. but basically you get either:
>>> >>>> * document content executed
>>> >>>> * if a class sheet is defined for one of the document objects
>>> classes,
>>> >>>> the class sheet is executed
>>> >>>> * if a document sheet is defined for the documment, the document
>>> sheet
>>> >>>> is executed
>>> >>>>
>>> >>>> That's pretty much all, then is a matter of free script and wiki
>>> >>>> syntax to actually display the content.
>>> >>>>
>>> >>>> > 2)  package com.xpn.xwiki.api: I don't need to consider this, do I?
>>> >>>>
>>> >>>> That's limited scripting API so you should not consider this.
>>> >>>>
>>> >>>> > 3)
>>> >>>> >  Cache<
>>> http://extensions.xwiki.org/xwiki/bin/view/Extension/Cache+Module>
>>> >>>> >  : Need not implement similar component. Android OS does it nicely
>>> for
>>> >>>> > the
>>> >>>> > REST responses
>>> >>>> > but still don't have a clear picture on this.
>>> >>>> > To save a blog doc
>>> >>>> > option 1)Seems like I have to convert a document entity to relevent
>>> >>>> > xwiki-model-simplexml entities and send to server.
>>> >>>> > option 2) We also can edit the relevent simplexml model object
>>> fields
>>> >>>> > directly. (Looks a bad option to me.It does not hide the
>>> complexity of
>>> >>>> > lower levels for the client layer.Anyway my work load  is reduced
>>> with
>>> >>>> > opt:2 ;-))
>>> >>>>
>>> >>>> IMO you should not even look at
>>> >>>> http://extensions.xwiki.org/xwiki/bin/view/Extension/Cache+Moduleand
>>> >>>> instead look at how caching is usually done in Android. The idea is
>>> >>>> not to port the xwiki-platform to Android IMO but to follow Android
>>> >>>> standards to provide a library to manipulate XWiki model.
>>> >>>>
>>> >>>> You can set the annotation you want to the simplexml model but the
>>> >>>> classes/methods should remain an exact copy of what's on
>>> >>>> xwiki-platform-rest-model. The idea being that we could decide to
>>> >>>> change the implementation from simplexml to anything (JAXB, gson,
>>> >>>> etc.) without breaking anything.
>>> >>>>
>>> >>>> >
>>> >>>> >
>>> >>>> > *3: Development/architectural approach Change*
>>> >>>> > *
>>> >>>> > *
>>> >>>> > I was first thinking for a addon like architecture for the XWiki
>>> android
>>> >>>> > app. We have the client.Main app (with all platfrom libs included)
>>> and
>>> >>>> > Blog
>>> >>>> > app as a seperate apk.
>>> >>>> > But here Blog app will need to have the platform lib also. That
>>> would be
>>> >>>> > a
>>> >>>> > complete waste of space. But dynamically extending the app is lot
>>> >>>> > easier.
>>> >>>> > The client.Main app can add the activities defined in other apks
>>> in to
>>> >>>> > its
>>> >>>> > launcher interface using android PackageManager class.
>>> >>>> >
>>> >>>> >
>>> http://stackoverflow.com/questions/9236803/android-build-an-application-that-supports-add-ons
>>> >>>> > But with this approach rises additional complexities. For example
>>> naming
>>> >>>> > conflicts in the Components library module when two apps have the
>>> same
>>> >>>> > library with same activities defined. Sync issues etc etc....
>>> >>>> > So we will go with single .apk approach.
>>> >>>> > When going with single .apk we dont need a content provider to
>>> share
>>> >>>> > config/ preferences data. So sharing module is now not needed. The
>>> >>>> > client
>>> >>>> > applications now can directly access the Configuration.java class
>>> to
>>> >>>> > get/put configuration entries.
>>> >>>> > Also since I am having a User entity a configuration like
>>> >>>> > defaultUser(currently the admin user , hard coded in login.xml
>>> layout
>>> >>>> > file)
>>> >>>> > will only be needed for the first use of the app. Otherwise users
>>> need
>>> >>>> > not
>>> >>>> > configure a default user as the application now suggests the user
>>> names
>>> >>>> > and
>>> >>>> > automatically fill the rest.
>>> >>>>
>>> >>>> Keep in mind that the main goal of this project is to provide tools
>>> >>>> for any application to access an XWiki instance and manipulate its
>>> >>>> datas easily an improving those libraries should always be the first
>>> >>>> goal. Your blog application is here as a good demo and because it's
>>> >>>> hard to design a library without using it.
>>> >>>>
>>> >>>> I really don't understand why you talk about naming conflict. Of
>>> >>>> course a library should never provide a complete final activity but
>>> >>>> only interface components (View), fragments or base activities to
>>> >>>> extend. Putting those elements in an activity is each application
>>> job.
>>> >>>> An activity is by definition unique so it has nothing to do in a
>>> >>>> library. The complete activities in
>>> >>>>
>>> >>>>
>>> https://github.com/xwiki-contrib/android-client/tree/master/xwiki-android-components/
>>> >>>> should have never been there, it's actually a mistake.
>>> >>>>
>>> >>>> >
>>> >>>> > *4: Plan for this week*
>>> >>>>
>>> >>>> As a priority you should really merge your branch as soon as you have
>>> >>>> something building fine. So that it goes through Jenkins and deploy
>>> >>>> snapshot build of what you do. Jenkins will tells you in live when
>>> >>>> your project does not build anymore or if there is any test failing
>>> >>>> and it allows anyone to very easily test the current test of the
>>> >>>> client just by installing the apks on
>>> >>>> http://maven.xwiki.org/snapshots/org/xwiki/android/. You need to
>>> have
>>> >>>> something working and in good shape to succeed the GSOC so fixing
>>> when
>>> >>>> you break something in your build should be your priority over adding
>>> >>>> more features.
>>> >>>>
>>> >>>> Also as I commented in your commit you should be more careful on what
>>> >>>> you commit. There is many binaries and Eclipse stuff in your branch.
>>> >>>>
>>> >>>> > *
>>> >>>> > *
>>> >>>> > Make a launch pad .We can launch XWiki Navigator, blog etc from
>>> this.
>>> >>>> > The
>>> >>>> > launch pad is shown when we launch XWiki main client.
>>> >>>> > Consider adding the WYSIWYG to my blog. It will be useless without
>>> the
>>> >>>> > ability to convert text formatting to xwiki syntax.So I may just
>>> >>>> > integrate
>>> >>>> > it and ignore the uselessness for now.
>>> >>>>
>>> >>>> Not exactly, you could actually reuse WYSIWYG service to send html
>>> and
>>> >>>> let it convert it to wiki syntax. Note that you are not limited to
>>> >>>> what you can find in the current Android library. This is just what
>>> >>>> Chamika had the time to do. There is others REST (or not REST) server
>>> >>>> interfaces you can use in your client or even add more if its generic
>>> >>>> enough and make sense for something else than just Android client.
>>> >>>>
>>> >>>> > We currently don't have any config to save( Other than default
>>> user)
>>> >>>> > config. I will add some demo config data and have a developer
>>> tools app
>>> >>>> > added to the above mentioned XWiki launch pad that can view/edit
>>> the
>>> >>>> > config
>>> >>>> > file.
>>> >>>> >
>>> >>>> > That will complete milestone 1. But it is not the Sharing
>>> >>>> > module(intended
>>> >>>> > to share data with other .apks).That is the configuration
>>> component does
>>> >>>> > not have a ContentProvider to share config data with other apks.
>>> Also I
>>> >>>> > will define a seperate class to have preferences which will be
>>> edited by
>>> >>>> > users. Config files are for configuration stuff and will be edited
>>> by
>>> >>>> > developers. Users have preferences files(natively supported by
>>> android)
>>> >>>> > to
>>> >>>> > change app preferences. For example users will add the default
>>> login
>>> >>>> > username as a preference.(This will invalidate the use of default
>>> User
>>> >>>> > entry in the config file which is used until the user edits his
>>> >>>> > preferences)
>>> >>>>
>>> >>>> I'm fine with not sharing datas between applications but it does not
>>> >>>> prevent the libraries to  provide tools to manage those datas in a
>>> per
>>> >>>> application basis.
>>> >>>>
>>> >>>> >
>>> >>>> > Beg your pardon if the mail is too lengthy.;-)
>>> >>>>
>>> >>>> No problem, never too much information for this ;)
>>> >>>>
>>> >>>> > Thank you.
>>> >>>> > Best Regards.
>>> >>>> >
>>> >>>> > Sasinda Rukshan.
>>> >>>> >
>>> >>>> >
>>> >>>> > Best Regards.
>>> >>>> >
>>> >>>> >
>>> >>>> > On Wed, May 30, 2012 at 1:11 PM, Thomas Mortagne
>>> >>>> > <[hidden email]>wrote:
>>> >>>> >
>>> >>>> >> On Wed, May 30, 2012 at 4:28 AM, sasinda rukshan
>>> >>>> >> <[hidden email]> wrote:
>>> >>>> >> > Hi,
>>> >>>> >> > I am studying ORM Lite these days.
>>> >>>> >> > Please It would be comforting if you can confirm whether it is
>>> worth
>>> >>>> >> > the
>>> >>>> >> > overhead to use ORM Lite.
>>> >>>> >> >
>>> >>>> >>
>>> >>>> >>
>>> http://logic-explained.blogspot.com/2011/12/using-ormlite-in-android-projects.html
>>> >>>> >> > http://ormlite.com/
>>> >>>> >> > ORM Lite features:
>>> >>>> >> > Automatically Creates standard DAOs for an annotated entity.
>>> >>>> >> > Coding will be lot easier.
>>> >>>> >>
>>> >>>> >> Remember it's a framework for a mobile platform so it has to
>>> remain
>>> >>>> >> light and have good performances. I can see that Android version
>>> of
>>> >>>> >> ormlite is very small but I never used it so I don't know if it's
>>> good
>>> >>>> >> or not. At least it seems petty active which is a good point so I
>>> >>>> >> don't have anything against it.
>>> >>>> >>
>>> >>>> >> >
>>> >>>> >> > Can you suggest how to name the entities.
>>> >>>> >> > I am going to go with,
>>> >>>> >> > <entity>  org.xwiki.xdroid.data.User  --> <table> C_USER
>>> >>>> >>
>>> >>>> >> Note that there is already a package name prefix and group id
>>> defined
>>> >>>> >> for the framework and it's org.xwiki.android as you can see on
>>> >>>> >> https://github.com/xwiki-contrib/android-client. Why do you want
>>> to
>>> >>>> >> change it ? It's more consistent with
>>> >>>> >> org.xwiki.commons/org.xwiki.rendering/org.xwiki.platform so I
>>> would
>>> >>>> >> prefer to keep it that way unless you can give arguments. The
>>> goal is
>>> >>>> >> not to redo something completely but complete and improve the
>>> existing
>>> >>>> >> framework.
>>> >>>> >>
>>> >>>> >> Also as far as I can see there is already several things called
>>> >>>> >> "xdroid" on Google play among which an application developer
>>> >>>> >> (https://play.google.com/store/apps/developer?id=x-droid) and an
>>> >>>> >> application (
>>> >>>> >>
>>> >>>> >>
>>> https://play.google.com/store/apps/details?id=com.gurudigitalsolutions.xdroid
>>> >>>> >> ).
>>> >>>> >>
>>> >>>> >> >
>>> >>>> >> > Thanks,
>>> >>>> >> > Best Regards
>>> >>>> >> >
>>> >>>> >> > Sasinda.
>>> >>>> >> >
>>> >>>> >> >
>>> >>>> >> >
>>> >>>> >> >
>>> >>>> >> >
>>> >>>> >> > On Wed, May 30, 2012 at 7:42 AM, sasinda rukshan
>>> >>>> >> > <[hidden email]>wrote:
>>> >>>> >> >
>>> >>>> >> >> Hi,
>>> >>>> >> >>
>>> >>>> >> >> I am commiting my work to my fork
>>> >>>> >> >> https://github.com/sasinda/android-client.
>>> >>>> >> >> I ll request to pull it to xwiki-contrib later.
>>> >>>> >> >>
>>> >>>> >> >> I was running in a wrong path these days. Wanted to save login
>>> >>>> >> >> history
>>> >>>> >> and
>>> >>>> >> >> suggest login. I was going to do it using an xml file (login
>>> >>>> >> attempts.xml).
>>> >>>> >> >> Now it seems database is better.
>>> >>>> >> >> Any way before I go wrong again I will say what I am going to
>>> do.
>>> >>>> >> >> I am going to enforce following conventions.These are not yet
>>> >>>> >> >> needed,
>>> >>>> >> >> considered the small scale.But when the system grows it would
>>> be
>>> >>>> >> >> nice to
>>> >>>> >> >> have them to avoid confusions.
>>> >>>> >> >> *Database prefixes for:*
>>> >>>> >> >> *Platform tables (can begin with appropriate prefix)*
>>> >>>> >> >> AD_ //application dictionary : don't know when it will be
>>> needed ;-)
>>> >>>> >> >> C_ //core functionality
>>> >>>> >> >> *Client Applications.*
>>> >>>> >> >> X<App name prefix>  ex: XBLOG_   for Blog app// All client add
>>> in
>>> >>>> >> modules
>>> >>>> >> >> must begin with table prefix X(for xwiki and ordering) + App
>>> name.
>>> >>>> >>  This is
>>> >>>> >> >> for my blog.
>>> >>>> >> >>
>>> >>>> >> >> I will create
>>> >>>> >> >> C_User for user data.
>>> >>>> >> >> C_LoginAttempt  for saving login attempts.
>>> >>>> >> >>
>>> >>>> >> >> From C_LoginAttempt I can filter uniqe login combinations and
>>> give
>>> >>>> >> >> suggestions in the login UI component. Also save the history.
>>> >>>> >> >>
>>> >>>> >> >> All saved data for blog app will be linked to a perticular
>>> login :
>>> >>>> >> >> User,
>>> >>>> >> >> XWiki server.
>>> >>>> >> >> But only a single user will be most probably using his personal
>>> >>>> >> >> device.
>>> >>>> >> So
>>> >>>> >> >> above will be relevant only when he has multiple wikis.
>>> >>>> >> >>
>>> >>>> >> >> Best Regards,
>>> >>>> >> >> Sasinda Rukshan.
>>> >>>> >> >>
>>> >>>> >> >>
>>> >>>> >> >>
>>> >>>> >> >>
>>> >>>> >> >>
>>> >>>> >> >> On Sun, May 27, 2012 at 5:43 PM, Chamika Weerasinghe <
>>> >>>> >> [hidden email]>wrote:
>>> >>>> >> >>
>>> >>>> >> >>> On Fri, May 25, 2012 at 1:25 AM, Jerome Velociter <
>>> >>>> >> [hidden email]
>>> >>>> >> >>> >wrote:
>>> >>>> >> >>>
>>> >>>> >> >>> > On Thu, May 24, 2012 at 6:09 PM, Thomas Mortagne
>>> >>>> >> >>> > <[hidden email]> wrote:
>>> >>>> >> >>> > > On Thu, May 24, 2012 at 5:52 PM, sasinda rukshan
>>> >>>> >> >>> > > <[hidden email]> wrote:
>>> >>>> >> >>> > >> Hi all,
>>> >>>> >> >>> > >> I am starting this thread for my XWiki Android Platform
>>> >>>> >> >>> > >> Project.
>>> >>>> >> >>> > >>
>>> >>>> >> >>> > >> Please check whether following are OK.
>>> >>>> >> >>> > >> [1] INFO
>>> >>>> >> >>> > >> I tried to start my new modules with the
>>> >>>> >> >>> de.akquinet.android.archetypes:
>>> >>>> >> >>> > >> android-quickstart:1.0.8.  (added eclipse plugins m2e,
>>> >>>> >> >>> > >> m2e-android[a.k.a  *Android
>>> >>>> >> >>> > >> Configurator* ]). But this seems buggy in eclipse.
>>> >>>> >> >>> > >> Any way the earlier project has not followed the above
>>> >>>> >> >>> > >> archtype
>>> >>>> >> >>> either.
>>> >>>> >> >>> > So
>>> >>>> >> >>> > >> I am going to write pom.xml manually for my each module.
>>> >>>> >> >>> > >>
>>> >>>> >> >>> > >> [2] ADVICE NEEDED
>>> >>>> >> >>> > >> xwiki-rest-model module contains 2 submodules
>>> >>>> >> >>> > >>  |-- xwiki-rest-model-gson  ( gson should be corrected to
>>> >>>> >> >>> > >> json)
>>> >>>> >> >>> > >
>>> >>>> >> >>> > > No the g is not a mistake, it's a model to be used with
>>> the
>>> >>>> >> >>> > > gson
>>> >>>> >> >>> > > library (http://code.google.com/p/google-gson/). See
>>> >>>> >> >>> > >
>>> >>>> >> >>> >
>>> >>>> >> >>>
>>> >>>> >>
>>> >>>> >>
>>> http://extensions.xwiki.org/xwiki/bin/view/Extension/Google+Android+Client#HXWikiAndroidDevelopmentAPIsandResources
>>> >>>> >> >>> > .
>>> >>>> >> >>> > >
>>> >>>> >> >>> > >>  |-- xwiki-rest-model-simplexml
>>> >>>> >> >>> > >> I think the xwiki-rest-model-gson is redundant. The
>>> classes
>>> >>>> >> >>> > >> in xwiki-rest-model-simplexml is added with simple xml
>>> >>>> >> annotations,
>>> >>>> >> >>> > >> otherwise both modules have same classes. There is no
>>> problem
>>> >>>> >> >>> > >> with
>>> >>>> >> >>> the
>>> >>>> >> >>> > >> added annotations for using the same model objects for
>>> Json
>>> >>>> >> >>> > >> REST
>>> >>>> >> web
>>> >>>> >> >>> > >> services. And I intend to add my JPA (ORMLite library for
>>> >>>> >> >>> persistence)
>>> >>>> >> >>> > >> annotations on top of it.
>>> >>>> >> >>> > >> Shall I re-factor them to a single module
>>> xwiki-rest-model.
>>> >>>> >> >>> > >
>>> >>>> >> >>> > > No keep them separated, the idea is that both are useful
>>> tool
>>> >>>> >> >>> > > to be
>>> >>>> >> >>> > > used by someone else that might be moved to
>>> xwiki-platform at
>>> >>>> >> >>> > > some
>>> >>>> >> >>> > > point along with the current xwiki-rest-model (to be
>>> renamed to
>>> >>>> >> >>> > > xwiki-rest-model-jaxb).
>>> >>>> >> >>> > >
>>> >>>> >> >>> > > Chamika initially started with gson and since XWiki REST
>>> JSON
>>> >>>> >> >>> > > representation had some limitation he moved to XML
>>> >>>> >> >>> > > representation.
>>> >>>> >> >>> > > Maybe at some point Android will have native support for
>>> jaxb
>>> >>>> >> >>> > > which
>>> >>>> >> >>> > > would obviously be the easier for us (embedding jaxb is
>>> not an
>>> >>>> >> option
>>> >>>> >> >>> > > in mobile world where size it still pretty important
>>> especially
>>> >>>> >> >>> > > on
>>> >>>> >> >>> > > phones). Maybe it's already the case on most recent
>>> versions
>>> >>>> >> >>> > > like
>>> >>>> >> 4.0
>>> >>>> >> >>> > > I don't know.
>>> >>>> >> >>> >
>>> >>>> >> >>> > There's also Jackson that could be tried for JSON
>>> >>>> >> >>> > deserialization, if
>>> >>>> >> >>> > said limitations are actually GSON limitations.
>>> >>>> >> >>> >
>>> >>>> >> >>> GSON wasn't the limitation.
>>> >>>> >> >>> It was XWiki RESTful API which doesn't support JSON in some
>>> cases.
>>> >>>> >> >>> So
>>> >>>> >> it's
>>> >>>> >> >>> safe to go with xml.
>>> >>>> >> >>>
>>> >>>> >> >>> >
>>> >>>> >> >>> > Having full JAXB support sound a bit overweight for such an
>>> >>>> >> >>> > "embedded
>>> >>>> >> >>> > API", even if one day it is natively supported by Android.
>>> What's
>>> >>>> >> >>> > important is to have an easy and fast deserialization, IMO.
>>> >>>> >> >>> > The only advantage I can see of going JAXB would be in
>>> re-using
>>> >>>> >> >>> > the
>>> >>>> >> >>> > exact representations and body readers/writers from XWiki
>>> core.
>>> >>>> >> >>> > But
>>> >>>> >> >>> > you probably don't even want to do that since it would mean
>>> >>>> >> >>> > dragging
>>> >>>> >> >>> > XWiki core with you :)
>>> >>>> >> >>> >
>>> >>>> >> >>> > Jerome
>>> >>>> >> >>> >
>>> >>>> >> >>> > >
>>> >>>> >> >>> > >>
>>> >>>> >> >>> > >> [3] INFO
>>> >>>> >> >>> > >>  I had to change some pom.xml s. As the current project
>>> at:
>>> >>>> >> >>> > >> https://github.com/xwiki-contrib/android-client.gitdoes not
>>> >>>> >> build.
>>> >>>> >> >>> > Error
>>> >>>> >> >>> > >> with parent pom.xml coordinates.
>>> >>>> >> >>> > >
>>> >>>> >> >>> > > You probably did not setup you maven install properly
>>> since
>>> >>>> >> >>> > > what's
>>> >>>> >> on
>>> >>>> >> >>> > > https://github.com/xwiki-contrib/android-client.git build
>>> >>>> >> perfectly
>>> >>>> >> >>> as
>>> >>>> >> >>> > > you can see on
>>> >>>> >> http://ci.xwiki.org/view/All/job/xwiki-android-client/
>>> >>>> >> >>> > > which run a build every time something changes on the git
>>> >>>> >> repository..
>>> >>>> >> >>> > > You should look at
>>> >>>> >> >>> > > http://dev.xwiki.org/xwiki/bin/view/Community/Building.
>>> >>>> >> >>> > >
>>> >>>> >> >>> > >>
>>> >>>> >> >>> > >>
>>> >>>> >> >>> > >> Thank you
>>> >>>> >> >>> > >> Best Regards.
>>> >>>> >> >>> > >> Sasinda Rukshan
>>> >>>> >> >>> > >> _______________________________________________
>>> >>>> >> >>> > >> devs mailing list
>>> >>>> >> >>> > >> [hidden email]
>>> >>>> >> >>> > >> http://lists.xwiki.org/mailman/listinfo/devs
>>> >>>> >> >>> > >
>>> >>>> >> >>> > >
>>> >>>> >> >>> > >
>>> >>>> >> >>> > > --
>>> >>>> >> >>> > > Thomas Mortagne
>>> >>>> >> >>> > > _______________________________________________
>>> >>>> >> >>> > > devs mailing list
>>> >>>> >> >>> > > [hidden email]
>>> >>>> >> >>> > > http://lists.xwiki.org/mailman/listinfo/devs
>>> >>>> >> >>> >
>>> >>>> >> >>> >
>>> >>>> >> >>> >
>>> >>>> >> >>> > --
>>> >>>> >> >>> > Jérôme Velociter
>>> >>>> >> >>> > Winesquare
>>> >>>> >> >>> > http://www.winesquare.net/
>>> >>>> >> >>> > _______________________________________________
>>> >>>> >> >>> > devs mailing list
>>> >>>> >> >>> > [hidden email]
>>> >>>> >> >>> > http://lists.xwiki.org/mailman/listinfo/devs
>>> >>>> >> >>> >
>>> >>>> >> >>> _______________________________________________
>>> >>>> >> >>> devs mailing list
>>> >>>> >> >>> [hidden email]
>>> >>>> >> >>> http://lists.xwiki.org/mailman/listinfo/devs
>>> >>>> >> >>>
>>> >>>> >> >>
>>> >>>> >> >>
>>> >>>> >> > _______________________________________________
>>> >>>> >> > devs mailing list
>>> >>>> >> > [hidden email]
>>> >>>> >> > http://lists.xwiki.org/mailman/listinfo/devs
>>> >>>> >>
>>> >>>> >>
>>> >>>> >>
>>> >>>> >> --
>>> >>>> >> Thomas Mortagne
>>> >>>> >> _______________________________________________
>>> >>>> >> devs mailing list
>>> >>>> >> [hidden email]
>>> >>>> >> http://lists.xwiki.org/mailman/listinfo/devs
>>> >>>> >>
>>> >>>> > _______________________________________________
>>> >>>> > devs mailing list
>>> >>>> > [hidden email]
>>> >>>> > http://lists.xwiki.org/mailman/listinfo/devs
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>> --
>>> >>>> Thomas Mortagne
>>> >>>
>>> >>>
>>> >>
>>> >>
>>> >>
>>> >> --
>>> >> Thomas Mortagne
>>> >
>>> >
>>> >
>>> > --
>>> > Thomas Mortagne
>>>
>>>
>>>
>>> --
>>> Thomas Mortagne
>>>
>>
>>
> _______________________________________________
> devs mailing list
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs



--
Thomas Mortagne
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [GSoc] XDroid Platform

Thomas Mortagne
Administrator
In reply to this post by sasinda
On Sun, Jun 17, 2012 at 2:16 PM, sasinda rukshan
<[hidden email]> wrote:

> Hi,
>
> Status Rept:
> I reverse engineered the com.xpn.objects /.object.classes / .object.meta
> packages. I think I understand it somewhat now.
> I am making up my own simple design for the model classes.
> I will soon post UML diagram with my design. Since XWiki ReST interfaces
> are so robust I don't have to fill many of the attribute fields and
> propertiest to post a blog post.
> I will further experiment (Using Postman chrome plugin for ReST testing,
> it's nice) before coming up with the class diagram.
>
> Questions:
> 1) A page has its own class. When we make a new page a custom class gets
> created. I checked the xml file for  Blog.BlogIntroduction. It looked more
> of a representation of a document object. Not a class definition. (It had
> values defined. So can it be considered as a class def) ?

Well a better way to see it is that a document contains zero or one
class and zero or several objects. Not every document really have a
class.

You always get an empty class when you ask for the class of a document
for the same reason that you get an empty document when your as for a
document that does not exists.

>
> 2) Is this idea correct?
> I make a new page named NEWPAGE1  in Blog space.
>  page  :is of class type  Blog.NEWPAGE1.
>  can have objects of any type.
> I posted a BlogPostClass object. But there are no restrictions to post
> another BlogPostClass object. But only the first BlogPostClass object is
> rendered when viewing the page.
>
> Shouldn't the page be of type BlogClass (extends BlogCode).?
> So,
> Shall I give a type for a document object. Something like
> doc.setType(BlocClass.class); When this happens the document object
> enforces type restrictions. Like only BlogPostClass objects should be in
> the page and etc.
>
> I'll be happy to provide with clarifications If I said things very briefly.
> I will design a uml class diag for this part and send before implementation
> starts.
>
>
> Thanks
> Best Regards
> Sasinda.
>
>
>
>
>
>
>
> Thank You
>
>
> On Sat, Jun 16, 2012 at 10:31 PM, sasinda rukshan
> <[hidden email]>wrote:
>
>> Hi,
>> I checked the source code.(still it would be helpful if u cn explain)
>> I have  a little issue.
>> Say with the current model
>> Blog.BlogPostClass
>>   properties|__DBTreeList  category  {has a list of attributes}
>>                   |__TextAreaClass content   {has a list of attributes}
>>             |__ MYType  myComplexTypeProp {has a list of attributes
>>  which are all simple properties such as StringProperty etc}  [ for
>> ex:TagClass tagprop ]
>>                                    |__ StringClass mystring   {also have a
>> list of attributes.
>>
>> The XML schema
>>
>> <complexType name="Object">
>>    <complexContent>
>>      <extension base="{http://www.xwiki.org}ObjectSummary">
>>        <sequence>
>>          <element name="property" type="{http://www.xwiki.org}Property" maxOccurs="unbounded" minOccurs="0"/>
>>        </sequence>
>>      </extension>
>>    </complexContent>
>>  </complexType>
>>
>> <complexType name="Property">
>>    <complexContent>
>>      <extension base="{http://www.xwiki.org}LinkCollection">
>>        <sequence>
>>          <element name="attribute" type="{http://www.xwiki.org}Attribute" maxOccurs="unbounded" minOccurs="0"/>
>>          <element name="value" type="{http://www.w3.org/2001/XMLSchema}string"/>
>>        </sequence>
>>        <attribute name="name" use="required" type="{http://www.w3.org/2001/XMLSchema}string" />
>>        <attribute name="type" type="{http://www.w3.org/2001/XMLSchema}string" />
>>      </extension>
>>    </complexContent>
>>  </complexType>
>>
>>  <complexType name="Attribute">
>>    <complexContent>
>>      <extension base="{http://www.xwiki.org}LinkCollection">
>>        <attribute name="name" use="required" type="{http://www.w3.org/2001/XMLSchema}string" />
>>        <attribute name="value" type="{http://www.w3.org/2001/XMLSchema}string" />
>>      </extension>
>>    </complexContent>
>>  </complexType>
>>
>> does not seem to be addressing such an occasion where multiple levels of
>> nesting is happening. (May be I'm horribly wrong here)
>>
>> Am I correct to think that any type of Object like BlogPostClass obj will only have properties of simple types such as StringClass, TextAreaClass and etc. It will not have a complex type for example XWiki.TagClass in it.(I know it never happens in BlogPostClass, but don't know if someone needs to do a weird class). ?
>>
>> My findings and comprehension on the model:
>>
>> I guess StringClass, TextAreaClass etc, carry most of those many attributes for rendering purpose. I saw StaticListClass has attribute (separators) for defining the list value delimeters as well.
>>
>> Can you please post me a diagram taking a single class like DateClass. How
>> the aggregations and inheritance is done.

There is no such thing as inheritance with XWiki classes (yet).

>> Ill send my design. I intend to do all that with just single definition
>> for each XWiki data type classes.For ex: XString extends XObject.XObject
>> contains the collection of fields.These can be converted to <attribute>
>> elements. A Document Object will contain a BlogPost (represent
>> BlobPostClass) object which contains XObject s as properties. (ideally if
>> multiple levels of nesting is supported BlogPost should also be a XObject).
>> The Document Object is an entity.(refer
>> https://docs.google.com/drawings/d/1hwfQMVgCvYKS6iHU060drcET3Aq3Vles2DQlJOOt3n8/edit<https://docs.google.com/drawings/d/1hwfQMVgCvYKS6iHU060drcET3Aq3Vles2DQlJOOt3n8/edit?pli=1>
>>  )
>> When we persist a document object it should serialize the BLogPost class
>> into its xml representation and save it on the filesystem. SQLite DB will
>> have a row with the URI for that file. So I am not going to persist
>> rest-model objects ( neither annotate them for persistence). Storing such
>> bulk objects may degrade DB performance. In the android dev guides it is
>> said a curser to a table should not exceed 2 MB of data otherwise the
>> performance will be low due to paging.
>> This makes the persistence a little complex. I will manage it. PLS tell if
>> my approach is wrong.
>>
>> By the way I will merge my work to the master branch next week. Is it ok
>> to duplicate your maven work to a mvn branch and undo the commit in master
>> and merge my work with a fast forward merge, so that it will show  a linear
>> history.
>>
>> Thanks
>> Best Regards.
>> Sasinda Rukshan.
>>
>>
>>
>>
>>
>>
>>
>> On Sat, Jun 16, 2012 at 11:21 AM, sasinda rukshan <
>> [hidden email]> wrote:
>>
>>> Thanks very much for the help on maven build.
>>>
>>> *About making a object from Blog.BlogPostClass  and toXML()*
>>>
>>> A blog object is having properties of type other xobject classes. So to
>>> make the things general can we do a stripped down replication or make
>>> something similer to the java classes in com.xpn.xwiki.objects and its 2
>>> sub packages .classes, .meta .
>>>  We can make a document object representing a page and put a
>>> Blog.BlogPostClass object to its list of objects.We can convert them to
>>> simple xml model directly.If we want to post blog object we can post the
>>> Blog object.If the page does not exist we can put the page by getting the
>>> xml from the Document object.
>>> Then the things will be general not only for blog client app. Also we can
>>> have Type checking when we don't directly manipulate simplexml objects.
>>> i.e. XStringClass will define the attributes for it and likewise.
>>>
>>> I don't have a good idea on the above packages and classes. Specially why
>>> there are three classes for each XType ex: StringProperty, StringClass,
>>> StringMeta.
>>> It will be helpful if you can give an explanation.
>>>
>>> My draft solution is to do some simple thing as,
>>> XObject
>>>  |____ XBoolean
>>>
>>> XObject
>>> |____XString
>>>
>>> XString has methods,
>>> toEmbedXML  gives a <property><attribute/>...</property> string/
>>> simpleXML objects
>>> toXML  gives <object><id><ClassName>.......</object> for the same thing.
>>>
>>> Also
>>> XObject
>>> |_____ XBlogPost       for(BlogPostClass and other 2 Meta,Property
>>> classes)
>>>
>>> I don't yet have a clear idea on this. May be I am wrong on this.
>>> Can you give me your idea here as well. How to approach the problem and
>>> what should the design be like?
>>>
>>> Thanks.
>>> Best Regards
>>> Sasinda.
>>>
>>>
>>>
>>> On Thu, Jun 7, 2012 at 9:28 PM, Thomas Mortagne <
>>> [hidden email]> wrote:
>>>
>>>> As just did a commit with last version of android plugin and some
>>>> cleanup. Seems to work well.
>>>>
>>>> On Thu, Jun 7, 2012 at 12:19 PM, Thomas Mortagne
>>>> <[hidden email]> wrote:
>>>> > BTW if you have quick questions it's probaly better to use IRC (I'm
>>>> > tmortgane on the channel and I'm on GMT+2 tome zone but you can ask
>>>> > anyone when I'm not around). See
>>>> > http://dev.xwiki.org/xwiki/bin/view/Community/IRC.
>>>> >
>>>> > On Thu, Jun 7, 2012 at 12:17 PM, Thomas Mortagne
>>>> > <[hidden email]> wrote:
>>>> >> Not need to send this kind of mail privately to me.
>>>> >>
>>>> >> On Thu, Jun 7, 2012 at 5:33 AM, sasinda rukshan
>>>> >> <[hidden email]> wrote:
>>>> >>> Thanks,
>>>> >>> The project is building perfectly well in eclipse (and runs well
>>>> too) [I
>>>> >>> configured the build paths for eclipse opening each module as a
>>>> project and
>>>> >>> giving project dependencies and etc.]. This is because android facet
>>>> and
>>>> >>> maven-android plugin for eclipse [m2e-android] (not the jayway
>>>>  androi maven
>>>> >>> plugin)does not work together well.
>>>> >>> Maven build does not work with newer jayway android maven plugins
>>>> because of
>>>> >>> the simplexml library. I checked with another helloworld app that
>>>> does not
>>>> >>> have simplexml dependancy and have simplexml dependancy. When we
>>>> have the
>>>> >>> dependancy it does not work. Also when packaged with the beta
>>>> version maven
>>>> >>> plugin I get runtime error logs notifying that the exact classes
>>>> informed
>>>> >>> missed in the compile time for newer maven plugin are missing. But
>>>> the app
>>>> >>> is running ok.
>>>> >>> I will try with it some more and if I can't can you help me with it a
>>>> >>> little.
>>>> >>
>>>> >> Sure If it's just related to simplexml it's probably not much. I will
>>>> >> try to take a look today. At worst the version we are using right now
>>>> >> is working fine so you can continue with it anyway.
>>>> >>
>>>> >>>
>>>> >>> I looked at the Enterprise platform apis just to make my apis
>>>> similar when
>>>> >>> possible.Source code is not at all relevant to me. But as you say It
>>>> will be
>>>> >>> imperfect if I use its style heavily for the mobile version as well.
>>>> >>
>>>> >> Yes there is several issues here:
>>>> >> * most APIs in oldcore module are old and bad and we are trying to get
>>>> >> rif of them so better not getting too much attached to it ;)
>>>> >> * they are designed to run in an enironment with lots of resources and
>>>> >> don't care as much as a mobile API should about memory, etc.
>>>> >>
>>>> >>>
>>>> >>>
>>>> >>> Thank you.
>>>> >>> Best Regards.
>>>> >>> Sasinda.
>>>> >>>
>>>> >>>
>>>> >>> On Wed, Jun 6, 2012 at 1:03 PM, Thomas Mortagne <
>>>> [hidden email]>
>>>> >>> wrote:
>>>> >>>>
>>>> >>>> On Tue, Jun 5, 2012 at 7:07 PM, sasinda rukshan
>>>> >>>> <[hidden email]> wrote:
>>>> >>>> > Hi,
>>>> >>>> > *1: User Config Saving*
>>>> >>>> > *
>>>> >>>> > *
>>>> >>>> > Xwiki android can now save user login data.
>>>> >>>> > I refered
>>>> >>>> > http://platform.xwiki.org/xwiki/bin/view/AdminGuide/AccessWiki.
>>>> >>>> > Currently assuming the authority
>>>> >>>> >
>>>> >>>> > part(platform.xwiki.org<
>>>> http://platform.xwiki.org/xwiki/bin/view/AdminGuide/AccessWiki>)
>>>> >>>> > only
>>>> >>>> > as a unique wiki identifier. But in the
>>>> org.xwiki.android.entity.User I
>>>> >>>> > have the method
>>>> >>>> > setXWikiRealm(String url);:
>>>> >>>> > Here I have intended the meaning realm as the url root path for a
>>>> unique
>>>> >>>> > wiki instance.
>>>> >>>> > i.e. it should identify a wiki using path upto
>>>> >>>> > http://host/xwiki/wiki/wikialias/
>>>> >>>> > But that functionality is not implemented.I just mailed this
>>>> asking for
>>>> >>>> > the
>>>> >>>> > opinion wether the usage of word realm was right here.
>>>> >>>> > Also do you have seperate users for  wikis for path based wiki
>>>> access.Or
>>>> >>>> > are they the same with the main wiki *http://<host>/xwiki*.
>>>> >>>>
>>>> >>>> Both actually, you can have global users (which are the one on main
>>>> >>>> wiki) and local users.
>>>> >>>>
>>>> >>>> > *2: Entity model*
>>>> >>>> > *
>>>> >>>> > *
>>>> >>>> > About the convention for using C_ prefix for core entity tables. I
>>>> >>>> > was referring to make the android versions of these entities
>>>> >>>> > http://platform.xwiki.org/xwiki/bin/view/DevGuide/DatabaseSchemaand
>>>> >>>> > start
>>>> >>>> > there db prefixes with C_
>>>> >>>> > This is because other apps may need to store some specific tables
>>>> needed
>>>> >>>> > for them. Rather than having a seperate DB schema for them we can
>>>> put
>>>> >>>> > those
>>>> >>>> > tables here as well prefixing them with <appname>_ .
>>>> >>>> > I added more entities like User as well to the core entities(table
>>>> >>>> > C_User).Also will implement a Log Entity(C_Log table) for logging
>>>> some
>>>> >>>> > important application activities(such as login attempts) But the
>>>> Log may
>>>> >>>> > be
>>>> >>>> > a little additional weight to the space and performance.I may
>>>> implement
>>>> >>>> > a
>>>> >>>> > generic DBCleaning service to clean the tables like Log, if I
>>>> have time.
>>>> >>>> > (Perhaps this description will resolve the confusion about the DB
>>>> >>>> > conventions. Sorry I was not very clear in that earlier mail.
>>>> ;-).)
>>>> >>>> >
>>>> >>>> > I am sorry to say I am somewhat confused with all those entities
>>>> in
>>>> >>>> > http://platform.xwiki.org/xwiki/bin/view/DevGuide/DatabaseSchema.
>>>> >>>>
>>>> >>>> The XWiki model is based on generic classes and objects wich is why
>>>> >>>> you see lots of tables (class properties, object properties , etc.).
>>>> >>>> There is no table for users for example, its an object of class
>>>> >>>> XWiki.XWikiUsers.
>>>> >>>>
>>>> >>>> >
>>>> >>>> > Any way to reduce my confusion
>>>> >>>> > I refered
>>>> >>>> > 1)  XWiki Data
>>>> >>>> > Model<http://platform.xwiki.org/xwiki/bin/view/DevGuide/DataModel
>>>> >
>>>> >>>> > :
>>>> >>>> >   can you give me a link to a documentation that explains the
>>>> workflow
>>>> >>>> > of
>>>> >>>> > how a normal request is converted in to the requested page by the
>>>> >>>> > bin View action . So I can get a better understanding of how
>>>> classes ,
>>>> >>>> > objects are used.
>>>> >>>>
>>>> >>>> Not sure there is one. but basically you get either:
>>>> >>>> * document content executed
>>>> >>>> * if a class sheet is defined for one of the document objects
>>>> classes,
>>>> >>>> the class sheet is executed
>>>> >>>> * if a document sheet is defined for the documment, the document
>>>> sheet
>>>> >>>> is executed
>>>> >>>>
>>>> >>>> That's pretty much all, then is a matter of free script and wiki
>>>> >>>> syntax to actually display the content.
>>>> >>>>
>>>> >>>> > 2)  package com.xpn.xwiki.api: I don't need to consider this, do
>>>> I?
>>>> >>>>
>>>> >>>> That's limited scripting API so you should not consider this.
>>>> >>>>
>>>> >>>> > 3)
>>>> >>>> >  Cache<
>>>> http://extensions.xwiki.org/xwiki/bin/view/Extension/Cache+Module>
>>>> >>>> >  : Need not implement similar component. Android OS does it
>>>> nicely for
>>>> >>>> > the
>>>> >>>> > REST responses
>>>> >>>> > but still don't have a clear picture on this.
>>>> >>>> > To save a blog doc
>>>> >>>> > option 1)Seems like I have to convert a document entity to
>>>> relevent
>>>> >>>> > xwiki-model-simplexml entities and send to server.
>>>> >>>> > option 2) We also can edit the relevent simplexml model object
>>>> fields
>>>> >>>> > directly. (Looks a bad option to me.It does not hide the
>>>> complexity of
>>>> >>>> > lower levels for the client layer.Anyway my work load  is reduced
>>>> with
>>>> >>>> > opt:2 ;-))
>>>> >>>>
>>>> >>>> IMO you should not even look at
>>>> >>>> http://extensions.xwiki.org/xwiki/bin/view/Extension/Cache+Moduleand
>>>> >>>> instead look at how caching is usually done in Android. The idea is
>>>> >>>> not to port the xwiki-platform to Android IMO but to follow Android
>>>> >>>> standards to provide a library to manipulate XWiki model.
>>>> >>>>
>>>> >>>> You can set the annotation you want to the simplexml model but the
>>>> >>>> classes/methods should remain an exact copy of what's on
>>>> >>>> xwiki-platform-rest-model. The idea being that we could decide to
>>>> >>>> change the implementation from simplexml to anything (JAXB, gson,
>>>> >>>> etc.) without breaking anything.
>>>> >>>>
>>>> >>>> >
>>>> >>>> >
>>>> >>>> > *3: Development/architectural approach Change*
>>>> >>>> > *
>>>> >>>> > *
>>>> >>>> > I was first thinking for a addon like architecture for the XWiki
>>>> android
>>>> >>>> > app. We have the client.Main app (with all platfrom libs
>>>> included) and
>>>> >>>> > Blog
>>>> >>>> > app as a seperate apk.
>>>> >>>> > But here Blog app will need to have the platform lib also. That
>>>> would be
>>>> >>>> > a
>>>> >>>> > complete waste of space. But dynamically extending the app is lot
>>>> >>>> > easier.
>>>> >>>> > The client.Main app can add the activities defined in other apks
>>>> in to
>>>> >>>> > its
>>>> >>>> > launcher interface using android PackageManager class.
>>>> >>>> >
>>>> >>>> >
>>>> http://stackoverflow.com/questions/9236803/android-build-an-application-that-supports-add-ons
>>>> >>>> > But with this approach rises additional complexities. For example
>>>> naming
>>>> >>>> > conflicts in the Components library module when two apps have the
>>>> same
>>>> >>>> > library with same activities defined. Sync issues etc etc....
>>>> >>>> > So we will go with single .apk approach.
>>>> >>>> > When going with single .apk we dont need a content provider to
>>>> share
>>>> >>>> > config/ preferences data. So sharing module is now not needed. The
>>>> >>>> > client
>>>> >>>> > applications now can directly access the Configuration.java class
>>>> to
>>>> >>>> > get/put configuration entries.
>>>> >>>> > Also since I am having a User entity a configuration like
>>>> >>>> > defaultUser(currently the admin user , hard coded in login.xml
>>>> layout
>>>> >>>> > file)
>>>> >>>> > will only be needed for the first use of the app. Otherwise users
>>>> need
>>>> >>>> > not
>>>> >>>> > configure a default user as the application now suggests the user
>>>> names
>>>> >>>> > and
>>>> >>>> > automatically fill the rest.
>>>> >>>>
>>>> >>>> Keep in mind that the main goal of this project is to provide tools
>>>> >>>> for any application to access an XWiki instance and manipulate its
>>>> >>>> datas easily an improving those libraries should always be the first
>>>> >>>> goal. Your blog application is here as a good demo and because it's
>>>> >>>> hard to design a library without using it.
>>>> >>>>
>>>> >>>> I really don't understand why you talk about naming conflict. Of
>>>> >>>> course a library should never provide a complete final activity but
>>>> >>>> only interface components (View), fragments or base activities to
>>>> >>>> extend. Putting those elements in an activity is each application
>>>> job.
>>>> >>>> An activity is by definition unique so it has nothing to do in a
>>>> >>>> library. The complete activities in
>>>> >>>>
>>>> >>>>
>>>> https://github.com/xwiki-contrib/android-client/tree/master/xwiki-android-components/
>>>> >>>> should have never been there, it's actually a mistake.
>>>> >>>>
>>>> >>>> >
>>>> >>>> > *4: Plan for this week*
>>>> >>>>
>>>> >>>> As a priority you should really merge your branch as soon as you
>>>> have
>>>> >>>> something building fine. So that it goes through Jenkins and deploy
>>>> >>>> snapshot build of what you do. Jenkins will tells you in live when
>>>> >>>> your project does not build anymore or if there is any test failing
>>>> >>>> and it allows anyone to very easily test the current test of the
>>>> >>>> client just by installing the apks on
>>>> >>>> http://maven.xwiki.org/snapshots/org/xwiki/android/. You need to
>>>> have
>>>> >>>> something working and in good shape to succeed the GSOC so fixing
>>>> when
>>>> >>>> you break something in your build should be your priority over
>>>> adding
>>>> >>>> more features.
>>>> >>>>
>>>> >>>> Also as I commented in your commit you should be more careful on
>>>> what
>>>> >>>> you commit. There is many binaries and Eclipse stuff in your branch.
>>>> >>>>
>>>> >>>> > *
>>>> >>>> > *
>>>> >>>> > Make a launch pad .We can launch XWiki Navigator, blog etc from
>>>> this.
>>>> >>>> > The
>>>> >>>> > launch pad is shown when we launch XWiki main client.
>>>> >>>> > Consider adding the WYSIWYG to my blog. It will be useless
>>>> without the
>>>> >>>> > ability to convert text formatting to xwiki syntax.So I may just
>>>> >>>> > integrate
>>>> >>>> > it and ignore the uselessness for now.
>>>> >>>>
>>>> >>>> Not exactly, you could actually reuse WYSIWYG service to send html
>>>> and
>>>> >>>> let it convert it to wiki syntax. Note that you are not limited to
>>>> >>>> what you can find in the current Android library. This is just what
>>>> >>>> Chamika had the time to do. There is others REST (or not REST)
>>>> server
>>>> >>>> interfaces you can use in your client or even add more if its
>>>> generic
>>>> >>>> enough and make sense for something else than just Android client.
>>>> >>>>
>>>> >>>> > We currently don't have any config to save( Other than default
>>>> user)
>>>> >>>> > config. I will add some demo config data and have a developer
>>>> tools app
>>>> >>>> > added to the above mentioned XWiki launch pad that can view/edit
>>>> the
>>>> >>>> > config
>>>> >>>> > file.
>>>> >>>> >
>>>> >>>> > That will complete milestone 1. But it is not the Sharing
>>>> >>>> > module(intended
>>>> >>>> > to share data with other .apks).That is the configuration
>>>> component does
>>>> >>>> > not have a ContentProvider to share config data with other apks.
>>>> Also I
>>>> >>>> > will define a seperate class to have preferences which will be
>>>> edited by
>>>> >>>> > users. Config files are for configuration stuff and will be
>>>> edited by
>>>> >>>> > developers. Users have preferences files(natively supported by
>>>> android)
>>>> >>>> > to
>>>> >>>> > change app preferences. For example users will add the default
>>>> login
>>>> >>>> > username as a preference.(This will invalidate the use of default
>>>> User
>>>> >>>> > entry in the config file which is used until the user edits his
>>>> >>>> > preferences)
>>>> >>>>
>>>> >>>> I'm fine with not sharing datas between applications but it does not
>>>> >>>> prevent the libraries to  provide tools to manage those datas in a
>>>> per
>>>> >>>> application basis.
>>>> >>>>
>>>> >>>> >
>>>> >>>> > Beg your pardon if the mail is too lengthy.;-)
>>>> >>>>
>>>> >>>> No problem, never too much information for this ;)
>>>> >>>>
>>>> >>>> > Thank you.
>>>> >>>> > Best Regards.
>>>> >>>> >
>>>> >>>> > Sasinda Rukshan.
>>>> >>>> >
>>>> >>>> >
>>>> >>>> > Best Regards.
>>>> >>>> >
>>>> >>>> >
>>>> >>>> > On Wed, May 30, 2012 at 1:11 PM, Thomas Mortagne
>>>> >>>> > <[hidden email]>wrote:
>>>> >>>> >
>>>> >>>> >> On Wed, May 30, 2012 at 4:28 AM, sasinda rukshan
>>>> >>>> >> <[hidden email]> wrote:
>>>> >>>> >> > Hi,
>>>> >>>> >> > I am studying ORM Lite these days.
>>>> >>>> >> > Please It would be comforting if you can confirm whether it is
>>>> worth
>>>> >>>> >> > the
>>>> >>>> >> > overhead to use ORM Lite.
>>>> >>>> >> >
>>>> >>>> >>
>>>> >>>> >>
>>>> http://logic-explained.blogspot.com/2011/12/using-ormlite-in-android-projects.html
>>>> >>>> >> > http://ormlite.com/
>>>> >>>> >> > ORM Lite features:
>>>> >>>> >> > Automatically Creates standard DAOs for an annotated entity.
>>>> >>>> >> > Coding will be lot easier.
>>>> >>>> >>
>>>> >>>> >> Remember it's a framework for a mobile platform so it has to
>>>> remain
>>>> >>>> >> light and have good performances. I can see that Android version
>>>> of
>>>> >>>> >> ormlite is very small but I never used it so I don't know if
>>>> it's good
>>>> >>>> >> or not. At least it seems petty active which is a good point so I
>>>> >>>> >> don't have anything against it.
>>>> >>>> >>
>>>> >>>> >> >
>>>> >>>> >> > Can you suggest how to name the entities.
>>>> >>>> >> > I am going to go with,
>>>> >>>> >> > <entity>  org.xwiki.xdroid.data.User  --> <table> C_USER
>>>> >>>> >>
>>>> >>>> >> Note that there is already a package name prefix and group id
>>>> defined
>>>> >>>> >> for the framework and it's org.xwiki.android as you can see on
>>>> >>>> >> https://github.com/xwiki-contrib/android-client. Why do you
>>>> want to
>>>> >>>> >> change it ? It's more consistent with
>>>> >>>> >> org.xwiki.commons/org.xwiki.rendering/org.xwiki.platform so I
>>>> would
>>>> >>>> >> prefer to keep it that way unless you can give arguments. The
>>>> goal is
>>>> >>>> >> not to redo something completely but complete and improve the
>>>> existing
>>>> >>>> >> framework.
>>>> >>>> >>
>>>> >>>> >> Also as far as I can see there is already several things called
>>>> >>>> >> "xdroid" on Google play among which an application developer
>>>> >>>> >> (https://play.google.com/store/apps/developer?id=x-droid) and an
>>>> >>>> >> application (
>>>> >>>> >>
>>>> >>>> >>
>>>> https://play.google.com/store/apps/details?id=com.gurudigitalsolutions.xdroid
>>>> >>>> >> ).
>>>> >>>> >>
>>>> >>>> >> >
>>>> >>>> >> > Thanks,
>>>> >>>> >> > Best Regards
>>>> >>>> >> >
>>>> >>>> >> > Sasinda.
>>>> >>>> >> >
>>>> >>>> >> >
>>>> >>>> >> >
>>>> >>>> >> >
>>>> >>>> >> >
>>>> >>>> >> > On Wed, May 30, 2012 at 7:42 AM, sasinda rukshan
>>>> >>>> >> > <[hidden email]>wrote:
>>>> >>>> >> >
>>>> >>>> >> >> Hi,
>>>> >>>> >> >>
>>>> >>>> >> >> I am commiting my work to my fork
>>>> >>>> >> >> https://github.com/sasinda/android-client.
>>>> >>>> >> >> I ll request to pull it to xwiki-contrib later.
>>>> >>>> >> >>
>>>> >>>> >> >> I was running in a wrong path these days. Wanted to save login
>>>> >>>> >> >> history
>>>> >>>> >> and
>>>> >>>> >> >> suggest login. I was going to do it using an xml file (login
>>>> >>>> >> attempts.xml).
>>>> >>>> >> >> Now it seems database is better.
>>>> >>>> >> >> Any way before I go wrong again I will say what I am going to
>>>> do.
>>>> >>>> >> >> I am going to enforce following conventions.These are not yet
>>>> >>>> >> >> needed,
>>>> >>>> >> >> considered the small scale.But when the system grows it would
>>>> be
>>>> >>>> >> >> nice to
>>>> >>>> >> >> have them to avoid confusions.
>>>> >>>> >> >> *Database prefixes for:*
>>>> >>>> >> >> *Platform tables (can begin with appropriate prefix)*
>>>> >>>> >> >> AD_ //application dictionary : don't know when it will be
>>>> needed ;-)
>>>> >>>> >> >> C_ //core functionality
>>>> >>>> >> >> *Client Applications.*
>>>> >>>> >> >> X<App name prefix>  ex: XBLOG_   for Blog app// All client
>>>> add in
>>>> >>>> >> modules
>>>> >>>> >> >> must begin with table prefix X(for xwiki and ordering) + App
>>>> name.
>>>> >>>> >>  This is
>>>> >>>> >> >> for my blog.
>>>> >>>> >> >>
>>>> >>>> >> >> I will create
>>>> >>>> >> >> C_User for user data.
>>>> >>>> >> >> C_LoginAttempt  for saving login attempts.
>>>> >>>> >> >>
>>>> >>>> >> >> From C_LoginAttempt I can filter uniqe login combinations and
>>>> give
>>>> >>>> >> >> suggestions in the login UI component. Also save the history.
>>>> >>>> >> >>
>>>> >>>> >> >> All saved data for blog app will be linked to a perticular
>>>> login :
>>>> >>>> >> >> User,
>>>> >>>> >> >> XWiki server.
>>>> >>>> >> >> But only a single user will be most probably using his
>>>> personal
>>>> >>>> >> >> device.
>>>> >>>> >> So
>>>> >>>> >> >> above will be relevant only when he has multiple wikis.
>>>> >>>> >> >>
>>>> >>>> >> >> Best Regards,
>>>> >>>> >> >> Sasinda Rukshan.
>>>> >>>> >> >>
>>>> >>>> >> >>
>>>> >>>> >> >>
>>>> >>>> >> >>
>>>> >>>> >> >>
>>>> >>>> >> >> On Sun, May 27, 2012 at 5:43 PM, Chamika Weerasinghe <
>>>> >>>> >> [hidden email]>wrote:
>>>> >>>> >> >>
>>>> >>>> >> >>> On Fri, May 25, 2012 at 1:25 AM, Jerome Velociter <
>>>> >>>> >> [hidden email]
>>>> >>>> >> >>> >wrote:
>>>> >>>> >> >>>
>>>> >>>> >> >>> > On Thu, May 24, 2012 at 6:09 PM, Thomas Mortagne
>>>> >>>> >> >>> > <[hidden email]> wrote:
>>>> >>>> >> >>> > > On Thu, May 24, 2012 at 5:52 PM, sasinda rukshan
>>>> >>>> >> >>> > > <[hidden email]> wrote:
>>>> >>>> >> >>> > >> Hi all,
>>>> >>>> >> >>> > >> I am starting this thread for my XWiki Android Platform
>>>> >>>> >> >>> > >> Project.
>>>> >>>> >> >>> > >>
>>>> >>>> >> >>> > >> Please check whether following are OK.
>>>> >>>> >> >>> > >> [1] INFO
>>>> >>>> >> >>> > >> I tried to start my new modules with the
>>>> >>>> >> >>> de.akquinet.android.archetypes:
>>>> >>>> >> >>> > >> android-quickstart:1.0.8.  (added eclipse plugins m2e,
>>>> >>>> >> >>> > >> m2e-android[a.k.a  *Android
>>>> >>>> >> >>> > >> Configurator* ]). But this seems buggy in eclipse.
>>>> >>>> >> >>> > >> Any way the earlier project has not followed the above
>>>> >>>> >> >>> > >> archtype
>>>> >>>> >> >>> either.
>>>> >>>> >> >>> > So
>>>> >>>> >> >>> > >> I am going to write pom.xml manually for my each module.
>>>> >>>> >> >>> > >>
>>>> >>>> >> >>> > >> [2] ADVICE NEEDED
>>>> >>>> >> >>> > >> xwiki-rest-model module contains 2 submodules
>>>> >>>> >> >>> > >>  |-- xwiki-rest-model-gson  ( gson should be corrected
>>>> to
>>>> >>>> >> >>> > >> json)
>>>> >>>> >> >>> > >
>>>> >>>> >> >>> > > No the g is not a mistake, it's a model to be used with
>>>> the
>>>> >>>> >> >>> > > gson
>>>> >>>> >> >>> > > library (http://code.google.com/p/google-gson/). See
>>>> >>>> >> >>> > >
>>>> >>>> >> >>> >
>>>> >>>> >> >>>
>>>> >>>> >>
>>>> >>>> >>
>>>> http://extensions.xwiki.org/xwiki/bin/view/Extension/Google+Android+Client#HXWikiAndroidDevelopmentAPIsandResources
>>>> >>>> >> >>> > .
>>>> >>>> >> >>> > >
>>>> >>>> >> >>> > >>  |-- xwiki-rest-model-simplexml
>>>> >>>> >> >>> > >> I think the xwiki-rest-model-gson is redundant. The
>>>> classes
>>>> >>>> >> >>> > >> in xwiki-rest-model-simplexml is added with simple xml
>>>> >>>> >> annotations,
>>>> >>>> >> >>> > >> otherwise both modules have same classes. There is no
>>>> problem
>>>> >>>> >> >>> > >> with
>>>> >>>> >> >>> the
>>>> >>>> >> >>> > >> added annotations for using the same model objects for
>>>> Json
>>>> >>>> >> >>> > >> REST
>>>> >>>> >> web
>>>> >>>> >> >>> > >> services. And I intend to add my JPA (ORMLite library
>>>> for
>>>> >>>> >> >>> persistence)
>>>> >>>> >> >>> > >> annotations on top of it.
>>>> >>>> >> >>> > >> Shall I re-factor them to a single module
>>>> xwiki-rest-model.
>>>> >>>> >> >>> > >
>>>> >>>> >> >>> > > No keep them separated, the idea is that both are useful
>>>> tool
>>>> >>>> >> >>> > > to be
>>>> >>>> >> >>> > > used by someone else that might be moved to
>>>> xwiki-platform at
>>>> >>>> >> >>> > > some
>>>> >>>> >> >>> > > point along with the current xwiki-rest-model (to be
>>>> renamed to
>>>> >>>> >> >>> > > xwiki-rest-model-jaxb).
>>>> >>>> >> >>> > >
>>>> >>>> >> >>> > > Chamika initially started with gson and since XWiki REST
>>>> JSON
>>>> >>>> >> >>> > > representation had some limitation he moved to XML
>>>> >>>> >> >>> > > representation.
>>>> >>>> >> >>> > > Maybe at some point Android will have native support for
>>>> jaxb
>>>> >>>> >> >>> > > which
>>>> >>>> >> >>> > > would obviously be the easier for us (embedding jaxb is
>>>> not an
>>>> >>>> >> option
>>>> >>>> >> >>> > > in mobile world where size it still pretty important
>>>> especially
>>>> >>>> >> >>> > > on
>>>> >>>> >> >>> > > phones). Maybe it's already the case on most recent
>>>> versions
>>>> >>>> >> >>> > > like
>>>> >>>> >> 4.0
>>>> >>>> >> >>> > > I don't know.
>>>> >>>> >> >>> >
>>>> >>>> >> >>> > There's also Jackson that could be tried for JSON
>>>> >>>> >> >>> > deserialization, if
>>>> >>>> >> >>> > said limitations are actually GSON limitations.
>>>> >>>> >> >>> >
>>>> >>>> >> >>> GSON wasn't the limitation.
>>>> >>>> >> >>> It was XWiki RESTful API which doesn't support JSON in some
>>>> cases.
>>>> >>>> >> >>> So
>>>> >>>> >> it's
>>>> >>>> >> >>> safe to go with xml.
>>>> >>>> >> >>>
>>>> >>>> >> >>> >
>>>> >>>> >> >>> > Having full JAXB support sound a bit overweight for such an
>>>> >>>> >> >>> > "embedded
>>>> >>>> >> >>> > API", even if one day it is natively supported by Android.
>>>> What's
>>>> >>>> >> >>> > important is to have an easy and fast deserialization, IMO.
>>>> >>>> >> >>> > The only advantage I can see of going JAXB would be in
>>>> re-using
>>>> >>>> >> >>> > the
>>>> >>>> >> >>> > exact representations and body readers/writers from XWiki
>>>> core.
>>>> >>>> >> >>> > But
>>>> >>>> >> >>> > you probably don't even want to do that since it would mean
>>>> >>>> >> >>> > dragging
>>>> >>>> >> >>> > XWiki core with you :)
>>>> >>>> >> >>> >
>>>> >>>> >> >>> > Jerome
>>>> >>>> >> >>> >
>>>> >>>> >> >>> > >
>>>> >>>> >> >>> > >>
>>>> >>>> >> >>> > >> [3] INFO
>>>> >>>> >> >>> > >>  I had to change some pom.xml s. As the current project
>>>> at:
>>>> >>>> >> >>> > >> https://github.com/xwiki-contrib/android-client.gitdoes not
>>>> >>>> >> build.
>>>> >>>> >> >>> > Error
>>>> >>>> >> >>> > >> with parent pom.xml coordinates.
>>>> >>>> >> >>> > >
>>>> >>>> >> >>> > > You probably did not setup you maven install properly
>>>> since
>>>> >>>> >> >>> > > what's
>>>> >>>> >> on
>>>> >>>> >> >>> > > https://github.com/xwiki-contrib/android-client.gitbuild
>>>> >>>> >> perfectly
>>>> >>>> >> >>> as
>>>> >>>> >> >>> > > you can see on
>>>> >>>> >> http://ci.xwiki.org/view/All/job/xwiki-android-client/
>>>> >>>> >> >>> > > which run a build every time something changes on the git
>>>> >>>> >> repository..
>>>> >>>> >> >>> > > You should look at
>>>> >>>> >> >>> > > http://dev.xwiki.org/xwiki/bin/view/Community/Building.
>>>> >>>> >> >>> > >
>>>> >>>> >> >>> > >>
>>>> >>>> >> >>> > >>
>>>> >>>> >> >>> > >> Thank you
>>>> >>>> >> >>> > >> Best Regards.
>>>> >>>> >> >>> > >> Sasinda Rukshan
>>>> >>>> >> >>> > >> _______________________________________________
>>>> >>>> >> >>> > >> devs mailing list
>>>> >>>> >> >>> > >> [hidden email]
>>>> >>>> >> >>> > >> http://lists.xwiki.org/mailman/listinfo/devs
>>>> >>>> >> >>> > >
>>>> >>>> >> >>> > >
>>>> >>>> >> >>> > >
>>>> >>>> >> >>> > > --
>>>> >>>> >> >>> > > Thomas Mortagne
>>>> >>>> >> >>> > > _______________________________________________
>>>> >>>> >> >>> > > devs mailing list
>>>> >>>> >> >>> > > [hidden email]
>>>> >>>> >> >>> > > http://lists.xwiki.org/mailman/listinfo/devs
>>>> >>>> >> >>> >
>>>> >>>> >> >>> >
>>>> >>>> >> >>> >
>>>> >>>> >> >>> > --
>>>> >>>> >> >>> > Jérôme Velociter
>>>> >>>> >> >>> > Winesquare
>>>> >>>> >> >>> > http://www.winesquare.net/
>>>> >>>> >> >>> > _______________________________________________
>>>> >>>> >> >>> > devs mailing list
>>>> >>>> >> >>> > [hidden email]
>>>> >>>> >> >>> > http://lists.xwiki.org/mailman/listinfo/devs
>>>> >>>> >> >>> >
>>>> >>>> >> >>> _______________________________________________
>>>> >>>> >> >>> devs mailing list
>>>> >>>> >> >>> [hidden email]
>>>> >>>> >> >>> http://lists.xwiki.org/mailman/listinfo/devs
>>>> >>>> >> >>>
>>>> >>>> >> >>
>>>> >>>> >> >>
>>>> >>>> >> > _______________________________________________
>>>> >>>> >> > devs mailing list
>>>> >>>> >> > [hidden email]
>>>> >>>> >> > http://lists.xwiki.org/mailman/listinfo/devs
>>>> >>>> >>
>>>> >>>> >>
>>>> >>>> >>
>>>> >>>> >> --
>>>> >>>> >> Thomas Mortagne
>>>> >>>> >> _______________________________________________
>>>> >>>> >> devs mailing list
>>>> >>>> >> [hidden email]
>>>> >>>> >> http://lists.xwiki.org/mailman/listinfo/devs
>>>> >>>> >>
>>>> >>>> > _______________________________________________
>>>> >>>> > devs mailing list
>>>> >>>> > [hidden email]
>>>> >>>> > http://lists.xwiki.org/mailman/listinfo/devs
>>>> >>>>
>>>> >>>>
>>>> >>>>
>>>> >>>> --
>>>> >>>> Thomas Mortagne
>>>> >>>
>>>> >>>
>>>> >>
>>>> >>
>>>> >>
>>>> >> --
>>>> >> Thomas Mortagne
>>>> >
>>>> >
>>>> >
>>>> > --
>>>> > Thomas Mortagne
>>>>
>>>>
>>>>
>>>> --
>>>> Thomas Mortagne
>>>>
>>>
>>>
>>
> _______________________________________________
> devs mailing list
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs



--
Thomas Mortagne
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Fwd: [GSoc] XDroid Platform

sasinda
---------- Forwarded message ----------
From: sasinda rukshan <[hidden email]>
Date: Mon, Jun 18, 2012 at 2:56 PM
Subject: Re: [xwiki-devs] [GSoc] XDroid Platform
To: XWiki Developers <[hidden email]>


Hi Thomas,

Thanks for the explanations.
The methods toXML , toEmbedXML are wrong.It was just an idea that came up
without much thinking. I will use a separate model
converter.(xwikitTosimpleModelConverter implements ModelConverter like
thing). So the model objects don't know about it at all.
By what you ment by "user" I think it is the client app developer is it?
you did not mean end user. I never reveal the xml representations to end
users.

I came up with a simpler design. I will post diagram later tomorrow.
To give a brief on it,
XObject           : has protected property List<XProperty>
|__XPoperty  :<< all objects that can be added as a  property of an objects
should extend this. Has an attribute list. cancels the
|                         property list of XObject
|      |_____XString          :
|__Abstract XDocObject  :<< all documents should have an object of this.
This is the pages class. Has a object  List<XObject>
|       |____XBlog             :<< all documents which are blogs should
have a object of this. This determines the class of the object.
|                                          but this data is not posted
anywhere in <link rel="...../class"> . It is just kept for type checks.
That is like
|                                         this page should include
XBlogPost objects.
|__XBlogPost                   : <<the BlogPostClass object.

In my view I assume every page has an object of some class. And this object
holds the objects which you can get under .../pages/BlogPg1/objects/

[
an added advantage:
I think we can make a ViewEngine to generate android View components from
the above model. Since the objects in the page carry rendering
descriptions.We can make a general model like a browser to
brows xwiki using generated the views. But the problem is some features in
specific spaces like blog do not seem to be totally defined by the XWiki
Object model behind them. Also this is just an idea (not suggesting I do
for the GSoc).Making it a  usable reality is a little challenge.
]

So as you said if a document (I think it equivalent to a page) can have
many class types my assumption fails.
Why should a document be of multiple classes. I was thinking a page belongs
to a class. And the page is an instance of that class. If page can have
multiple classes my understanding should be wrong. Isn't it?

Thanks
Best Regards
Sasinda.




> >>>> >>>> > On Wed, May 30, 2012 at 1:11 PM, Thomas Mortagne
> >>>> >>>> > <[hidden email]>wrote:
> >>>> >>>> >
> >>>> >>>> >> On Wed, May 30, 2012 at 4:28 AM, sasinda rukshan
> >>>> >>>> >> <[hidden email]> wrote:
> >>>> >>>> >> > Hi,
> >>>> >>>> >> > I am studying ORM Lite these days.
> >>>> >>>> >> > Please It would be comforting if you can confirm whether it
> is
> >>>> worth
> >>>> >>>> >> > the
> >>>> >>>> >> > overhead to use ORM Lite.
> >>>> >>>> >> >
> >>>> >>>> >>
> >>>> >>>> >>
> >>>>
> http://logic-explained.blogspot.com/2011/12/using-ormlite-in-android-projects.html
> >>>> >>>> >> > http://ormlite.com/
> >>>> >>>> >> > ORM Lite features:
> >>>> >>>> >> > Automatically Creates standard DAOs for an annotated entity.
> >>>> >>>> >> > Coding will be lot easier.
> >>>> >>>> >>
> >>>> >>>> >> Remember it's a framework for a mobile platform so it has to
> >>>> remain
> >>>> >>>> >> light and have good performances. I can see that Android
> version
> >>>> of
> >>>> >>>> >> ormlite is very small but I never used it so I don't know if
> >>>> it's good
> >>>> >>>> >> or not. At least it seems petty active which is a good point
> so I
> >>>> >>>> >> don't have anything against it.
> >>>> >>>> >>
> >>>> >>>> >> >
> >>>> >>>> >> > Can you suggest how to name the entities.
> >>>> >>>> >> > I am going to go with,
> >>>> >>>> >> > <entity>  org.xwiki.xdroid.data.User  --> <table> C_USER
> >>>> >>>> >>
> >>>> >>>> >> Note that there is already a package name prefix and group id
> >>>> defined
> >>>> >>>> >> for the framework and it's org.xwiki.android as you can see on
> >>>> >>>> >> https://github.com/xwiki-contrib/android-client. Why do you
> >>>> want to
> >>>> >>>> >> change it ? It's more consistent with
> >>>> >>>> >> org.xwiki.commons/org.xwiki.rendering/org.xwiki.platform so I
> >>>> would
> >>>> >>>> >> prefer to keep it that way unless you can give arguments. The
> >>>> goal is
> >>>> >>>> >> not to redo something completely but complete and improve the
> >>>> existing
> >>>> >>>> >> framework.
> >>>> >>>> >>
> >>>> >>>> >> Also as far as I can see there is already several things
> called
> >>>> >>>> >> "xdroid" on Google play among which an application developer
> >>>> >>>> >> (https://play.google.com/store/apps/developer?id=x-droid)
> and an
> >>>> >>>> >> application (
> >>>> >>>> >>
> >>>> >>>> >>
> >>>>
> https://play.google.com/store/apps/details?id=com.gurudigitalsolutions.xdroid
> >>>> >>>> >> ).
> >>>> >>>> >>
> >>>> >>>> >> >
> >>>> >>>> >> > Thanks,
> >>>> >>>> >> > Best Regards
> >>>> >>>> >> >
> >>>> >>>> >> > Sasinda.
> >>>> >>>> >> >
> >>>> >>>> >> >
> >>>> >>>> >> >
> >>>> >>>> >> >
> >>>> >>>> >> >
> >>>> >>>> >> > On Wed, May 30, 2012 at 7:42 AM, sasinda rukshan
> >>>> >>>> >> > <[hidden email]>wrote:
> >>>> >>>> >> >
> >>>> >>>> >> >> Hi,
> >>>> >>>> >> >>
> >>>> >>>> >> >> I am commiting my work to my fork
> >>>> >>>> >> >> https://github.com/sasinda/android-client.
> >>>> >>>> >> >> I ll request to pull it to xwiki-contrib later.
> >>>> >>>> >> >>
> >>>> >>>> >> >> I was running in a wrong path these days. Wanted to save
> login
> >>>> >>>> >> >> history
> >>>> >>>> >> and
> >>>> >>>> >> >> suggest login. I was going to do it using an xml file
> (login
> >>>> >>>> >> attempts.xml).
> >>>> >>>> >> >> Now it seems database is better.
> >>>> >>>> >> >> Any way before I go wrong again I will say what I am going
> to
> >>>> do.
> >>>> >>>> >> >> I am going to enforce following conventions.These are not
> yet
> >>>> >>>> >> >> needed,
> >>>> >>>> >> >> considered the small scale.But when the system grows it
> would
> >>>> be
> >>>> >>>> >> >> nice to
> >>>> >>>> >> >> have them to avoid confusions.
> >>>> >>>> >> >> *Database prefixes for:*
> >>>> >>>> >> >> *Platform tables (can begin with appropriate prefix)*
> >>>> >>>> >> >> AD_ //application dictionary : don't know when it will be
> >>>> needed ;-)
> >>>> >>>> >> >> C_ //core functionality
> >>>> >>>> >> >> *Client Applications.*
> >>>> >>>> >> >> X<App name prefix>  ex: XBLOG_   for Blog app// All client
> >>>> add in
> >>>> >>>> >> modules
> >>>> >>>> >> >> must begin with table prefix X(for xwiki and ordering) +
> App
> >>>> name.
> >>>> >>>> >>  This is
> >>>> >>>> >> >> for my blog.
> >>>> >>>> >> >>
> >>>> >>>> >> >> I will create
> >>>> >>>> >> >> C_User for user data.
> >>>> >>>> >> >> C_LoginAttempt  for saving login attempts.
> >>>> >>>> >> >>
> >>>> >>>> >> >> From C_LoginAttempt I can filter uniqe login combinations
> and
> >>>> give
> >>>> >>>> >> >> suggestions in the login UI component. Also save the
> history.
> >>>> >>>> >> >>
> >>>> >>>> >> >> All saved data for blog app will be linked to a perticular
> >>>> login :
> >>>> >>>> >> >> User,
> >>>> >>>> >> >> XWiki server.
> >>>> >>>> >> >> But only a single user will be most probably using his
> >>>> personal
> >>>> >>>> >> >> device.
> >>>> >>>> >> So
> >>>> >>>> >> >> above will be relevant only when he has multiple wikis.
> >>>> >>>> >> >>
> >>>> >>>> >> >> Best Regards,
> >>>> >>>> >> >> Sasinda Rukshan.
> >>>> >>>> >> >>
> >>>> >>>> >> >>
> >>>> >>>> >> >>
> >>>> >>>> >> >>
> >>>> >>>> >> >>
> >>>> >>>> >> >> On Sun, May 27, 2012 at 5:43 PM, Chamika Weerasinghe <
> >>>> >>>> >> [hidden email]>wrote:
> >>>> >>>> >> >>
> >>>> >>>> >> >>> On Fri, May 25, 2012 at 1:25 AM, Jerome Velociter <
> >>>> >>>> >> [hidden email]
> >>>> >>>> >> >>> >wrote:
> >>>> >>>> >> >>>
> >>>> >>>> >> >>> > On Thu, May 24, 2012 at 6:09 PM, Thomas Mortagne
> >>>> >>>> >> >>> > <[hidden email]> wrote:
> >>>> >>>> >> >>> > > On Thu, May 24, 2012 at 5:52 PM, sasinda rukshan
> >>>> >>>> >> >>> > > <[hidden email]> wrote:
> >>>> >>>> >> >>> > >> Hi all,
> >>>> >>>> >> >>> > >> I am starting this thread for my XWiki Android
> Platform
> >>>> >>>> >> >>> > >> Project.
> >>>> >>>> >> >>> > >>
> >>>> >>>> >> >>> > >> Please check whether following are OK.
> >>>> >>>> >> >>> > >> [1] INFO
> >>>> >>>> >> >>> > >> I tried to start my new modules with the
> >>>> >>>> >> >>> de.akquinet.android.archetypes:
> >>>> >>>> >> >>> > >> android-quickstart:1.0.8.  (added eclipse plugins
> m2e,
> >>>> >>>> >> >>> > >> m2e-android[a.k.a  *Android
> >>>> >>>> >> >>> > >> Configurator* ]). But this seems buggy in eclipse.
> >>>> >>>> >> >>> > >> Any way the earlier project has not followed the
> above
> >>>> >>>> >> >>> > >> archtype
> >>>> >>>> >> >>> either.
> >>>> >>>> >> >>> > So
> >>>> >>>> >> >>> > >> I am going to write pom.xml manually for my each
> module.
> >>>> >>>> >> >>> > >>
> >>>> >>>> >> >>> > >> [2] ADVICE NEEDED
> >>>> >>>> >> >>> > >> xwiki-rest-model module contains 2 submodules
> >>>> >>>> >> >>> > >>  |-- xwiki-rest-model-gson  ( gson should be
> corrected
> >>>> to
> >>>> >>>> >> >>> > >> json)
> >>>> >>>> >> >>> > >
> >>>> >>>> >> >>> > > No the g is not a mistake, it's a model to be used
> with
> >>>> the
> >>>> >>>> >> >>> > > gson
> >>>> >>>> >> >>> > > library (http://code.google.com/p/google-gson/). See
> >>>> >>>> >> >>> > >
> >>>> >>>> >> >>> >
> >>>> >>>> >> >>>
> >>>> >>>> >>
> >>>> >>>> >>
> >>>>
> http://extensions.xwiki.org/xwiki/bin/view/Extension/Google+Android+Client#HXWikiAndroidDevelopmentAPIsandResources
> >>>> >>>> >> >>> > .
> >>>> >>>> >> >>> > >
> >>>> >>>> >> >>> > >>  |-- xwiki-rest-model-simplexml
> >>>> >>>> >> >>> > >> I think the xwiki-rest-model-gson is redundant. The
> >>>> classes
> >>>> >>>> >> >>> > >> in xwiki-rest-model-simplexml is added with simple
> xml
> >>>> >>>> >> annotations,
> >>>> >>>> >> >>> > >> otherwise both modules have same classes. There is no
> >>>> problem
> >>>> >>>> >> >>> > >> with
> >>>> >>>> >> >>> the
> >>>> >>>> >> >>> > >> added annotations for using the same model objects
> for
> >>>> Json
> >>>> >>>> >> >>> > >> REST
> >>>> >>>> >> web
> >>>> >>>> >> >>> > >> services. And I intend to add my JPA (ORMLite library
> >>>> for
> >>>> >>>> >> >>> persistence)
> >>>> >>>> >> >>> > >> annotations on top of it.
> >>>> >>>> >> >>> > >> Shall I re-factor them to a single module
> >>>> xwiki-rest-model.
> >>>> >>>> >> >>> > >
> >>>> >>>> >> >>> > > No keep them separated, the idea is that both are
> useful
> >>>> tool
> >>>> >>>> >> >>> > > to be
> >>>> >>>> >> >>> > > used by someone else that might be moved to
> >>>> xwiki-platform at
> >>>> >>>> >> >>> > > some
> >>>> >>>> >> >>> > > point along with the current xwiki-rest-model (to be
> >>>> renamed to
> >>>> >>>> >> >>> > > xwiki-rest-model-jaxb).
> >>>> >>>> >> >>> > >
> >>>> >>>> >> >>> > > Chamika initially started with gson and since XWiki
> REST
> >>>> JSON
> >>>> >>>> >> >>> > > representation had some limitation he moved to XML
> >>>> >>>> >> >>> > > representation.
> >>>> >>>> >> >>> > > Maybe at some point Android will have native support
> for
> >>>> jaxb
> >>>> >>>> >> >>> > > which
> >>>> >>>> >> >>> > > would obviously be the easier for us (embedding jaxb
> is
> >>>> not an
> >>>> >>>> >> option
> >>>> >>>> >> >>> > > in mobile world where size it still pretty important
> >>>> especially
> >>>> >>>> >> >>> > > on
> >>>> >>>> >> >>> > > phones). Maybe it's already the case on most recent
> >>>> versions
> >>>> >>>> >> >>> > > like
> >>>> >>>> >> 4.0
> >>>> >>>> >> >>> > > I don't know.
> >>>> >>>> >> >>> >
> >>>> >>>> >> >>> > There's also Jackson that could be tried for JSON
> >>>> >>>> >> >>> > deserialization, if
> >>>> >>>> >> >>> > said limitations are actually GSON limitations.
> >>>> >>>> >> >>> >
> >>>> >>>> >> >>> GSON wasn't the limitation.
> >>>> >>>> >> >>> It was XWiki RESTful API which doesn't support JSON in
> some
> >>>> cases.
> >>>> >>>> >> >>> So
> >>>> >>>> >> it's
> >>>> >>>> >> >>> safe to go with xml.
> >>>> >>>> >> >>>
> >>>> >>>> >> >>> >
> >>>> >>>> >> >>> > Having full JAXB support sound a bit overweight for
> such an
> >>>> >>>> >> >>> > "embedded
> >>>> >>>> >> >>> > API", even if one day it is natively supported by
> Android.
> >>>> What's
> >>>> >>>> >> >>> > important is to have an easy and fast deserialization,
> IMO.
> >>>> >>>> >> >>> > The only advantage I can see of going JAXB would be in
> >>>> re-using
> >>>> >>>> >> >>> > the
> >>>> >>>> >> >>> > exact representations and body readers/writers from
> XWiki
> >>>> core.
> >>>> >>>> >> >>> > But
> >>>> >>>> >> >>> > you probably don't even want to do that since it would
> mean
> >>>> >>>> >> >>> > dragging
> >>>> >>>> >> >>> > XWiki core with you :)
> >>>> >>>> >> >>> >
> >>>> >>>> >> >>> > Jerome
> >>>> >>>> >> >>> >
> >>>> >>>> >> >>> > >
> >>>> >>>> >> >>> > >>
> >>>> >>>> >> >>> > >> [3] INFO
> >>>> >>>> >> >>> > >>  I had to change some pom.xml s. As the current
> project
> >>>> at:
> >>>> >>>> >> >>> > >>
> https://github.com/xwiki-contrib/android-client.gitdoes not
> >>>> >>>> >> build.
> >>>> >>>> >> >>> > Error
> >>>> >>>> >> >>> > >> with parent pom.xml coordinates.
> >>>> >>>> >> >>> > >
> >>>> >>>> >> >>> > > You probably did not setup you maven install properly
> >>>> since
> >>>> >>>> >> >>> > > what's
> >>>> >>>> >> on
> >>>> >>>> >> >>> > >
> https://github.com/xwiki-contrib/android-client.gitbuild
> >>>> >>>> >> perfectly
> >>>> >>>> >> >>> as
> >>>> >>>> >> >>> > > you can see on
> >>>> >>>> >> http://ci.xwiki.org/view/All/job/xwiki-android-client/
> >>>> >>>> >> >>> > > which run a build every time something changes on the
> git
> >>>> >>>> >> repository..
> >>>> >>>> >> >>> > > You should look at
> >>>> >>>> >> >>> > >
> http://dev.xwiki.org/xwiki/bin/view/Community/Building.
> >>>> >>>> >> >>> > >
> >>>> >>>> >> >>> > >>
> >>>> >>>> >> >>> > >>
> >>>> >>>> >> >>> > >> Thank you
> >>>> >>>> >> >>> > >> Best Regards.
> >>>> >>>> >> >>> > >> Sasinda Rukshan
> >>>> >>>> >> >>> > >> _______________________________________________
> >>>> >>>> >> >>> > >> devs mailing list
> >>>> >>>> >> >>> > >> [hidden email]
> >>>> >>>> >> >>> > >> http://lists.xwiki.org/mailman/listinfo/devs
> >>>> >>>> >> >>> > >
> >>>> >>>> >> >>> > >
> >>>> >>>> >> >>> > >
> >>>> >>>> >> >>> > > --
> >>>> >>>> >> >>> > > Thomas Mortagne
> >>>> >>>> >> >>> > > _______________________________________________
> >>>> >>>> >> >>> > > devs mailing list
> >>>> >>>> >> >>> > > [hidden email]
> >>>> >>>> >> >>> > > http://lists.xwiki.org/mailman/listinfo/devs
> >>>> >>>> >> >>> >
> >>>> >>>> >> >>> >
> >>>> >>>> >> >>> >
> >>>> >>>> >> >>> > --
> >>>> >>>> >> >>> > Jérôme Velociter
> >>>> >>>> >> >>> > Winesquare
> >>>> >>>> >> >>> > http://www.winesquare.net/
> >>>> >>>> >> >>> > _______________________________________________
> >>>> >>>> >> >>> > devs mailing list
> >>>> >>>> >> >>> > [hidden email]
> >>>> >>>> >> >>> > http://lists.xwiki.org/mailman/listinfo/devs
> >>>> >>>> >> >>> >
> >>>> >>>> >> >>> _______________________________________________
> >>>> >>>> >> >>> devs mailing list
> >>>> >>>> >> >>> [hidden email]
> >>>> >>>> >> >>> http://lists.xwiki.org/mailman/listinfo/devs
> >>>> >>>> >> >>>
> >>>> >>>> >> >>
> >>>> >>>> >> >>
> >>>> >>>> >> > _______________________________________________
> >>>> >>>> >> > devs mailing list
> >>>> >>>> >> > [hidden email]
> >>>> >>>> >> > http://lists.xwiki.org/mailman/listinfo/devs
> >>>> >>>> >>
> >>>> >>>> >>
> >>>> >>>> >>
> >>>> >>>> >> --
> >>>> >>>> >> Thomas Mortagne
> >>>> >>>> >> _______________________________________________
> >>>> >>>> >> devs mailing list
> >>>> >>>> >> [hidden email]
> >>>> >>>> >> http://lists.xwiki.org/mailman/listinfo/devs
> >>>> >>>> >>
> >>>> >>>> > _______________________________________________
> >>>> >>>> > devs mailing list
> >>>> >>>> > [hidden email]
> >>>> >>>> > http://lists.xwiki.org/mailman/listinfo/devs
> >>>> >>>>
> >>>> >>>>
> >>>> >>>>
> >>>> >>>> --
> >>>> >>>> Thomas Mortagne
> >>>> >>>
> >>>> >>>
> >>>> >>
> >>>> >>
> >>>> >>
> >>>> >> --
> >>>> >> Thomas Mortagne
> >>>> >
> >>>> >
> >>>> >
> >>>> > --
> >>>> > Thomas Mortagne
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> Thomas Mortagne
> >>>>
> >>>
> >>>
> >>
> > _______________________________________________
> > devs mailing list
> > [hidden email]
> > http://lists.xwiki.org/mailman/listinfo/devs
>
>
>
> --
> Thomas Mortagne
>
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: [GSoc] XDroid Platform

Thomas Mortagne
Administrator
On Mon, Jun 18, 2012 at 11:30 AM, sasinda rukshan
<[hidden email]> wrote:

> ---------- Forwarded message ----------
> From: sasinda rukshan <[hidden email]>
> Date: Mon, Jun 18, 2012 at 2:56 PM
> Subject: Re: [xwiki-devs] [GSoc] XDroid Platform
> To: XWiki Developers <[hidden email]>
>
>
> Hi Thomas,
>
> Thanks for the explanations.
> The methods toXML , toEmbedXML are wrong.It was just an idea that came up
> without much thinking. I will use a separate model
> converter.(xwikitTosimpleModelConverter implements ModelConverter like
> thing). So the model objects don't know about it at all.
> By what you ment by "user" I think it is the client app developer is it?

Yes I mean the user of the API.

> you did not mean end user. I never reveal the xml representations to end
> users.
>
> I came up with a simpler design. I will post diagram later tomorrow.

Ok, this ASCII art here is not very easy to read ;)

> To give a brief on it,
> XObject           : has protected property List<XProperty>

A Map<XProperty> would probably make more sense here since each
property as a unique name in an object and you will need to set some
specific property very often.

> |__XPoperty  :<< all objects that can be added as a  property of an objects
> should extend this. Has an attribute list. cancels the
> |                         property list of XObject
> |      |_____XString          :
> |__Abstract XDocObject  :<< all documents should have an object of this.
> This is the pages class. Has a object  List<XObject>
> |       |____XBlog             :<< all documents which are blogs should
> have a object of this. This determines the class of the object.
> |                                          but this data is not posted
> anywhere in <link rel="...../class"> . It is just kept for type checks.
> That is like
> |                                         this page should include
> XBlogPost objects.
> |__XBlogPost                   : <<the BlogPostClass object.
>
> In my view I assume every page has an object of some class. And this object
> holds the objects which you can get under .../pages/BlogPg1/objects/

Well not exactly, you don't always have an object. A document can be
just about content. Just a wiki page if you prefer.

>
> [
> an added advantage:
> I think we can make a ViewEngine to generate android View components from
> the above model. Since the objects in the page carry rendering
> descriptions.We can make a general model like a browser to
> brows xwiki using generated the views. But the problem is some features in
> specific spaces like blog do not seem to be totally defined by the XWiki
> Object model behind them. Also this is just an idea (not suggesting I do
> for the GSoc).Making it a  usable reality is a little challenge.
> ]
>
> So as you said if a document (I think it equivalent to a page) can have
> many class types my assumption fails.
> Why should a document be of multiple classes. I was thinking a page belongs
> to a class. And the page is an instance of that class. If page can have
> multiple classes my understanding should be wrong. Isn't it?

I don't understand, what I said is that you can only have one class in
a document but you can have several objects.

>
> Thanks
> Best Regards
> Sasinda.
>
>
>
>
>> >>>> >>>> > On Wed, May 30, 2012 at 1:11 PM, Thomas Mortagne
>> >>>> >>>> > <[hidden email]>wrote:
>> >>>> >>>> >
>> >>>> >>>> >> On Wed, May 30, 2012 at 4:28 AM, sasinda rukshan
>> >>>> >>>> >> <[hidden email]> wrote:
>> >>>> >>>> >> > Hi,
>> >>>> >>>> >> > I am studying ORM Lite these days.
>> >>>> >>>> >> > Please It would be comforting if you can confirm whether it
>> is
>> >>>> worth
>> >>>> >>>> >> > the
>> >>>> >>>> >> > overhead to use ORM Lite.
>> >>>> >>>> >> >
>> >>>> >>>> >>
>> >>>> >>>> >>
>> >>>>
>> http://logic-explained.blogspot.com/2011/12/using-ormlite-in-android-projects.html
>> >>>> >>>> >> > http://ormlite.com/
>> >>>> >>>> >> > ORM Lite features:
>> >>>> >>>> >> > Automatically Creates standard DAOs for an annotated entity.
>> >>>> >>>> >> > Coding will be lot easier.
>> >>>> >>>> >>
>> >>>> >>>> >> Remember it's a framework for a mobile platform so it has to
>> >>>> remain
>> >>>> >>>> >> light and have good performances. I can see that Android
>> version
>> >>>> of
>> >>>> >>>> >> ormlite is very small but I never used it so I don't know if
>> >>>> it's good
>> >>>> >>>> >> or not. At least it seems petty active which is a good point
>> so I
>> >>>> >>>> >> don't have anything against it.
>> >>>> >>>> >>
>> >>>> >>>> >> >
>> >>>> >>>> >> > Can you suggest how to name the entities.
>> >>>> >>>> >> > I am going to go with,
>> >>>> >>>> >> > <entity>  org.xwiki.xdroid.data.User  --> <table> C_USER
>> >>>> >>>> >>
>> >>>> >>>> >> Note that there is already a package name prefix and group id
>> >>>> defined
>> >>>> >>>> >> for the framework and it's org.xwiki.android as you can see on
>> >>>> >>>> >> https://github.com/xwiki-contrib/android-client. Why do you
>> >>>> want to
>> >>>> >>>> >> change it ? It's more consistent with
>> >>>> >>>> >> org.xwiki.commons/org.xwiki.rendering/org.xwiki.platform so I
>> >>>> would
>> >>>> >>>> >> prefer to keep it that way unless you can give arguments. The
>> >>>> goal is
>> >>>> >>>> >> not to redo something completely but complete and improve the
>> >>>> existing
>> >>>> >>>> >> framework.
>> >>>> >>>> >>
>> >>>> >>>> >> Also as far as I can see there is already several things
>> called
>> >>>> >>>> >> "xdroid" on Google play among which an application developer
>> >>>> >>>> >> (https://play.google.com/store/apps/developer?id=x-droid)
>> and an
>> >>>> >>>> >> application (
>> >>>> >>>> >>
>> >>>> >>>> >>
>> >>>>
>> https://play.google.com/store/apps/details?id=com.gurudigitalsolutions.xdroid
>> >>>> >>>> >> ).
>> >>>> >>>> >>
>> >>>> >>>> >> >
>> >>>> >>>> >> > Thanks,
>> >>>> >>>> >> > Best Regards
>> >>>> >>>> >> >
>> >>>> >>>> >> > Sasinda.
>> >>>> >>>> >> >
>> >>>> >>>> >> >
>> >>>> >>>> >> >
>> >>>> >>>> >> >
>> >>>> >>>> >> >
>> >>>> >>>> >> > On Wed, May 30, 2012 at 7:42 AM, sasinda rukshan
>> >>>> >>>> >> > <[hidden email]>wrote:
>> >>>> >>>> >> >
>> >>>> >>>> >> >> Hi,
>> >>>> >>>> >> >>
>> >>>> >>>> >> >> I am commiting my work to my fork
>> >>>> >>>> >> >> https://github.com/sasinda/android-client.
>> >>>> >>>> >> >> I ll request to pull it to xwiki-contrib later.
>> >>>> >>>> >> >>
>> >>>> >>>> >> >> I was running in a wrong path these days. Wanted to save
>> login
>> >>>> >>>> >> >> history
>> >>>> >>>> >> and
>> >>>> >>>> >> >> suggest login. I was going to do it using an xml file
>> (login
>> >>>> >>>> >> attempts.xml).
>> >>>> >>>> >> >> Now it seems database is better.
>> >>>> >>>> >> >> Any way before I go wrong again I will say what I am going
>> to
>> >>>> do.
>> >>>> >>>> >> >> I am going to enforce following conventions.These are not
>> yet
>> >>>> >>>> >> >> needed,
>> >>>> >>>> >> >> considered the small scale.But when the system grows it
>> would
>> >>>> be
>> >>>> >>>> >> >> nice to
>> >>>> >>>> >> >> have them to avoid confusions.
>> >>>> >>>> >> >> *Database prefixes for:*
>> >>>> >>>> >> >> *Platform tables (can begin with appropriate prefix)*
>> >>>> >>>> >> >> AD_ //application dictionary : don't know when it will be
>> >>>> needed ;-)
>> >>>> >>>> >> >> C_ //core functionality
>> >>>> >>>> >> >> *Client Applications.*
>> >>>> >>>> >> >> X<App name prefix>  ex: XBLOG_   for Blog app// All client
>> >>>> add in
>> >>>> >>>> >> modules
>> >>>> >>>> >> >> must begin with table prefix X(for xwiki and ordering) +
>> App
>> >>>> name.
>> >>>> >>>> >>  This is
>> >>>> >>>> >> >> for my blog.
>> >>>> >>>> >> >>
>> >>>> >>>> >> >> I will create
>> >>>> >>>> >> >> C_User for user data.
>> >>>> >>>> >> >> C_LoginAttempt  for saving login attempts.
>> >>>> >>>> >> >>
>> >>>> >>>> >> >> From C_LoginAttempt I can filter uniqe login combinations
>> and
>> >>>> give
>> >>>> >>>> >> >> suggestions in the login UI component. Also save the
>> history.
>> >>>> >>>> >> >>
>> >>>> >>>> >> >> All saved data for blog app will be linked to a perticular
>> >>>> login :
>> >>>> >>>> >> >> User,
>> >>>> >>>> >> >> XWiki server.
>> >>>> >>>> >> >> But only a single user will be most probably using his
>> >>>> personal
>> >>>> >>>> >> >> device.
>> >>>> >>>> >> So
>> >>>> >>>> >> >> above will be relevant only when he has multiple wikis.
>> >>>> >>>> >> >>
>> >>>> >>>> >> >> Best Regards,
>> >>>> >>>> >> >> Sasinda Rukshan.
>> >>>> >>>> >> >>
>> >>>> >>>> >> >>
>> >>>> >>>> >> >>
>> >>>> >>>> >> >>
>> >>>> >>>> >> >>
>> >>>> >>>> >> >> On Sun, May 27, 2012 at 5:43 PM, Chamika Weerasinghe <
>> >>>> >>>> >> [hidden email]>wrote:
>> >>>> >>>> >> >>
>> >>>> >>>> >> >>> On Fri, May 25, 2012 at 1:25 AM, Jerome Velociter <
>> >>>> >>>> >> [hidden email]
>> >>>> >>>> >> >>> >wrote:
>> >>>> >>>> >> >>>
>> >>>> >>>> >> >>> > On Thu, May 24, 2012 at 6:09 PM, Thomas Mortagne
>> >>>> >>>> >> >>> > <[hidden email]> wrote:
>> >>>> >>>> >> >>> > > On Thu, May 24, 2012 at 5:52 PM, sasinda rukshan
>> >>>> >>>> >> >>> > > <[hidden email]> wrote:
>> >>>> >>>> >> >>> > >> Hi all,
>> >>>> >>>> >> >>> > >> I am starting this thread for my XWiki Android
>> Platform
>> >>>> >>>> >> >>> > >> Project.
>> >>>> >>>> >> >>> > >>
>> >>>> >>>> >> >>> > >> Please check whether following are OK.
>> >>>> >>>> >> >>> > >> [1] INFO
>> >>>> >>>> >> >>> > >> I tried to start my new modules with the
>> >>>> >>>> >> >>> de.akquinet.android.archetypes:
>> >>>> >>>> >> >>> > >> android-quickstart:1.0.8.  (added eclipse plugins
>> m2e,
>> >>>> >>>> >> >>> > >> m2e-android[a.k.a  *Android
>> >>>> >>>> >> >>> > >> Configurator* ]). But this seems buggy in eclipse.
>> >>>> >>>> >> >>> > >> Any way the earlier project has not followed the
>> above
>> >>>> >>>> >> >>> > >> archtype
>> >>>> >>>> >> >>> either.
>> >>>> >>>> >> >>> > So
>> >>>> >>>> >> >>> > >> I am going to write pom.xml manually for my each
>> module.
>> >>>> >>>> >> >>> > >>
>> >>>> >>>> >> >>> > >> [2] ADVICE NEEDED
>> >>>> >>>> >> >>> > >> xwiki-rest-model module contains 2 submodules
>> >>>> >>>> >> >>> > >>  |-- xwiki-rest-model-gson  ( gson should be
>> corrected
>> >>>> to
>> >>>> >>>> >> >>> > >> json)
>> >>>> >>>> >> >>> > >
>> >>>> >>>> >> >>> > > No the g is not a mistake, it's a model to be used
>> with
>> >>>> the
>> >>>> >>>> >> >>> > > gson
>> >>>> >>>> >> >>> > > library (http://code.google.com/p/google-gson/). See
>> >>>> >>>> >> >>> > >
>> >>>> >>>> >> >>> >
>> >>>> >>>> >> >>>
>> >>>> >>>> >>
>> >>>> >>>> >>
>> >>>>
>> http://extensions.xwiki.org/xwiki/bin/view/Extension/Google+Android+Client#HXWikiAndroidDevelopmentAPIsandResources
>> >>>> >>>> >> >>> > .
>> >>>> >>>> >> >>> > >
>> >>>> >>>> >> >>> > >>  |-- xwiki-rest-model-simplexml
>> >>>> >>>> >> >>> > >> I think the xwiki-rest-model-gson is redundant. The
>> >>>> classes
>> >>>> >>>> >> >>> > >> in xwiki-rest-model-simplexml is added with simple
>> xml
>> >>>> >>>> >> annotations,
>> >>>> >>>> >> >>> > >> otherwise both modules have same classes. There is no
>> >>>> problem
>> >>>> >>>> >> >>> > >> with
>> >>>> >>>> >> >>> the
>> >>>> >>>> >> >>> > >> added annotations for using the same model objects
>> for
>> >>>> Json
>> >>>> >>>> >> >>> > >> REST
>> >>>> >>>> >> web
>> >>>> >>>> >> >>> > >> services. And I intend to add my JPA (ORMLite library
>> >>>> for
>> >>>> >>>> >> >>> persistence)
>> >>>> >>>> >> >>> > >> annotations on top of it.
>> >>>> >>>> >> >>> > >> Shall I re-factor them to a single module
>> >>>> xwiki-rest-model.
>> >>>> >>>> >> >>> > >
>> >>>> >>>> >> >>> > > No keep them separated, the idea is that both are
>> useful
>> >>>> tool
>> >>>> >>>> >> >>> > > to be
>> >>>> >>>> >> >>> > > used by someone else that might be moved to
>> >>>> xwiki-platform at
>> >>>> >>>> >> >>> > > some
>> >>>> >>>> >> >>> > > point along with the current xwiki-rest-model (to be
>> >>>> renamed to
>> >>>> >>>> >> >>> > > xwiki-rest-model-jaxb).
>> >>>> >>>> >> >>> > >
>> >>>> >>>> >> >>> > > Chamika initially started with gson and since XWiki
>> REST
>> >>>> JSON
>> >>>> >>>> >> >>> > > representation had some limitation he moved to XML
>> >>>> >>>> >> >>> > > representation.
>> >>>> >>>> >> >>> > > Maybe at some point Android will have native support
>> for
>> >>>> jaxb
>> >>>> >>>> >> >>> > > which
>> >>>> >>>> >> >>> > > would obviously be the easier for us (embedding jaxb
>> is
>> >>>> not an
>> >>>> >>>> >> option
>> >>>> >>>> >> >>> > > in mobile world where size it still pretty important
>> >>>> especially
>> >>>> >>>> >> >>> > > on
>> >>>> >>>> >> >>> > > phones). Maybe it's already the case on most recent
>> >>>> versions
>> >>>> >>>> >> >>> > > like
>> >>>> >>>> >> 4.0
>> >>>> >>>> >> >>> > > I don't know.
>> >>>> >>>> >> >>> >
>> >>>> >>>> >> >>> > There's also Jackson that could be tried for JSON
>> >>>> >>>> >> >>> > deserialization, if
>> >>>> >>>> >> >>> > said limitations are actually GSON limitations.
>> >>>> >>>> >> >>> >
>> >>>> >>>> >> >>> GSON wasn't the limitation.
>> >>>> >>>> >> >>> It was XWiki RESTful API which doesn't support JSON in
>> some
>> >>>> cases.
>> >>>> >>>> >> >>> So
>> >>>> >>>> >> it's
>> >>>> >>>> >> >>> safe to go with xml.
>> >>>> >>>> >> >>>
>> >>>> >>>> >> >>> >
>> >>>> >>>> >> >>> > Having full JAXB support sound a bit overweight for
>> such an
>> >>>> >>>> >> >>> > "embedded
>> >>>> >>>> >> >>> > API", even if one day it is natively supported by
>> Android.
>> >>>> What's
>> >>>> >>>> >> >>> > important is to have an easy and fast deserialization,
>> IMO.
>> >>>> >>>> >> >>> > The only advantage I can see of going JAXB would be in
>> >>>> re-using
>> >>>> >>>> >> >>> > the
>> >>>> >>>> >> >>> > exact representations and body readers/writers from
>> XWiki
>> >>>> core.
>> >>>> >>>> >> >>> > But
>> >>>> >>>> >> >>> > you probably don't even want to do that since it would
>> mean
>> >>>> >>>> >> >>> > dragging
>> >>>> >>>> >> >>> > XWiki core with you :)
>> >>>> >>>> >> >>> >
>> >>>> >>>> >> >>> > Jerome
>> >>>> >>>> >> >>> >
>> >>>> >>>> >> >>> > >
>> >>>> >>>> >> >>> > >>
>> >>>> >>>> >> >>> > >> [3] INFO
>> >>>> >>>> >> >>> > >>  I had to change some pom.xml s. As the current
>> project
>> >>>> at:
>> >>>> >>>> >> >>> > >>
>> https://github.com/xwiki-contrib/android-client.gitdoes not
>> >>>> >>>> >> build.
>> >>>> >>>> >> >>> > Error
>> >>>> >>>> >> >>> > >> with parent pom.xml coordinates.
>> >>>> >>>> >> >>> > >
>> >>>> >>>> >> >>> > > You probably did not setup you maven install properly
>> >>>> since
>> >>>> >>>> >> >>> > > what's
>> >>>> >>>> >> on
>> >>>> >>>> >> >>> > >
>> https://github.com/xwiki-contrib/android-client.gitbuild
>> >>>> >>>> >> perfectly
>> >>>> >>>> >> >>> as
>> >>>> >>>> >> >>> > > you can see on
>> >>>> >>>> >> http://ci.xwiki.org/view/All/job/xwiki-android-client/
>> >>>> >>>> >> >>> > > which run a build every time something changes on the
>> git
>> >>>> >>>> >> repository..
>> >>>> >>>> >> >>> > > You should look at
>> >>>> >>>> >> >>> > >
>> http://dev.xwiki.org/xwiki/bin/view/Community/Building.
>> >>>> >>>> >> >>> > >
>> >>>> >>>> >> >>> > >>
>> >>>> >>>> >> >>> > >>
>> >>>> >>>> >> >>> > >> Thank you
>> >>>> >>>> >> >>> > >> Best Regards.
>> >>>> >>>> >> >>> > >> Sasinda Rukshan
>> >>>> >>>> >> >>> > >> _______________________________________________
>> >>>> >>>> >> >>> > >> devs mailing list
>> >>>> >>>> >> >>> > >> [hidden email]
>> >>>> >>>> >> >>> > >> http://lists.xwiki.org/mailman/listinfo/devs
>> >>>> >>>> >> >>> > >
>> >>>> >>>> >> >>> > >
>> >>>> >>>> >> >>> > >
>> >>>> >>>> >> >>> > > --
>> >>>> >>>> >> >>> > > Thomas Mortagne
>> >>>> >>>> >> >>> > > _______________________________________________
>> >>>> >>>> >> >>> > > devs mailing list
>> >>>> >>>> >> >>> > > [hidden email]
>> >>>> >>>> >> >>> > > http://lists.xwiki.org/mailman/listinfo/devs
>> >>>> >>>> >> >>> >
>> >>>> >>>> >> >>> >
>> >>>> >>>> >> >>> >
>> >>>> >>>> >> >>> > --
>> >>>> >>>> >> >>> > Jérôme Velociter
>> >>>> >>>> >> >>> > Winesquare
>> >>>> >>>> >> >>> > http://www.winesquare.net/
>> >>>> >>>> >> >>> > _______________________________________________
>> >>>> >>>> >> >>> > devs mailing list
>> >>>> >>>> >> >>> > [hidden email]
>> >>>> >>>> >> >>> > http://lists.xwiki.org/mailman/listinfo/devs
>> >>>> >>>> >> >>> >
>> >>>> >>>> >> >>> _______________________________________________
>> >>>> >>>> >> >>> devs mailing list
>> >>>> >>>> >> >>> [hidden email]
>> >>>> >>>> >> >>> http://lists.xwiki.org/mailman/listinfo/devs
>> >>>> >>>> >> >>>
>> >>>> >>>> >> >>
>> >>>> >>>> >> >>
>> >>>> >>>> >> > _______________________________________________
>> >>>> >>>> >> > devs mailing list
>> >>>> >>>> >> > [hidden email]
>> >>>> >>>> >> > http://lists.xwiki.org/mailman/listinfo/devs
>> >>>> >>>> >>
>> >>>> >>>> >>
>> >>>> >>>> >>
>> >>>> >>>> >> --
>> >>>> >>>> >> Thomas Mortagne
>> >>>> >>>> >> _______________________________________________
>> >>>> >>>> >> devs mailing list
>> >>>> >>>> >> [hidden email]
>> >>>> >>>> >> http://lists.xwiki.org/mailman/listinfo/devs
>> >>>> >>>> >>
>> >>>> >>>> > _______________________________________________
>> >>>> >>>> > devs mailing list
>> >>>> >>>> > [hidden email]
>> >>>> >>>> > http://lists.xwiki.org/mailman/listinfo/devs
>> >>>> >>>>
>> >>>> >>>>
>> >>>> >>>>
>> >>>> >>>> --
>> >>>> >>>> Thomas Mortagne
>> >>>> >>>
>> >>>> >>>
>> >>>> >>
>> >>>> >>
>> >>>> >>
>> >>>> >> --
>> >>>> >> Thomas Mortagne
>> >>>> >
>> >>>> >
>> >>>> >
>> >>>> > --
>> >>>> > Thomas Mortagne
>> >>>>
>> >>>>
>> >>>>
>> >>>> --
>> >>>> Thomas Mortagne
>> >>>>
>> >>>
>> >>>
>> >>
>> > _______________________________________________
>> > devs mailing list
>> > [hidden email]
>> > http://lists.xwiki.org/mailman/listinfo/devs
>>
>>
>>
>> --
>> Thomas Mortagne
>>
> _______________________________________________
> devs mailing list
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs



--
Thomas Mortagne
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Fwd: Fwd: [GSoc] XDroid Platform

sasinda
Hi Thomas,

Oops sorry,
> I don't understand, what I said is that you can only have one class in
> a document but you can have several objects

I was busy with some office work also. Just skimmed through.
I will send a draft UML class diagram later.It will be prettier than asci
art :-).

>>A Map<XProperty> would probably make more sense
Yeah needs to use Maps. Thnx. I was careless.

Thanks for the Quick reply.

Best Regards
Sasinda.

---------- Forwarded message ----------
From: Thomas Mortagne <[hidden email]>
Date: Mon, Jun 18, 2012 at 3:08 PM
Subject: Re: [xwiki-devs] Fwd: [GSoc] XDroid Platform
To: [hidden email], XWiki Developers <[hidden email]>


On Mon, Jun 18, 2012 at 11:30 AM, sasinda rukshan
<[hidden email]> wrote:

> ---------- Forwarded message ----------
> From: sasinda rukshan <[hidden email]>
> Date: Mon, Jun 18, 2012 at 2:56 PM
> Subject: Re: [xwiki-devs] [GSoc] XDroid Platform
> To: XWiki Developers <[hidden email]>
>
>
> Hi Thomas,
>
> Thanks for the explanations.
> The methods toXML , toEmbedXML are wrong.It was just an idea that came up
> without much thinking. I will use a separate model
> converter.(xwikitTosimpleModelConverter implements ModelConverter like
> thing). So the model objects don't know about it at all.
> By what you ment by "user" I think it is the client app developer is it?

Yes I mean the user of the API.

> you did not mean end user. I never reveal the xml representations to end
> users.
>
> I came up with a simpler design. I will post diagram later tomorrow.

Ok, this ASCII art here is not very easy to read ;)

> To give a brief on it,
> XObject           : has protected property List<XProperty>

A Map<XProperty> would probably make more sense here since each
property as a unique name in an object and you will need to set some
specific property very often.

> |__XPoperty  :<< all objects that can be added as a  property of an
objects

> should extend this. Has an attribute list. cancels the
> |                         property list of XObject
> |      |_____XString          :
> |__Abstract XDocObject  :<< all documents should have an object of this.
> This is the pages class. Has a object  List<XObject>
> |       |____XBlog             :<< all documents which are blogs should
> have a object of this. This determines the class of the object.
> |                                          but this data is not posted
> anywhere in <link rel="...../class"> . It is just kept for type checks.
> That is like
> |                                         this page should include
> XBlogPost objects.
> |__XBlogPost                   : <<the BlogPostClass object.
>
> In my view I assume every page has an object of some class. And this
object
> holds the objects which you can get under .../pages/BlogPg1/objects/

Well not exactly, you don't always have an object. A document can be
just about content. Just a wiki page if you prefer.

>
> [
> an added advantage:
> I think we can make a ViewEngine to generate android View components from
> the above model. Since the objects in the page carry rendering
> descriptions.We can make a general model like a browser to
> brows xwiki using generated the views. But the problem is some features in
> specific spaces like blog do not seem to be totally defined by the XWiki
> Object model behind them. Also this is just an idea (not suggesting I do
> for the GSoc).Making it a  usable reality is a little challenge.
> ]
>
> So as you said if a document (I think it equivalent to a page) can have
> many class types my assumption fails.
> Why should a document be of multiple classes. I was thinking a page
belongs
> to a class. And the page is an instance of that class. If page can have
> multiple classes my understanding should be wrong. Isn't it?

I don't understand, what I said is that you can only have one class in
a document but you can have several objects.

>
> Thanks
> Best Regards
> Sasinda.
>
>
>
>
>> >>>> >>>> > On Wed, May 30, 2012 at 1:11 PM, Thomas Mortagne
>> >>>> >>>> > <[hidden email]>wrote:
>> >>>> >>>> >
>> >>>> >>>> >> On Wed, May 30, 2012 at 4:28 AM, sasinda rukshan
>> >>>> >>>> >> <[hidden email]> wrote:
>> >>>> >>>> >> > Hi,
>> >>>> >>>> >> > I am studying ORM Lite these days.
>> >>>> >>>> >> > Please It would be comforting if you can confirm whether
it
>> is
>> >>>> worth
>> >>>> >>>> >> > the
>> >>>> >>>> >> > overhead to use ORM Lite.
>> >>>> >>>> >> >
>> >>>> >>>> >>
>> >>>> >>>> >>
>> >>>>
>>
http://logic-explained.blogspot.com/2011/12/using-ormlite-in-android-projects.html
>> >>>> >>>> >> > http://ormlite.com/
>> >>>> >>>> >> > ORM Lite features:
>> >>>> >>>> >> > Automatically Creates standard DAOs for an annotated
entity.

>> >>>> >>>> >> > Coding will be lot easier.
>> >>>> >>>> >>
>> >>>> >>>> >> Remember it's a framework for a mobile platform so it has to
>> >>>> remain
>> >>>> >>>> >> light and have good performances. I can see that Android
>> version
>> >>>> of
>> >>>> >>>> >> ormlite is very small but I never used it so I don't know if
>> >>>> it's good
>> >>>> >>>> >> or not. At least it seems petty active which is a good point
>> so I
>> >>>> >>>> >> don't have anything against it.
>> >>>> >>>> >>
>> >>>> >>>> >> >
>> >>>> >>>> >> > Can you suggest how to name the entities.
>> >>>> >>>> >> > I am going to go with,
>> >>>> >>>> >> > <entity>  org.xwiki.xdroid.data.User  --> <table> C_USER
>> >>>> >>>> >>
>> >>>> >>>> >> Note that there is already a package name prefix and group
id
>> >>>> defined
>> >>>> >>>> >> for the framework and it's org.xwiki.android as you can see
on
>> >>>> >>>> >> https://github.com/xwiki-contrib/android-client. Why do you
>> >>>> want to
>> >>>> >>>> >> change it ? It's more consistent with
>> >>>> >>>> >> org.xwiki.commons/org.xwiki.rendering/org.xwiki.platform so
I
>> >>>> would
>> >>>> >>>> >> prefer to keep it that way unless you can give arguments.
The
>> >>>> goal is
>> >>>> >>>> >> not to redo something completely but complete and improve
the

>> >>>> existing
>> >>>> >>>> >> framework.
>> >>>> >>>> >>
>> >>>> >>>> >> Also as far as I can see there is already several things
>> called
>> >>>> >>>> >> "xdroid" on Google play among which an application developer
>> >>>> >>>> >> (https://play.google.com/store/apps/developer?id=x-droid)
>> and an
>> >>>> >>>> >> application (
>> >>>> >>>> >>
>> >>>> >>>> >>
>> >>>>
>>
https://play.google.com/store/apps/details?id=com.gurudigitalsolutions.xdroid

>> >>>> >>>> >> ).
>> >>>> >>>> >>
>> >>>> >>>> >> >
>> >>>> >>>> >> > Thanks,
>> >>>> >>>> >> > Best Regards
>> >>>> >>>> >> >
>> >>>> >>>> >> > Sasinda.
>> >>>> >>>> >> >
>> >>>> >>>> >> >
>> >>>> >>>> >> >
>> >>>> >>>> >> >
>> >>>> >>>> >> >
>> >>>> >>>> >> > On Wed, May 30, 2012 at 7:42 AM, sasinda rukshan
>> >>>> >>>> >> > <[hidden email]>wrote:
>> >>>> >>>> >> >
>> >>>> >>>> >> >> Hi,
>> >>>> >>>> >> >>
>> >>>> >>>> >> >> I am commiting my work to my fork
>> >>>> >>>> >> >> https://github.com/sasinda/android-client.
>> >>>> >>>> >> >> I ll request to pull it to xwiki-contrib later.
>> >>>> >>>> >> >>
>> >>>> >>>> >> >> I was running in a wrong path these days. Wanted to save
>> login
>> >>>> >>>> >> >> history
>> >>>> >>>> >> and
>> >>>> >>>> >> >> suggest login. I was going to do it using an xml file
>> (login
>> >>>> >>>> >> attempts.xml).
>> >>>> >>>> >> >> Now it seems database is better.
>> >>>> >>>> >> >> Any way before I go wrong again I will say what I am
going

>> to
>> >>>> do.
>> >>>> >>>> >> >> I am going to enforce following conventions.These are not
>> yet
>> >>>> >>>> >> >> needed,
>> >>>> >>>> >> >> considered the small scale.But when the system grows it
>> would
>> >>>> be
>> >>>> >>>> >> >> nice to
>> >>>> >>>> >> >> have them to avoid confusions.
>> >>>> >>>> >> >> *Database prefixes for:*
>> >>>> >>>> >> >> *Platform tables (can begin with appropriate prefix)*
>> >>>> >>>> >> >> AD_ //application dictionary : don't know when it will be
>> >>>> needed ;-)
>> >>>> >>>> >> >> C_ //core functionality
>> >>>> >>>> >> >> *Client Applications.*
>> >>>> >>>> >> >> X<App name prefix>  ex: XBLOG_   for Blog app// All
client

>> >>>> add in
>> >>>> >>>> >> modules
>> >>>> >>>> >> >> must begin with table prefix X(for xwiki and ordering) +
>> App
>> >>>> name.
>> >>>> >>>> >>  This is
>> >>>> >>>> >> >> for my blog.
>> >>>> >>>> >> >>
>> >>>> >>>> >> >> I will create
>> >>>> >>>> >> >> C_User for user data.
>> >>>> >>>> >> >> C_LoginAttempt  for saving login attempts.
>> >>>> >>>> >> >>
>> >>>> >>>> >> >> From C_LoginAttempt I can filter uniqe login combinations
>> and
>> >>>> give
>> >>>> >>>> >> >> suggestions in the login UI component. Also save the
>> history.
>> >>>> >>>> >> >>
>> >>>> >>>> >> >> All saved data for blog app will be linked to a
perticular

>> >>>> login :
>> >>>> >>>> >> >> User,
>> >>>> >>>> >> >> XWiki server.
>> >>>> >>>> >> >> But only a single user will be most probably using his
>> >>>> personal
>> >>>> >>>> >> >> device.
>> >>>> >>>> >> So
>> >>>> >>>> >> >> above will be relevant only when he has multiple wikis.
>> >>>> >>>> >> >>
>> >>>> >>>> >> >> Best Regards,
>> >>>> >>>> >> >> Sasinda Rukshan.
>> >>>> >>>> >> >>
>> >>>> >>>> >> >>
>> >>>> >>>> >> >>
>> >>>> >>>> >> >>
>> >>>> >>>> >> >>
>> >>>> >>>> >> >> On Sun, May 27, 2012 at 5:43 PM, Chamika Weerasinghe <
>> >>>> >>>> >> [hidden email]>wrote:
>> >>>> >>>> >> >>
>> >>>> >>>> >> >>> On Fri, May 25, 2012 at 1:25 AM, Jerome Velociter <
>> >>>> >>>> >> [hidden email]
>> >>>> >>>> >> >>> >wrote:
>> >>>> >>>> >> >>>
>> >>>> >>>> >> >>> > On Thu, May 24, 2012 at 6:09 PM, Thomas Mortagne
>> >>>> >>>> >> >>> > <[hidden email]> wrote:
>> >>>> >>>> >> >>> > > On Thu, May 24, 2012 at 5:52 PM, sasinda rukshan
>> >>>> >>>> >> >>> > > <[hidden email]> wrote:
>> >>>> >>>> >> >>> > >> Hi all,
>> >>>> >>>> >> >>> > >> I am starting this thread for my XWiki Android
>> Platform
>> >>>> >>>> >> >>> > >> Project.
>> >>>> >>>> >> >>> > >>
>> >>>> >>>> >> >>> > >> Please check whether following are OK.
>> >>>> >>>> >> >>> > >> [1] INFO
>> >>>> >>>> >> >>> > >> I tried to start my new modules with the
>> >>>> >>>> >> >>> de.akquinet.android.archetypes:
>> >>>> >>>> >> >>> > >> android-quickstart:1.0.8.  (added eclipse plugins
>> m2e,
>> >>>> >>>> >> >>> > >> m2e-android[a.k.a  *Android
>> >>>> >>>> >> >>> > >> Configurator* ]). But this seems buggy in eclipse.
>> >>>> >>>> >> >>> > >> Any way the earlier project has not followed the
>> above
>> >>>> >>>> >> >>> > >> archtype
>> >>>> >>>> >> >>> either.
>> >>>> >>>> >> >>> > So
>> >>>> >>>> >> >>> > >> I am going to write pom.xml manually for my each
>> module.
>> >>>> >>>> >> >>> > >>
>> >>>> >>>> >> >>> > >> [2] ADVICE NEEDED
>> >>>> >>>> >> >>> > >> xwiki-rest-model module contains 2 submodules
>> >>>> >>>> >> >>> > >>  |-- xwiki-rest-model-gson  ( gson should be
>> corrected
>> >>>> to
>> >>>> >>>> >> >>> > >> json)
>> >>>> >>>> >> >>> > >
>> >>>> >>>> >> >>> > > No the g is not a mistake, it's a model to be used
>> with
>> >>>> the
>> >>>> >>>> >> >>> > > gson
>> >>>> >>>> >> >>> > > library (http://code.google.com/p/google-gson/). See
>> >>>> >>>> >> >>> > >
>> >>>> >>>> >> >>> >
>> >>>> >>>> >> >>>
>> >>>> >>>> >>
>> >>>> >>>> >>
>> >>>>
>>
http://extensions.xwiki.org/xwiki/bin/view/Extension/Google+Android+Client#HXWikiAndroidDevelopmentAPIsandResources
>> >>>> >>>> >> >>> > .
>> >>>> >>>> >> >>> > >
>> >>>> >>>> >> >>> > >>  |-- xwiki-rest-model-simplexml
>> >>>> >>>> >> >>> > >> I think the xwiki-rest-model-gson is redundant. The
>> >>>> classes
>> >>>> >>>> >> >>> > >> in xwiki-rest-model-simplexml is added with simple
>> xml
>> >>>> >>>> >> annotations,
>> >>>> >>>> >> >>> > >> otherwise both modules have same classes. There is
no
>> >>>> problem
>> >>>> >>>> >> >>> > >> with
>> >>>> >>>> >> >>> the
>> >>>> >>>> >> >>> > >> added annotations for using the same model objects
>> for
>> >>>> Json
>> >>>> >>>> >> >>> > >> REST
>> >>>> >>>> >> web
>> >>>> >>>> >> >>> > >> services. And I intend to add my JPA (ORMLite
library

>> >>>> for
>> >>>> >>>> >> >>> persistence)
>> >>>> >>>> >> >>> > >> annotations on top of it.
>> >>>> >>>> >> >>> > >> Shall I re-factor them to a single module
>> >>>> xwiki-rest-model.
>> >>>> >>>> >> >>> > >
>> >>>> >>>> >> >>> > > No keep them separated, the idea is that both are
>> useful
>> >>>> tool
>> >>>> >>>> >> >>> > > to be
>> >>>> >>>> >> >>> > > used by someone else that might be moved to
>> >>>> xwiki-platform at
>> >>>> >>>> >> >>> > > some
>> >>>> >>>> >> >>> > > point along with the current xwiki-rest-model (to be
>> >>>> renamed to
>> >>>> >>>> >> >>> > > xwiki-rest-model-jaxb).
>> >>>> >>>> >> >>> > >
>> >>>> >>>> >> >>> > > Chamika initially started with gson and since XWiki
>> REST
>> >>>> JSON
>> >>>> >>>> >> >>> > > representation had some limitation he moved to XML
>> >>>> >>>> >> >>> > > representation.
>> >>>> >>>> >> >>> > > Maybe at some point Android will have native support
>> for
>> >>>> jaxb
>> >>>> >>>> >> >>> > > which
>> >>>> >>>> >> >>> > > would obviously be the easier for us (embedding jaxb
>> is
>> >>>> not an
>> >>>> >>>> >> option
>> >>>> >>>> >> >>> > > in mobile world where size it still pretty important
>> >>>> especially
>> >>>> >>>> >> >>> > > on
>> >>>> >>>> >> >>> > > phones). Maybe it's already the case on most recent
>> >>>> versions
>> >>>> >>>> >> >>> > > like
>> >>>> >>>> >> 4.0
>> >>>> >>>> >> >>> > > I don't know.
>> >>>> >>>> >> >>> >
>> >>>> >>>> >> >>> > There's also Jackson that could be tried for JSON
>> >>>> >>>> >> >>> > deserialization, if
>> >>>> >>>> >> >>> > said limitations are actually GSON limitations.
>> >>>> >>>> >> >>> >
>> >>>> >>>> >> >>> GSON wasn't the limitation.
>> >>>> >>>> >> >>> It was XWiki RESTful API which doesn't support JSON in
>> some
>> >>>> cases.
>> >>>> >>>> >> >>> So
>> >>>> >>>> >> it's
>> >>>> >>>> >> >>> safe to go with xml.
>> >>>> >>>> >> >>>
>> >>>> >>>> >> >>> >
>> >>>> >>>> >> >>> > Having full JAXB support sound a bit overweight for
>> such an
>> >>>> >>>> >> >>> > "embedded
>> >>>> >>>> >> >>> > API", even if one day it is natively supported by
>> Android.
>> >>>> What's
>> >>>> >>>> >> >>> > important is to have an easy and fast deserialization,
>> IMO.
>> >>>> >>>> >> >>> > The only advantage I can see of going JAXB would be in
>> >>>> re-using
>> >>>> >>>> >> >>> > the
>> >>>> >>>> >> >>> > exact representations and body readers/writers from
>> XWiki
>> >>>> core.
>> >>>> >>>> >> >>> > But
>> >>>> >>>> >> >>> > you probably don't even want to do that since it would
>> mean
>> >>>> >>>> >> >>> > dragging
>> >>>> >>>> >> >>> > XWiki core with you :)
>> >>>> >>>> >> >>> >
>> >>>> >>>> >> >>> > Jerome
>> >>>> >>>> >> >>> >
>> >>>> >>>> >> >>> > >
>> >>>> >>>> >> >>> > >>
>> >>>> >>>> >> >>> > >> [3] INFO
>> >>>> >>>> >> >>> > >>  I had to change some pom.xml s. As the current
>> project
>> >>>> at:
>> >>>> >>>> >> >>> > >>
>> https://github.com/xwiki-contrib/android-client.gitdoes not
>> >>>> >>>> >> build.
>> >>>> >>>> >> >>> > Error
>> >>>> >>>> >> >>> > >> with parent pom.xml coordinates.
>> >>>> >>>> >> >>> > >
>> >>>> >>>> >> >>> > > You probably did not setup you maven install
properly

>> >>>> since
>> >>>> >>>> >> >>> > > what's
>> >>>> >>>> >> on
>> >>>> >>>> >> >>> > >
>> https://github.com/xwiki-contrib/android-client.gitbuild
>> >>>> >>>> >> perfectly
>> >>>> >>>> >> >>> as
>> >>>> >>>> >> >>> > > you can see on
>> >>>> >>>> >> http://ci.xwiki.org/view/All/job/xwiki-android-client/
>> >>>> >>>> >> >>> > > which run a build every time something changes on
the

>> git
>> >>>> >>>> >> repository..
>> >>>> >>>> >> >>> > > You should look at
>> >>>> >>>> >> >>> > >
>> http://dev.xwiki.org/xwiki/bin/view/Community/Building.
>> >>>> >>>> >> >>> > >
>> >>>> >>>> >> >>> > >>
>> >>>> >>>> >> >>> > >>
>> >>>> >>>> >> >>> > >> Thank you
>> >>>> >>>> >> >>> > >> Best Regards.
>> >>>> >>>> >> >>> > >> Sasinda Rukshan
>> >>>> >>>> >> >>> > >> _______________________________________________
>> >>>> >>>> >> >>> > >> devs mailing list
>> >>>> >>>> >> >>> > >> [hidden email]
>> >>>> >>>> >> >>> > >> http://lists.xwiki.org/mailman/listinfo/devs
>> >>>> >>>> >> >>> > >
>> >>>> >>>> >> >>> > >
>> >>>> >>>> >> >>> > >
>> >>>> >>>> >> >>> > > --
>> >>>> >>>> >> >>> > > Thomas Mortagne
>> >>>> >>>> >> >>> > > _______________________________________________
>> >>>> >>>> >> >>> > > devs mailing list
>> >>>> >>>> >> >>> > > [hidden email]
>> >>>> >>>> >> >>> > > http://lists.xwiki.org/mailman/listinfo/devs
>> >>>> >>>> >> >>> >
>> >>>> >>>> >> >>> >
>> >>>> >>>> >> >>> >
>> >>>> >>>> >> >>> > --
>> >>>> >>>> >> >>> > Jérôme Velociter
>> >>>> >>>> >> >>> > Winesquare
>> >>>> >>>> >> >>> > http://www.winesquare.net/
>> >>>> >>>> >> >>> > _______________________________________________
>> >>>> >>>> >> >>> > devs mailing list
>> >>>> >>>> >> >>> > [hidden email]
>> >>>> >>>> >> >>> > http://lists.xwiki.org/mailman/listinfo/devs
>> >>>> >>>> >> >>> >
>> >>>> >>>> >> >>> _______________________________________________
>> >>>> >>>> >> >>> devs mailing list
>> >>>> >>>> >> >>> [hidden email]
>> >>>> >>>> >> >>> http://lists.xwiki.org/mailman/listinfo/devs
>> >>>> >>>> >> >>>
>> >>>> >>>> >> >>
>> >>>> >>>> >> >>
>> >>>> >>>> >> > _______________________________________________
>> >>>> >>>> >> > devs mailing list
>> >>>> >>>> >> > [hidden email]
>> >>>> >>>> >> > http://lists.xwiki.org/mailman/listinfo/devs
>> >>>> >>>> >>
>> >>>> >>>> >>
>> >>>> >>>> >>
>> >>>> >>>> >> --
>> >>>> >>>> >> Thomas Mortagne
>> >>>> >>>> >> _______________________________________________
>> >>>> >>>> >> devs mailing list
>> >>>> >>>> >> [hidden email]
>> >>>> >>>> >> http://lists.xwiki.org/mailman/listinfo/devs
>> >>>> >>>> >>
>> >>>> >>>> > _______________________________________________
>> >>>> >>>> > devs mailing list
>> >>>> >>>> > [hidden email]
>> >>>> >>>> > http://lists.xwiki.org/mailman/listinfo/devs
>> >>>> >>>>
>> >>>> >>>>
>> >>>> >>>>
>> >>>> >>>> --
>> >>>> >>>> Thomas Mortagne
>> >>>> >>>
>> >>>> >>>
>> >>>> >>
>> >>>> >>
>> >>>> >>
>> >>>> >> --
>> >>>> >> Thomas Mortagne
>> >>>> >
>> >>>> >
>> >>>> >
>> >>>> > --
>> >>>> > Thomas Mortagne
>> >>>>
>> >>>>
>> >>>>
>> >>>> --
>> >>>> Thomas Mortagne
>> >>>>
>> >>>
>> >>>
>> >>
>> > _______________________________________________
>> > devs mailing list
>> > [hidden email]
>> > http://lists.xwiki.org/mailman/listinfo/devs
>>
>>
>>
>> --
>> Thomas Mortagne
>>
> _______________________________________________
> devs mailing list
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs



--
Thomas Mortagne
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
12