24 Jun
2012
24 Jun
'12
10:17 a.m.
Hi ,
Updated current archi.
https://docs.google.com/drawings/d/1hwfQMVgCvYKS6iHU060drcET3Aq3Vles2DQlJOO…
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
<sasindarukshan(a)gmail.com>wrote;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 <
sasindarukshan(a)gmail.com> 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 <
sasindarukshan(a)gmail.com> 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 <
sasindarukshan(a)gmail.com> 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 <
sasindarukshan(a)gmail.com> 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 <
> sasindarukshan(a)gmail.com> wrote:
>
>> Hi Thomas,
>>
>>
>
>> ---------- Forwarded message ----------
>> From: Thomas Mortagne <thomas.mortagne(a)xwiki.com>
>> Date: Mon, Jun 18, 2012 at 3:08 PM
>> Subject: Re: [xwiki-devs] Fwd: [GSoc] XDroid Platform
>> To: sasindarukshan(a)gmail.com, XWiki Developers <devs(a)xwiki.org>
>>
>>
>> On Mon, Jun 18, 2012 at 11:30 AM, sasinda rukshan
>> <sasindarukshan(a)gmail.com> wrote:
>> > ---------- Forwarded message ----------
>> > From: sasinda rukshan <sasindarukshan(a)gmail.com>
>> > Date: Mon, Jun 18, 2012 at 2:56 PM
>> > Subject: Re: [xwiki-devs] [GSoc] XDroid Platform
>> > To: XWiki Developers <devs(a)xwiki.org>
>> >
>> >
>> > 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.
>> >
>> >
>> >
>> >
>>
>