Para asegurarme que el código funciona correctamente en todos los dispositivos, durante el desarrollo pruebo en un simulador (ojo que no emulador, suelo usar el simulador de http://www.android-x86.org/download eeepc para 2.2) porque si solo probase en un dispositivo 4.x podría estar generando código que solo funciona en el SDK con el que estoy compilando y luego vendrían los crashes inesperados
La parte complicada para mi es estar al tanto de las novedades que van saliendo en cada SDK e ir introduciéndolas con cuidado para que la aplicación siga siendo retrocompatible.
Un buen ejemplo es el código de Reto Meier para geoposicionar el dispositivo usando la mejor implementación del SDK en cada caso. Ahora ya no es necesario liarla así de gorda porque con Google Services han abstraído toda esta lógica (al fin han descubierto que hay cosas que pueden dejarlas bien guardadas en el SDK sin que tengamos que hacernos más cicatrices los developers de apps...). Aquí podéis ver la explicación http://android-developers.blogspot.com.es/2011/06/deep-dive-into-location.html, y aquí la clase que quería mencionar, https://code.google.com/p/android-protips-location/source/browse/trunk/src/com/radioactiveyak/location_best_practices/utils/PlatformSpecificImplementationFactory.java, que luego carga según la versión clases como GingerbreadLocationUpdateRequester, FroyoLocationUpdateRequester...
Lo ideal sería hacer así las implementaciones pero personalmente, la mayoría de las veces no me merece la pena, a no ser que necesite explícitamente alguna de las nuevas características. Por ejemplo, alguien usa el método apply() de SharedPreferences? No habría mucho problema porque es del API 9, pero tampoco aporta demasiado a cambio de tener que estar haciendo herencia, if's... Depende de cada situación como todo
Según un estudio de instabridge cubres el 98% del mercado de android si haces tu app compatible con las versiones:
- 2.2
- 2.3
- 4.0
- 4.1
- 4.2
- 4.3
¿Qué medidas tenéis en cuenta en android para evitar cuelgues y puntuaciones bajas por estos fallos técnicos?
05/08/2013 18:37
android:minSdkVersion="8"
android:targetSdkVersion="17"
Para asegurarme que el código funciona correctamente en todos los dispositivos, durante el desarrollo pruebo en un simulador (ojo que no emulador, suelo usar el simulador de http://www.android-x86.org/download eeepc para 2.2) porque si solo probase en un dispositivo 4.x podría estar generando código que solo funciona en el SDK con el que estoy compilando y luego vendrían los crashes inesperados
La parte complicada para mi es estar al tanto de las novedades que van saliendo en cada SDK e ir introduciéndolas con cuidado para que la aplicación siga siendo retrocompatible.
Un buen ejemplo es el código de Reto Meier para geoposicionar el dispositivo usando la mejor implementación del SDK en cada caso. Ahora ya no es necesario liarla así de gorda porque con Google Services han abstraído toda esta lógica (al fin han descubierto que hay cosas que pueden dejarlas bien guardadas en el SDK sin que tengamos que hacernos más cicatrices los developers de apps...). Aquí podéis ver la explicación http://android-developers.blogspot.com.es/2011/06/deep-dive-into-location.html, y aquí la clase que quería mencionar, https://code.google.com/p/android-protips-location/source/browse/trunk/src/com/radioactiveyak/location_best_practices/utils/PlatformSpecificImplementationFactory.java, que luego carga según la versión clases como GingerbreadLocationUpdateRequester, FroyoLocationUpdateRequester...
Lo ideal sería hacer así las implementaciones pero personalmente, la mayoría de las veces no me merece la pena, a no ser que necesite explícitamente alguna de las nuevas características. Por ejemplo, alguien usa el método apply() de SharedPreferences? No habría mucho problema porque es del API 9, pero tampoco aporta demasiado a cambio de tener que estar haciendo herencia, if's... Depende de cada situación como todo