8:42 a.m.
On 08 Jan 2014, at 15:30, Summers Pittman <supittma(a)redhat.com> 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?
Passos, wdyt?
>
> PS: You can find the whole text with highlighted syntax here:
>
> —
> Tadeas Kriz
> tkriz(a)redhat.com
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev