Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How do I retrieve data and why is there no "get" method? #44

Closed
ocram opened this issue Dec 13, 2015 · 1 comment
Closed

How do I retrieve data and why is there no "get" method? #44

ocram opened this issue Dec 13, 2015 · 1 comment
Labels

Comments

@ocram
Copy link
Contributor

ocram commented Dec 13, 2015

No description provided.

@ocram ocram added the question label Dec 13, 2015
@ocram
Copy link
Contributor Author

ocram commented Dec 13, 2015

There are two special things about Meteor: It works asynchronously and it has been designed specifically for real-time applications. Thus it has a few different concepts for retrieving data and for some other tasks.

In a synchronous application, you would just call insert(...) and immediately get the method's return value, e.g. a boolean value for success/error or a numeric value for the number of rows that have been inserted.

You would call get(...) and immediately receive a collection of rows as the method's return value.

But in Meteor, everything is asynchronous. This means that you get the results not immediately, but a few (milli)seconds later, in a callback method.

When you call insert(...), this is not so important, as you have noticed. You just call this method and often forget about the result, i.e. you don't wait and check for the result because insertions are usually successful. But this method is still asynchronous and you could (and sometimes should) listen for the result which will arrive a few (milli)seconds later, again.

When you want to call get(...), this would be possible in theory, with the important point again being that it's asynchronous. So you would say "get me all chat messages from the last 5 minutes". There would be no result or return value, as usual, but the result would arrive a short time later, asynchronously, in a callback method that you define. This is what onDataAdded(...), onDataChanged(...) and onDataRemoved(...) are for.

Now it's not clear, yet, why you can't call get(...) and wait for data to arrive in those methods.

The answer to that question is Meteor being designed for real-time applications. This is why you can't say "get me all chat messages from the last 5 minutes". Instead, you have to say "I want to subscribe to all chat messages from the last 5 minutes and always be updated about changes".

So, in Meteor, you subscribe to data sets instead of requesting them via get(...).

All in all, this means the following:

  1. If you want to get some messages, you subscribe to your data set that holds those messages.
  2. When the initial rows are sent (!) and whenever new rows are added to the collection, you receive those in your onDataAdded(...) callback. When rows are modified, you receive those changes in your onDataChanged(...) callback. And, finally, when rows are deleted, you are informed about those deletions in your onDataRemoved(...) callback.
  3. When you don't want to get updates for your data set anymore, you unsubscribe from that set. This is optional.

With the Android-DDP library in your Android application, it translates to the following:

  1. final String subscriptionId = mMeteor.subscribe("chats");
  2. public void onDataAdded(String collection, String docID, String json) { ... }
  3. mMeteor.unsubscribe(subscriptionId);

As you can see, what you have to learn is really Meteor and not the library Android-DDP. Meteor has some new concepts that one has to understand. But when you know how Meteor works, translating those things to Android-DDP is really simple and only a matter of looking up the method names.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant