[Fehler] Metro: Nav löst auch auf Folgeseite Tastendruck aus
-
Bin erst durch meinen Thread http://forum.iobroker.net/viewtopic.php … 907#p99907 (Zeitverögerte Ausführung möglich?) auf diesen aufmerksam gemacht worden. Das Problem ist anscheinend nicht Metro-spezifisch. Habe nur html-Widgets. Kombination ebenfalls android+touch.
-
Moin!
Zusammenfassend heißt das:
-
vis prellt (wenn die Seite im cache ist)
-
betroffen scheinen alle Widget-Sets
-
Problem scheint nur bei Touch-Bedienung aufzutreten (windows & Android; Chrome und FireFox und APP)
….sowiet alle Infos vollständig?
Dann werden wir wohl @Bluefox hilfe benötigen... :arrow:
bis denne
Mr.Lee
-
-
` > Zusammenfassend heißt das:
-
vis prellt (wenn die Seite im cache ist)
-
betroffen scheinen alle Widget-Sets
-
Problem scheint nur bei Touch-Bedienung aufzutreten (windows & Android; Chrome und FireFox und APP) `
das Thema ist so alt wie ich dabei bin… http://forum.iobroker.net/viewtopic.php?f=30&t=4821
aber genau das ist es
-
-
Nun gut, aber durch die neuerdings höhere Geschwindigkeit der App ist diese mittlerweile zumindest für mich nicht mehr nutzbar.
Aber genau dafür benötigt ich vis. Am PC bedienen ist ja nett, aber brauchen tu ich es unterwegs… Und das sin nunmal touch Geräte.
Bis denne
MrLee
Gesendet von meinem SM-G930F mit Tapatalk
-
Ich habe diese Probleme überhaupt nicht.
Mit keinem Widget.
Welche Versionen von .vis und App?
Gruß
Rainer
-
Diese Probleme merkst du auch nur, wenn du auf der Folgeview direkt an der gleichen Stelle einen Button hast.
Bei meiner "Home View" merke ich das auch nicht. Meine Handy View ist dagegen nicht zu bedienen.
App 1.1.1 und VIS 1.0.4
-
Mir fällt da gerade ne vielleicht einfache Lösung ein.
Einfach ein Rahmenwidget über den ganzen Bildschirm erstellen, mit einem hohen z-Index, also wenigstens einen höher als der bisher höchste. Für die Sichtbarkeit des Rahmens erstellt ihr eine Variable, die auf Veränderungen der vis.o-control-data bei mehreren Anzeigen auch noch auf instace. Per Script diesen Rahmen für wenige Zehntel-Sekunden anzeigen lassen. Damit wäre dann möglicherweise das Problem weg, allerdings ist dann im vis-Editor imm dieser Rahmen im Weg.
Enrico
-
Moin!
Naja, so einfach ist die Lösunf leider nicht da ich bei meiner "Handy-App" über 20+ Seiten rede…
@Bluefox: HILFE !
-
Mir fällt da gerade ne vielleicht einfache Lösung ein.
Einfach ein Rahmenwidget über den ganzen Bildschirm erstellen, mit einem hohen z-Index, also wenigstens einen höher als der bisher höchste. Für die Sichtbarkeit des Rahmens erstellt ihr eine Variable, die auf Veränderungen der vis.o-control-data bei mehreren Anzeigen auch noch auf instace. Per Script diesen Rahmen für wenige Zehntel-Sekunden anzeigen lassen. Damit wäre dann möglicherweise das Problem weg, allerdings ist dann im vis-Editor imm dieser Rahmen im Weg.
Enrico `
vergiss es .. hab ich auch schon ausprobiert.. die reaktion dauert manchmal mehr als 1 sec. bis der Rahmen verschwindet.. (bei mir bis zu 5 sec wo ich nichts machen kann weil der Rahmen drüber liegt)
-
Moin!
Naja, so einfach ist die Lösunf leider nicht da ich bei meiner "Handy-App" über 20+ Seiten rede…
@Bluefox: HILFE !
`Naja, wenn ich bei vis ein Widget auf mehreren Seiten haben möchte, kann man das auswählen, auf welchen Seiten das angezeigt werden soll, da spielt es keine Rolle, wieviel Seiten ein Projekt hat!
arteck hat allerdings schon geschrieben, sowas getestet zu haben, was nicht so lief wie es soll! War ja auch nur ne Idee. Ich habe dieses Problem nicht, weil ich ne feste Navigationsleiste habe.
Ich hatte auch schonmal ein Handyprojekt ausprobiert, wo ich mit + und - navigiert habe, das hatte ich hier im Forum mal irgendwo gelesen. Da wurde über ein Script hochgezählt und die entsprechende Viewseite angefordert, das hat dann lange genug gedauert um den "Doppelklick" zu vermeiden.
Ein Problem wird es auch sein, dass sich andere User über zu lange Umschaltzeiten beschweren, dem könnte man aber möglicherweise mit einer einstellbaren Verzögerung für die Navigationsbutton entgegen wirken.
Enrico
-
Ich denke bei diesem Thema wird einfach von falschen Ausgangsbedingungen ausgegangen.
Das eigentliche Problem ist kein Prellen. Es gibt verschiedene Touch Events, diese wiederum werden auch von vis Korrekt abgefangen.
Dieses falsche verhalten trifft nicht auf alle Widgets zu, da nicht alle Widgets auf das touchend Event reagieren. Aber wiederum alle Metro Widgets reagieren auf das touchstart und touchend Event. Das sieht man daran das die Kacheln wenn man sie drückt und hält leicht schräg stehen.
In der Annahme dass das touchend Event das Widget auf der Folge Seite auslöst habe ich etwas gespielt und festgestellt das bei längerem halten des Fingers kein Auslösen statt findet.
Schlussfolgerung: Die Zeit zwischen touchstart und touchend hat einen Einfluss auf die Interpretation des touchend Events.
Die Korrekte Lösung wäre demnach ein touchcancel Event aus zu lösen beim wechsel des Views.
Ob das Programmiertechnisch mit JS möglich ist weiss ich nicht.
EDIT: Ist mir gerade noch eingefallen. Die Frage ist ob damit das folgende touchend überhaupt verhindert werden würde.
-
Moin!
Danke für die Erklärung (auch wenn ich tatsächlich nicht alles verstanden habe :-)).
Leider hilft mir die kaum.
Natürlich kann man jede Navi-Taste sehr lange drücken…und selektiert dann auf der Folgeseite den text
Des weiteren bleibt die Handy-Bedienung damit recht riskant (zum Beispiel habe ich einen alles aus Button der abends keinerlei freundschaftliche Enfindungen meiner frau erzeugt...)
Ich sehe hier immernoch eine Notwendigkeit beim anzeigen eines Views 1 sek Gedenkpause vor Eingaben als notwendig.
Und mal ehrlich: Eine Visualisierung die heutzutage nicht gut auf touch-gerätren läuft...schwierig...
bis denne
Mr.Lee
-
Ihr seid nicht allein! Auch ich quäle mich mit dem Aktivieren einer weiteren Schaltfläche rum, nachdem die View aktiviert wurde.
Auch hier liegt die Schaltfläche direkt an der Position, an welcher in der vorherigen View der Wechsel per "JQUI - Navigation-Icon" -Button ausgelöst wurde.
iobroker.vis 1.0.4
Android 4.2.2 (Wandtablet)
Chrome 63.0.3239.111
-
Moin!
laut changelog https://github.com/ioBroker/ioBroker.vis soll der feher ja behoben sein.
Kann es sein das dafür die Andoid-App nocheine neue Version benötigt? Hier habe ich den Fehler nähmlich noch.
Hat jeand schon testen können ob es in der Web-Version nicht mehr auftritt?
bis denne
Mr.Lee
-
Moin!
laut changelog https://github.com/ioBroker/ioBroker.vis soll der feher ja behoben sein.
Kann es sein das dafür die Andoid-App nocheine neue Version benötigt? Hier habe ich den Fehler nähmlich noch.
Hat jeand schon testen können ob es in der Web-Version nicht mehr auftritt?
bis denne
Mr.Lee `
Hat du in der app dein Projekt Mal komplett neu synchronisiert ?
–-----------------------
Send from mobile device
Das schöne ios hat Auto Korrektur zum k****
Wer Schreibfehler findet darf sie behalten oder auf eBay verkaufen, mindest Umsatz 10% für die community
-
Moin!
Jo, hab ich gemacht. Das Problem tritt aber in der App noch auf.
App: 1.1.1
vis 1.1.1
bis denne
Mr.Lee
-
Moin!
Habe jetzt mal ausführlich auf diversen Touch-Geräten mit Andoid & Wind10, Edge, Chrome und FF getestet…alles bestens!!! Vielen Dank.
Aber:
Die Android-App hat noch das selbe Verhalten. Ich vermute diese muß aktualisiert werden?!
Ich weiß es ist gerade Streß wegen der free-cloud, aber gibt es einen ungefähren Zeithorizont wann das passiert?
bis denne
Mr.Lee
-
Moin!
Kann mal jemand nen Ausblick geben ob es eine neue Android App geben wird die auch ohne prellen funktioniert?
bis denne
Mr.Lee
-
push….
-
Moin!
Bin ich der einzige mit dem Problem in der app?
bis denne
Mr.Lee
