Finalement, Android N n'aura pas de 3D Touch
Android N ne prendra pas en charge les écrans de type 3D Touch. Google a retiré l'API de reconnaissance de pression de la quatrième developer preview du nouveau système. Cette preview sortie hier finalisant les API, la reconnaissance de pression n'a aucune chance de faire son retour dans une prochaine bêta.
Google avait officialisé en avril la prise en charge d'une technologie similaire à 3D Touch dans Android N, avant de se rétracter à peine un mois plus tard pour une raison inconnue. Le retrait de l'API dans la DP 4 d'Android N vient donc acter cet abandon.
Cela n'empêchera pas les fabricants Android de sortir des terminaux 3D Touch — une poignée est déjà disponible —, mais ils devront développer eux-mêmes la partie logicielle et les développeurs d'applications n'auront pas de socle commun sur lequel s'appuyer.
On a vu avec les lecteurs d'empreintes digitales qu'il a fallu attendre leur prise en charge native par Android Marshmallow pour qu'ils se démocratisent (aussi bien sur le plan matériel que logiciel) dans l'écosystème de Google.
Selon toute vraisemblance, il en sera de même avec la reconnaissance de pression. Si Google attend le successeur d'Android N pour remettre sur le tapis cette technologie, les utilisateurs devront prendre leur mal en patience jusqu'à fin 2017. Cet abandon intervient alors qu'iOS 10 met les bouchées doubles sur 3D Touch avec l'ajout de de nouvelles interactions.
Android N sortira en version finale au troisième trimestre. Une dernière bêta est prévue d'ici là, tout comme l'annonce de son nom. Le responsable du système a publié plusieurs tweets donnant à penser qu'il s'appellera Nutella, mais il peut s'agir de fausses pistes, comme Google aime si bien le faire.
La pression qui donne l'impression de toucher du Nutella c'est pour quand, pas'qu'là c'est tout mou chez les droïds
Et paf : ils sont nuls ! La course à la technologie serait trop rapide pour Google ?
Tellement nul que cela existe depuis API 5 en 2009:
https://developer.android.com/reference/android/view/MotionEvent.html#getPressure(int)
EDIT: Houps, c'est bien l'API 1: https://developer.android.com/reference/android/view/MotionEvent.html#getPressure()
Dommage pour le troll raté.
Pour info, l'article est faux, c'est l'API du launcher qui a été retiré, l'API de pression existe bien depuis 8 ans et le restera encore!
@Ze_misanthrope :
Le splitview existait aussi depuis iOS 1 , ce n'est pas pour ça qu'on vient pleurnicher comme toi mon petit fanboy. À quoi ça sert , si c'est inopérant ?
@Malcom, parceque l'article dit qu'il vient d'être inventé et qu'il sera retiré, ce qui est faux.
C'est quoi le rapport avec splitview???
Ils ont juste fait un amalgamme entre "capteur de pression" et l'API du Launcher.
Mais c'est pas grave, je ne pleurniche pas, merci de rester dans le sujet
@Ze_misanthrope
Mais tu parles de quoi ?
L'action de pression à la 3DTouch/ForceTouch ?
Je n'en vois aucune ?
Bien l'article dit "l'API de reconnaissance de pression" ils se sont juste trompés.
Google a retiré l'API de reconnaissance de pression lié au Launcher. Mais Android contient bien un API pour détécter le niveau de pression depuis des lustres. Il y a juste qu'lle n'est pas utilisée par le système en lui même.
Qui suit qui alors ?
Si je voulais troller (comme le font certains intervenants lorsque c'est Apple qui prend du retard), je dirais que Google préfère attendre que la technologie soit suffisamment mure pour l'intégrer, plutôt que de l'intégrer trop tôt et à la va-vite comme le fait Apple.
Plus sérieusement, ce n'est pas la première fois que Google repousse l'intégration d'une fonction. Par exemple, la gestion des permissions est apparue officieusement avec Android 4.3, mais il a fallu attendre la version 6 pour la voir apparaître officiellement.
@carabat
"Si je voulais troller (comme le font certains intervenants lorsque c'est Apple qui prend du retard), je dirais que Google préfère attendre que la technologie soit suffisamment mure pour l'intégrer, plutôt que de l'intégrer trop tôt et à la va-vite comme le fait Apple."
Bah ça marche très bien sur iOS...
C'est quoi une technologies suffisamment mure ?
Le problème est que l'implémentation a été retirée... donc ça n'a rien à voir avec la technologies mure ou pas. C'est juste qu'ils sont incapables... Donc tu trolles :p
Justement, Google a tendance a mettre des trucs pas mûrs pour être présents. C'est aussi la spécialité de m$.
Sachouba va venir nous expliquer que c'est pas bien grave puisque Android gère la reconnaissance de pression depuis l'API 1.
Non, c'est l'API 1 en 2008: https://developer.android.com/reference/android/view/MotionEvent.html#getPressure()
L'article est complètement faux, c'est l'API du Launcher qui a été retiré, pas l'API de détection de pression!
@Ze_misanthrope
Les APIs de pression décritent dans ton lien concernent la pression d'un boutton.
En gros c'est l'équivalent d'un clique, mais pas la pression à la ForceTouch/3DTouch qui reconnait justement la valeur de la pression et pas juste 0 et 1 comme décrite dans ton lien
@XiliX
Tu sembles bien sur de toi. Cette API renvoie une valeur en float de 0 à 1 suivant le degré de pression. Evidemment, pas reconnu sur tous les écrans,
Et non, ce n'est pas un click, nous l'utilisons dans des applis de musique, par nos devs Android.
Je te promets que c'est bien une pression variable.
Tu l'utilises sur des appareils qui n'ont pas d'écran compatible? Champion du monde ou quoi?
Bien évidemment, l'option se grise si l'écran n'est pas compatible. Quel est ton délire, j'ai du mal à suivre...
@Rez2a :
1 ahah
@Rez2a :
1 ahah !
C'est surtout pas bien grave quand on voit l'intérêt du truc...
@Lemmings :
Moi je m'en sers tous les jours avec un 6splus !
Ça me manque cruellement sur l'ipad pro !
Quand on y est habitué c'est redoutable d'efficacité
@Lemmings :
Tu n'as pas du souvent l'utiliser.
La machine à copier n'a pas été efficace cette fois-çi.
Le plus drôle, c'est de lire les Android Lovers qui minimisent le truc en disant que la fonction ne sert pas à grand chose.
Android utilise l'appui long depuis toujours et massivement. Un appuie fort en plus pourquoi pas mais à mon avis et je pense que c'est pour cela qu'ils l'on retirer ne ferait qu'apporter de la confusion.
En outre les Chromebook ne gèrent pas l'appui fort et vu la taille de certains écrans, je ne suis pas sûr que proposer dessus un appuie fort soit une bonne idée.
Il ne s'agit pas d'un appui long.... t'es borné!
Je n'ai pas dit le contraire. J'ai dis que sur Android l'appui long est utilisé partout, et notamment pour avoir des actions contextuelles. RAJOUTER un appui fort complexifierait significativement les interactions.
@lmouillart :
L'appui long est aussi utilisé dans iOS sur les icônes d'applications.
Pour avoir testé je trouve 3D Touch bien foutu, et ça va s'améliorer avec ios10
Normal, c'est Apple qui l'a piquée la machine à copier ;-)
@Doctomac :
Apple a déposé un brevet pour la machine à copier rectangulaire à coins arrondis. Google ne peut donc pas l'utiliser... :(
Autant Touch ID je ne pourrais plus m'en passer, autant 3D Touch ... C'est anecdotique encore.
J'aime bien ce qui dise que le 3D Touch n'a aucun intérêt, ni à court ou à long terme. Qu'auraient il dit lorsque que l'on a pondu la souris à cliqué droit
Intéressante remarque.
En considérant justement qu'Apple a longtemps refuser de tirer partie de la présence d'un second bouton sur la souris justement parce qu'elle considérait que cela allait à l'encontre de la simplicité, l'utilisateur devant se souvenir de quelle fonction était associée avec quel bouton.
Comme quoi, tout le monde peut changer d'avis...
Il faut juste donner du temps au temps.
Le click droit est pourtant une fonction essentielle de OSX...
@Ze_misanthrope
Le clique droit "essentiel" ??? la réponse est "NON"...
Il y a multitudes actions sous OS X permettant d'obtenir le menu contextuel.
Peux tu définir ta "multitude" ?
Quoi qu'il en soit, c'est une option en plus que le click de souris, et le cerveau humain y arrive, que ce soit un click droit ou un geste...
@Ze_misanthrope :
Heureusement qu'ils n'enlèvent pas l'API de pression, sinon ton smartphone tactile, tu peux le mettre à la poubelle XD
Quand je regarde, le résultat de l'API est 0 ou 1.
Or pour 3D Touch (ou équivalent) ça doit être du type 0, 1 ou 2
@Strix.
Le retour est un float!
Returns the current pressure of this event for the given pointer index (use getPointerId(int) to find the pointer identifier for this index). The pressure generally ranges from 0 (no pressure at all) to 1 (normal pressure), however values higher than 1 may be generated depending on the calibration of the input device.
@Ze_misanthrope
C'est ce que je disais plus haut... il ne sait pas traité la "valeur" d'une pression.
Certes le type est float, mais les valeurs ne sont que des integers.
A savoir les valeurs principales sont 0 ou 1. Toutes valeurs supérieurs à 1 ne sont que des valeurs correspondantes à la calibration du "input device".
DONC ça n'a rien à voir avec D3Touch/ForceTouch !
Non, tu te trompes!!!!!
The value is normalized to a range from 0 (no pressure at all) to 1 (normal pressure), although values higher than 1 may be generated depending on the calibration of the input device.
Nous utilisons cette API dans dfes applis de musiques, et je te promets que c'est un float qui va de 0 à 1, quoi que tu dises.
Je veux bien que tu penses que je mente, mais les docs ne mentent pas!
@Ze_misanthrope :
Toutes mes confuses !
@Strix, pas de soucis. On est d'accord que ce n'est pas du 3D Touch, ou ce que l'on veut, mais la valeur est tout à fait exploitable et déjà utilisée dans des applis de dessins.
Dans les devices classiques, cela se fait evidemment avec la surface de contact, qui reste une approximation valable, mais avec les dernières générations d'écran, c'est comme Apple, et cela reste utilisable sans modif d'API.
> Quand je regarde, le résultat de l'API est 0 ou 1.
Nope.
Cela retourne un float positif ou nul, a priori entre 0.0 et 1.0 mais selon le callibrage cela peut être plus.
Y'a donc largement matière à gérer une palette de pression non binaire avec cette API.
Comme déjà dit, le support au niveau entrée est présent depuis le départ.
Mais 1) il n'est pas utilisé par beaucoup de fabricants faute d'avoir des écrans tactiles sensible a la pression à tarif compétitifs et 2) peu d'applications s'en serve pour autre chose que pour du dessin à pression variable, Il n'y a donc pas d'usage transversal et unifié dans Android du niveau de pression, bien qu'au niveau technique les couches bases le permettent.
Merci @Byte_Order, cela ne me semblait pas difficile à comprendre, pourtant.
@byte_order
Non les valeurs superieures à 1 ne concernent que les valeurs de la calibration.
Elles ne peuvent être utilisées pour obtenir la "profondeur" de la pression.
Donc non, ces fonctions ne sont que des fonctions permettant d'obtenir l'état des boutons de type souris... Par pour les pressions de type 3DTouch/ForceTouch
Et à ton avis, comment font toutes les applis de dessins du STore qui exploite cette API si elle ne revoie que 1 ou 0, banane? C'est incroyable d'être aussi obstiné!
@XiliX
> Elles ne peuvent être utilisées pour obtenir la "profondeur" de la pression.
Si.
Un exemple de valeurs possible de retour :
0.0, 0.1, 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1.0,
Hop, rien que là on a 11 niveaux de pressions différents.
Évidement, la précision d'un float permet nettement mieux que ça.
Je dois expliquer plus simplement encore, ou cela sera suffisant ?
@byte_order :
Ok merci pour les explications :)
La stratégie de Google ne consisterait pas justement à pousser Apple à essuyer les plâtres ?
En tout cas à récupérer les applications qu'ils développent. J'en suis convaincu.
@malcom
Fais dodo, je te réponds avec l'application et mon téléphone principal, tu verras que l'on est pas un fanboy juste pour une remarque négative contre un article
Pages