

Show HN: Meteor client for Android - marco1
https://github.com/delight-im/Android-DDP/blob/master/README.md

======
djmashko2
It would be even more awesome if this supported automatic data caching from
subscriptions, like the Meteor web client with Minimongo or meteor-iOS does
with CoreData: [https://github.com/martijnwalraven/meteor-
ios](https://github.com/martijnwalraven/meteor-ios)

~~~
marco1
Thanks! I've thought about this already but wasn't sure what to do.

In its original JavaScript implementation, Meteor has Minimongo, as you said.
But building such an interface in Java would lose all the convenience,
wouldn't it? The advantage of Minimongo is that you can use it just like
MongoDB itself, e.g. "myColl.find({ _id: "some-key" })", which is not possible
(with that syntax) in Java.

Then you mention Core Data from iOS, which is great as well, but specific to
the platform again. Android doesn't have this.

What would be an equivalently widespread (and convenient) solution for
Android? Storing it in SQLite? Or deeply nested "Map<String, Object>"
instances?

~~~
djmashko2
The way I understand it, a replacement for Minimongo just for reading data
needs two things:

    
    
      1. A simple filtering/querying API (doesn't need to be as fancy as Mongo)
      2. Change events on filtered views of data so that you can update the view
      when new data comes from a subscription
    

If you also want Meteor Method-style optimistic UI, then you need:

    
    
      1. Tracking of temporary changes from a specific method
      2. Ability to roll back those changes when DDP tells you it's done
    

Having a mongo-specific syntax isn't crucial, I think.

~~~
marco1
Sounds good, thanks!

Such an in-memory database seems quite important for productivity, so I will
definitely consider this.

Read access could be implemented in a first step, while the semantics would
still have to be discussed. I think write access would actually be quite
important as well so that you can completely abstract away the sending,
receiving and processing of events.

Latency compensation or optimistic UI would be nice to have (for making
applications more snappy), but I think this is only the third most important
piece.

Maybe one can use "SQLiteOpenHelper" with "name" set to "null" for in-memory
storage. Or perhaps some things can be adopted from or based on Minimongo,
Realm or MapDB:

[http://www.quora.com/How-is-Meteors-client-side-database-
imp...](http://www.quora.com/How-is-Meteors-client-side-database-implemented)

[https://realm.io/](https://realm.io/)

[https://github.com/jankotek/mapdb](https://github.com/jankotek/mapdb)

------
jchung
Could you please explain when I'd want to use this vs. using the built-in
Meteor mobile app system[1]?

[1]
[http://docs.meteor.com/#/basic/buildingmobileapps](http://docs.meteor.com/#/basic/buildingmobileapps)

~~~
marco1
Thanks for asking, I should have made this clearer, both here and in the
documentation.

This library is for building _native_ Android apps (written in Java) that can
talk to a Meteor server via their DDP protocol.

On the other hand, Meteor's built-in app system is for building _wrappers_
around _web applications_ that are built with HTML/CSS/JavaScript. For that,
you don't need an Android client, of course, because it just uses their normal
JavaScript libraries.

