L’atsortingbut xml singleLine est-il obsolète ou non dans Android?

singleLine est / a été utilisé dans les fichiers de mise en page XML pour TextView et EditText comme suit:

  

Certaines personnes sur SO disent que singleLine est obsolète, alors que d’ autres suggèrent toujours de l’utiliser. Parfois, il semble même nécessaire d’utiliser lorsque maxLines="1" ne fonctionne pas. (voir ici , ici et ici )

Les documents devraient être l’endroit où aller pour répondre à cette question, non? Ici, ils disent:

Cette constante est obsolète au niveau 3 de l’API.

Cet atsortingbut est obsolète. Utilisez plutôt maxLines pour modifier la disposition d’un texte statique et utilisez textMultiLine indicateur textMultiLine dans l’atsortingbut inputType pour les vues de texte modifiables (si singleLine et inputType sont fournis, les indicateurs inputType remplacent la valeur de singleLine).

Cependant, dans les documents TextView , rien n’indique qu’il soit obsolète, que ce soit pour android:singleLine ou pour setSingleLine ou pour setTransformationMethod . Par comparaison, les mêmes documents TextView indiquent que d’autres éléments, tels que STATUS_BAR_HIDDEN et fitSystemWindows sont obsolètes. Donc, la dépréciation de singleLine est- singleLine une omission, est-ce que c’était “sans décision”, ou quoi?

Cette question a déjà été posée auparavant mais n’était pas au centre de la question (et n’a pas reçu de réponse).

Je pense que la réponse à votre question se trouve déjà dans l’un des messages de SO auxquels vous êtes lié . Malheureusement, la dépréciation de singleLines n’est pas une question de noir ou blanc.

Il est obsolète, mais il ne va nulle part bientôt.

Il est déconseillé car ses performances sont médiocres par rapport à son successeur, maxLines . Il utilise SingleLineTransformationMethod pour remplacer les nouvelles lignes et les retours chariot dans la chaîne que vous placez dans TextView , contrairement à maxLines , qui “ajuste” simplement la hauteur de TextView fonction du nombre de lignes et ne remplace pas la chaîne.

Cette méthode de remplacement des caractères signifiait également que singleLine pouvait se briser de manière inattendue (par exemple, si vous utilisez des fonts personnalisées). Ce sont ces problèmes de performance et de fiabilité qui ont conduit à sa dépréciation.

Cependant, il ne va nulle part car , comme le poste SO que vous avez lié aux états, il est toujours utilisé par de nombreuses anciennes applications Android, et il est parfois utile (par exemple lorsque vous souhaitez afficher le texte entier sur une seule ligne et ignorer retours chariot et nouvelles lignes).

Notez que la dépréciation ne signifie pas nécessairement qu’une API disparaît. Cela signifie simplement que son utilisation est déconseillée, mais peut être autorisée.

L’atsortingbut obsolète a été ajouté dans la modification d24b8183b9 qui n’est rien d’autre qu’un vidage du SCM interne de Google:

import automatique depuis //twigs/cupcake/…@130745

Comme on peut le voir depuis le changement core/res/res/values/attrs.xml diff ajoute le commentaire de doc @deprecated, mais diff core/java/android/widget/TextView.java ne modifie rien du document commentaire.

Maintenant, sans access à l’historique SCM interne de Google, il n’est pas possible de savoir exactement ce qui a provoqué des modifications dans le commentaire de document attrs.xml , mais pour votre question

Donc, la dépréciation de singleLine est- singleLine une omission, est-ce que c’était “sans décision”, ou quoi?

Une réponse possible est: la TextView simple de TextView n’était ni dépréciée, ni «non déconseillée», mais elle a été améliorée pour tenir compte de l’éditable de la vue, d’un champ de mot de passe ou de tout autre indicateur de type la linéarité.

Dans le grepcode officiel de TextView (v5.1.0 r1):

android:singleLine n’est pas annoté avec @Deprecated .

Je le vois aussi dans la méthode setInputType :

 boolean singleLine = !isMultilineInputType(type); // We need to update the single line mode if it has changed or we // were previously in password mode. if (mSingleLine != singleLine || forceUpdate) { // Change single line mode, but only change the transformation if // we are not in password mode. applySingleLine(singleLine, !isPassword, true); } 

setInputType remplace la valeur mSingleLine .

EDIT: Cet atsortingbut xml est maintenant officiellement obsolète. ( depuis API 3? ). Il est maintenant visible dans l’éditeur xml AndroidStudio.

singleLine EST obsolète. Aucune discussion nécessaire

Le seul problème est la mauvaise documentation.
“Utilisez textMultiLine l’atsortingbut inputType dans l’atsortingbut inputType pour les vues de texte modifiables” est le contraire de ce que vous souhaitez obtenir en utilisant singleLine .

Au lieu de cela, vous pouvez utiliser android:inputType="text" .
Pour moi, il a fait exactement ce que je voulais – une édition avec une seule ligne sans sauts de ligne.

Je pensais juste que j’appendai qu’Android Studio 2.2.1 marque un singleLine comme étant obsolète. Cependant, ce que j’ai trouvé, c’est que dans mon cas:

 android:singleLine="false" 

fonctionne bien, alors que

 android:maxLines="2" 

ne fait pas.

Alors qu’Android Studio affirme qu’il est obsolète, nous avions en réalité un texte d’édition qui devrait se limiter à une seule ligne.

L’ajout de maxLines="1" fait autoriser les caractères de nouvelle ligne, ce qui ne convient pas à nos besoins.

Nous sums donc revenus à utiliser singleLine="true" .

Juste pour append plus d’informations à la discussion, Lint a maintenant l’erreur suivante:

“Combiner ellipsize et maxLines=1 peut entraîner des pannes sur certains périphériques. Les versions précédentes de lint recommandaient de remplacer singleLine=true par maxLines=1 mais cela ne devrait pas être fait lors de l’utilisation d’ ellipsize .

Plus d’infos: https://issuetracker.google.com/issues/36950033

Donc, je suppose que singleLine est maintenant, et je pense que nous devrions trouver un nouveau terme … “déprécié”?

Je viens d’append android:inputType="text" et android:maxLines="1" supprimé android:maxLines="1" , cela fonctionnait très bien pour moi.

Fournir seulement android:maxLines="1" et android:minLines="1" ne résoudra pas le problème de l’action actionNext lié. Utilisez android:inputType="text" pour le même.

Voie alternative simple, utilisez: android:maxLines="1"