Note that it would be nice to update https://github.com/xwiki-contrib/android-client/blob/master/README with new stuff.
On Tue, Jul 3, 2012 at 5:18 PM, Thomas Mortagne <[email protected]> wrote: > Hi, > > Looks like you merge your work on master which is great but is it > normal that the "p2" branch is still here ? Also I don't understand > what is the "tm" branch for. > > On Sun, Jun 24, 2012 at 10:17 AM, sasinda rukshan > <[email protected]> wrote: >> Hi , >> Updated current archi. >> https://docs.google.com/drawings/d/1hwfQMVgCvYKS6iHU060drcET3Aq3Vles2DQlJOOt3n8/edit >> >> >> >> Improved XWikiApplicationContext object. It is now used for IOC. >> Also it is now integrated to android native runtime. All activities can now >> call android native method "this.getApplication()" to receive a >> XWikiApplicationContext. >> https://github.com/xwiki-contrib/android-client/tree/p2 >> >> Thanks >> Regards. >> >> >> Thanks, >> Best Regards. >> >> On Sat, Jun 23, 2012 at 10:40 AM, sasinda rukshan >> <[email protected]>wrote: >> >>> PS: >>> Forgot to mention, >>> Document API will have 2 additional methods. >>> activate() >>> passivate() >>> These are introduced to passivate the document when an Android Activity >>> shuts down if user is doing multi tasking. >>> For the rationale behind this, refer to >>> http://developer.android.com/guide/components/tasks-and-back-stack.html >>> Tasks and BackStack >>> http://developer.android.com/guide/components/activities.html >>> see, figure1:The Activity Lifecycle >>> >>> passivate() will pass the Document object to an Android >>> Service which will persist document to the device. >>> >>> I will do an incremental development. >>> 1st increment: BlogDocument object will have functionality to send a >>> BlogPost. All lower layer functinality needed will be implemented. >>> 2nd increment: Save the BlogDocument in the device drive. >>> Rest I have not planned. >>> >>> Thanks >>> Best Regards. >>> Sasinda. >>> >>> >>> On Sat, Jun 23, 2012 at 10:26 AM, sasinda rukshan < >>> [email protected]> wrote: >>> >>>> hi, >>>> >>>> API update. >>>> Document: create,retrieve,update,delete. (same as above) >>>> >>>> We are using a ReSTful Manager and ReSTfulAccessObject[i.e. RAO<Document> >>>> for accssing doc from server and all that.]. It is the Data Access Object >>>> Pattern.This is to hide the underlying rest communication model.(i.e. >>>> Jackson/Gson/SimpleXml...). Also this will apply a database like feeling >>>> when accessing remote server ReSTful API. (this makes the architecture >>>> simple and consistent also). >>>> >>>> I did not see a method to querry all pages having a BlogPostClass object, >>>> in the ReSTAPI documentation. Only possible way I found is to retrieve all >>>> pages and there object summaries and find which pages have a BlogPostClass >>>> in them. >>>> I will add the querry method to an implementation of RAO<Space>. >>>> It will be something like this. >>>> >>>> class defs >>>> interface RAO<T>{has a method querry()} >>>> MYSpaceRAOImpl implements RAO<Space> >>>> ReSTfulManager : Think that an instance of this is like a hibernate >>>> session. Since this is a mobile env (and I am not that smart to implement >>>> something like hibernate:-) >>>> we get an RAO(same as a DataAccessObject) >>>> from it rather than hiding everything behind it. >>>> >>>> RAO<Space> spcRAO=ResTfulManager.getRAO(Space.class , fetchstrategy) >>>> spcRAO.querry( all documents having a BlogPostClass object in them) >>>> >>>> The SpaceRAO will handle the querying and return Document objects >>>> matching the query. Actually this should return a list of Wrappers of >>>> Document objects, to do things like lazy fetching from the RemoteXWiki >>>> Server.Since time is limited, I will forget about wrappers and return back >>>> the whole document, fully loaded. >>>> I will implement a minimal functionality set in the above components. It >>>> is very easy to evolve the feature set later because of the patterns >>>> applied. >>>> >>>> Please give feedback on the idea. >>>> >>>> Thanks >>>> Best Regards. >>>> Sasinda. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> On Fri, Jun 22, 2012 at 9:08 AM, sasinda rukshan < >>>> [email protected]> wrote: >>>> >>>>> hi, >>>>> Document API. >>>>> >>>>> *create()* >>>>> put the page on server. If the doc includes Objects post them as well. >>>>> (likely for comments tags, attatchments) >>>>> * >>>>> * >>>>> *update(int strategy)* >>>>> Update all things in Page. Throw XWikiException if page not yet created. >>>>> @param : strategy values={MERGE / FORCED } OR {ALL/ OBJECTS / >>>>> TAGS/...} >>>>> ex: thing there are objects 0,1,2 in server page. >>>>> >>>>> - merge (when local doc has objects 0,1 only) >>>>> - update obj 0,1 >>>>> - forced (whne local doc has obj 0,1 only) >>>>> - delete obj 2 in server. Update obj 0,1. >>>>> >>>>> usage: >>>>> doc.update(MERGE || OBJECTS || TAGS) means update page, >>>>> merge objects and tags. Leave the rest as it is >>>>> >>>>> >>>>> *delete() * >>>>> delete the whole document. >>>>> >>>>> *get()* >>>>> load the doc from server >>>>> >>>>> *save()* >>>>> save to local device >>>>> *load()* >>>>> load from local device >>>>> >>>>> Document API is not exposed directly to Client Developers. All it's >>>>> methods are protected. >>>>> We have a BlogDocument [extension to Document] which is exposed to the >>>>> BlogClient developer. >>>>> BlogDocument knows what a blog post is and it knows that it only needs >>>>> to update the BlogPostClass object in the server page. It calls the super >>>>> update() method with the relevant strategy. >>>>> Any way the Document is not the real guy who does all these updates to >>>>> server and local saves and loads. >>>>> For local saves and loads it calls a DAO(data Access Object ) in our >>>>> persistence lib.This DAO will call a FAO (File Access Object ) to save the >>>>> documents bulk to the local file system and enter a light weight entry in >>>>> the SQLite DataBase. >>>>> For updating the server, Document delegate duties to >>>>> ReSTfulDocumentAdapter{implements ReSTfulAdapter}.We can configure which >>>>> ReST model to use in the adapter (currently only simpleXML model). >>>>> Adapters >>>>> convert and adapt the Document model to a rest model and call the >>>>> XWikiReST >>>>> API abstraction layer to update the remote server. >>>>> By the way, those ReSTfulAdapter(s) do a lot of things. Convert Document >>>>> to REST model.Choose an Update Strategy object for the document (passed by >>>>> param in doc.update(strat)) Calls REST api abstraction inside android >>>>> according to the Update strategy. They do a lot of things for an adapter.I >>>>> don't know what to call it :-).An Adapter or something else ??? :-O. >>>>> >>>>> Also for automatic syncs with the server when the device is offline and >>>>> user have made a blog post, user should be given the option to select >>>>> whether to automatically do it or manually post it. >>>>> For automatic sync/posting we can make android Services. >>>>> >>>>> Also currently the xwiki-androi-rest module does not use android native >>>>> services to call server.If a user gets a phone call or something when >>>>> uploading to server things might get messy.This is because android >>>>> Activities are stoped and may be destroyed on these occasions.I will see >>>>> if >>>>> I can rectify it if I have time after the mid eval.(It may totally affect >>>>> how web services are called from upper layers) >>>>> >>>>> Thanks >>>>> Best Regards. >>>>> Sasinda. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Fri, Jun 22, 2012 at 7:33 AM, sasinda rukshan < >>>>> [email protected]> wrote: >>>>> >>>>>> hi, >>>>>> PS: >>>>>> check the *p2 branch*. Not master. Did not merge yet. :-) >>>>>> >>>>>> Regards, >>>>>> Sasinda. >>>>>> >>>>>> On Fri, Jun 22, 2012 at 7:31 AM, sasinda rukshan < >>>>>> [email protected]> wrote: >>>>>> >>>>>>> Hi, >>>>>>> Pushed some initial scaffolding's of XWiki model to android, in to >>>>>>> https://github.com/xwiki-contrib/android-client >>>>>>> This is the basic idea. >>>>>>> The client app developers will be only exposed to a service layer. All >>>>>>> packages suffixed with "Svc" have these. >>>>>>> package: cmnSvc >> has the LoginFacade. called to log in to server and >>>>>>> system.(also update state of XWikiContext in the android and etc) >>>>>>> package blogSvc >> will have BlogDocument, CategoryDocument and etc >>>>>>> which can be used to create posts and update server. >>>>>>> The base class Document will handle all server updations(through a >>>>>>> ReSTfulAdapter, to decouple Document and underlying rest model: simple >>>>>>> XML/Gson) and etc. >>>>>>> >>>>>>> Please check whether approach to redesigning com.xpn....objects into >>>>>>> org.xwiki.android.xmodel.xobjects is correct. >>>>>>> >>>>>>> Thanks. >>>>>>> Best Regards. >>>>>>> Sasinda. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Mon, Jun 18, 2012 at 3:20 PM, sasinda rukshan < >>>>>>> [email protected]> wrote: >>>>>>> >>>>>>>> Hi Thomas, >>>>>>>> >>>>>>>> >>>>>>> >>>>>>>> ---------- Forwarded message ---------- >>>>>>>> From: Thomas Mortagne <[email protected]> >>>>>>>> Date: Mon, Jun 18, 2012 at 3:08 PM >>>>>>>> Subject: Re: [xwiki-devs] Fwd: [GSoc] XDroid Platform >>>>>>>> To: [email protected], XWiki Developers <[email protected]> >>>>>>>> >>>>>>>> >>>>>>>> On Mon, Jun 18, 2012 at 11:30 AM, sasinda rukshan >>>>>>>> <[email protected]> wrote: >>>>>>>> > ---------- Forwarded message ---------- >>>>>>>> > From: sasinda rukshan <[email protected]> >>>>>>>> > Date: Mon, Jun 18, 2012 at 2:56 PM >>>>>>>> > Subject: Re: [xwiki-devs] [GSoc] XDroid Platform >>>>>>>> > To: XWiki Developers <[email protected]> >>>>>>>> > >>>>>>>> > >>>>>>>> > 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. >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> _______________________________________________ >> devs mailing list >> [email protected] >> http://lists.xwiki.org/mailman/listinfo/devs > > > > -- > Thomas Mortagne -- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
