On 01/08/2014 09:57 AM, Tadeas Kriz
wrote:
On 01/08/2014 09:42 AM, Tadeas
Kriz wrote:
On 01/08/2014 05:51 AM, Tadeas Kriz wrote:
Hey everyone,
I’ve been recently going through the DataManager
API in aerogear-android. In this email, I’d like
to suggest addiction of two method (or possibly
three) into the `Store<T>` interface. These
would be:
```java
/**
* If store is open, it can be read or written to.
*/
boolean isOpen();
/**
* Opens store in current thread (blocking).
*/
Store<T> open();
/**
* Opens store in background thread and then
callback#onSuccess is called.
*/
void open(Callback<Store<T>>
callback);
```
I think those are fine. Feel free to JIRA it up and
Passos and I will
review.
From my point of view,
this makes sense to be in the `Store<T>`
so I can switch between stores easily during
development with no need to change other code.
Also, if `read` or `write` operations are done
with closed store, there are two possible
workflows. First one is, that I’d fail and throw
an exception. Second (and for me a preferred
one) is, that all those methods would internally
check if the store is open and if not, they’d
call the `open` method. This also leads me to
another API change for `Store<T>`.
```java
/**
* Reads all the data from the underlying storage
system asynchronously.
*/
void readAll(Callback<Collection<T>>
callback);
/**
* Reads a specific object/record from the
underlying storage system asynchronously.
*/
void read(Serializable id, Callback<T>
callback);
/**
* Search for objects/records from the underlying
storage system asynchronously.
*/
void readWithFilter(ReadFilter filter,
Callback<List<T>> callback);
/**
* Saves the given object in the underlying
storage system asynchronously.
*/
void save(T item, Callback<Void> callback);
/**
* Resets the entire storage system
asynchronously.
*/
void reset(Callback<Void> callback);
/**
* Removes a specific object/record from the
underlying storage system asynchronously.
*/
void remove(Serializable id, Callback<Void>
callback);
/**
* Checks if the storage system contains no stored
elements asynchronously.
*/
void isEmpty(Callback<Boolean> callback);
```
That’s right, async methods for easy access to the
storage from background thread, without the pain
of writing it myself (for example, it makes no
sense if I want to just call `store.save(..)` and
I’d have to write all the `AsyncTask`
boilerplate).
So, what do you think?
I would rather throw an exception than open a
database when you call
read and friends. That way a developer doesn't
accidentally open a
database he meant to be closed. I don't have that
strong of a feeling on
that point one way or another however.
That’s right, it’s probably less error prone in
scenarios when you want the store closed.
My stronger feeling is on adding callbacks to the
stores methods. I
prefer for the Store to be synchronous and Pipes to
be asynchronous. We
could add a StorePipe to our PypeTipes which may
solve some of the headache.
Would “void open(Callback<Store<T>>
callback);” make sense then? I mean, that would add
another inconsistency in the API, as one method would
be async and the rest would be only synchronous,
wouldn’t it?
True. The reason for the exception here was that opening a
SQL store or an encrypted store COULD take significant
amount of time. For in Memory data stores this is instant of
course.
I understand, but that’s just an assumption. Let’s say that
there’s a storage, that’d take an instant to load data from,
but a lot of time to save data (like XML file based store).
What’s the main reason to not have async “read”/“write”
methods?
The best reason I can give is if your Store implementation will be
that slow either a) Write a Pipe instead or b) Manage the latency
yourself.
In Android land you want code on your main thread to be fast or non
blocking. If we are working off the main thread then having things
be slow and blocking is less of an issue. Synchronous code is
easier to debug (in Java) and easier to write (in Java) and faster
(because we don't have to route through callback classes).
Having either or, in my opinion, clouds what your usage target
should be.
Also this is the most though Stores have been given in a long time.
Anything we come up with we will probably need to get the other
platforms alerted to as well.