Supposons que vous définissiez android:onClick="doClick"
dans votre Activity
comme
protected void doClick(View view) { }
El documentation déclare que
Ce nom doit correspondre à une méthode publique qui prend exactement un paramètre de type View.
Il s'agit d'une exigence donnée du système sous-jacent Class.getMethod()
qui ne trouve que les méthodes publiques comme la méthode documentation déclare qu'il
Retourne un
Method
qui reflète la méthode membre publique spécifiée de la classe ou de l'interface représentée par cet objetClass
objet.
Alors comment est-il possible que cette mise en œuvre, qui ne devrait pas fonctionner du tout, fonctionne sur certains appareils et émulateurs, alors qu'elle ne fonctionne pas sur d'autres appareils utilisant les mêmes niveaux d'API ?
0 votes
J'ai été intéressé par la question, je peux me tromper complètement mais je pense que cela fonctionne avec
protected
en raison du fait que sigetMethod()
ne trouve pas de méthode correspondante dans une classe donnée, il poursuit sa recherche de manière récursive dans la super classe.1 votes
Ça ne devrait pas fonctionner idéalement. J'ai vérifié le code source et ils ne rendent pas la méthode accessible, ce qui est nécessaire pour accéder aux méthodes non publiques en utilisant la réflexion, peut-être qu'ils ont une implémentation différente de ceci dans une version différente de l'API.
0 votes
Je me pencherais sur la méthode DeclaredOnClickListener et sur les différences entre le cadre et les implémentations de la bibliothèque de support : github.com/aosp-mirror/platform_frameworks_base/blob/master/ et : github.com/reverseengineeringer/com.twitter.Android/blob/master/
1 votes
@Miquel font tous deux appel à
AppCompatViewInflater.DeclaredOnClickListener
de 27.1.1 qui ressemble à la dernière implémentation du framework.0 votes
@SuhaibRoomy il n'est pas nécessaire de rendre une méthode protégée accessible si l'accesseur est dans une sous-classe ou dans le même paquet que la méthode. Je pense que LieForBananas a raison et que le framework peut créer un proxy d'exécution de l'implémentation de la vue, lui permettant d'appeler #onClick sans réflexion. Les dispositifs où cela ne fonctionne pas peuvent essayer de l'appeler sans sous-classer (avec réflexion), ce qui échouera sans appeler AccessibleObject#setAccessible.
0 votes
Ce que vous dites à propos de la méthode protégée est juste. Mais la vue n'est pas une sous-classe de votre activité. Il ne peut jamais être. Aussi la vue n'appelle pas la méthode directement. Il y a une classe statique interne DeclaredOnClickListener (qui détient la référence de la vue) qui appelle réellement la méthode, il n'y a aucun moyen qu'elle puisse être une sous-classe de votre activité.
0 votes
@SuhaibRoomy, vous avez raison. tynn, on dirait que cet utilisateur a eu le même problème .
0 votes
@tynn, je ne sais pas ce qui se passe, mais il semble probable que cela se résume à un code différent en langage C++ lié à la réflexion/AccessibleObject pour les différentes plateformes dans Dalvik/ART.
0 votes
"Alors comment est-il possible, que cette implémentation, qui ne devrait pas fonctionner du tout" Qu'est-ce qui vous fait penser qu'une méthode protégée ne peut pas être invoquée par réflexion ?
0 votes
@Onik le
getMethod()
ne trouve que les méthodes publiques. Je ne suppose pas qu'il soit impossible d'appeler la méthode ultérieurement. Je me demandais simplement comment la méthode non publique pouvait être trouvée. La réponse est que la méthode est de toute façon publique. Mais seulement dans certaines configurations.