Google Android Client>>Platform>>Architecture
- [A] Architecture
- [B] Introduction to architectural components.
[A] Architecture
[B] Introduction to architectural components.
[1]Xwiki REST APIs.
[1.1] ReST Connector
This layer is concerned with communicating with the XWiki server instance via REST. 
Above module abstract the XWiki Restful API documented here http://platform.xwiki.org/xwiki/bin/view/Features/XWikiRESTfulAPI.
[1.2] ReST models
Contains models representing Xwiki RESTful resources such as Page element, Object element and etc. XML RESTful communication is supported by xwiki-rest-model-simple-xml. (http://extensions.xwiki.org/xwiki/bin/view/Extension/Google+Android+Client))
[1.3] RAL : RESTful Access Layer
Rest Access Layer. This is a simplified model for accessing XWiki RESTful API. Strips down all the fine grained calls of XWiki RESTful API to simple CRUD (Create, Retreive, Update, Delete) operations. Making the programming model much more simple. The RAL module supports CRUD operations only for the main first class entities which are Document, Space, Wiki. The RAL layer fully decouples the REST Model from the client components in RESTful communication with the server. A client component for the RAL layer only needs the knowledge of XWiki Domain model to do RESTful communication with the server.
[2] Transformation
This component is used for transforming the Xwiki Domain Model into underlying Xwiki Rest Model for communication with the server.
[3] Domain Model
[3.1] Xwiki Domain Model
This is a representation of the XWiki Domain model. It represents Domain objects for Wiki, Spaces, Document, and Attachments etc.Mobile version of XWiki module "model". Also represents the Xwik Class, Object, Properties model. Refer http://platform.xwiki.org/xwiki/bin/view/DevGuide/DataModel for Xwiki data model.
These model entities can directly be transformed to android RESTful model and thus be used to manipulate the state of the server. Ex: a Document object in the XA(XWiki Android) is same as that in XE. So a Document object that is created in the client application can be directly send to the server through the RAL so that it will be created in the server as well.
[3.2] Xwiki Android Entities
This contains model entities wich are not directly adopted from XWiki Domain mode. Represents entities such as User, AuditEntry etc.
These entities do not have a direct mapping with the Domain model of the server. These entities are there to represent XWiki Android specific data model.
[4] Data Access Layer
[4.1]FAL/FileStore
The File Store is the module that allows persistence for XWiki Domain model objects. For example you can directly save a Xwiki Document object in to the android device through the file store apis.Contains APIs for saving, loading, deleting, listing all Xwiki Domain Entities in the device. This module is designed with Data Access Object Pattern offering objects named as Fao(File Access Objects). When a Xwiki model object like document is in need to be persisted we can use a Fao to save it to the device. The file store implementation saves the entity as a file in the device and keeps a lightweight reference to the saved entity in the SQLite database.
[4.2] DAL/ORMLite
The Data Access Layer provides functionality to persist XWiki Android Entities in to the SQLite Database. The API is very simple to use as this layer provides simple Object to Relational mapping through Data Access Objects.
[5] Services Layer
[5.1] Base Services
These are simply business facades that simplify the usage of underlying APIs such as RAL, FAL, DAL and other modules.
The base services provide service functionality as follows.
- Xwiki Model Services
- Ex:Local: Save, Load, List saved documents and Delete services for Documents. Remote: Create, Retrieve, Update, Delete - Xwiki Common Services
- Ex: Login service, sync services.
[5.2] Extended Services [a.k.a App Specific Services]
These services use the Base services. But are specific for each application. For example if you are creating a blog application there are blog application specific features that need to be implemented. The Android activities can directly use the Base services but implementing them as a separate layer will lead to a cleaner design.
[5.3] Cross Cutting Services
These services are used by many components.(i.e. data layers, entities, and normal service layers all may use these services)
[5.3.1] Security
Security module offers API for encryption and decryption.
[5.3.1] Audit
Audit module offers Android logging like API for application level audit purposes. EX: Login Façade in the service layer use this module to log a user login entry so users can view the last logged in time.
[6] XWiki Application Context
This is one of the core parts of the architecture. The XWiki Application Context is used for simple IoC (Invertion of Control). The control of constructing EntityManagers(DAL layer), FileStoreManagers( FAL layer) and other major components are given to the Application Context. (It is there to achieve flexibility and declarative configurations to the platform). The XWiki Application Context is integrated to the Android Application Context.
