Ai-je besoin tous les trois constructeurs pour Android affichage personnalisé?

Lors de la création d'un affichage personnalisé, j'ai remarqué que beaucoup de gens semblent le faire comme ceci:

public MyView(Context context) {
  super(context);
  //this constructor used when programmatically creating view
  doAdditionalConstructorWork();
}

public MyView(Context context, AttributeSet attrs) {
  super(context, attrs);
  //this constructor used when creating view through XML
  doAdditionalConstructorWork();
}

private void doAdditionalConstructorWork() {

  //init variables etc.
}

Ma première question est, quel est le constructeur MyView(Context context, AttributeSet attrs, int defStyle)? Je ne suis pas sûr de l'endroit où il est utilisé, mais je le vois dans la super-classe. J'ai besoin de lui, et où est-il utilisé?

Il y a une autre partie à cette question.

InformationsquelleAutor Micah Hainline | 2012-02-08
  1. 137

    Si vous allez ajouter votre personnalisé View de xml aussi :

     <com.mypack.MyView
      ...
      />

    vous aurez besoin du constructeur public MyView(Context context, AttributeSet attrs), sinon vous aurez un Exception quand Android tente de gonfler votre View.

    Si vous ajoutez votre View de xml et de spécifier le android:style attribut comme :

     <com.mypack.MyView
      style="@styles/MyCustomStyle"
      ...
      />

    le 2ème constructeur sera appelé par défaut et le style de MyCustomStyle avant d'appliquer explicite des attributs XML.

    Le troisième constructeur est généralement utilisé lorsque vous voulez toutes les Vues de votre application afin d'avoir le même style.

    • quand utiliser le premier constructeur alors ?
    • lorsque vous créez votre View de code.
    • pouvez-vous s'il vous plaît montrer un exemple de la troisième CTOR (avec les 3 paramètres) ?
    • puis-je ajouter des paramètres supplémentaires au constructeur et Comment puis-je les utiliser ?
    • Quant à la troisième constructeur, c'est en fait complètement faux. XML toujours les appels les deux arguments du constructeur. Les trois-argument (et quatre-argument) les constructeurs sont appelés par sous-classes si ils veulent spécifier un attribut contenant un style par défaut, ou un style par défaut directement (dans le cas de la quatre-argument du constructeur)
    • Je viens d'envoyer une modification à apporter la réponse correcte. J'ai également proposé une autre réponse ci-dessous.

    InformationsquelleAutor Ovidiu Latcu
  2. 111

    Si vous remplacez tous les trois constructeurs, s'il vous plaît NE PAS CASCADE this(...) APPELS. Vous devriez plutôt faire ceci:

    public MyView(Context context) {
    super(context);
    init(context, null, 0);
}

public MyView(Context context, AttributeSet attrs) {
    super(context,attrs);
    init(context, attrs, 0);
}

public MyView(Context context, AttributeSet attrs, int defStyle) {
    super(context, attrs, defStyle);
    init(context, attrs, defStyle);
}

private void init(Context context, AttributeSet attrs, int defStyle) {
    //do additional work
}

    La raison en est que la classe parent peut inclure des attributs par défaut dans ses propres constructeurs que vous avez peut-être accidentellement primordial. Par exemple, c'est le constructeur de TextView:

    public TextView(Context context) {
    this(context, null);
}

public TextView(Context context, @Nullable AttributeSet attrs) {
    this(context, attrs, com.android.internal.R.attr.textViewStyle);
}

public TextView(Context context, @Nullable AttributeSet attrs, int defStyleAttr) {
    this(context, attrs, defStyleAttr, 0);
}

    Si vous n'avez pas appeler super(context), vous n'auriez pas correctement configuré R.attr.textViewStyle que le style attr.

    • Cela est essentiel conseils lors de l'extension de la liste. Comme une (ancienne) fan de la au-dessus de ce-en cascade, je me souviens de passer des heures à la poursuite d'un bug subtil qui a disparu lorsque j'ai appelé le bon super méthode pour chaque constructeur.
    • BTW @Jin, j'ai utilisé le code dans cette réponse: stackoverflow.com/a/22780035/294884 qui semble être basé sur votre réponse mais note que l'auteur comprend l'utilisation de l'Inflateur ?
    • Je pense que c'est pas nécessaire d'appeler init dans tous les constructeurs, parce que quand vous suivez la hiérarchie d'appel, vous allez vous retrouver dans le constructeur par défaut pour programmatique en vue de la création de toute façon Vue(Context context){}
    • je m en faire de même, mais a échoué à définir des valeurs dans textview qui est disponible dans mon affichage personnalisé je veux mettre en valeur à partir de l'activité
    • Comment ai-je jamais savoir?
    • Exactement, moi aussi! Cette réponse est claire et précise. Doit être marqué comme accepté de répondre.

    InformationsquelleAutor Jin
  3. 43

    Mavue(Context context)

    Utilisé lors de la instanciating Vues par programmation.

    Mavue(Context context, AttributeSet attrs)

    Utilisé par le LayoutInflater pour appliquer des attributs xml. Si un de cet attribut est nommé style, les attributs seront regardé le style avant de chercher les valeurs explicites dans la mise en page du fichier xml.

    Mavue(Context context, AttributeSet attrs, int defStyleAttr)

    Supposons que vous souhaitez appliquer un style par défaut pour tous les widgets sans avoir à spécifier style dans chaque fichier de mise en page. Pour un exemple de prendre toutes les cases de rose par défaut. Vous pouvez faire cela avec defStyleAttr et le cadre de recherche le style par défaut dans votre thème.

    Noter que defStyleAttr a été nommé incorrectement defStyle il y a quelques temps et il y a une discussion sur la question de savoir si ce constructeur est vraiment nécessaire ou pas. Voir https://code.google.com/p/android/issues/detail?id=12683

    Mavue(Context context, AttributeSet attrs, int defStyleAttr, int defStyleRes)

    Le 3ème constructeur fonctionne bien si vous avez le contrôle sur le thème de base des applications. Qui travaille pour google, car ils expédient leurs widgets sur le côté de la Thèmes par défaut. Mais supposons que vous êtes en train de rédiger une bibliothèque de widgets et que vous voulez un style par défaut pour fixer vos utilisateurs d'avoir à ajuster leur thème. Vous pouvez désormais le faire à l'aide de defStyleRes en paramètre à la valeur par défaut dans les 2 premiers constructeurs:

    public MyView(Context context) {
  super(context, null, 0, R.style.MyViewStyle);
  init();
}

public MyView(Context context, AttributeSet attrs) {
  super(context, attrs, 0, R.style.MyViewStyle);
  init();
}

    Dans l'ensemble

    Si vous êtes à la mise en œuvre de votre propre point de vue, seuls les 2 premiers constructeurs ne devrait être nécessaire et peut être appelée par le framework.

    Si vous voulez que votre point de Vue pour être extensible, vous pourriez mettre en œuvre le 4ème constructeur pour les enfants de votre classe afin d'être en mesure d'utiliser le style.

    Je ne vois pas un réel cas d'utilisation pour la 3ème constructeur. Peut-être un raccourci, si vous ne fournissez pas un style par défaut pour votre widget, mais encore envie à vos utilisateurs d'être en mesure de le faire. Ne devrait pas se produire tant que ça.

    InformationsquelleAutor mbonnin
  4. 3

    Kotlin semble prendre énormément de cette douleur:

    class MyView
@JvmOverloads constructor(context: Context, attrs: AttributeSet? = null, defStyle: Int = 0)
    : View(context, attrs, defStyle)

    @JvmOverloads va générer tous tenus de constructeurs (voir cette annotation est la documentation), chacun de qui sans doute des appels à super(). Ensuite, il suffit de remplacer votre méthode d'initialisation avec un Kotlin init {} bloc. Code réutilisable disparu!

    InformationsquelleAutor jules
  5. 0

    Le troisième constructeur est beaucoup plus compliqué.Permettez-moi de tenir un exemple.

    Soutien-v7 SwitchCompact package prend en charge thumbTint et trackTint attribut depuis le 24 version 23 version ne prend pas en charge.Maintenant, vous voulez les soutenir dans 23 version et comment allez-vous faire pour y parvenir?

    Nous supposons pour utiliser la Vue personnalisée SupportedSwitchCompact s'étend SwitchCompact.

    public SupportedSwitchCompat(Context context) {
    this(context, null);
}

public SupportedSwitchCompat(Context context, AttributeSet attrs) {
    this(context, attrs, 0);
}

public SupportedSwitchCompat(Context context, AttributeSet attrs, int defStyleAttr) {
    super(context, attrs, defStyleAttr);
    init();
}

private void init(){
    mThumbDrawable = getThumbDrawable();
    mTrackDrawable = getTrackDrawable();
    applyTint();
}

    C'est un code traditionnel de style.Remarque nous passer de 0 à la troisième param ici. Lorsque vous exécutez le code, vous trouverez getThumbDrawable() toujours retourner la valeur null comment c'est étrange parce que la méthode getThumbDrawable() est sa super classe SwitchCompacts'méthode.

    Si vous passez R.attr.switchStyle à la troisième param, tout va bien.Alors pourquoi?

    Le troisième paramètre est un simple attribut. Les points d'attributs à un style de ressources.Dans le cas ci-dessus, le système trouverez switchStyle attribut dans le thème actuel heureusement système trouve.

    Dans frameworks/base/core/res/res/values/themes.xml, vous verrez:

    <style name="Theme">
    <item name="switchStyle">@style/Widget.CompoundButton.Switch</item>
</style>
    InformationsquelleAutor CoXier
  6. -2

    Si vous devez inclure trois constructeurs comme celui en discussion maintenant, vous pouvez faire cela aussi.

    public MyView(Context context) {
  this(context,null,0);
}

public MyView(Context context, AttributeSet attrs) {
  this(context,attrs,0);
}

public MyView(Context context, AttributeSet attrs, int defStyle) {
  super(context, attrs, defStyle);
  doAdditionalConstructorWork();

}
    • MERCI DE NE PAS LE FAIRE. lire ma réponse ci-dessous.
    • C'est une bonne idée, dans de nombreux cas, mais c'est aussi sûr, dans de nombreux cas (par exemple: RelativeLayout, FrameLayout, RecyclerView, etc.). Donc, je dirais que c'est probablement un cas-par-cas de l'exigence et de la classe de base doit être vérifié avant de prendre la décision de cascade ou pas. Essentiellement, si le 2-param constructeur dans la classe de base est juste l'appel de cette(context, attrs, 0), alors il est sécuritaire de le faire dans la vue personnalisée de classe ainsi.
    • bien sûr, il sera appelé, car la première et la deuxième sont les méthodes de l'appel de la troisième.
    InformationsquelleAutor arTsmarT