Strategies for Honeycomb & backward compatibility

后端 未结 5 1186
轮回少年
轮回少年 2020-12-12 13:50

So we\'ve seen the preview sdk and the neat new stuff like ActionBar and Fragments. Making a lot of method calls will be unavoidable to make use of these, so what strategies

相关标签:
5条回答
  • 2020-12-12 14:02

    Well google just announced honeycomb will be tablet only: http://www.pcmag.com/article2/0,2817,2379271,00.asp

    So if your device is meant for mobile only this may not even be an issue.

    0 讨论(0)
  • 2020-12-12 14:05

    You might find Reto Meier's article on backwards-compatibility useful, specifically the section headed "Dealing with missing classes".

    I've yet to look at the Honeycomb SDK myself but I, like you, am hoping it's pretty easy and hassle-free to make use the new features without jeopardising compatibility with older devices.

    0 讨论(0)
  • 2020-12-12 14:06

    Conveniently, Google's Dianne Hackborne has posted a blog entry covering this exact topic. Google say they'll be providing static libraries so older versions of Android will also be able to use fragments.

    0 讨论(0)
  • 2020-12-12 14:16

    Official Android sample that will help you achieve ActionBar from 1.6 to 4.x

    0 讨论(0)
  • 2020-12-12 14:25

    The same fragment APIs are now available as a static library for use with older versions of Android; it's compatible right back to Android 1.6.

    There are a few tricks you can use to see if the various new APIs are available to your app. Generally speaking, you'll probably want to create two alternative sets of Activities, one that uses the fancy new APIs (ActionBar, Animators, etc.) -- and another set that don't.

    The following code shows how you can use reflection and exception catching to determine the availability of the Fragment APIs, and version checking to confirm if the other Honeycomb APIs are available.

      private static boolean shinyNewAPIsSupported = android.os.Build.VERSION.SDK_INT > 10;
    
      private static boolean fragmentsSupported = false;
    
      private static void checkFragmentsSupported() throws NoClassDefFoundError {
        fragmentsSupported = android.app.Fragment.class != null;
      }
    
      static {
        try {
          checkFragmentsSupported();
        } catch (NoClassDefFoundError e) {
          fragmentsSupported = false;
        }
      }
    
      @Override
      public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
    
        Intent startActivityIntent = null;
        if (!shinyNewAPIsSupported)
          startActivityIntent = new Intent(this, MainNonActionBarActivity.class);
        else
          startActivityIntent = new Intent(this, MainActionActivity.class);
    
        startActivity(startActivityIntent);
        finish();
      }
    

    Generally speaking you can use the same layout definitions. Where Fragments are available you'll inflate each layout within a different Fragment, where they aren't you'll probably want to use <include> tags to embed several of them into a more complex Activity layout.

    A more detailed work through of how to write the code to support backwards compatibility on Honeycomb can be found here: http://blog.radioactiveyak.com/2011/02/strategies-for-honeycomb-and-backwards.html

    0 讨论(0)
提交回复
热议问题