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
