-
Type: Task
-
Status: Resolved
-
Priority: Minor
-
Resolution: Incomplete
-
Affects Version/s: None
-
Fix Version/s: None
-
Component/s: Android Automation Client
-
Tags:
-
Impact type:API added
we would like to expose a nice and simple API to access Nuxeo Document Management services hosted on the server side.
Basically, it's about providing an API to search, read, create, modifiy documents stored on a server.
Possible approaches
Basically there are 3 possible approaches
1 - Java Lib approach
This is clearly the simplest solution and what was done during the sprint.
I simply create a lib that exposes a Java API that wrapps Automation WS calls.
This works quite well, but there are some drawbacks.
- All client applications have to reimplement the preference screens (define url, login, password ...)
- All client applications have to manage the cache (this is not efficient if 2 apps use the same server)
- All client applications have to watch the network events to use offline mode
So basically, it works, but client app developper has to do some work.
2 - ContentProvider
Android contains a concept of ContentProvider.
It's basically a generic interface to do CRUD operations on something that is seen as a SQL table.
The table types are mapped to content-type url like content://org.nuxeo/documnet or content://org.nuxeo/tasks ...
The model is relatively simple to implement but is very limiting.
- objects exposed should be pure data objects (like a Map)
- it's hard to have dynamic columns
- some API are not easy to map (like start a workflow)
Nevertheless, for people that would like to use Nuxeo as a simple source for content, it makes sens.
3 - Android Service
I hoped this would be the solution.
Unfortunatly, Android Apps are sandoxed so all IPC calls have to be marshaled.
With the default model if we end up with an API like : service.invoke("methodName")
=> this is crap
If we want more, we have to define the interface using AIDL
This is of course doable, but the main drawback is that we will have to manage by hand the marshaling of the Document object.
So in a way we will have:
Document (app process) <= AIDL Marshaling => Document (other app exposing the servide) <= JSON Marshaling => DocumentModel (server side)
This seems :
- complicated to do and to use
- not very good for perfs
So at this end it would mean split automation client in 2 parts :
- one part that expose pure JSON and that is exposed via AIDL service
- one part that is client of the Servcie and contains the JSON/Java mapping layer
=> we end up pretty much with the same model as Nb 1 but in more complicated.
Proposed Design
Low level API
Finish and clean up the automation client lib.
- add primites to implement caching
- add callback to be notified about network
Content user API
Create a sample application that uses the automation lib and adds :
- Local caching (in SQL DB)
- Configuration management screens
- Some screens to do queries
This sample app could also expose some Nuxeo ContentProvider :
- one with as much meta-data as we can
- one very simple that could be plugged into Android Google Search
Sample Application
We update the sample Nuxeo Android Client that will continue using Droid4Me and Automation lib