i Ajoutez et supprimez une vue de manière dynamique à une vue personnalisée (Framelayout) en faisant ceci: plus tard, j'essaie de supprimer la vue mais la vue ne supprimera pas: si je fais cela à la place, tout fonctionne comme prévu: La seule différence est que je ajoute manuellement la vue au lieu de laisser L'appel de gonflement le faire.
Est-ce que quelqu'un sait pourquoi cela ferait une différence?
4 Réponses :
Si vous utilisez la vue de la liste, avez-vous essayé d'invalider cela après avoir retiré.
L'ajout de la vue se produit dans la méthode GeveView () d'un adaptateur de liste afin de créer la vue à afficher. Invalidation de la vue Liste provoquerait probablement une boucle d'infini ...
Mettez-vous la version SupportView dans GeveView ()?
Ok je vois ce que tu veux dire. La vue est supprimée lorsqu'un bouton est cliqué sur l'élément de la liste. J'ai ajouté une invalidation après avoir supprimé la vue mais rien ne change.
Dans mon expérience, cela dépend d'où créez-vous votre référence à la vue parente que vous passez à gonfler (...). Je suis dans votre situation et (même si cela ne devrait pas échouer, il fait parfois si nous ne l'appelons pas du bon endroit) J'ai prouvé qu'il est bien meilleur lors de la création d'une vue personnalisée dans le code, de définir les layoutparams également aussi bien. Dans la documentation, vous pouvez déduire que le groupe de visiteurs parent est principalement utilisé pour obtenir les paramètres de mise en page. Pour cette raison, après avoir gonflé (avec «Faux»), vous pouvez construire vos propres framelayOnt.LayoutParams, offrir la vue gonflée avec eux, puis en ajoutant la vue au parent. Vous voudrez peut-être essayer également au lieu de retirer la vue directement à partir de votre mise en page personnalisée, appelez la vue.Getparent (), de la jeter à votre FRAMELAYOUT personnalisé, puis appelez SupprimerView (...) à partir du résultat coulé.
((MyCustomFrameLayout)mMyView.getParent()).removeView(mMyView);
Qu'il s'agisse explicitement de la mise en page ou de l'utilisation de ceux fournis par la disposition racine ne correspond à la question. En outre, utiliser getparent () retournerait simplement le Framelayout personnalisé qui est identique à la même chose que "Ceci" et faire (((myCustomframeLayout) mmyView.getern ()). SupprimerView (mmyvie w) est identique à SupprimerView (MMYView), au moins si MMYVIEW est effectivement ajouté au Framelayout personnalisé (ce qu'il n'est pas que pour des raisons pour lesquelles vous n'expliquez pas dans votre réponse).
La réponse réside dans cet appel
mMyView = inflater.inflate(resId, this, true);
4 ans plus tard et les mêmes décisions stupides de l'API Android trébuchent toujours les gens. Merci pour cette réponse.
Merci pour le rappel :) J'avais appris cela un peu de temps après une lecture minutieuse de la documentation, mais je suis tombé sur ce problème récemment sans se souvenir de la cause. Vous m'avez sauvé du temps grâce à votre message!
On dirait que dans les versions Android plus récentes, les transitions de mise en page peuvent retarder la suppression des vues, soit retarder l'appel à addview () ou utiliser parent.setlayouttransition (null) .