On Jul 4, 2012, at 12:36 AM, Liam Houlahan wrote:
> For the data caching this application could very much make use of caching
> business objects. I am already using the ImageLoader cache for images which
> caches a maximum of 50 images in memory at any one time.
Remember the primary rule of caching: A cache with a bad policy is another name
for a memory leak:
http://blogs.msdn.com/b/oldnewthing/archive/2006/05/02/588350.aspx
Having a GC doesn't change this; if you have a "cache" with no mechanism/policy
to remove items from that cache, you don't have a cache, you have unbounded
memory growth. (Perhaps you need "unbounded memory growth" -- see XLinq, etc.
-- just don't call it a cache.)
> The data in this app is grouped by days. At any one time the user will only
> be viewing data for a selected day. How might I/should I go about caching the
> business objects in terms of limiting the amount of objects in memory at any
> one time to limit the amount of memory used? Do business objects take up
> enough memory to even be concerned?
I don't know; I'm sure there are various patterns for this. One thing to keep
in mind: if your business objects inherit Java.Lang.Object, directly or
otherwise, their lifetime is automatically extended and they hold a gref. This
may be intended/required; it's something you need to explicitly choose.
Given your requirement that the object graph contain relationships/etc., what
may make more sense is to have a local disk "cache" of the XML/JSON/whatever
you received from the server, and deserialize that data within the Activity
that needs it. When the Activity dies, drop the object graph and recreate it
when you need it again (assuming that the data is read-only and derived from
the cached representation).
- Jon
_______________________________________________
Monodroid mailing list
[email protected]
UNSUBSCRIBE INFORMATION:
http://lists.ximian.com/mailman/listinfo/monodroid
