I'm sorry, but I'm still not understanding what exactly I should be holding a reference to. What should mData contain (or rather, what are the properties in the MyRetainedData class)? I appreciate the help immensely :)
Bara On Jun 22, 10:23 am, Streets Of Boston <[email protected]> wrote: > You return an object that doesn't hold any permanent residence to an > activity, just a temporary one. > > private final Runnable mUpdateDisplayRunnable = new Runnable() { > public void run() { > mData.getCurrentActivity().updateDisplay(); > } > > }; > > public void onCreate(...) { > ... > mData = (MyRetainedData)getLastNonConfigurationInstance(); > if (mData == null) { > mData = new MyRetainedData(); > ... > ... > } > mData.setCurrentActivity(this); > ... > > } > > public void onDestroy() { > ... > // don't hold on to activity about to be destroyed > mData.setCurrentActivity(null); > .. > > } > > public Object onRetainNonConfigurationInstance() { > return mData; > > } > > The trick here is that the field mData in the destroyed Activity and > the newly created Activity point to the exact same instance of > MyRetainedData. This instance almost acts like a static/global > variable > > And if you would be using AsyncTasks in your app, you can put > references to those in the MyRetainedData to hold on to them when > changing configurations. Or you could stuff other stateful data in > there that needs to survive config-changes. > > On Jun 21, 11:30 pm, Bara <[email protected]> wrote: > > > Wait, what exactly should I be returning with > > onRetainNonConfigurationInstance? Wouldn't anything I return with > > that be from the original activity, not the new one? So wouldn't that > > cause the same problem? > > > Bara > > > On Jun 21, 7:27 pm, Streets Of Boston <[email protected]> wrote: > > > > This probably happens because your runnable 'mUpdateDisplayRunnable' > > > has an implicit reference to 'this' activity that calls > > > 'this.updateDisplay()' in its run() method. > > > > When an orientation-change happens the current activity ('this') is > > > destroyed a brand-new activity is created. When the handler > > > ('mHandler') finally executes your old 'mUpdateDisplayRunnable' after > > > the rotation change, the 'mUpdateDisplayRunnable' still has an > > > implicit reference to the destroyed activity. This will cause the list- > > > view of the destroyed activity to be updated, not the list-view of the > > > new activity. > > > > In other words, the instance that is referred to by > > > 'mUpdateDisplayRunnable' should be a static instance that does not > > > have a reference to 'this' activity. To get hold of the current active > > > (and not destroyed) activity, use either a static variable or use the > > > onRetainNonConfigurationInstance/getLastNonConfigurationInstance > > > methods. > > > > On Jun 20, 10:35 pm, Bara <[email protected]> wrote: > > > > > Hello all, > > > > > I have a semi-complicated problem and hoping that someone here will be > > > > able to help me. > > > > > On a click event I create a thread and start a long-running operation > > > > based on this method (http://jnb.ociweb.com/jnb/jnbJan2009.html). > > > > After the long-running task is completed, it does a callback to > > > > another method, which does a post to the handler: > > > > > @Override > > > > public void contentSearchModelChanged(Model_ContentSearch csm, > > > > ArrayList<Class_Reminder> newRemindersList) { > > > > remindersList = newRemindersList; > > > > mHandler.post(mUpdateDisplayRunnable);} > > > > > Which calls a Runnable: > > > > > // post this to the Handler when the background thread completes > > > > private final Runnable mUpdateDisplayRunnable = new Runnable() { > > > > public void run() { > > > > updateDisplay(); > > > > }}; > > > > > Finally, here is what my updateDisplay() method is doing: > > > > > private void updateDisplay() { > > > > if (csModel.getState() != Model_ContentSearch.State.RUNNING) { > > > > if(remindersList != null && remindersList.size() > 0){ > > > > r_adapter = new > > > > ReminderAdapater(Activity_ContentSearch.this, remindersList, > > > > thisListView); > > > > thisListView.setAdapter(r_adapter); > > > > r_adapter.notifyDataSetChanged(); > > > > } > > > > }} > > > > > This works beautifully when I do this normally. However, if I change > > > > the orientation while the long-running operation is running, it > > > > doesn't work. It does make the callback properly, and the > > > > remindersList does have items in it. But when it gets to this line: > > > > > r_adapter.notifyDataSetChanged(); > > > > Nothing happens. The odd thing is, if I do another submit and have it > > > > run the whole process again (without changing orientation), it > > > > actually updates the view twice, once for the previous submit and > > > > again for the next. So the view updates once with the results of the > > > > first submit, then again with the results of the second submit a > > > > second later. So the adapater DID get the data, it just isn't > > > > refreshing the view. > > > > > I know this has something to do with the orientation change, but I > > > > can't for the life of me figure out why. Can anyone help? Or, can > > > > anyone suggest an alternative method of handling threads with > > > > orientation changes? > > > > > Bara- Hide quoted text - > > > - Show quoted text - -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
