The first thing to mention is that I deprecated onRetainNonConfigurationInstance() because the new fragment APIs are much easier to deal with than that old method. If you are currently using onRetainNonConfigurationInstance() and that is working well for you, there is no need to move off it. (In fact that method is fundamental to how the support lib's FragmentActivity is able to work.)
As far as errors from loaders, the design is that there are no errors as such. Ultimately they need to deliver a result back to the activity/fragment. If your result can include an error state, then this should be part of the result you deliver. This should be as simple as wrapping your result data in a container class that has it and the error state, and making that the result. On Sun, Aug 21, 2011 at 10:23 PM, Nikolay Elenkov <[email protected] > wrote: > I am migrating some of my activities to FragmentActivity using the > compatibility library. > I was using onRetainNonConfigurationInstance() to save an AsyncTask > between > re-creations, but since this is now final, the recommended approach seems > to be > to replace my AsyncTask with a loader. I now have a class derived from > AsyncTaskLoader that does basically the same thing as the old AsyncTask, > and I am > trying to figure out what the best approach to handle load errors is. > > LoaderManger/Loader don't have any support for error handling (no > onLoadError(), > etc. Why?), and any unhandled exceptions just bubble up. Which means one > needs > to make sure loadInBackground() doesn't throw and get your process killed > (at least > that's what happens when using the compatibility library). To pass error > info to the > callback you need to either: > > 1. use the return value: wrap any results in a class that has an > Exception > member in addition to the actual result, and check if is null or not in > onLoaderFinished(); or > 2. save the error state in the Loader, cast it in onLoaderFinished() and > check > for errors > > 1. seems rather awkward if type safe, 2. is not too pretty either. Any > other ideas? > > > > -- > 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 -- Dianne Hackborn Android framework engineer [email protected] 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 [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
