I actually have 2 approaches. For my legacy app, which has a larger installed base, I just included an xlarge layout to support tablets. In my case, I didn't do too much in this layout, other than adjust font size, and padding to ensure everything still rendered well. This isn't optimal, but was a simple fix, and allowed me to support all variety of platforms (although, certainly, I am not supporting tablets to it's full potential).
For my professional gig, which is completely green field right now, I am thinking of writing all UI components as fragments. I will use similar strategies as Al mentioned previously (using an Activity to filter device type, and pass control to an appropriate fragment). I am currently only supporting phones, but am approaching the concept, as building a catalog of UI components (each fragment), which I then arrange on multiple different layouts in any way I want. When it is time to support tablets, it should be relatively easy to Bottom line, I am planning on building all UI components (unless they are very simple, and absolutely have no re-use value) as fragments. I get the feeling this is the approach Google is promoting for development moving forward. As a fundamental approach, am I on base? Not having researched fragments much (yet), I don't fully understand the full impact of supporting them. On Jul 9, 12:23 pm, Brian Conrad <[email protected]> wrote: > On 07/09/2011 12:37 AM, Al Sutton wrote: > > > When I coded the Tablet stuff for TouchNote (which ended up being featured > > in Android Market) we didn't use Fragments. The most important things was > > the UI design and the tablet version was designed specifically for large > > screens rather than trying to take an existing 'phone layout and tweak it > > or combine screens. If you install the app and use it on a phone and a > > tablet you'll see the difference. > > > Personally Fragments have little appeal to me. It seems there's little (if > > anything) you can't achieve using the existing view system and well written > > code, and as the support jar for Fragments on 'phones seems to be ~100k > > that's a lot to add just so you can code using a framework that's only > > native on 0.9% of devices (according to Googles android version breakdown > > athttp://developer.android.com/resources/dashboard/platform-versions.html). > > > You also have the issue that the fragments support library doesn't support > > Android 1.5, and, as of the July figures, there are more 1.5 devices > > accessing Market than there are Honeycomb ones (1.4% -v- 0.9%) > > > To me it makes more sense to stick with Views which adds nothing to the > > apk, works on all devices, and, at the end of the day, you'd end up writing > > less than 100k of compiled code to achieve the same UI effects. > > > Al. > > I find Fragments quite useful and a better way to code interfaces. I > really like my mock up of the tablet design using them and I think my > customers will like them too. As for 1.5 my statistics show 1 user for > the specific app. If I only do a tablet specific version (xlarge > screen) then the market will filter it. I'll just leave the phone > version as is. I agree with the other poster that tablet are pretty a > different paradigm compared to phones. Some of my users wanted to have > my apps integrated into phones almost 10 years ago. They got the the > Palm Treo where the existing app could be run on the phone side of > device. And without doing anything some Windows Mobile phones could run > my Pocket PC version. I had requests for iPhone version but the cost > of development to me was too high (had to buy a Mac). I already had a > desktop Java app so converting it to Android wasn't that much work. > Plus it gave me a codebase to use for other products. -- You received this message because you are subscribed to the Google Groups "Android Discuss" 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-discuss?hl=en.
