[
https://jira.nuxeo.com/browse/NXMOB-6?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thierry Delprat updated NXMOB-6:
--------------------------------
Description:
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.
h2. Possible approaches
Basically there are 3 possible approaches
h3. 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.
h3. 2 - ContentProvider
Android contains a concept of {{ContentProvider}}.
See [Android Documentation |
http://developer.android.com/guide/topics/providers/content-providers.html]
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.
h3. 3 - Android Service
I hoped this would be the solution.
Unfortunatly, Android Apps are sandoxed to all IPC calls have to be marshaled
and if we want more that {{service.invoke("methodName")}} we have to define the
interface using [ {{AIDL}} |
http://developer.android.com/guide/developing/tools/aidl.html]
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.
h2. Proposed Design
h3. Low level API
Finish and clean up the automation client lib.
- add primites to implement caching
- add callback to be notified about network
h3. 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
h3. Sample Application
We update the sample Nuxeo Android Client that will continue using Droid4Me and
Automation lib
was:
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.
h2. Possible approaches
Basically there are 3 possible approaches
h3. 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.
h3. 2 - ContentProvider
Android contains a concept of {{ContentProvider}}.
See [Android Documentation |
http://developer.android.com/guide/topics/providers/content-providers.html]
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.
h3. 3 - Android Service
I hoped this would be the solution.
Unfortunatly, Android Apps are sandoxed to all IPC calls have to be marshaled
and if we want more that {{service.invoke("methodName")}} we have to define the
interface using [ {{AIDL}} |
http://developer.android.com/guide/developing/tools/aidl.html]
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 ad this end it would mean split cutomation 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.
h2. Proposed Design
h3. Low level API
Finish and clean up the automation client lib.
- add primites to implement caching
- add callback to be notified about network
h3. 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
h3. Sample Application
We update the sample Nuxeo Android Client that will continue using Droid4Me and
Automation lib
> Expose Nuxeo Automation as an Android Content Provider
> ------------------------------------------------------
>
> Key: NXMOB-6
> URL: https://jira.nuxeo.com/browse/NXMOB-6
> Project: Nuxeo Mobile
> Issue Type: Task
> Components: Android Automation Client, Android SDK
> Reporter: Thierry Delprat
>
> 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.
> h2. Possible approaches
> Basically there are 3 possible approaches
> h3. 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.
> h3. 2 - ContentProvider
> Android contains a concept of {{ContentProvider}}.
> See [Android Documentation |
> http://developer.android.com/guide/topics/providers/content-providers.html]
> 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.
> h3. 3 - Android Service
> I hoped this would be the solution.
> Unfortunatly, Android Apps are sandoxed to all IPC calls have to be marshaled
> and if we want more that {{service.invoke("methodName")}} we have to define
> the interface using [ {{AIDL}} |
> http://developer.android.com/guide/developing/tools/aidl.html]
> 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.
> h2. Proposed Design
> h3. Low level API
> Finish and clean up the automation client lib.
> - add primites to implement caching
> - add callback to be notified about network
> h3. 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
> h3. Sample Application
> We update the sample Nuxeo Android Client that will continue using Droid4Me
> and Automation lib
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
_______________________________________________
ECM-tickets mailing list
[email protected]
http://lists.nuxeo.com/mailman/listinfo/ecm-tickets
