tray
tray copied to clipboard
Memory cache
Would it be possible to add a memory cache mechanism to Tray to boost its performances.
Something inspired by https://github.com/tumblr/Remember ?
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.
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 ?
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.
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 [email protected]:
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 https://github.com/grandcentrix/tray/issues/22#issuecomment-103105955.
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
Listener work as expected. I'll focus on the memory cache now