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 at http://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. -- T: @alsutton W: www.funkyandroid.com The views expressed in this email are those of the author and not necessarily those of Funky Android Limited, it's associates, or it's subsidiaries. On 8 Jul 2011, at 20:40, Brian Conrad wrote: > I watched the one on fragments. The first presenter had a well put together > explanation that was easy to follow. The second presenter seemed to realize > as he was diving into his slides that things were getting a bit complicated. > > Fragments are not the difficult part though the Google would do well to do > "Hello <new feature>" examples rather than throwing the kitchen sink at us. > They can fill them out with follow ups. Problem with the examples and my > situation is I may have as many as 6 fragments on the tablet screen and the > interface runs really slick that way. It's dealing with those fragments on a > smaller phone screen where the problem arises. The Motodev example had only > two fragments and that's easy to deal with. > > I may just do a tablet edition and skip making it compatible with phones. > Users who get a tablet in addition to the phone will have to purchase the app > again anyway. My users do tend to fall into two groups: ones that want the > app on phone and others who care not about a phone but a tablet suits them. > > On 07/06/2011 11:04 PM, Ravishankar V wrote: >> Check out the webinars from motodev. The only resource that I have >> found (so far) that address tablet related design and development. >> http://developer.motorola.com/docstools/library/motodev-webinars/ >> The 'Top Tips for Android UIs' discusses some interesting patterns. >> Regards, >> Ravi >> >> On Jul 7, 7:44 am, Brian Conrad<[email protected]> wrote: >>> Thanks. It's always good to get some different opinions on design >>> approaches. My activities are GUI thin supported by subclasses which do >>> the drawing etc. It's just a particular had nut to crack when the >>> design is with tabs for smaller-than-tablet displays and a tablet >>> display would be all the screens on one. I will look into the two main >>> layouts idea. >>> >>> On 07/06/2011 01:18 PM, Al wrote: >>> >>> >>> >>> >>> >>> >>> >>>> For ActionBar support, I moved my menus into xml files and used the >>>> android:showAsAction attribute. >>>> For using Fragments, I wrote a class that has various subclasses for >>>> different Android versions. When a fragment related method is called, >>>> the honeycomb subclass does the work. In the other subclasses, the >>>> fragments related methods are empty. (I'm not a fan of the idea of >>>> writing 2 activities since I would be forced to copy/paste a lot of >>>> code unnecessarily). >>>> For contextual action bars, the honeycomb classes post messages to my >>>> activity's handler when items are clicked. I also used the resource >>>> system to load a blue-ifid versions of my icons in honeycomb and show/ >>>> hide different parts of the app in honeycomb. >>>> All that said, my app was fairly simple in terms of the enhancements >>>> to bring to tablet users. >>>> For your app, having 2 layouts and working around that is a possible >>>> idea. >>>> On Jul 2, 5:20 pm, Brian Conrad<[email protected]> wrote: >>>>> I'm curious about what folks are doing with their apps to support >>>>> tablets? I realize that in some cases nothing may need to be done. My >>>>> paid apps run fine on tablets (I now have an Acer a500) but the display >>>>> is a bit large. I thought I would take the two apps that use tabs to >>>>> navigate and put all those screens available on the tablet screen with >>>>> no tabs. Big problem is keeping the tabs for the smaller displays and >>>>> doing away with them on the tablets. For tablets the display is like my >>>>> popular Windows version. >>>>> This gets tricky even with the compatibility library. Either I release >>>>> a version just for tablets or figure out something different than tabs >>>>> for the lower resolutions. Of course the ActionBar isn't available in >>>>> the compatibility library and it is unnecessary in the tablet version. >>>>> So this become a bit of a design problem. The fun of developing for >>>>> Android. > > -- > 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. > -- 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.
