11
votes

Comment prolonger ImageView dans une application Android-Scala?

J'ai essayé de nombreuses solutions trouvées dans Google par les mots-clés: plusieurs constructeurs, scala, héritage, sous-classes.

Aucun ne semble fonctionner pour cette occasion. imageview code> a trois constructeurs: p> xxx pré>

dans SCALA, vous ne pouvez en prolonger l'un d'entre eux que. Et la solution d'utilisation du constructeur plus complet ( imageview (contexte, jeu d'attributs, style) code>) et le passage des valeurs par défaut ne fonctionne pas non plus parce que le constructeur imageview (contexte) code> fait quelque chose de complètement différent des deux autres constructeurs. P>

Certaines solutions d'utilisation d'un trait ou d'un objet compagnon ne semblent pas fonctionner car la personnalité doit être une classe! Je veux dire que je ne suis pas le seul à utiliser cette classe (afin que je puisse écrire le code Scala de toute façon que je voulais) il existe également l'Android-SDK qui utilise cette classe et oui, il doit s'agir d'une classe. P>

La cible consiste à avoir une vision personnalisée qui s'étend sur imageview et tous ces travaux: P>

new CustomView(context)
new CustomView(context,attribute set)
new CustomView(context,attribute set, style)

android scala inheritance multiple-constructors

2 commentaires

Pouvez-vous fournir des exemples spécifiques qui nécessitent CustoralView d'être une classe?

Oui bien sûr! Dans une mise en page régulière dans Android, vous écrivez du XML. Google Android SDK analyse de ce XML et crée une instance CustomView. Cela le fait (probablement) en exécutant Nouveau CustomView (contexte, attribut Set) . Bien que dans certaines parties de mon propre code, je dois créer une vue personnalisée sans attributs, donc je devrais appeler Nouveau CustomVoir (contexte) . (Non! Passer NULL à l'ensemble d'attributs ne fera pas le travail)



                                    
                    4 Réponses :
                    
                                            
                            
                                
                                    5
 votes
                                
                            
                            
                                
                                     On dirait que vous pourrez peut-être mieux écrire la sous-classe de Java. Sinon, si votre hypothèse sur le SDK à l'aide du constructeur de trois arguments est correct, vous pouvez utiliser un trait et une classe avec un objet compagnon. Le SDK utiliserait les trois arguments constructeur de  CustomView , qui implémente également un trait contenant tout comportement supplémentaire dont vous avez besoin:  xxx  
 dans le code de l'application, vous pouvez utiliser celui-ci. , deux ou trois arguments la version de cette manière:   xxx  
 semble avoir beaucoup de travail. En fonction de vos objectifs, vous pourrez peut-être ajouter un comportement supplémentaire avec implicite:   xxx                                  


                                                                    
                                    
                                    
                                        2 commentaires
                                        
                                                                                            
                                                    Je vois ... L'utilisation du constructeur des trois paramètres lancerait une exception car à l'intérieur de la SDK, il existe un appel comme celui-ci:  Nouveau CustomVoir (contexte, attributs) . Vous avez donc vraiment besoin de CustomView (2 params) et de CustomView (3 paramètres) pour le SDK. Heureusement, la valeur par défaut du troisième paramètre est simplement zéro afin que vous puissiez en avoir ces deux. Maintenant, que s'il existe du code dans le SDK, je n'ai pas encore utilisé que les appels  Nouveau CustomVoir (contexte) ?!                                                

                                                
                                                                                            
                                                    Vous seriez pas de chance et laissé deux options plus sensibles: java ou implicite.                                                
                                                
                                                                                    

                                    

                                                            

                        

                        
                                            
                            
                                
                                    7
 votes
                                
                            
                            
                                
                                     Selon Martin Odersky (le créateur de Scala), ce n'est pas possible. 

 in  http: // scala-programmation- langue.1934581.n4.n.nbabilk.com/scabe-calling-Différent-super-constructors-td1994456.html : 


   "Y a-t-il un moyen d'appeler différents super-constructeurs dans différents
  constructeurs de classe - ou doivent-ils tous aller au constructeur principal et seulement
  Un super-constructeur est soutenu? 
  
  
 Non, il doit passer par le constructeur principal. C'est un détail où
  Scala est plus restrictif que Java. "


 Je pense que votre meilleure approche consiste à mettre en œuvre vos points de vue en Java.                                 

                                                                    
                                    
                                    
                                        0 commentaires
                                        
                                                                                    
                                    
                                                            
                        
                        
                                            
                            
                                
                                    1
 votes
                                
                            
                            
                                
                                     Cette question me conduise à plusieurs considérations de conception que je voudrais partager avec vous. 
 Mon premier examen est que si une classe Java a été correctement conçue, la disponibilité de plusieurs constructeurs devrait être un signe du fait que certaines propriétés de classe pourraient avoir  valeur par défaut   
 Scala fournit des valeurs  par défaut  comme une fonctionnalité de langue  , de sorte que vous ne devez pas vous soucier de fournir plusieurs constructeurs, vous pouvez simplement fournir une valeur par défaut pour certains arguments de votre constructeur. Cette approche mène à une API  beaucoup plus propre  que trois constructeurs différents qui produisent ce type de comportement, car vous ne saisissez pas pourquoi vous n'avez pas besoin de spécifier tous les paramètres.  
 My Decond La considération est que cela ne s'applique pas toujours au cas où vous éroticulez des cours d'une bibliothèque tiers. Toutefois:  

 Si vous extension une classe d'une bibliothèque open source et que la classe est correctement conçue, vous pouvez simplement enquêter sur les valeurs par défaut de l'argument de constructeur 
  Si vous extension d'une classe qui n'est pas correctement conçue (c'est-à-dire où les constructeurs surchargés ne sont pas une API à défaut certains paramètres) ou où vous n'avez aucun accès à la source,  vous pouvez remplacer l'héritage avec la composition  et fournir une conversion implicite. 

 XXX  
                                 

                                                                    
                                    
                                    
                                        4 commentaires
                                        
                                                                                            
                                                    Je suis tout à fait d'accord avec vous concernant les considérations de conception que vous avez mentionnées. Cependant, dans ce cas, cela ne l'aidera pas beaucoup, car Android construit des instances de vues à l'aide de la réflexion (et c'est pourquoi les trois constructeurs sont nécessaires). Sa classe doit implémenter  imageview  afin d'éviter  classcastexceptions ; Bien entendu, il peut avoir une instance intérieure qu'il peut construire correctement, mais il a également dû rediriger toutes les méthodes  imageview  à cette instance, qui est un fardeau. Entre cela et écrire sa classe en Java ...                                                

                                                
                                                                                            
                                                    Merci pour cette réponse, je pense que c'est utile dans l'ensemble! Mais oui, le SDK Android nous a obtenu:  Causé par: Android.View.inflateException: Ligne de fichier XML binaire # 43: La classe n'est pas une vue Vues.Cardview  Je garderai à l'esprit les conceptions futures mais dans d'autres types de projets. Peut-être un peu de refactoring sur le code Android afin que nous puissions avoir une classe correctement conçue comme vous l'avez mentionné serait le meilleur                                                

                                                
                                                                                            
                                                    Merci Rui pour votre commentaire. Vous avez raison ! Y a-t-il une raison pour laquelle Android SDK crée des instances avec une réflexion en utilisant différents constructeurs? Que se passe-t-il si vous fournissez un constructeur unique?                                                
                                                
                                                                                            
                                                    @ EDMONDO1984 Différents ensembles d'attributs dans les fichiers XML entraînent des appels à différents constructeurs, comme vous pouvez le voir  ici . Je ne suis pas au courant de la raison pour laquelle ils ne définissaient que le constructeur de trois paramètres, car il suffirait pour tous les cas d'utilisation que je peux imaginer ...                                                
                                                
                                                                                    

                                    

                                                            

                        

                        
                                            
                            
                                
                                    0
 votes
                                
                            
                            
                                
                                     Selon le  Android  Voir  code> Documentation  a>  Voir (contexte)  code> est utilisé lors de la construction à partir de code et  Vue (contexte, attributset)  code> et  affichage (contexte, attributset, int)  code> ( et puisque le niveau d'API 21  vue (contexte, attributset, int, int)  code>) sont utilisés lorsque la vue   code> est gonflée de xml. 
 Le constructeur XML Tout simplement appeler le Même constructeur, celui avec la plupart des arguments qui est le seul à une implémentation réelle, nous pouvons donc utiliser des arguments par défaut dans Scala. Le "Code Constructor" d'autre part peut avoir une autre implémentation, il est donc préférable d'appeler en réalité de Scala.  P> 
 La mise en œuvre suivante peut être une solution:  P> 
private trait MyViewTrait extends View {
  protected def setMeasuredDimensionAccessor(w: Int, h: Int): Unit
  def callingSetMeasuredDimensionAccessor(): Unit = {
    setMeasuredDimensionAccessor(1, 2)
  }
} 

class MyView(context: Context, attrs: AttributeSet, defStyle: Int = 0)
    extends View(context, attrs, defStyle) with MyViewTrait {
  override protected def setMeasuredDimensionAccessor(w: Int, h: Int) =
    setMeasuredDimension(w, h)
}

object MyView {
  def apply(context: Context) = new View(context) with MyViewTrait {
    override protected def setMeasuredDimensionAccessor(w: Int, h: Int) =
      setMeasuredDimension(w, h)
  }
}

                                

                                                                    
                                    
                                    
                                        0 commentaires