Yes only updating when the data has changed is a good approach. Instead of a timestamp, I would suggest just using a sequence number that you increment every time the data has changed. This technique is used in a lot of places in Android -- for example to know when the locale cache of the Settings provider values is out of date, or when dispatching a new Configuration to determine if it is a newer one than the last one that was handled.
On Thu, Jun 9, 2011 at 7:59 AM, Diego Tori <diegotoridoesandr...@gmail.com>wrote: > So you're saying in this case it's better to just populate the UI in > onResume for data that is dependent on the outcome of that event? That > would be the case for a couple of activities that depend on it. > However, I'm more concerned about the performance impact, since this > data in particular has dozens of members and if I have to re-create > the UI every time onResume is called, it will create a bad UX within > those Activities, even if I put up a loading screen and use a thread. > > I guess one way to reduce the number of unnecessary data refreshes is > once my event occurs, I save a timestamp to my in-memory cache, and > then every time an activity is added to the stack, it retrieves that > value and keeps it there. As a result, every time the user generates > the event, all the other activities below it will check the new > timestamp in onResume and if the latest one is greater than the one > the activity has, it refreshes itself and its current timestamp value. > Also, my app guarantees that this event will occur when it first > starts up, before it launches its home activity, so there will be a > timestamp available. > > On Jun 8, 5:02 pm, Mark Murphy <mmur...@commonsware.com> wrote: > > On Wed, Jun 8, 2011 at 4:16 PM, Diego Tori > > > > <diegotoridoesandr...@gmail.com> wrote: > > > That's the thing, if I set a shared preference flag or cached flag via > > > cache object, and they did try to check for that value in onResume, > > > wouldn't the first activity from the back stack to get the foreground > > > check its state, then set it back to false after checking for it being > > > true before having to do work? > > > > Delete the flag. You don't need the flag. Update the UI of the > > activity in onResume(). Period. > > > > > Even if I didn't reset the flag, every > > > time it would hit that function, it would still get caught in that > > > flag, so that isn't really useful. > > > > Hence, get rid of the flag. Update the UI of the activity in onResume(). > Period. > > > > > So there is no way that I can just > > > broadcast one intent that my listening activities can listen to after > > > the intent is sent as soon as they get the foreground again? > > > > What makes you think that your activity even exists? Your > > non-foreground activities may not even be in memory, because Android > > may have destroyed them to save RAM. > > > > If you simply update your UI in onResume(), it handles both the > > activity-in-RAM and the activity-out-of-RAM scenario. > > > > Your proposed model is akin to: every time Google indexes a new page, > > it proactively updates every browser on the face of the planet, even > > those that do not use Google, do not care about the newly indexed > > page, or are not even running. > > > > > Keep in mind that this is not a one-time event. > > > > All the more reason to not push updates out to activities that do not > > yet need the information. > > > > > Rather it is an event > > > that the user generates, all I want those other activities to know is > > > whether or not the event was generated by the user while in the > > > background. > > > > So, update the UI of the activity from your persistent store or > > in-memory cache in onResume(). Period. > > > > -- > > Mark Murphy (a Commons Guy)http://commonsware.com| > http://github.com/commonsguyhttp://commonsware.com/blog|http://twitter.com/commonsguy > > > > Android 3.0 Programming Books:http://commonsware.com/books > > -- > You received this message because you are subscribed to the Google > Groups "Android Developers" group. > To post to this group, send email to android-developers@googlegroups.com > To unsubscribe from this group, send email to > android-developers+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/android-developers?hl=en > -- Dianne Hackborn Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
