Uploaded image for project: 'Nuxeo Mobile'
  1. Nuxeo Mobile
  2. NXMOB-1

Define scope for Android Client and SDK

    XMLWordPrintable

    Details

    • Type: Task
    • Status: Resolved
    • Priority: Minor
    • Resolution: Incomplete
    • Affects Version/s: None
    • Fix Version/s: None

      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.

      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.

      See Android Documentation

      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

        Attachments

          Activity

            People

            • Assignee:
              tdelprat Thierry Delprat
              Reporter:
              tdelprat Thierry Delprat
              Participants:
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Time Tracking

                Estimated:
                Original Estimate - 1 day
                1d
                Remaining:
                Remaining Estimate - 1 day
                1d
                Logged:
                Time Spent - Not Specified
                Not Specified