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 <[email protected]>wrote: > On Wed, May 30, 2012 at 4:28 AM, sasinda rukshan > <[email protected]> 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 > > <[email protected]>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 < > [email protected]>wrote: > >> > >>> On Fri, May 25, 2012 at 1:25 AM, Jerome Velociter < > [email protected] > >>> >wrote: > >>> > >>> > On Thu, May 24, 2012 at 6:09 PM, Thomas Mortagne > >>> > <[email protected]> wrote: > >>> > > On Thu, May 24, 2012 at 5:52 PM, sasinda rukshan > >>> > > <[email protected]> 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 > >>> > >> [email protected] > >>> > >> http://lists.xwiki.org/mailman/listinfo/devs > >>> > > > >>> > > > >>> > > > >>> > > -- > >>> > > Thomas Mortagne > >>> > > _______________________________________________ > >>> > > devs mailing list > >>> > > [email protected] > >>> > > http://lists.xwiki.org/mailman/listinfo/devs > >>> > > >>> > > >>> > > >>> > -- > >>> > Jérôme Velociter > >>> > Winesquare > >>> > http://www.winesquare.net/ > >>> > _______________________________________________ > >>> > devs mailing list > >>> > [email protected] > >>> > http://lists.xwiki.org/mailman/listinfo/devs > >>> > > >>> _______________________________________________ > >>> devs mailing list > >>> [email protected] > >>> http://lists.xwiki.org/mailman/listinfo/devs > >>> > >> > >> > > _______________________________________________ > > devs mailing list > > [email protected] > > http://lists.xwiki.org/mailman/listinfo/devs > > > > -- > Thomas Mortagne > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
