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
