Skip to content
This repository has been archived by the owner on Mar 16, 2021. It is now read-only.

Memory cache #22

Open
stephanenicolas opened this issue May 17, 2015 · 6 comments
Open

Memory cache #22

stephanenicolas opened this issue May 17, 2015 · 6 comments
Milestone

Comments

@stephanenicolas
Copy link

Would it be possible to add a memory cache mechanism to Tray to boost its performances.

Something inspired by https://github.com/tumblr/Remember ?

@passsy
Copy link
Contributor

passsy commented May 18, 2015

read it yesterday, too. After checking the implementation I'm not sure if it is possible with Tray because Remember doesn't work multiprocess, it's only thread safe.
Of cause you could swap out the SharedPreferences in Remember and replace them with Tray but losing the key feature of Tray seems wrong. The API itself is identical and Tray wouldn't benefit from this wrapper.
Also Remember doesn't detect changes in the SharedPreferences made with another API than Remember. This could lead to big problems when you use Remember and the SharedPreferences in the same project.

Side note: Having Guava as a hard dependency for a single class SharedPreferences wrapper seems wrong.

I'm currently working on dataChangedListeners which work multiprocess. Once they are complete I'm confident an in memory layer which updates itself based on the listeners is possible.

@stephanenicolas
Copy link
Author

Hey Pascal,

I agree that guava as a dependency for an android app is a nightmare.

But I am not sure to understand why you couldn't build a memory cache
backed by tray. The concurrency can be handled well in java. There must be
something else that is blocking you, no ?

@passsy
Copy link
Contributor

passsy commented May 18, 2015

It's only the multiprocess thing. If you have two processes, a SyncAdapter and your Application UI, there will be two instances of the memory cache. Although the memory cache is a singleton! So they are working on two different data sets and both instances wont know about each others changes.
Trays current implementation solves this problem by using IPC with the ContentProvider. This is slow but the data is always correct.

@stephanenicolas
Copy link
Author

Humm, I must get more familiar with Tray before going on this thread. I am
not sure I got all the pieces of the puzzle.
But it's in the pipeline, I should give it a try soon.

Thx for your answers,
Stéphane

2015-05-18 8:33 GMT-07:00 Pascal Welsch notifications@github.com:

It's only the multiprocess thing. If you have two processes, a SyncAdapter
and your Application UI, there will be two instances of the memory cache.
Although the memory cache is a singleton! So they are working on two
different data sets and both instances wont know about each others changes.
Trays current implementation solves this problem by using IPC with the
ContentProvider. This is slow but the data is always correct.


Reply to this email directly or view it on GitHub
#22 (comment).

@passsy passsy added this to the 1.1.0 milestone Sep 15, 2015
@passsy
Copy link
Contributor

passsy commented Sep 27, 2015

A memory chace is now possible with new data changed listener which can be used to sync the database with the cache in the background

@passsy
Copy link
Contributor

passsy commented Nov 5, 2015

Listener work as expected. I'll focus on the memory cache now

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Development

No branches or pull requests

2 participants