Hi Jon Thanks again for your reply.
>All data will always be out of date to some degree. (Consider: user launches app, sleeps the device, returns an hour later. Will your >data be updated? Should it be?) The question is, what is a reasonable boundary for caching. You can always provide an explicit >Refresh command if the cached data is "too old." Sorry I should have worded this better. The solution that I have implemented is exactly as you have described. 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. 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 have never really done any caching of plain objects so I am not too sure on how I could/should measure the amount. The Image cache is simple as all the images are the same in terms of their classification but with my business objects there are relationships etc. that should be also be persisted in the cache. Are there any standard caching examples/libraries that have been written for or used in Mono mobile apps? Thanks Again Liam On Tue, Jul 3, 2012 at 3:12 AM, Jonathan Pryor <j...@xamarin.com> wrote: > On Jul 1, 2012, at 11:16 PM, Liam Houlahan wrote: > > 1. Calling the GC did help with things however because the GC takes a > millisecond or whatever to execute the UI suffers and gets a stutter > effect. Is there a way to avoid this? > > My usual advice is to call it within Activity.OnDestroy(), as that's done > when the UI is being hidden. That may or may not be appropriate. > > > In terms of memory management and making requests based on the > individual activities my biggest concern is really the user flooding the > app with network requests. Something else that has an influence on this in > my app is that I am also loading images within my activities and caching > them. I suspect that this was a cause for getting out of memory. > > > > I have come up with a solution based on the ImageLoader in the MWC app. > I have managed to hack together a version of this ImageLoader that unifies > queuing of the image requests and the data requests. This seemed good for > managing the memory but it now has some other issues. Ideally what I think > I need is: > > - Two queues one for images and one for the data requests. > > - The worker for processing the queues should limit the number of > requests across the queues. > > - The data queue should take higher priority to the image queue. So the > data queue is always processed before the image queue. > > - If the activity is destroyed before loading all of the data/images it > should dequeue any outstanding requests. Any ideas how I might dequeue if I > am using something like the ImageLoader from the MWC app? > > Unfortunately no. > > > What are your thoughts on this design for managing the requests? > > This makes a lot of sense: centralize network access so that you can > prevent flooding. You could also implement a data caching layer here (so > for e.g. image data you check disk before sending the network request), > transparent to the caller. > > > I still need to make individual requests for each activity as the data > retrieved from each request is specific to the individual activity and it > can only be retrieved on the per activity basis. I need to have realtime up > to date info for each activity. > > Do you? Really? :-) > > All data will always be out of date to some degree. (Consider: user > launches app, sleeps the device, returns an hour later. Will your data be > updated? Should it be?) The question is, what is a reasonable boundary for > caching. You can always provide an explicit Refresh command if the cached > data is "too old." > > This may be apocryphal, but at last weeks MADExpo I heard a story that > Microsoft was profiling some web apps, and found that for a large number of > them 95% of all database access requests can be avoided if you implement a > 5s data cache. 5s isn't a terribly long time, and it supposedly had a large > reduction on database queries. > > > If I initiate the all of the requests from the Application class as you > suggest and then raise the events to update the activities from the > application class when raising the event should it always be done on the UI > thread using SynchronizationContext.Post? Or is it ok to raise it on > another thread, then in the event handler in the Activity call > RunOnUIThread? > > Both sound appropriate; pick one and stick with it (to minimize confusion). > > - Jon > > _______________________________________________ > Monodroid mailing list > Monodroid@lists.ximian.com > > UNSUBSCRIBE INFORMATION: > http://lists.ximian.com/mailman/listinfo/monodroid >
_______________________________________________ Monodroid mailing list Monodroid@lists.ximian.com UNSUBSCRIBE INFORMATION: http://lists.ximian.com/mailman/listinfo/monodroid
