Estrategias para Honeycomb y compatibilidad con versiones anteriores

Así que hemos visto el preview sdk y las nuevas cosas como ActionBar y Fragments. Hacer un montón de llamadas de método será inevitable para hacer uso de estos, así que ¿qué estrategias hay para mantener una versión de la aplicación, que me permitirá utilizar todas las nuevas cosas elegantes, sino también trabajar en los dispositivos de ejecución de 2,3 o menos? Mi aplicación se dirige a 1,5 – 2,3 en este momento.

Las API del mismo fragmento ya están disponibles como una biblioteca estática para su uso con versiones anteriores de Android; Es compatible de nuevo con Android 1.6.

Hay algunos trucos que puedes usar para ver si las distintas API nuevas están disponibles para tu aplicación. En general, es probable que desee crear dos conjuntos alternativos de Actividades, uno que utiliza las nuevas API de fantasía (ActionBar, Animators, etc) – y otro conjunto que no lo hacen.

El código siguiente muestra cómo puede utilizar la reflexión y la captura de excepciones para determinar la disponibilidad de las API de fragmentos y la comprobación de versiones para confirmar si las otras API de Honeycomb están disponibles.

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(); } 

En general, puede utilizar las mismas definiciones de diseño. Donde estén disponibles Fragmentos, inflarás cada diseño dentro de un Fragmento diferente, donde probablemente no quieras usar etiquetas <include> para incrustar varias de ellas en un diseño de actividad más complejo.

Un trabajo más detallado a través de cómo escribir el código para apoyar la compatibilidad hacia atrás en Honeycomb se puede encontrar aquí: http://blog.radioactiveyak.com/2011/02/strategies-for-honeycomb-and-backwards.html

Convenientemente, Dianne Hackborne de Google ha publicado una entrada de blog que cubre este tema exacto. Google dice que proporcionará bibliotecas estáticas para que las versiones más antiguas de Android también puedan utilizar fragmentos.

Podría encontrar útil el artículo de Reto Meier sobre compatibilidad con versiones anteriores , específicamente la sección titulada "Tratamiento de las clases que faltan".

Todavía no he visto el Honeycomb SDK, pero yo, como tú, espero que sea bastante fácil y sin complicaciones hacer uso de las nuevas características sin poner en peligro la compatibilidad con dispositivos antiguos.

Bueno google acaba de anunciar panal será sólo tableta: http://www.pcmag.com/article2/0,2817,2379271,00.asp

Por lo tanto, si su dispositivo está diseñado para dispositivos móviles, esto puede que no sea un problema.

Muestra oficial de Android que te ayudará a alcanzar ActionBar de 1.6 a 4.x

  • ¿Cómo hacer que la función de notificación de respuesta directa de Android funcione en dispositivos pre-Android N?
  • SDK 19 y siguientes no reconoce android.support.v7.widget.CardView, Error al inflar la clase <unknown>
  • Inflar ActionBarSherlock Menú definido en XML
  • FlipAndroid es un fan de Google para Android, Todo sobre Android Phones, Android Wear, Android Dev y Aplicaciones para Android Aplicaciones.