Re: [xwiki-devs] [GSoc] XDroid Platform

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 <thomas.mortagne(a)xwiki.com> wrote: > Not need to send this kind of mail privately to me. > > On Thu, Jun 7, 2012 at 5:33 AM, sasinda rukshan > <sasindarukshan(a)gmail.com> wrote: >> Thanks, >> The project is building perfectly well in eclipse (and runs well too)

>> configured the build paths for eclipse opening each module as a

>> giving project dependencies and etc.]. This is because android facet

>> maven-android plugin for eclipse [m2e-android] (not the jayway  androi

>> plugin)does not work together well. >> Maven build does not work with newer jayway android maven plugins

>> the simplexml library. I checked with another helloworld app that does

>> have simplexml dependancy and have simplexml dependancy. When we have

>> dependancy it does not work. Also when packaged with the beta version

>> plugin I get runtime error logs notifying that the exact classes

>> missed in the compile time for newer maven plugin are missing. But the

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

>> possible.Source code is not at all relevant to me. But as you say It

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

>> wrote: >>> >>> On Tue, Jun 5, 2012 at 7:07 PM, sasinda rukshan >>> &lt;sasindarukshan(a)gmail.com&gt; 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<

>>> > only >>> > as a unique wiki identifier. But in the

>>> > have the method >>> > setXWikiRealm(String url);: >>> > Here I have intended the meaning realm as the url root path for a

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

>>> > the >>> > opinion wether the usage of word realm was right here. >>> > Also do you have seperate users for  wikis for path based wiki

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

>>> > for them. Rather than having a seperate DB schema for them we can

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

>>> > important application activities(such as login attempts) But the

>>> > be >>> > a little additional weight to the space and performance.I may

>>> > a >>> > generic DBCleaning service to clean the tables like Log, if I have

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

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

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

>>> >  : Need not implement similar component. Android OS does it nicely

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

>>> > directly. (Looks a bad option to me.It does not hide the complexity

>>> > lower levels for the client layer.Anyway my work load  is reduced

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

>>> > app. We have the client.Main app (with all platfrom libs included)

>>> > Blog >>> > app as a seperate apk. >>> > But here Blog app will need to have the platform lib also. That

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

>>> > its >>> > launcher interface using android PackageManager class. >>> > >>> >

>>> > But with this approach rises additional complexities. For example

>>> > conflicts in the Components library module when two apps have the

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

>>> > file) >>> > will only be needed for the first use of the app. Otherwise users

>>> > not >>> > configure a default user as the application now suggests the user

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

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

>>> > The >>> > launch pad is shown when we launch XWiki main client. >>> > Consider adding the WYSIWYG to my blog. It will be useless without

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

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

>>> > not have a ContentProvider to share config data with other apks.

>>> > will define a seperate class to have preferences which will be

>>> > users. Config files are for configuration stuff and will be edited

>>> > developers. Users have preferences files(natively supported by

>>> > to >>> > change app preferences. For example users will add the default login >>> > username as a preference.(This will invalidate the use of default

>>> > 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 >>> > &lt;thomas.mortagne(a)xwiki.com&gt;wrote;wrote: >>> > >>> >> On Wed, May 30, 2012 at 4:28 AM, sasinda rukshan >>> >> &lt;sasindarukshan(a)gmail.com&gt; wrote: >>> >> > Hi, >>> >> > I am studying ORM Lite these days. >>> >> > Please It would be comforting if you can confirm whether it is

>>> >> > the >>> >> > overhead to use ORM Lite. >>> >> > >>> >> >>> >>

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

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

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

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

>>> >> not to redo something completely but complete and improve the

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

>>> >> ). >>> >> >>> >> > >>> >> > Thanks, >>> >> > Best Regards >>> >> > >>> >> > Sasinda. >>> >> > >>> >> > >>> >> > >>> >> > >>> >> > >>> >> > On Wed, May 30, 2012 at 7:42 AM, sasinda rukshan >>> >> > &lt;sasindarukshan(a)gmail.com&gt;wrote;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

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

>>> >> >> C_ //core functionality >>> >> >> *Client Applications.* >>> >> >> X<App name prefix>  ex: XBLOG_   for Blog app// All client add

>>> >> modules >>> >> >> must begin with table prefix X(for xwiki and ordering) + App

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

>>> >> >> suggestions in the login UI component. Also save the history. >>> >> >> >>> >> >> All saved data for blog app will be linked to a perticular

>>> >> >> 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 < >>> >> chamikaw(a)gmail.com&gt;wroteote: >>> >> >> >>> >> >>> On Fri, May 25, 2012 at 1:25 AM, Jerome Velociter < >>> >> jerome(a)winesquare.net >>> >> >>> >wrote: >>> >> >>> >>> >> >>> > On Thu, May 24, 2012 at 6:09 PM, Thomas Mortagne >>> >> >>> > &lt;thomas.mortagne(a)xwiki.com&gt; wrote: >>> >> >>> > > On Thu, May 24, 2012 at 5:52 PM, sasinda rukshan >>> >> >>> > > &lt;sasindarukshan(a)gmail.com&gt; 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 >>> >> >>> > > >>> >> >>> > >>> >> >>> >>> >> >>> >>

>>> >> >>> > . >>> >> >>> > > >>> >> >>> > >>  |-- xwiki-rest-model-simplexml >>> >> >>> > >> I think the xwiki-rest-model-gson is redundant. The

>>> >> >>> > >> in xwiki-rest-model-simplexml is added with simple xml >>> >> annotations, >>> >> >>> > >> otherwise both modules have same classes. There is no

>>> >> >>> > >> with >>> >> >>> the >>> >> >>> > >> added annotations for using the same model objects for

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

>>> >> >>> > > >>> >> >>> > > No keep them separated, the idea is that both are useful

>>> >> >>> > > to be >>> >> >>> > > used by someone else that might be moved to xwiki-platform

>>> >> >>> > > some >>> >> >>> > > point along with the current xwiki-rest-model (to be

>>> >> >>> > > xwiki-rest-model-jaxb). >>> >> >>> > > >>> >> >>> > > Chamika initially started with gson and since XWiki REST

>>> >> >>> > > representation had some limitation he moved to XML >>> >> >>> > > representation. >>> >> >>> > > Maybe at some point Android will have native support for

>>> >> >>> > > which >>> >> >>> > > would obviously be the easier for us (embedding jaxb is

>>> >> option >>> >> >>> > > in mobile world where size it still pretty important

>>> >> >>> > > on >>> >> >>> > > phones). Maybe it's already the case on most recent

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

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

>>> >> >>> > important is to have an easy and fast deserialization, IMO. >>> >> >>> > The only advantage I can see of going JAXB would be in

>>> >> >>> > the >>> >> >>> > exact representations and body readers/writers from XWiki

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

>>> >> >>> > >> https://github.com/xwiki-contrib/android-client.git does

-- Thomas Mortagne