android-3.0-honeycomb

As Android documentation states: "An activity is a single, focused thing that the user can do." However with Fragments we will be able to do many "things" within the same Activity as Reto Meier suggest . His suggestion is to replace a selection fragment by a content fragment within the same Activity (section "Within our code this produces a dilemma"). Lets say my application is a "bit" more complex, with many activities, with a complex navigation tree and designed with the "single, focused thing that the user can do" principle in mind. Lets say now I have to adapt it to Fragments and large

The Honeycomb docs are vague: When the hardware-accelerated renderer is enabled, most operations in Canvas, Paint, Xfermode, ColorFilter, Shader, and Camera are accelerated. Is there a definitive list of the exact APIs that are (and are not) supported when hardware acceleration is enabled? Some methods fail fast with exceptions, while other features simply render differently when acceleration is enabled. For example, Canvas.clipPath(...) fails fast with an exception. Though the clipPath API makes no mention of this, it is easy enough to determine when testing on real hardware. Other features

I am interested in creating a ListView where each row is marked the way it is done in GMail for 3.0+. This creates a nice separation of the left and right ListFragment. Other examples include also Google Calendar on 2.3.4 for instance where a color marker is on the left of the ListView. See the grey vertical divider between the two lists. How does one achive something like this? A bonus would be also the alternating width, but I guess that is only a smaller layout change. I know I could probably do something like inserting an ImageView in there and then fill it with the color I would like but

I'd like to show a different fragment in a TabHost, for every tab. But it seems that there's no easy way to do this. TabHost can only accept A. Views or B. Intents that launch Activities when the user selects a tab. Going with A means that I have to initialize every fragment and load them into container Views that are given to the TabHost. But I want these fragments to load only when needed - when the user selects their tab that is. Going with B means that I load the fragments into separate Activities for each tab. But I'd like the fragment to be able to reach the "original" parent Activity,

I have a Honeycomb style preferences. I define the headers: <preference-headers xmlns:android="http://schemas.android.com/apk/res/android"> <header android:id="@+id/pref_general" android:fragment="MyPreferencesFragment" android:title="@string/pref_general_title"> <extra android:name="resource" android:value="pref_general" /> </header> <header android:id="@+id/pref_sharing" android:fragment="MyPreferencesFragment" android:title="@string/pref_sharing_title"> <extra android:name="resource" android:value="pref_sharing" /> </header> </preference-headers> Then I load them in PreferenceActivity: