Discussion :

[ClaudeBg]

Bonjour à tous,

Je remets à jour une ancienne de mes applications, qui utilise un FragmentPagerAdapter personnalisé. Étant passé sous androidx, je me vois signalé que le constructeur avec un seul paramètre que j'utilisais comme à peu près tout le monde (le FragmentManager) est déprécié et qu'il faut utiliser celui avec deux paramètres (le FragmentManager et Behavior).

De fait, je modifie en utilisant le constructeur à deux paramètres, et lorsque je fais une recherche sur ce paramèter "Behavior" supplémentaire, je trouve qu'il existe deux valeurs possibles sous forme de deux constantes:
- BEHAVIOR_RESUME_ONLY_CURRENT_FRAGMENT
- BEHAVIOR_SET_USER_VISIBLE_HINT

Mais lorsque je recherche quelle est la différence entre les deux, je me vois signaler que la seconde constante est également dépréciée.

Moralité: Le constructeur à un seul paramètre n'est plus accepté car on impose de préciser le second, qui, lui, se retrouve imposé car une seule valeur possible.

Ma question est: Est-ce complètement stupide ou est-ce que quelque chose d'important m'a échappé?

Sinon, j'en profite pour "pester" un peu contre Android: À chaque fois qu'on reprend un de ses anciens projets on s'aperçoit d'un nombre incalculable de choses qui sont dépréciées. Et évidemment, lorsqu'on cherche une explication ou un exemple sur le net, on finit par ne tomber que sur des exemples qui utilisent des éléments dépréciés, c'est limite pénible. Le côté dynamique c'est bien, mais trop, c'est trop, on a l'impression de développer sur des OS en version beta.

[grunk]

Pour le moment ça peut paraître étrange , mais dans le futur c'est pas impossible qu'il y'est d'autre Behavior dsponible.

Ceci étant dit si tu veux éviter ce genre de désagrément , il faut éviter d'utiliser les lib de compatibilité (androidx ou appcompat) puisqu'elle peuvent être mise à jour indépendamment du système. En revanche tu te limite dans les compatibilités avec des appareils plus anciens.
Je pense que Google n'avait pas envisager que fabricant ne jouerais pas le jeu des mises à jour et que la fragmentation d'android serait si importante. Du coup il sauve les meubles à coup de lib qui sont mise à jour régulièrement et qui du coup rende notre travail pénible.

Dans le genre , j'ai fait une mise à jour mineur sur une de mes applis , et j'ai une autre partie qui ne fonctionnait plus du tout (plus d'affichage). C'était en fait le constraint layout que j'avais mis à jour sans trop me poser de question qui ne marchais plus comme avant ...

[ClaudeBg]

Merci pour la réponse. Je n'ai pas vraiment cherché à utiliser androidx, c'est proposé maintenant par défaut pour une nouvelle application, j'ai été lire un peu partout à ce sujet et il semblait conseillé de l'utiliser. J'ai donc laissé l'option par défaut, d'autant qu'en même temps je sus en train d'apprendre Kotlin à mon fils, donc j'essaye de ne pas lui apprendre du "déjà obsolète".

Je confirme cependant ta remarque: En ajoutant une "bête" appBarLayout je me suis retrouvé avec un message m'indiquant un problème de référence entre

androidx.appcompat:appcompat:1.1.0
et
'androidx.core:core-ktx:1.1.0

Le premier référençant les annotations en version 1.0 et le second en 2.0: Et moi je n'ai rien demandé, ces librairies ont été référencées automatiquement. Bon, ils semblent dire que Gradle gère ça sans problème mais c'était quand même un message qui semblait inquiétant (risque de non compilation etc).

Dans le même ordre d'idée, en ajoutant cette appBarLayout avec un Floating Button, je me retrouve avec deux problèmes dans le xml généré (un problème de fermeture de balise et un problème de guillemets en trop), problèmes qui sont systématiques et que j'ai du régler en éditant le xml: Bon, c'est simple à faire,mais pour du code généré par l'IDE c'est pas très sérieux et ça n'inspire pas confiance.

Je suis resté plus d'un an sans développer de l'Android, mon dernier projet était en Kotlin mais avec A.S. 2.2 et sans ce fameux androidx, je viens de reprendre un projet et je tombe sur plein de changements: Tu pourrais me donner deux mots d'explication sur ce que c'est, ce que ça apporte, et si mieux vaut s'en passer et rester comme avant? Si je te suis bien, s'en passer ferait que l'application ne tournerait pas sur les appareils récents? Donc, on n'a pas trop le choix, si? Par "récents," j'entends, mettons Android 7.
Si je tente de supprimer la "androidx.appcompat:appcompat" et que je recompile, ben je perds par exemple la constante "BEHAVIOR_RESUME_ONLY_CURRENT_FRAGMENT" dont je te parlais.

Et si, comme toi, je reprends d'anciens projets et que je laisse faire les mises à jour.... c'est la panade: La compatibilité ascendante, c'est juste illusoire sur Android, comme tu dis: c'est pénible.

[grunk]

L'utilisation d'androidx est recommandé car ca permet une rétro compatibilité importante. Ce qui n'est pas possible avec les API système.
Si tu développes pour le grand publique et donc une grande variété de version , androidx est quasi un incontournable. Si tu développe pour ton téléphone d'une certaines version , ce n'est pas obligatoire et comme tu as pu le voir peut parfois être génant.
En revanche la compatibilité ascendante est généralement plutôt bien assurée. Il peut y'avoir des suppression ou modification mais ca passe par une phase de dépréciation d'au moins un an ou deux.

Je suis resté plus d'un an sans développer de l'Android

C'est le problème majeur . Android évolue rapidement et un projet qui compilait il y'a un an ne compile en général plus aujourd'hui.
Ca m'arrive à chaque fois que je dois faire de la maintenance sur des vieux projets. D'un autre coté j'ai une appli que je maintient depuis plus de 7 ans et comme je développe régulièrement dessus j'ai jamais de souçis majeure (bon je suis quand même passé de android 2 à 4.4 en prérequis minimum ^^ ).

[ClaudeBg]

Merci pour ces explications sur Androidx, maintenant je cerne mieux l'intérêt associé des inconvénients: Je reste donc sur Androidx qui va améliorer un peu cette foutue non-compatibilité.

A+
Claude