Fragment ou de Soutien Fragment?

Je développe une application qui prend en charge Android >= 4.0. Il utilise des fragments de la android.app paquet. Comme je suis confronté à des problèmes avec le plus vieux fragment de mise en œuvre de la version 4.0, comme cette une, qui sont déjà fixés dans la bibliothèque de prise en charge, j'envisage de passer à l'fragment de mise en œuvre de la bibliothèque de prise en charge pour obtenir une mesure plus fiable et une mise en œuvre cohérente.

Quelle est votre opinion à ce sujet? Êtes-vous à l'aide de fragments provenant de la bibliothèque de prise en charge, même s'ils sont déjà disponibles, le développement pour Android 4?

  • C'est une belle question (+1 car il me rend curieux). Il n'y a pas une bonne explication sur le web pour cela. Je suis avec le soutien de la bibliothèque pour mon application et je me demande si je me trompe ou pas, parce que je n'ai pas remarqué de toute erreur lors de la compilation ou au cours de l'essai.
  • La réponse par brillenheini prouve que ce n'est pas principalement un avis de réponse.
InformationsquelleAutor brillenheini | 2013-06-25
  1. 90

    De mon expérience, en utilisant le même fragment de mise en œuvre sur tous les appareils Android est un grand avantage. Je ne pouvais pas me débarrasser de tous les NullPointerExceptions lorsque l'état est enregistré sur Android 4.0 à l'aide de natif de fragments, avec le soutien de la bibliothèque, ils sont tous partis. Aussi je ne pouvais pas voir aucun inconvénient à ce jour avec cette approche.

    Donc, ma réponse à ma propre question est maintenant: Lors du développement d'Android 4.x, à l'aide de fragments de la bibliothèque de prise en charge est une bonne idée. La bibliothèque de prise en charge a des bogues fixes qui sont toujours présents dans les vieux fragment de mise en œuvre et est fréquemment mis à jour avec des corrections de bug plus.

    • Alors, quel est le but de la android.app.Fragment alors? Si vous pouvez l'ajouter à votre réponse, here avec un peu plus d'explication, je serais pleinement satisfait. Merci!
    • La raison en est sans doute historique. Veuillez voir ma mise à jour de réponse.
    • Par souci d'exhaustivité, il semble y avoir des choses de soutien fragments ne peuvent pas le faire (par exemple, animé par objectAnimator, même si la cible réelle de l'OS prend en charge). Qui, dans le cas où vous utilisez ViewPager, signifie que vous avez à utiliser les adaptateurs de v13 bibliothèque de prise en charge, sinon vous ne pouvez pas avoir les deux viewpager et de retournement de l'animation.
    • Attention également, en août 2014, le v13 bibliothèque ne peut pas le faire Imbriquée Fragments.
    • Pourquoi les mecs de chez google a opté pour l'utilisation de la v13 bibliothèque pour iosched app github.com/google/iosched/blob/master/android/src/main/java/com/... , ils doivent avoir une raison
    • Est-ce encore valable avec android 6.x coming out?
    • Agréable à entendre les expériences, ce qui ajoute beaucoup de valeur pour le travail des autres. Tout beau réponses.

    InformationsquelleAutor brillenheini
  2. 40

    Une grande raison de s'en tenir au SupportFragment pendant un certain temps, c'est que vous n'avez pas accès à la ChildFragmentManager jusqu'à ce que l'API 17. La bibliothèque de prise en charge vous donnera une version prise en charge de l'enfant fragment de manager.

    Cela devient un gros problème si vous avez des fragments qui contiennent d'autres fragments. Cela est courant dans les applications pour tablettes avec une bonne dose de complexité et/ou de l'ensemble de votre architecture est basée sur l'un des onglets de mise en page ou utilise le tiroir de navigation.

    InformationsquelleAutor Ross Hambrick
  3. 21

    J'ai également été frustré à avoir à inclure les bibliothèques de prise en charge, malgré ciblant Android 4.0+ - mais il semble qu'il est officiellement recommandé:

    Android Support Library package contient plusieurs bibliothèques
    peut être inclus dans votre demande. Chacune de ces bibliothèques prend en charge
    une gamme spécifique de la plate-forme Android versions et fonctionnalités.

    Ce guide explique les caractéristiques et le support de version
    fournis par les Bibliothèques de Soutien pour vous aider à décider lequel d'entre eux vous
    devriez inclure dans votre application. En général, nous recommandons d'inclure
    la v4 et v7 appcompat bibliothèques, car ils prennent en charge un large
    gamme de versions d'Android et de fournir des Api pour l'utilisateur recommandé
    l'interface de modèles.

    http://developer.android.com/tools/support-library/features.html

    • Ce doit être la accepté de répondre, malgré le fait que @brillenheini fourni une réponse lui-même/elle-même. Il répond à la question avec la meilleure précision et la concision.
    InformationsquelleAutor sourabhj
  4. 4

    À mon humble avis, si vous êtes planification à développer pour la version 4.0, je vous recommande d'aller avec les bibliothèques natives depuis l'exécutable devient plus petit. Il est vrai que vous pourriez avoir des problèmes de bugs dans les premières versions, mais je pense que la plupart de ceux-ci devraient être assez trivial pour contourner. Aussi la bibliothèque de compatibilité est censé carte pour le natif de fragments dans le cas où vous êtes en cours d'exécution sur 4.0 et plus de toute façon. Donc, vous pourriez vous retrouver avoir à se battre avec ces sortes de problèmes de toute façon.
    Le problème, avec le soutien des bibliothèques, c'est que vous avez beaucoup de classes apparaissent 2x (une fois dans le paquet de soutien de la structure et une fois dans le "natif" de la structure du package) qui rend le développement un peu plus lourd.

    Cependant, si vous souhaitez également publier votre app pré 4.0, puis il n'y a aucun moyen de contourner la bibliothèque de prise en charge. En outre, depuis il y a environ 38% de tous les utilisateurs sur 2.3 il pourrait faire les affaires d'inclure cette version de l'OS. Dans ce cas, vous pouvez utiliser la bibliothèque de prise en charge en combinaison avec Jake Wartons ActionBarSherlock (ou avec googles soutien ActionBar Bibliothèque une fois qu'il est enfin libéré).

    • Merci pour votre réponse. Parce que j'ai besoin ViewPager, je dois inclure la bibliothèque de prise en charge de toute façon. Aussi, le soutien fragment de ne pas essayer de passer à l'implémentation native si disponible. C'est ce que le docs dire.
    • Ouais, le truc, c'est (comme @brillenheini dit) que pour avoir le ViewPager vous avez besoin v4, de sorte que même si vous ciblez uniquement v13+ appareils dont vous aurez probablement finir avoir la v4 de toute façon.
    • Je viens de découvrir que trop (ViewPager besoins v4) sur mon API 21 et sur l'app. Meh :-/
    InformationsquelleAutor RaB
  5. 2

    Il semble qu'il est préférable d'utiliser la Bibliothèque de prise en charge maintenant parce que j'ai vu la déclaration ici https://developer.android.com/reference/android/app/Fragment.html

    Cette classe était dépréciée de l'API de niveau P. Utiliser la Bibliothèque de prise en charge
    Fragment de comportement cohérent sur tous les appareils et l'accès à
    Cycle de vie.

    InformationsquelleAutor code4j