material-components/material-components-android

[BottomNavigationView] BottomNavigationView can have only one setOnNavigationItemSelectedListener

Open

#735 ouverte le 5 nov. 2019

Voir sur GitHub
 (3 commentaires) (8 réactions) (0 assignés)Java (3 023 forks)batch import
Good First IssueWidget: BottomNavigationfeature request

Métriques du dépôt

Stars
 (15 910 stars)
Métriques de merge PR
 (Aucune PR mergée en 30 j)

Description

FEATURE REQUEST

As per title, BottomNavigationView can have only one setOnNavigationItemSelectedListener. This is annoying because if i use the bottomNavigationView.setupWithNavController(navController) this internally sets that listener, and i cannot use it anymore for anything else (like setting the text in a custom appBar, for example) A list of listeners would be the right thing in my opinion.

Ps. this probably applies to setOnNavigationItemReselectedListener(BottomNavigationView.OnNavigationItemReselectedListener listener) too.

For Pattern reference, see NavController addOnDestinationChangedListener and removeOnDestinationChangedListener

Guide contributeur

Direction de recherche
Le problème demande d'autoriser plusieurs écouteurs sur BottomNavigationView au lieu d'un seul. L'approche recommandée est de suivre le modèle utilisé par addOnDestinationChangedListener/removeOnDestinationChangedListener de NavController, qui maintient une liste d'écouteurs. Pour implémenter, localisez la classe BottomNavigationView (probablement dans le code source de la bibliothèque) et modifiez la pour stocker une liste d'instances OnNavigationItemSelectedListener, puis itérez sur elles lorsqu'un élément est sélectionné. Assurez la rétrocompatibilité en conservant la méthode setter unique mais en l'adaptant à la nouvelle liste. Aucune PR liée ou commentaires récents ne fournissent de directives supplémentaires.
Stack technique
javaandroid
Domaine
mobile
Type d'issue
Fonctionnalité
DifficultéDifficulté estimée pour un nouveau contributeur, de 1 pour un très petit changement à 5 pour un travail expert.
2
Temps estiméFourchette de temps approximative pour investiguer, implémenter, tester et préparer une pull request.
1-3 heures
Statut d'activitéDisponibilité apparente de l'issue : fraîche, active, ancienne, bloquée ou en attente d'un mainteneur.
Active
ClartéClarté avec laquelle l'issue explique le changement attendu, les critères d'acceptation et la prochaine étape.
Claire
Prérequis
Android development
Accessibilité débutantScore de 1 à 100 estimant l'accessibilité de cette issue pour un premier contributeur.
70