Roadmap for Java/Android?

[Brandon Rosenbaum]

Is there any sort of summary timeline available for the Java/Android API? Mostly I'm curious to see if any model layer work is in the pipeline for parity with iOS and their CBLModel functionality.

Apologies in advance for asking "do we have it yet?", but I can't seem to find anything recent regarding the roadmap.

[Traun Leyden]

Hey Brandon,

I can tell you that having a model layer is on our roadmap, but I don't know the exact priority.  (@Zack want to chime in on this?)

Creating a model layer that everyone loves is actually kind of tricky.  It's made even trickier by the fact that reflection is very expensive on Android, and so would have to be used extremely sparingly.

There is already quite a lot of things that can be done using Jackson to make the "model <-> docuement" translation fairly seamless, so I think we really need to be exploiting that to the max in our examples and try to get an idea of exactly what is missing.  We don't want to end up re-inventing the Jackson wheel here.

A few design considerations I'll throw out, since I'd love to hear your feedback:

* Would you be OK having to extend a CBLModel class, or would this interfere in your existing class hierarchy?

* Does the annotations approach as used in ORMLite seem to be a good approach for you?

* What are the biggest pain points that you want a model layer to solve for you?

On Fri, Dec 19, 2014 at 9:28 AM, Brandon Rosenbaum <brandon....@gmail.com> wrote:

Is there any sort of summary timeline available for the Java/Android API? Mostly I'm curious to see if any model layer work is in the pipeline for parity with iOS and their CBLModel functionality.

Apologies in advance for asking "do we have it yet?", but I can't seem to find anything recent regarding the roadmap.

--
You received this message because you are subscribed to the Google Groups "Couchbase Mobile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mobile-couchba...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/mobile-couchbase/a79e5836-929c-4d4c-afde-45826f0145f3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Zack Gramana]

We're currently slating that for 1.2, which targets the second quarter of 2015.

To view this discussion on the web visit https://groups.google.com/d/msgid/mobile-couchbase/CACSSHCEPYHb3eo8t%2BWJQEkfYSysMZvusCGyHJbQDHBccw1QfrA%40mail.gmail.com.

[Brandon Rosenbaum]

I'm actually pretty new to Couchbase, but I passed the questions along to another member of our team that has more experience. His thoughts are quoted below in-line.

On Saturday, December 20, 2014 11:58:55 AM UTC-6, Traun Leyden wrote:

Hey Brandon,

I can tell you that having a model layer is on our roadmap, but I don't know the exact priority.  (@Zack want to chime in on this?)

Creating a model layer that everyone loves is actually kind of tricky.  It's made even trickier by the fact that reflection is very expensive on Android, and so would have to be used extremely sparingly.

There is already quite a lot of things that can be done using Jackson to make the "model <-> docuement" translation fairly seamless, so I think we really need to be exploiting that to the max in our examples and try to get an idea of exactly what is missing.  We don't want to end up re-inventing the Jackson wheel here.

A few design considerations I'll throw out, since I'd love to hear your feedback:

* Would you be OK having to extend a CBLModel class, or would this interfere in your existing class hierarchy?

"Ok extending CBLModel.  That fits well with what we do in iOS and we were hoping that was the direction to be taken." From what I've seen our iOS code takes advantage of the CBLModel class and we've actually created a CBLModel of our own on Android to emulate some of the same features (it's not very built out though).

 

* Does the annotations approach as used in ORMLite seem to be a good approach for you?

"Looked at ORMLite....perfect.  Reminds me a lot of C#'s XML annotations. Good way to mix properties that are serialized with those that are not. Helps prevent recursion issues as well." I'm not familiar with ORMLite, but this sounds like GSON's annotations which I've always found very helpful for POJO <--> JSON conversion

 

* What are the biggest pain points that you want a model layer to solve for you?

"Biggest pain points: CBLModel reduces maintenance when models are modified.  And during runtime, it ensures that updates to couchbase (new doc revisions) is done smoothly and efficiently when the model is modified." Pretty much just that as far as I can tell as well. I think we'll have to take another look into Jackson to see how much that can help and hopefully will be able to provide more feedback when we do.

[Jens Alfke]

Here's my take on this. Disclaimer: I'm the author of CBLModel, but my Java experience is very old and rusty.

I think the value of CBLModel is that it does three things:

1. Provides a layer of in-memory mutable state for a Document. Documents aren't immutable but they have to be updated all-at-once by adding a new revision, which is a persistent operation. But in an application you very frequently want to be able to make incremental changes in memory, have those reflected in the UI, and then save (or revert) them.
2. Bridges a document's JSON properties with native-language object properties, letting you use idiomatic getter/setter calls: getXXX and setXXX in Java, or "." notation in Obj-C and C#.
3. Translates between native types and JSON types — at a basic level this involves boxing/unboxing scalars, but it can also convert higher-level platform types that don't have a JSON representation, like Date and Data, and can be extended to allow app-defined classes to marshal/unmarshal into JSON.

The first — mutable state — is platform neutral. IMHO it's something we should definitely make cross-platform.

The second is valuable but the details are very language-specific. Objective-C uses dynamic properties and some runtime handlers that synthesize the getter/setter methods the first time they're called. Java of course has to do this differently, probably using reflection (and maybe a code generator that spits out the source code for the get/set methods?) I don't know how C# would do it.

The third is mostly a detail of the second. I broke it out because I believe the Jackson library already provides this type of functionality in Java.

So what I'm thinking is that we should consider CBLModel minus the dynamic property support, and take that cross platform. Each platform would then add its own appropriate APIs to that class to enable the property bindings.

—Jens