I just got to the section on Reloading the list, and when I ran the experiment to update a Crime and then click back to return to the list view. The update is displayed in the list view? I even noticed if I clicked back to exit the app then restarted the changes were still present. Is it possible there is an update to the support library, or maybe some nuance of running the app on a simulator. I definitely haven’t added the on_resume code yet, so I’m not sure how I added the functionality. Thanks. Great book.
Try doing it a few times. We often have students say, “Hey, it’s already updating without the onResume code!” Then when I go and look at it, it magically doesn’t work the second time.
Whether or not it appears to work on first try, you need to have that code in onResume. You can’t absolutely rely on that behavior.
In my code, the list view was updated before the onResume code was added, but only after the screen was rotated in the list view. That makes sense, in a way, but not particularly useful to me at the moment. It would seem the the screen rotation does a manual onResume.
That makes sense - on rotation, it would of course destroy and recreate the list, which would cause its data to be reloaded.
Same here, even if I rotate the emulator the list status is unchanged.
Just test it in a real device, then it doest work
I’ve only just seen this, and am puzzled.
I had assumed that every reference to a Crime would address the location in CrimeLab where that Crime is located.
Since CrimeLab is a singleton, it only gets loaded once, and our ‘TextChanged’ listener will update the location of the Crime it is operating on.
This actually is the case with me. I find whatever I do then any edit I do is persistent.
I’m not using the support library, rather the API 11 interface discussed on page 147. Our getView() is called from ListView whenever it needs to show an element. And I find, on stepping through the code that the Crime location given by getItem(pos) is in fact the location within mCrimes in CrimeLab. And this is also the location altered when we edit the text in our TextChanged listener. “Reloading” the list doesn’t seem to be meaningful.
Maybe there is a difference between the support library and the API 11 interface? Or the underlying OS has a different strategy for caching screens?
Or maybe I’m confused…(more likely)…
Either way, please help.