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.
