Does the book cover use of the Android Compatibility Package for (legacy) Android apps? And what is your advise on this? Always look if a new version (of the compatibility package) incorporates some must have features and implement those?
Our book *almost* included a section on the Android Compatibility Package. That came out just as we were wrapping up our writing, and I did create a sample application that uses it. You'll find it in the sample source code of chapter 29 (Fragments). We knew the book was already really big, so there was some pressure to not include it. And my research was showing that it might not be all that great after all. I could see where fragments might be helpful for the 7" "tablets" like the first Samsung Galaxy Tab. But it turns out that you can't write the same code for an Android 3.0 app that you'd write for an Android 1.6-2.3 app using the compatibility package. Your activities definitely need to be different classes with the compatibility package since the old activities don't support fragments. So your activities need to be things like FragmentActivity. If you want to use the animations when swapping fragments in and out, you have to use the old animation library, not the new one introduced with Android 3.0. The new animation classes were not added to the compatibility package. ActionBar was not added to the compatibility package. And don't forget that there's not FragmentMapActivity in the compatibility package, so you can't use fragments with maps with the compatibility package. I've also read some bug reports that some basic stuff doesn't work in certain situations (like calling startActivityForResult from a fragment). My opinion/guess is that the compatibility package was created because it was relatively easy for them to make it available. They realized a clean separation that allowed for these classes to be put together into the compatibility package without too much effort on their side, and it would appease some developers. But they aren't so easy to work with. You'll need to modify your existing code whether it's smartphone code or tablet code to use the package. For smartphones, I don't see very many advantages of using fragments over using activities. Like I said, it could be useful for the 7" tablets running pre-3.x Android, but be prepared to have non-standard code to make it work, and be prepared to deal with gotchas where things may break.
I hear what you are saying about the Fragments API and e.g. extending FragmentActivity etc. but what about the CursorLoader? That looks useful in my view and I might use that for legacy Android apps. But is it worth including the extra library? Are there any other useful additions in the compatibility package in your view?
Cheers,
Johan
P.S. Hmm... examples in the book... I'd better win it then ;-)
You're right. The Loaders would be useful. Although a bit tricky unless you just stick to CursorLoader. Check out Android issue # 14944. CursorLoader builds on the AsyncTaskLoader but takes care of some things. So if you extend AsyncTaskLoader you'll need to do a few things like CursorLoader does. The source code is viewable once you've installed the compatibility package. Look under the Android SDK directory, in extras/android/compatibility/...
BTW, our source code is provided free of charge on our web site: http://www.androidbook.com/projects. There's a link to the project zip files (by chapter) and a link to instructions on how to import into Eclipse.
0
![[Thumbnail for Screen shot 2011-05-20 at 11.41.15.png]](/t/538549/a/2199/Screen shot 2011-05-20 at 11.41.15.png "Filename: Screen shot 2011-05-20 at 11.41.15.png
Description: Classes in the compatibility package v4")
