support - ¿Cómo funciona la Biblioteca de soporte de Android?
material design library android (6)
Por lo que yo sé, la biblioteca de soporte está usando porque los dispositivos viejos no tienen nuevas API. Por ejemplo, no saben qué es Fragment y cómo implementarlo. Por lo tanto, estos comportamientos se definen en la biblioteca de soporte.
Por lo tanto, mi principal pregunta es, ¿cuál es / son la diferencia (s) entre la biblioteca de Fragmento en la biblioteca de soporte con su hermana que se introduce en la API 11 (Android v3.0, Honeycomb).
Mi segunda pregunta es: si es posible poner cada API nueva en la biblioteca de soporte, ¿por qué tenemos dos tipos de bibliotecas? Quiero decir que Android puede lanzar todas las API solo debajo de la biblioteca de soporte en lugar de la biblioteca de soporte y la biblioteca X.xx de la versión de Android.
A Android se le ocurrió funciones geniales de fragmentos y barra de acción en lanzamientos recientes.
Ahora, si queremos utilizar estas características y también admitimos una versión anterior de Android, tendremos que escribir un código dependiente de la versión altamente desordenado, que no es bueno.
Para salvarnos de todos estos problemas, Android creó una biblioteca de soporte que no brinda soporte completo para las nuevas características, pero que es lo suficientemente buena como para permitir a los desarrolladores escribir código limpio que sea compatible con todos los dispositivos.
La respuesta a su segunda pregunta es muy simple, los fragmentos están integrados en v3.0 y si desea que su aplicación se ejecute únicamente en v3.0 +, entonces realmente no tiene que incluir una biblioteca externa.
Android 4.0.x (ICS) tiene muchas funciones adicionales en comparación con permite, por ejemplo, Android 2.3.x (Gingerbread). Las bibliotecas de compatibilidad están ahí para salvar algunos de los cambios que se agregaron a ICS que -podría- respaldarse con Gingerbread. "podría ser" la frase clave aquí porque hay una tonelada de cambios realizados en ICS que nunca funcionarían con Gingerbread y aquellos, por supuesto, no obtendrán una biblioteca de compatibilidad.
Los fragmentos, por ejemplo, que mencionó, en realidad se hacen de forma ligeramente diferente en ICS que en la biblioteca de compatibilidad porque ICS tiene más funciones que puede usar. Si observa el código de ICS para la clase Fragmentos, no son los mismos que los de la biblioteca de compatibilidad. Es un segundo conjunto de código para hacer que algo "como" los Fragmentos en ICS se use en una versión anterior como Gingerbread sin que el programador note mucha diferencia.
Ese es el punto de las bibliotecas de compatibilidad y la razón por la que no se utilizan para parchear extensivamente Gingerbread para usar todas las características en ICS (simplemente no pueden). El objetivo de las bibliotecas de compatibilidad es interconectar las cosas disponibles en las versiones más nuevas de Android, como ICS, de la manera ICS en versiones anteriores como GB, hecho a la manera de GB.
En cuanto a por qué no solo mantienen la biblioteca de soporte creciendo y dejan el mismo sistema operativo base, la respuesta a eso es problemas de compatibilidad. Si un usuario solo tiene v4 y v12 está fuera, ¿qué ocurre? Actualmente, Android usa la versión de la API de Android del sistema operativo como base para la compatibilidad de las aplicaciones y los desarrolladores tienen la opción de incluir bibliotecas de soporte (aumentando el tamaño de su aplicación, pero dándoles características más nuevas). Cada aplicación que usa bibliotecas de soporte, las incluye de manera independiente (es decir, 4 aplicaciones = 4x incluidas).
La idea es que solo descargue aplicaciones compatibles con la versión API actual de su sistema operativo (en lo que respecta a Google Play) y puede optar por incluir bibliotecas de soporte para mantener la apariencia de su aplicación compatible con API antiguas, que todavía no tiene características que elija que estén disponibles para los usuarios de API más nuevas. Es realmente un aspecto y una consideración más que cualquier otra cosa.
Espero que eso aclare las cosas :)
Fragmentos de la biblioteca de soporte equivalente a fragmentos de Honeycomb +.
Para una segunda búsqueda, de la documentación:
v13 es un superconjunto de v4 e incluye clases de soporte adicionales para trabajar con las API v13
es decir, el mismo funcional, simplemente adaptado a v13 API.
Estoy usando la biblioteca de soporte v4 modificado - con mapas.
La biblioteca de soporte de hecho no tiene todo lo que está en las nuevas API. Admite partes de Fragment API, pero aún no es compatible con ActionBar. Para eso necesitas otra biblioteca como ActionBar Sherlock.
¿Por qué hay dos bibliotecas?
Debido a que parte del problema fue que Google solo transfirió algunas de las cosas, pero tengo entendido que, además, algunas de las nuevas funcionalidades no pueden ser retransmitidas debido a las limitaciones del sistema operativo central y las API faltantes en el núcleo de Android. Marco de la interfaz de usuario.
Lo que se ha dicho ya es verdad. Aunque faltan algunos detalles. De hecho, tuve la oportunidad de asistir a una sesión en el último Google IO, donde hablaron especialmente sobre eso. En realidad, me sorprendió saber que la biblioteca de soporte no aloja el código para todas las posibles versiones de la API, sino que es una adaptación de las nuevas características que consideran lo suficientemente relevantes como para que estén disponibles para las plataformas más antiguas. Entonces, la forma en que funciona generalmente es la siguiente:
- Digamos que necesitamos usar el nuevo ConnectivityManager (disponible de la API 16) para realizar un seguimiento de los cambios en la red.
- Incluimos las bibliotecas de soporte v4 y usamos la clase
- La forma en que funciona después es que el sistema verificará nuestra versión de API y ejecutará el código nativo incorporado en caso de que estemos en la API 16 o ejecutaremos el código de la biblioteca de soporte en cualquier otro caso.
Entonces actúa como una especie de puerta de enlace de ruta. La razón de ser es que generalmente es más eficiente (y mejor rendimiento) utilizar el último código optimizado para el último sistema operativo y las últimas mejoras del sistema (es decir, aceleración de hardware).
No obstante, hay algunos elementos que no se han traducido a la biblioteca de compatibilidad, ya que están en el código nativo incorporado. Por ejemplo, los fragmentos no estaban destinados a volver a escribirse, ya que son de API13, ya que son un gran componente que debe ejecutarse en una amplia gama de escenarios diferentes dentro del sistema y dispositivos con menos capacidades.
En última instancia, y debido a todo esto, se recomienda el uso de bibliotecas compats, lo que se conoce como una buena práctica, especialmente si tiene la intención de hacer que sus aplicaciones / código estén disponibles para versiones anteriores (lo cual debería ser la forma ideal)
Por lo que yo entiendo, las bibliotecas de soporte pueden funcionar como una alternativa de las API integradas, pero no se supone que lo sean, porque afectan directamente el tamaño de la aplicación.
Por ejemplo, una biblioteca de soporte es de 2MB, y para usar su funcionalidad, se necesitan todas las clases, recursos, etc. (de 2MB), así que ahora classes.dex (el archivo ejecutable de Dalvik de todas las clases utilizadas en la aplicación) de mi aplicación también incluir esas clases de biblioteca de soporte, y lo mismo para los recursos. Entonces, si la biblioteca de soporte no tiene el tamaño de mi aplicación de 1 MB, ahora con la biblioteca de soporte el tamaño es de 2 MB extra, lo que significa 3 MB en total.
Ahora, supongamos que esta función de biblioteca de soporte es tan común que en un solo dispositivo, si tengo 10 aplicaciones, entonces al menos 9 están usando esta misma biblioteca de soporte, entonces 9 * 2 = 18MB en mi dispositivo está siendo utilizado por la misma biblioteca de soporte, que se repite en todas las aplicaciones, lo cual es malo, porque por ahora 18 MB no es mucho, pero el espacio requerido puede aumentar si tiene más aplicaciones usando esa biblioteca de soporte.
Por lo tanto, la mejor opción es tener esa biblioteca de soporte de 2MB ya en su sistema operativo para cualquier cantidad de aplicaciones, en lugar de tenerla para cada aplicación. Por lo tanto, las bibliotecas de soporte están destinadas a ser utilizadas cuando realmente desea algunas características eficientes en su aplicación para admitir versiones anteriores.
Otra pregunta surge aquí:
¿por qué no esta biblioteca de soporte se agrega al sistema operativo como su propia actualización, para que cada aplicación sin problemas de tamaño pueda acceder a esa funcionalidad?
La respuesta es que podría haber muchos errores. Supongamos que algún usuario no tiene instalada esa actualización (biblioteca de soporte) ...
También existe la posibilidad de que, como una actualización, no funcione tan eficiente como se supone que sea, o puede causar problemas al integrarse con el sistema operativo, ya que ya vimos que cada sistema operativo (Windows, Linux, Mac) viene con nuevas versiones, en lugar de simplemente dar actualizaciones de por vida para todas las funciones nuevas.