That could also work, since it would keep things simple and efficient. I think this approach makes more sense anyways, since I can fill out my onResume functions to first check for latest versions of said number and if it's newer, then invalidate old data, fetch new set, and populate, or whatever else that needs to be done regarding that new event.
On Jun 9, 12:02 pm, Dianne Hackborn <hack...@android.com> wrote: > 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
