Investigate LruCache usage for the persisters / cache manager about robospice

[andaag]

We've considered something like this for our project:
http://blog.wu-man.com/2012/10/twolevellrucache-standing-on-shoulder.html

I wouldn't mind having a memory cache sit ahead of the disk cache in a lot of cases. Of course optimally it would only drop to disk when the memory cache fills up.

[stephanenicolas]

David Stemmer has been working on an LruCache in memory that is supported by a file based ObjectPersister. It is integrated to master github's branch for now. We are waiting for a sample from David to integrate this new tech and realeasing RoboSpice cache 1.4.1.

[andaag]

Is there a pull request/discussion about this somewhere?

His approach is very simple and clean, and one I've seen used many places.

save:
put to memory cache
put in disk cache

However, I'd like an option to do this instead:
put in memory cache

if memory cache full (on entryRemoved(evicted=false)) drop to disk cache. It might be a good idea to try to group up the cache cleanups as well, to reduce disk io as much as possible and extend battery life. I don't know if it's a better idea, and it's more complicated, but I think it's worth considering.

[stephanenicolas]

The problem I got with this approach is that you can never know on Android
when your process is gonna get killed by memory pressure.
In that case, we have no hook to get notified and put the data to disk
before the RAM cache get garbage collected.

S.

2013/2/17 andaag [email protected]

Is there a pull request/discussion about this somewhere?

His approach is very simple and clean, and one I've seen used many places.

save:
put to memory cache
put in disk cache

However, I'd like an option to do this instead:
put in memory cache

if memory cache full (on entryRemoved(evicted=false)) drop to disk cache.
It might be a good idea to try to group up the cache cleanups as well, to
reduce disk io as much as possible and extend battery life. I don't know if
it's a better idea, and it's more complicated, but I think it's worth
considering.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/42#issuecomment-13682512.

Stéphane NICOLAS,
OCTO Technology
Développeur & Consultant Android / Java
..........................................................
50, Avenue des Champs-Elysées
75008 Paris
+33 (0)6.26.32.34.09
www.octo.com - blog.octo.com
www.usievents.com
...........................................................

[andaag]

You can monitor onTrimMemory, I believe that's a pretty sure way of catching it. And you can do that in the service itself, so the activity knows as little about the caching/background stuff as possible.

[stephanenicolas]

Ok, I would be open to an implementation. Do you wanna fork RS ?

S.

2013/2/17 andaag [email protected]

You can monitor onTrimMemory, I believe that's a pretty sure way of
catching it. And you can do that in the service itself, so the activity
knows as little about the caching/background stuff as possible.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/42#issuecomment-13689628.

Stéphane NICOLAS,
OCTO Technology
Développeur & Consultant Android / Java
..........................................................
50, Avenue des Champs-Elysées
75008 Paris
+33 (0)6.26.32.34.09
www.octo.com - blog.octo.com
www.usievents.com
...........................................................

[andaag]

Building something that sticks with memory cache by default and monitors onTrimMemory is on my todo list, but we're not quite there yet. When we get the application I'm working and move on to the polishing stage we'll do some performance measurements in the caching system and see if we want to replace it. If we get it working well you can expect a pull request :)

[stephanenicolas]

Fine ;)

2013/2/19 andaag [email protected]

Building something that sticks with memory cache by default and monitors
onTrimMemory is on my todo list, but we're not quite there yet. When we get
the application I'm working and move on to the polishing stage we'll do
some performance measurements in the caching system and see if we want to
replace it. If we get it working well you can expect a pull request :)

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/42#issuecomment-13761163.

Stéphane NICOLAS,
OCTO Technology
Développeur & Consultant Android / Java
..........................................................
50, Avenue des Champs-Elysées
75008 Paris
+33 (0)6.26.32.34.09
www.octo.com - blog.octo.com
www.usievents.com
...........................................................

[stephanenicolas]

Issue is closed to clean up the list of issues. It can be reopened by anyone to submit a pull request.

[StingerAJ]

Wouldn't it be better to assign a new label "needs contribution" or something like that instead of closing?
I don't think people will easily contribute to closed issues.

[stephanenicolas]

You are right, but is that possible with github ?

2013/5/16 StingerAJ [email protected]

Wouldn't it be better to assign a new label "needs contribution" or
something like that instead of closing?
I don't think people will easily contribute to closed issues.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/42#issuecomment-17988251
.

Stéphane NICOLAS,
OCTO Technology
Développeur & Consultant Android / Java
..........................................................
50, Avenue des Champs-Elysées
75008 Paris
+33 (0)6.26.32.34.09
www.octo.com - blog.octo.com
www.usievents.com
...........................................................