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 _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
