Différence entre androidx et com.android.support

Question

J'étais sur le point d'utiliser une contrainte de mise en page dans mon projet quand j'ai remarqué qu'il existe deux types de dépendances que je peux utiliser:

• com.android.support.constraint:constraint-layout
• androidx.constraintlayout:constraintlayout

Est-il une différence entre ces deux ou une recommandation sur ce qui est préférable?

MODIFIER

Google est l'arrêt de l'appui pour l' com.android.support et invite les utilisateurs à migrer vers la nouvelle - androidx équivalent.

Remarque: Avec la version d'Android 9.0 (API level 28) il y a une nouvelle version de la bibliothèque de prise en charge appelé AndroidX qui fait partie de Jetpack. Le AndroidX bibliothèque contient les bibliothèque de prise en charge et comprend aussi les dernières Jetpack composants.

Vous pouvez continuer à utiliser la bibliothèque de prise en charge. Des objets historiques (ceux de version 27 et antérieures, et emballés sous android.en charge.*) restera disponible sur Google Maven. Cependant, toutes les nouvelles de la bibliothèque aura lieu dans le AndroidX de la bibliothèque.

Nous vous recommandons d'utiliser le AndroidX bibliothèques dans tous les nouveaux projets. Vous devriez également considérer la migration des projets existants à AndroidX ainsi.

Voici l'officiel du guide de Migration et à la bibliothèque correspondante équivalents.

Answer 1

Toutes les bibliothèques de support abandonnent les balises v4 v7 v12 v13 etc. et tout est refactorisé dans les packages androidx.

Ils sont essentiellement les mêmes, mais pour référence future, androidx sera la bibliothèque que nous devrions utiliser dans nos applications.

Android studio 3.2 canary qui sort cette semaine (semaine du 14 mai 2018) devrait avoir l'outil qui permet une refactorisation automatique vers les packages androidx. Il y a eu une annonce à ce sujet lors de google i / o 2018.

Answer 2

L'une des différences entre AndroidX et les bibliothèques de support est que lorsque vous utilisez des bibliothèques de support, toutes les bibliothèques de support doivent être de la même version, mais dans androidX il n'y a rien de tel.

une autre chose est que dans la bibliothèque de support, la plupart du temps lorsque vous avez besoin d'un composant dans votre application, vous devez ajouter des dépendances qui ont tellement d'autres choses dont vous n'avez vraiment pas besoin. mais dans AndroidX, vous ne pouvez ajouter que la dépendance dont vous avez besoin et pas plus.

Answer 3

Cela peut vous aider,

Il y a quelques différences comme suit:

1. Avec l'actuelle convention d'affectation de noms, il n'est pas clair lequel les paquets sont livrés avec le système d'exploitation Android, et qui sont emballés avec votre application APK (Android Package Kit). Afin de clarifier cette situation, tous les dégroupés bibliothèques sera déplacé à AndroidX de androidx.* espace de noms, alors que l'androïde.* hiérarchie des paquets seront réservées pour les colis livrés avec le système d'exploitation Android. Par exemple: android.content.Intent; est Android OS dépendante & androidx.fragment.app.Fragment; c'est livré avec APK

2. Initialement, le nom de chaque colis indiquées au minimum de niveau API pris en charge par le package, par exemple un soutien-v4. Cependant, la version 26.0.0 de la Bibliothèque de prise en charge accrue de l'API minimum à 14 ans, donc aujourd'hui, beaucoup de noms de paquets n'ont rien à voir avec le minimum prise en charge de l'API de niveau. Lorsque le soutien-v4 et le soutien-v7 les paquets ont une API minimum de 14 ans, il est facile de voir pourquoi les gens deviennent confus!. Donc, maintenant, avec AndroidX, il n'y a pas de dépendance sur le niveau de l'API.

3. C'est juste une extension pour le 2ème point, un autre changement important est que le AndroidX les objets de mise à jour de manière indépendante, de sorte que vous serez en mesure de mettre à jour individuelles AndroidX bibliothèques dans votre projet, plutôt que d'avoir à changer toutes les dépendances à la fois. Ceux frustrant "Tous com.android.bibliothèques de prise en charge doivent utiliser la même version de la spécification, les messages" devrait devenir une chose du passé!

Answer 4

Comme dit ci-dessus et dans la Migration vers AndroidX, vous pouvez facilement migrer en tant QUE:

Avec Android Studio 3.2 et supérieur, vous pouvez transférer rapidement un projet existant pour utiliser AndroidX en sélectionnant Refactor > Migrer vers AndroidX à partir de la barre de menu.

À propos de la différence (TLDR: aucune perte de valeur n', c'est moi qui souligne)

AndroidX cartes de l'original de la bibliothèque de prise en charge de l'API de paquets dans l' androidx espace de noms. Seul le package et artefact Maven noms modifiés; classe, la méthode et les noms de champ n'a pas changé.