Compatibilidad con versiones anteriores de Android pero sigue utilizando las últimas funciones de la API
He observado en el Android Market que muchas aplicaciones populares tienen compatibilidad con versiones anteriores de Android. P.ej
Evernote - 1.6 Faceobook Messenger - 2.2 Estas aplicaciones se ven y funcionan muy bien, pero ¿cómo pueden hacer esto y soportar niveles de API mucho más antiguos? ¿Utilizan solamente las características de la API que existen en la versión de SO más baja soportada, apenas? Estoy asumiendo que deben utilizar algunas características de los últimos niveles de la API para proporcionar una gran UI y featurelist.
Puedo ver dos posibles soluciones:
Use Min/Target API levels in build. Then through code you check the OS version and implement the features using a supported method and degrade gracefully. This seems like a lot of work.
Have multiple app versions targeting various OS versions. Eg A release for 2.2 and another for 4.0. Is this possible?
La razón para preguntar es que estoy planeando una nueva aplicación que debe apoyar 2.2, pero me temo que puede requerir características de la API que sólo están disponibles en versiones posteriores? ¿Debo solo apuntar 2.2?
EDIT: Además, ¿qué papel desempeñan las bibliotecas de compatibilidad? ¿Es esta la clave?
Gracias.
Nosotros (Evernote) hacemos un trabajo extra para dar soporte a 1.6 y usar tantas API nuevas como podamos. El principal problema con el apoyo 1.6 es que Dalvik hace una búsqueda codiciosa en sus clases. Esto hace que sea imposible usar código como
if(Build.VERSION.SDK_INT >= Build.VERSION_CODES.GINGERBREAD) { prefEditor.apply(); } else { prefEditor.commit(); }
Porque lanzaría un error de verificación de clase. Esto se produce cuando dalvik ve su método e intenta acceder a él en tiempo de ejecución.
En su lugar, necesita utilizar una clase auxiliar para instanciar la clase adecuada para el SDK. Sí, esto es mucho más trabajo
public abstract class SharedPreferenceEditor { private static SharedPreferenceEditor sInstance; public static SharedPreferenceEditor getInstance() { if (sInstance == null) { /* * Check the version of the SDK we are running on. Choose an * implementation class designed for that version of the SDK. */ @SuppressWarnings("deprecation") int sdkVersion = Build.VERSION.SDK_INT; if(Evernote.DEBUG)Log.d("SharedPreferenceEditor", "sdkVersion=" + sdkVersion); if (sdkVersion < Build.VERSION_CODES.GINGERBREAD) { sInstance = new CommitSharedPreferenceEditor(); } else { sInstance = new ApplySharedPreferenceEditor(); } } return sInstance; } public abstract void save(SharedPreferences.Editor editor); }
Entonces usted tiene uno para el pan de jengibre + api nivel
public class ApplySharedPreferenceEditor extends SharedPreferenceEditor { public void save(SharedPreferences.Editor editor) { editor.apply(); } }
Y uno para el <nivel de pan de jengibre
public class CommitSharedPreferenceEditor extends SharedPreferenceEditor{ public void save(SharedPreferences.Editor editor) { editor.commit(); } }
Yo recomiendo el apoyo de 2,1 y hasta de modo que usted puede tomar ventaja de las mejoras a Dalvik y utilizar el primer ejemplo que he enumerado.
Existen algunas estrategias diferentes para mezclar el respaldo con las últimas funciones. Hay muchas referencias dentro de la documentación de Android, pero quizás empiece aquí: Compatibilidad con versiones anteriores para aplicaciones de Android .
Pero en general, le recomendamos encarecidamente que evite publicar múltiples versiones si es posible. Utilice el manifiesto de su aplicación para orientar un rango adecuado de versiones de SO y el código correspondiente.
Y sí, también hay la Biblioteca estándar de compatibilidad con Android (compatibilidad) . Generalmente, el propósito de las bibliotecas compatibles es permitir que su aplicación utilice algunas de las funciones más recientes del sistema operativo al tiempo que proporciona una implementación comparable para las plataformas más antiguas. Usted debe definitivamente mirar esto.
También hay algunas grandes bibliotecas de compatibilidad de terceros. Aquí hay algunos que he utilizado en mis proyectos y definitivamente recomiendo:
- ActionBarSherlock
- NineOldAndroids
- Hola en todos lados
Tenga en cuenta que NineOldAndroids está incluido en ActionBarSherlock.
Hay algunas cosas que usted puede hacer para soportar versiones anteriores de la plataforma Android mientras sigue aprovechando las características de las versiones más recientes. La guía de formación de Android que soporta diferentes versiones de plataforma describe algunos ejemplos y muestra un código de ejemplo que muestra cómo implementarlos.
En ningún orden particular:
-
Puede establecer una "minSdkVersion" y "targetSdkVersion" separadas. MinSdkVersion es la versión más antigua de Android que quieres soportar. TargetSdkVersion es la última versión en la que ha probado y el conjunto de características / comportamiento más reciente que desea incluir en su aplicación.
-
Puede comprobar las versiones del sistema en tiempo de ejecución e implementar una característica únicamente si la versión de la Plataforma Android necesaria se está ejecutando en el dispositivo. Esto se parece a:
private void setUpActionBar() { // Make sure we're running on Honeycomb or higher to use ActionBar APIs if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.HONEYCOMB) { ActionBar actionBar = getActionBar(); actionBar.setDisplayHomeAsUpEnabled(true); } } -
La biblioteca de soporte (también conocida comúnmente como la biblioteca de compatibilidad) contiene características de nuevas versiones de Android, escritas de tal manera que se pueden incluir en su aplicación y funcionarán incluso en versiones anteriores de Android. Por ejemplo, Fragmentos se introdujeron en Honeycomb (Api 11). Pero puedes usar la versión de Fragmentos incluida en la biblioteca de soporte en dispositivos que se remontan a Donut (Api 4)!