If #7 gets merged, then there isn't much point in the android tests any more. The android version of GRexPersister is an almost trivial extension of BaseGRexPersister and doesn't really need any tests.

Further, with the new unit testing support, Roboelectric is not needed any more. The unit testing stuff is new, admittedly, so it may not be totally stable.

In any case, the roboelectric-gradle-plugin version needs bumping, because the current version is incompatible with v1.1 of the android gradle plugin(I have a feeling that gradle plugin incompatibility is going to be a major headache in the future...).

I've found only the onComplete will be invoked, it's really odd.

I should have spotted this one a while ago.

Since all the get(), getList(), etc. methods take a Class<T> instead of a Type, it's not type-safe to use them with generic classes. If you want to try to get some Foo<Bar> back out you have to call the method with Foo.class and then cast from Foo to Foo<Bar>, which is not great.

The Converters use Type so it should actually not be a problem to change all of those methods to take Type. Furthermore, it shouldn't be a breaking change since Class<T> implements Type. All existing code should just work.

What do you think?

If you create new Android project, configure Kotlin (add Kotlin dependencies) and add RxStore dependencies Android build will fail with Error:
_Execution failed for task ':app:transformClassesWithDexForDebug'.

com.android.build.api.transform.TransformException: com.android.ide.common.process.ProcessException: java.util.concurrent.ExecutionException: com.android.dex.DexException: Multiple dex files define Lorg/jetbrains/annotations/NotNull;_

(make sure to run gradle build task becouse with incremental compilation this may actually work sometimes )

This happens becouse both Kotlin and RxStore are adding the same dependency to the project org.jetbrains.annotations

Fix
compile ('au.com.gridstone.rxstore:rxstore:5.0.5') { exclude group: 'org.jetbrains'} compile ('au.com.gridstone.rxstore:rxstore-kotlin:5.0.5') { exclude group: 'org.jetbrains'} compile ('au.com.gridstone.rxstore:converter-moshi:5.0.5') { exclude group: 'org.jetbrains'}

For now this fix works, but I wondes can we make it work by default? (kind of making dependencies optional?)

This is more of a tentative suggestion than an issue, but I wanted to get some opinion on it before I do any work on it and submit a pull request.

It seems slightly a shame that this library isn't "pure" Java. It would precisely fit a use case I have which isn't on Android, and the only thing preventing that is a single line of code!

I think it would be straightforward to create a grex-core library which the main grex library would then have as a dependency. And then the main grex would continue to be usable directly and transparently on Android, but people like me could use grex-core in a Java project and just provide the (hopefully tiny) implementation detail that would be needed.

The main problem with this approach is probably that it increases the maintenance load a non-trivial amount, but hopefully not too much. Apart from that I can't see any major problems with the idea, but just wanted to get some feedback before starting on it.

I'd also like to say for the record, I really like this library, and I'm hoping many more pop up providing an RxJava interface to useful functionality.

Hi. I want to make some sort of cache with your lib. Rxcache just don't work with dagger2.
Is there any way to delete files after I don't need them anymore?

Hi, I like lib, great job!

But I'm using Jackson against Gson in my projects, so possibly it will be much better to create something like .setConverter() in Retrofit?

I have and idea for Enhancement : store objects in a zip, to reduce size on phone

java.lang.RuntimeException: java.io.IOException: open failed: EROFS (Read-only file system)

I am trying to implement this using RxJava2. It was working fine in earlier version with RxJava!

Here is my piece of code :

`
ListStore suggestionListStore = RxStore
.list(new File("SearchSuggestion"), new GsonConverter(), SearchQuery.class);

    BaseNetworkSubscriber2<Object> baseNetworkSubscriber2 = suggestionListStore.get()
            .toObservable()
            .flatMap((Function<List<SearchQuery>, ObservableSource<?>>) searchQueries -> {
                ArrayList<SearchQuery> searchQueries2 = new ArrayList<>(searchQueries);
                searchQueries2.add(query);
                Single<List<SearchQuery>> listSingle = suggestionListStore
                        .observePut(searchQueries2);
                return listSingle.toObservable();
            }).subscribeWith(
                    new BaseNetworkSubscriber2<Object>(getView().getAppContextFromView()) {
                        @Override
                        public void onComplete() {
                            super.onComplete();
                        }

                        @Override
                        public void onError(Throwable e) {
                            super.onError(e);
                            e.printStackTrace();
                        }

                        @Override
                        public void onNext(Object o) {
                            super.onNext(o);

// getView().showRecentSearchSuggestion(suggestions);

                        }
                    });
    CompositeDisposable compositeDisposable = new CompositeDisposable();
    compositeDisposable.add(baseNetworkSubscriber2);`

Just wondering if there's any chance of a release happening soon based on what we merged? If there's work that needs doing to get it ready I'm happy to help.

Hello, I've been using this lib for some time now in my project. However, I found that my stores and data get corrupt at times. Upon examination, I found that data might be corrupted if the app is killed during the converter.write call, resulting in an incomplete write and so a corrupt file. This seems like a critical issue with this lib, IMHO could be solved by writing the data to a randomly named temporary file and then doing a rename-overrite to the key name so that at no point in time the store file is in an invalid state.

Would having a "latest version" for regular ol' RxJava users make sense? I say this as someone who essentially has to run RxJava in a project and can't upgrade at the moment but still want to use this library as it was before the RxJava2 update.

Thanks for the awesome lib with Rx!! I'm thinking of it will be more awesome with Disk-based LRU cache which specifically targets Android compatibility (https://github.com/JakeWharton/DiskLruCache )
like https://github.com/anupcowkur/Reservoir lib implemented.

Hopefully I am missing something here, but at first glance, it seems that addToList is not thread safe (race conditions can lead to lost updates).

I can see you have thought about write locks elsewhere (via the runInWriteLock method) but observeAddToList calls get() internally which uses a read lock.

Hopefully you have more insight into this, but it is a blocking issue for me.

Right now, when building this, you need an internet connection for the apply from line in build.gradle in the grex module. I understand what it's for, it's so you can publish to Maven Central, but it's a wee bit annoying when trying to work on the library with no/patchy internet, even though you've got all the dependencies locally cached.

I know of two ways of solving this:

1. Copy Chris Banes' gradle script into the repo, and use apply from with a relative path. I've seen this used in other projects but not done it myself.
2. Publish to jCenter, and let them push to Central. They have a gradle plugin which makes it all really easy. I've done part of this, the publishing to jCenter bit, but I didn't do the pushing to Central bit just because it's a bit of a faff to get set up on Maven Central.

Option 2 would be my preference, but it's not possible to do it via a PR since you'd want control of the Bintray repo and it needs your Maven Central password to do it. It's all actually really easy, since Bintray has good interfacing with GitHub, but it's up to you in the end.

Hello,
A Weird issue is coming up where a List of type X class is being converted into LinkedTreeMap when fetching from store.
`{
"selectedFilters": {
"LanguageFilter": [
{
"displayName": "German",
"mChecked": true,
"name": "German",
"value": 3
}
],
"LocationRadius": 50,
"SortOrder": [
{
"displayName": "By Distance",
"mChecked": true,
"name": "ByDistance",
"value": 1
}
]
}
}

The above screenshot will help. This is while fetching and when i am saving it in store, the actual model class is there`

can you compare your lib with snappyDB

https://github.com/nhachicha/SnappyDB

what being advantages/disadvantages that you can quickly see?

Don't you think it will be more natural if grex getters will fall into error while can't find value for key?
I see popular scenario here: i'am trying to get something persisted, and if i can't i'll go fetch from web.
Rx have some useful methods to handle error state, but emitting null not so cool.

example:

What i'm doing now:

 persister.get(key, City.class)
        .filter(city -> {
          if (city == null) {
            throw new NullPointerException("Can't get persisted value for: " + key);
          }
          return true;
        })
        .onErrorResumeNext(
            locationController.detectNearestCity().doOnNext(this::showDetectedCityInfo))
        .subscribeOn(Schedulers.io())
        .observeOn(AndroidSchedulers.mainThread())
        .subscribe(cityProperty::set, error -> Timber.d(error, "can't get selected city property"));

and with emitting error:

 persister.get(key, City.class)
        .onErrorResumeNext(locationController.detectNearestCity().doOnNext(this::showDetectedCityInfo))
        .subscribeOn(Schedulers.io())
        .observeOn(AndroidSchedulers.mainThread())
        .subscribe(cityProperty::set, error -> Timber.d(error, "can't get selected city property"));

Great lib !
But I have a problem, How can I know if an object already exists in the RxStore ?

Right now it sucks working with a Writer and a Reader, making it very difficult to support Moshi, or wrap files in GZip streams. Would be nice to come up with a more flexible solution.