Code Umstellung zur Performance-Optimierung

[Fry]

@mivola: solche Fehler kriege ich, wenn ich bestimmte Plugins wie "weather" oder so einbinde, und ich kriege die _nur_ auf Androiden. Nur mal so als Hinweis.
VG, Fry

[mivola]

@mivola: solche Fehler kriege ich, wenn ich bestimmte Plugins wie "weather" oder so einbinde, und ich kriege die _nur_ auf Androiden. Nur mal so als Hinweis.
VG, Fry

Naja, ich habe nur 2 aktiv (Windows):

      <plugin name="diagram"/>
      <plugin name="rsslog"/>

[Chris M.]

Kannst Du eine Minimal-Config bauen, bei der das auch nicht geht?
(Oder mit notfalls die ganze Config schicken?)

Ggf. versuch mal Plugins herauszunehmen - da sehe ich aktuell das größte Fehlerpotential...

[Chris M.]

Naja, ich habe nur 2 aktiv (Windows):

      <plugin name="diagram"/>
      <plugin name="rsslog"/>

Die beiden habe ich eigentlich getestet...

Ein Widget dass ich nicht getestet hatte ist das wgplugin_info - verwendest Du das?

[XueSheng]

Bei mir will die visu auch nicht mehr:

TypeError: ret_val.match(...) is null structure_plugin.js:109

Für heut' ist erst mal schluss... Morgen ist auch noch ein Tag .

[Chris M.]

Was auffällt, ist das es immer um irgendetwas in einer "structure_plugin.js" geht.

Nun haben wir mehrere structure_plugin.js - nämlich in jedem Plugin eine.
=> Bitte bei den Fehlermeldungen nachsehen, in welcher dieser structure_plugin.js die Meldung auftaucht. (Beim Chrome kann man z.B. mit der Maus drüber fahren, dann wird der Pfad eingeblendet - das relevante Plugin ist der letzte Teil im Pfad davor)

[XueSheng]

das relevante Plugin ist der letzte Teil im Pfad davor)

diagram plugin...

label : ($e.attr("title") ? $e.attr("title") : ret_val.match( /label">(.*)</ )[1] || '') || null,

[Chris M.]

Sehr gut! Ich glaub ich weiß, was das Problem ist.

Schau mal ob der Fix der jetzt drinnen ist funktioniert.

[mivola]

Sehr gut! Ich glaub ich weiß, was das Problem ist.

Schau mal ob der Fix der jetzt drinnen ist funktioniert.

Nachdem ich meine Config auf 10 Zeilen reduziert habe um es reproduzierbar zu machen, musste ich feststellen, dass ich einfach zu langsam war... (oder vorher hier weiter lesen sollte)...

Dafür kann ich aber bestätigen dass der Fix (Rev 15126) funktioniert :-)

Danke!!
Micha

[XueSheng]

Schau mal ob der Fix der jetzt drinnen ist funktioniert.

Sehr schön. Zumindest auf dem Androiden lädt die Visu wieder (noch keine Zeit gehabt am PC zu testen... Wird aber auch gehen).

Aufgefallen ist mir noch, dass Wischgesten (scrollen) auf meinen Androiden nicht mehr richtig funktionieren. Neben dem eigentlichen Scrollen wird auch immer ein Touch erkannt (also eine ungewollte Aktion ausgelöst). Das alte svn hat dieses Problem nicht. Ist nachvollziehbar was ich meine?

[Chris M.]

Aufgefallen ist mir noch, dass Wischgesten (scrollen) auf meinen Androiden nicht mehr richtig funktionieren. Neben dem eigentlichen Scrollen wird auch immer ein Touch erkannt (also eine ungewollte Aktion ausgelöst). Das alte svn hat dieses Problem nicht. Ist nachvollziehbar was ich meine?

Ja, ich kann's mir vorstellen. Und auch wo im Code das Problem liegen könnte (sollte schon vor ein paar Tagen reingekommen sein...)

Auf dem Tablet hatte ich noch nicht getestet. Mach ich heute mal.

[Chris M.]

Nach dem Test kann ich sagen: grundsätzlich funktioniert Android gut.

Die Frage die Du hier gestellt hast geht nicht in Richtung Bug (es ist nämlich keiner), sondern in Richtung Bedienkonzept. D.h. wir müssen hier eine Design-Entscheidung treffen:

Wie soll auf einem Touch-Display eine Benutzereingabe behandelt werden, wenn man auf einen Button (oder bei Bind to Widget gar auf das ganze Widget) drückt und dann den Finger bewegt?

• Bedienung abbrechen (vgl. Maus-Klick)?
• Scrollen?
• Ignorieren?

Und was soll passieren, wenn dann der Finger zurück bewegt wird und dann losgelassen wird?

• Bedienung wieder aktivieren und dann durchführen (vgl. Maus-Klick)?
• (ggf.) Zurück scrollen und Bedienung durchführen?

Und was soll passieren, wenn der Finger nicht zurück bewegt wurde und dann losgelassen wird?

• Bedienung abbrechen (vgl. Maus-Klick)?
• Scrollen?
• Ignorieren?

Oder anders gesagt: was soll nach diesen Aktionen jeweils passieren?

• Neben Button (ohne Bind to Widget) tippen und loslassen?
• Neben Button (ohne Bind to Widget) tippen, Finger bewegen und loslassen?
• Auf Button tippen und loslassen?
• Auf Button tippen, Finger herausbewegen und loslassen?
• Auf Button tippen, Finger herausbewegen, hinein bewegen und loslassen?

(Hab ich noch eine Möglichkeit vergessen?)

[XueSheng]

Grundsätzlich meine ich sollte man sich an den üblichen Bedienkonzepten orientieren. Da die CometVisu in einem Browser läuft, sollte Sie sich imho auch wie sonstige Webseiten verhalten. Eine Bedienung mit der Maus unterscheidet sich hier natürlich von der Bedienung eines Touchgerätes.

Ich sehe das aktuelle Verhalten schon als problematisch an, da man die Seiten der Visu nur noch bewegen kann, wenn man über einem Textbereich startet/endet. Gerade auf Touchgeräten ist der Platz eher knapp (ich rede jetzt von mobilen Geräten wie Smartphone und Tablet und nicht von dem 32" Touchpanel an der Wand). Aber selbst bei einem 32" Touchpanel würde ich erwarten, dass die Bedienung wie auf einem Smartphone funktioniert.

Nachfolgend meine subjektive (!) Einschätzung:

Oder anders gesagt: was soll nach diesen Aktionen jeweils passieren?

• Neben Button (ohne Bind to Widget) tippen und loslassen?

Button nicht berührt? => Keine Aktion.

• Neben Button (ohne Bind to Widget) tippen, Finger bewegen und loslassen?

Finger über eine Touchfläche bewegen sollte grundsätzlich zum Scrollen verwendet werden (sofern es denn etwas zu scrollen gibt). Sowohl das Berühren, als auch das Loslassen sollten keine zusätzliche Aktion auslösen.

• Auf Button tippen und loslassen?

Aktion auslösen. Auch wenn der Touch etwas länger dauern sollte (ohne Bewegung!).

• Auf Button tippen, Finger herausbewegen und loslassen?

Bewegung sollte auch hier zum Scrollen führen und keine weitere Aktion auslösen.

• Auf Button tippen, Finger herausbewegen, hinein bewegen und loslassen?

Hier sehe ich eine klare Differenzierung zur Bedienung mit der Maus. Wenn ich im Chrome auf einen Link tippe und den Finger bewege wird auch die Seite bewegt und der Link nicht (!) geöffnet. Sollte die Seite kein Scrollen erlauben, sollte trotzdem keine Aktion ausgelöst werden.
Mir ist ehrlich gesagt keine Applikation bekannt, wo dies anders gehandhabt wird (ich glaube die Zeiten von Windows Mobile sind vorbei).

[XueSheng]

(Hab ich noch eine Möglichkeit vergessen?)

Ein Sonderfall ist hier natürlich der Slider. Wenn man diesen antippt und den Finger bewegt, erwartet man natürlich schon eine Bewegung des Sliders. Wobei man hier natürlich schon wieder über die Bewegungsrichtung und -entfernung diskutieren kann. Bewegt man den Finger senkrecht zum Slider oder zu weit vom Slider weg, würde ich keine Aktion erwarten, sondern davon ausgehen, dass man nur scrollen wollte.

Eine zeitlang hatte ich slider auf dem Mobilgerät in voller Breite... hat nicht gut funktioniert. Das Scrollen über die Page hat ständig zu nicht gewollten Aktionen geführt!

[XueSheng]

Sehr schön. Zumindest auf dem Androiden lädt die Visu wieder (noch keine Zeit gehabt am PC zu testen... Wird aber auch gehen).

Etwas zu früh gefreut... die Visu lädt zwar wieder, aber die Diagramme werden nur noch als schmale Linie angezeigt. Screenshot angefügt.