android - library - ¿Por qué AOSP agrega nuevas API para admitir bibliotecas sin agregarlas a SDK?

com.android.support:appcompat-v7 last version

Question

Llevo unos meses desarrollando para Android, y esta pregunta surge una y otra vez: ¿cuál es la motivación detrás de la adición de características completamente nuevas (API) para admitir bibliotecas sin que estén disponibles en el SDK estándar?

Ejemplo:

FragmentTabHost API FragmentTabHost solo está disponible a través de android.support.v4.app.FragmentTabHost . Está bien la mayor parte del tiempo, pero si desea usar fragmentos anidando y PreferenceFragment juntos, está muerto en las aguas. El anidamiento requiere que cambie a android.support.v4.app.Fragment (para el soporte por debajo de 4.2). pero no hay implementación de PreferenceFragment en esta biblioteca de soporte. Como consecuencia, implementas soluciones personalizadas o usas bibliotecas de terceros que ya las han implementado (consulta esta pregunta )

Edición: como lo señaló @eugen en su respuesta, yo mismo hice referencia a FragmentTabHost desde support-v13, que admite fragmentos nativos. Sin embargo, esta información no cambia la pregunta general. De hecho, si hubiera usado esta API con anidación de fragmentos, mi aplicación no se ejecutaría en aproximadamente el 30% de los dispositivos en la actualidad (los fragmentos nativos admiten la anidación de 4.2 en adelante).

Ejemplo:

Otro problema que encontré hoy (y desperdicié demasiado tiempo) es con ActionBarDrawerToggle disponible a través de android.support.v7.app.ActionBarDrawerToggle . Quería usar esta funcionalidad, por lo tanto, agregué todo com.android.support:appcompat-v7:21.0.+ a las dependencias del proyecto. Supuse que esto funcionaría, pero estaba equivocado: mi aplicación no se compiló (faltan los recursos a los que hace referencia la biblioteca de soporte). Después de probar algunos trucos de la web, encontré esta pregunta que finalmente proporcionó la solución. En resumen: la biblioteca de soporte de v7 depende de SDK, por lo tanto tuve que definir compileSdkVersion 21 .

Consecuencias:

Ahora, me digo a mí mismo: FragmentTabHost aún no se ha agregado a ninguna versión de SDK, lo que implica que dentro de 4 a 5 años los desarrolladores seguirán usando support-v4 lib para proporcionar esta funcionalidad (porque incluso si esta API se agrega hoy , pasarán años antes de que pueda asumir con seguridad que todos los dispositivos de destino lo admiten de forma nativa), ¿verdad? El mismo argumento se aplica a android.support.v4.widget.DrawerLayout y otras API presentes solo en las bibliotecas de soporte.

Si los desarrolladores están obligados a usar bibliotecas de soporte durante años, esto también implica que están obligados a experimentar los problemas de incoherencia / dependencia anteriores mucho después de que estos problemas ya se hayan resuelto, ¿verdad?

Pregunta:

¿Por qué querría Google mantener estas bibliotecas para siempre? ¿No sería mejor para todos si todas las nuevas API se agregaran al SDK en paralelo a las bibliotecas de compatibilidad, de modo que las bibliotecas de compatibilidad puedan caducar y "retirarse" en algún momento?

Edición: siguiendo la respuesta de @ eugen, ahora me desconcierta aún más: algunas API "evolucionan" con nuevas versiones de soporte, pero no lo hacen en el SDK principal (como FragmentTabHost, que evolucionó de support-v4 a support-v7). ¿Cuál es la razón para no agregarlos a SDK?

Answer 1

La API FragmentTabHost solo está disponible a través de android.support.v4.app.FragmentTabHost.

Incorrecto. El enlace que proporcionó conduce a android.support.v13.app.FragmentTabHost que (a diferencia de android.support.v4.app.FragmentTabHost ) funciona con Fragment nativos, pero hace que las API introducidas anteriormente estén disponibles desde la API 13 desde la API 13 .

En resumen: la biblioteca de soporte de v7 depende de SDK, por lo tanto tuve que definir compileSdkVersion 21.

Por supuesto, la versión 21 de la biblioteca necesita la versión 21 de las herramientas y la versión 21 del SDK. Siempre use las versiones correspondientes de las herramientas de compilación, compile SDK y bibliotecas de soporte.

A partir de hoy se recomiendan estos valores:

compileSdkVersion 22
buildToolsVersion ''22.0.1''
targetSdkVersion 22
compile ''com.android.support:support-v4:22.0.0''
compile ''com.android.support:appcompat-v7:22.0.0'' // includes support-v4
compile ''com.android.support:support-v13:22.0.0'' // includes support-v4

Ahora, me digo a mí mismo: FragmentTabHost aún no se ha agregado a ninguna versión de SDK, lo que implica que dentro de 4 a 5 años los desarrolladores seguirán usando support-v4 lib para proporcionar esta funcionalidad (porque incluso si esta API se agrega hoy , pasarán años antes de que pueda asumir con seguridad que todos los dispositivos de destino lo admiten de forma nativa), ¿verdad?

Lo que significa que si lo implementas utilizando la biblioteca support-v13 , no tienes nada de qué preocuparte. Va a funcionar tan lejos como API 13.

Lea acerca de la diferencia entre support-v4 y support-v13 arriba.

¿Por qué querría Google mantener estas bibliotecas para siempre?

Porque lo más probable es que quieras soportar plataformas más antiguas. Lo que significa que necesita una biblioteca de soporte.

Incluso ahora, usa ActionBarActivity de appcompat-v7 (que originalmente fue pensado para realizar una ActionBarActivity de appcompat-v7 barra de acción a API 7) con minSdkVersion 14 porque desea que el diseño de material sea backport. Esto también significa que estás atascado con los fragmentos de soporte porque ActionBarActivity está utilizando.

¿No sería mejor para todos si todas las nuevas API se agregaran a SDK en paralelo a las bibliotecas de compatibilidad, de modo que las bibliotecas de compatibilidad puedan caducar y "renunciar" en algún momento?

Las bibliotecas de soporte envejecen. Es posible que haya notado que recyclerview-v7 (y otras bibliotecas recientes de Android) está disponible desde la API 7 y no desde la API 4. Y también puede haber notado que RecyclerView no está en el SDK nativo. ¿Por qué lo agregaría a un SDK nativo para que esté disponible solo para la plataforma más nueva cuando pueda publicar una biblioteca de soporte y esté disponible para todos?