posted 13 years ago
This is a touchy subject. In theory, a well-behaved app developed for a phone will run on a tablet, but you might see it centered with big black bars around it since it doesn't make sense to spread a small UI across a tablet's screen. So while it works, it's probably not what you would prefer. So now you're developing a version of your app for the tablet. You could use a custom layout for the xlarge screen size, but this is not what Google recommends. Besides, with all that extra screen real estate, you're probably going to want a different type of functionality anyway. Instead of displaying a list of items by itself, and displaying the details of that item in a new activity when you click on one, the tablet display allows you to display the list to the side, and display the details at the same time to the right. Fragments are intended to be the way to do this. One way to think about fragments are like sub-activities. In some ways, you encapsulate the behavior of part of the screen as if it were its own activity, but in fact they are fragments. Fragments work together on the screen in a single activity. It's difficult to explain them well in a post (we devoted a whole chapter to fragments!), so I want to also attempt to answer the other aspect of your question.
Trying to use fragments in older (pre-3.0) versions of Android is problematic. Yes Google released a fragment SDK that works back to version 1.6. BUT! It's buggy. And it doesn't include a fragment-ized version of MapActivity so you can't do maps using it. You'll need to implement different activities anyways for the older releases of your app so I just don't see that you're any better off. My advice is to try to share as much application logic classes between a phone version of your app and a tablet version, but only use fragments on the tablet side.
- dave
