Jump to content

v3.5.0 auf Android 8.0 - Erfahrungsbericht: Ersteinrichtung großartig, UI-Usability und -Performance machen die App jedoch fast unbenutzbar


Recommended Posts

Ich habe inzwischen fast alle Sat>IP Clients unter Android durch und weil ich mit keiner der kostenlosen Lösungen zu 100% glücklich wurde, habe ich auch die kostenpflichtigen getestet.

Eyetvs 99 Cent Lösung funktionierte als einzige überhaupt nicht (bzw. nur einmal und dann nie wieder) und ich hab den Kauf schlicht wieder storniert.

 

Von SAT>Viewer hatte ich mir viel versprochen, schließlich ist DVBViewer unter Windows unanfechtbarer Platzhirsch ohne echte Alternative. Die schlechten Bewertungen habe ich mit ihrer extrem geringen Zahl weggeredet - unglückliche Nutzer hinterlassen halt eher Bewerungen als glückliche.

 

Kurzer Erfahrungsbericht:

 

Als SAT>IP Server kommt ein Xoro 8100 zum Einsatz, Android Testgerät ist ein Mate 10 Pro - aktuelles Android Flaggschiff mit besten Benchmark-Werten und Android 8.0.

 

Der allererste Eindruck ist negativ: Keine native Unterstützung für das Display im 19:9 Format, Vollbild müsste ich erzwingen (tue es aber nicht, denn meist sind ein Haufen Bugs Folge des Erzwingens). In Zeiten in denen das 19/20:9 Format mit und ohne Notch zum effektiven Flaggschiff-Standard geworden ist das eigentlich nicht mehr entschuldbar.

 

Gut, dann muss ich halt mit dem schwarzen Balken und "Vollbild" Knopf leben, den Huawei etwas zu hilfsbereit dauerhaft einblendet. ?

 

Das die App kein adaptives Icon (sondern ein völlig unpassendes im iOS 5 Look) ist da noch eher verschmerzbar. ?

 

Zumindest der nächste Eindruck ist extrem positiv: Der Server wird in den Einstellungenen sofort gefunden, der Suchlauf ist dank sinnvoll vorkonfigurierter Vorgaben und gut sortierter Online-Senderliste in Sekunden abgeschlossen und die App ist sofort einsatzbereit. ?? Grandios, so gut macht es kein anderer! ?

 

Gut, die UI ist hier etwas holprig, die "Beginne Sendersuchlauf" Schaltfläche sieht aus wie alle anderen Optionen zur Konfiguration eben dieser und damit leicht zu übersehen, sicher wie der Rest der Oberfläche verbesserungswürdig aber kein Beinbruch. ?

 

Nun gut, die Senderliste ist lang und es gibt keinen offensichtlichen Weg mal eben seine zwei Dutzend Favoriten festzulegen (das geht wohl nur lang- und mühsam), aber wenigstens scrolled sie flüssig und unterstützt kinetisches scrollen halbwegs korrekt, allerdings mit zu geringer Höchstgeschwindigkeit. Leider lässt sich der Scrollbalken rechts nicht greifen um schnell an eine Position zu springen. ?

 

Die Senderliste füllt sich mit EPG Daten und ruckelt dabei gelegentlich leicht, aber wäre da nicht das nervige und unnötig niedrige Scrolling-Geschwindigkeitslimit, so gäbe es hier wenig zu meckern.

 

Die UI ist ziemlich eigenwillig, um es mal freundlich zu formulieren, und hält sich weder an Apple noch an Googles Designrichtlinien - noch an sinnvolle eigene:

Der Knopf rechts oben lässt ein Zusatzmenu von unten einblenden, dass sich nicht durch die Zurück-Taste schließen lässt (stattdessen zeigt sich dann kurz die Sidebar, warum um Himmels Willen?).

 

Schaut man einen Sender, so braucht die App  länger als andere Apps um ihn zu starten - aber die Streamqualität ist nach kurzem Ruckeln absolut top ...

 

Kein Knopf für's Vollbild um das ganze im Landschaftsmodus zu schauen - hierfür muss man den Bildschirm entsperren und das Handy drehen, dann geht's. Die App übergeht die Bildschirmrotation nicht eigenständig und erlaubt es auch nicht, sie im Landschaftsmodus zu sperren. Tippt man im Landschaftsmodus auf den "zurück" Knopf, friert Sat>IP Viewer einfach ein oder zeigt einen gelben Bildschirm.

 

Zappen durch Knöpfe oder Gesten? Fehlanzeige, Senderwechsel geht wohl nur über die Senderliste.

 

Nun gut, dann geht es über die absurd hakelige und merkwürdige UI mit dem links/rechts Swipe zurück zur Senderliste.

 

Nur wird die schlicht vollkommen unbrauchbar, sobald ein Sender läuft. Kinetisches Scrollen geht jetzt plötzlich gar nicht mehr und die Performance ist auf Slide-Show-Niveau. Alle paar Sekunden fragt das System, ob ich die eingefrorene App schließen will. Ab Android 9 kommt diesere Dialog übrigens nicht mehr, hier wird dann einfach automatisch abgeschossen. Manuell stoppen lässt sich ein Stream natürlich auch nicht.

 

Für einen erfolgreichen Senderwechsel muss man die App also schließen und neu starten um dann in der Senderliste einen Sender auszuwählen. Sobald dieser läuft ist die App unbrauchbar. Hardwarebeschleunigung an oder aus macht keinen Unterschied. Es wirkt fast so, als würde die gesamte App samt UI in einem einzigen Thread laufen.

 

Schade, ich wollte gerne 5 Sterne vergeben aber so ist es wohl am freundlichsten, überhaupt gar keine Bewertung zu schreiben.

 

Den Refund spar ich mir, vielleicht wird's ja irgendwann besser. Das Potential ist sicher da, aber aktuell geht's leider kaum schlechter und die Play-Store-Bewertungen sind noch fast zu positiv. ?

Edited by Gott
Link to comment

Vielen Dank für die Bewertung,

 

einiges kann ich (ehrlicherweise) nachvollziehen, zumindest aus Anwendersicht. Was viele Nutzer vergessen ist, dass beim Entwickeln von Software viel Zeit in das Bedienkonzept fließt. So auch in der Anwendung, wenngleich mir klar ist das für einige Nutzer die Bedienung wahrscheinlich nicht intuitiv ist.

Beim Design habe ich mich an die damals geltenden Richtlinien für Apple, Google und Microsoft gehalten. Leider ändern alle 3 (gut Microsoft jetzt nicht mehr) ihre Richtlinien alle paar Monate. Beim letzten Update kam bei Apple die Software nicht durch das Review, da ich keine nativen Screenshots vom IPhone X für den Store erstellt habe. 

 

Erschwerend kommt hinzu, dass gerne auch die API über den Haufen geworfen wird. 98% der Entwicklungszeit ging drauf, die Fehler nach einem Update der K*ck-Betriebssystemversionen zu beheben. Hat man die Anwendung für iOS fertig, braucht man wieder Wochen für Google, da wieder irgendetwas nicht mit neueren OS-Versionen geht. Oftmals sind das völlig bekloppte Schnittstellenverschlimmbesserungen die nicht reproduzierbar sind.

Was das angeht, kann man echt nur den Hut vor Microsoft ziehen, denn was da einmal in den NT4 Code gemeißelt wurde, geht in den meisten Fällen noch unter Windows 10.

 

IMG_5984.jpg

 

Zu der Bedienung:

 

Im Prinzip gibt es aktuell 2 verschiedene Bedienmodi.

Die Anwendung verhält sich im Telefon- etwas anders, als im Tabletbetrieb. Da man das Tablet meist im "Landscape"-Modus hält und die Darstellung sowieso etwas größer ist, habe ich mich entschieden die Senderliste links und das Video, sowie die EPG Daten rechts anzuzeigen.

Beim Telefon sieht man entweder die Senderliste, oder das TV-Bild und die EPG Daten. Durch "swipen" nach links bzw. rechts, wechselt man zwischen den beiden Darstellungen. 

Aus Designgründen habe ich mich damals entschlossen, dass man beim Telefon zwischen Vollbild und Listenansicht durch Drehen des Telefons wechseln kann. Beim Tablet geschieht dies durch das Drücken auf den dazugehörigen Knopf im OSD. Das blendet sich wie der Videotext ein, wenn man auf das TV Bild klickt. 

 

Dein Problem mit der ruckelnden Darstellung liegt wahrscheinlich daran, dass in deinem Fall die Hardwarebeschleunigung nicht verwendet wird. Ich habe ehrlich gesagt noch nicht herausgefunden warum das vornehmlich auf den billigsten Geräten aus China funktioniert und bei einigen Premiummodellen gerne mal nicht.

 

Die auf obigen Screenshot zu sehenden Geräte sind übrigens so ziemlich das Langsamste was man für Android kriegen kann. Links ein FireTV Tablet und rechts irgendein 0815 Chinafon mit MT6750T Chip. Das Telefon hat zudem eine recht verquere Bildschirmauflösung von 21:9. 

Übrigens gibt es hunderte verschiedene Auflösungen, insbesondere bei den Androiden, mit der die Anwendung klar kommen muss. So habe ich alleine 39 verschiedene Icongrößen für Android und iOS in der Anwendung. 

 

Weil das ganze gerade so gut passt, plaudere ich einfach mal kurz aus dem Nähkästchen der Entwicklung, da ich das Projekt ausschließlich selber entwickelt habe. 

Der DVBViewer ist ja bekanntlich in Delphi geschrieben und somit habe ich eine riesige Codebasis in Delphi, die angefangen von Klassen zur Auswertung aller DVB Pakete über die dazugehörigen Decodierung und Darstellung von EPG, Videotext usw. geht und bei nativen Netzwerkcode für Posix- und Windowssysteme (https://github.com/TetrisSQC/SynapseTCP) endet.

Für das Sat>IP Viewer Projekt lag es also nahe das ich das auch in Delphi erstelle. Nun hat Embarcadero (die Macher hinter Delphi) ja seit ein paar Jahren einen plattformunabhängigen Compiler und ein Framework für die Anzeige auf verschiedenen Systemen.  Leider ist Firemonkey alles andere als performant. Sobald man eine Liste hat, mit mehr als ein paar dutzend Einträgen, wird die Darstellung ziemlich träge.

Dazu gibt es ein paar Beiträge in mehreren Foren - unter anderem hier: https://www.delphipraxis.net/182601-firemonkey-grid-performance.html.

Die Erkenntnis aus dem Post von mir damals war, dass ich eine eigene Listenklasse erstelle. Ein normaler Nutzer mag den Aufwand gar nicht einschätzen und ich möchte nicht jammern, aber es hat unzählige Stunden gebraucht bis ich eine halbwegs schnelle Anzeige hatte.

Hat man "nur" DVB-T Sender als Basis, so braucht man sich darüber keine Gedanken zu machen, aber bei Astra 19.2° sind es schon 800 Sender und wenn man Hotbird oder eine andere Orbitposition mit dazu nimmt, kommt man auf mehrere tausend Einträge. Packt man noch ein Senderlogo dazu, was man anzeigen muss, dann verbrät man etliche MB nur für die Kanalliste. Die kann man leider nicht jedes Mal beim Rendern  (40x die Sekunde) neu zeichnen, denn Firemonkey ist auch nicht wirklich schnell was die Anzeige von Text angeht. So und nun kommt man zum nächsten Problem: Buchstaben darstellen und diese einige dutzend Mal in der Sekunde auf den Bildschirm zaubern. Hat das Telefon nur eine 720p Auflösung geht das halbwegs flüssig, bei den 2k und größeren Anzeigen wird es aber eng. Also rendert man die Einträge in Bitmaps und erstellt für den Font ein Raster. Sprich du hast für die Buchstaben eine Textur, schneidest den passenden Buchstaben raus und malst den in ein Rechteck auf dem Display. Das gibt es bei Firemonkey aber nicht, also muss man einen eigenen Rasterizer schreiben. Die Listeneinträge jeweils in einzelne Bitmaps zu rendern und diese anzuzeigen geht nicht, da es Geräte gibt die schlichtweg zu wenig Speicher haben, um da mal ein paar hundert MB an Grafiken vorzuhalten.Es gibt zwar im Internet ein paar Ansätze diesbezüglich, aber die haben es nie mit ein paar tausend Einträgen getestet - irgendwo hab ich das mal erklärt, finde aber den Link dazu nicht mehr ;)

"Was soll das Gejammer, bei anderen geht das doch auch." ist jetzt sicherlich eine Frage die vielen dazu einfällt. Nun die machen das nicht mit Firemonkey, sondern wahrscheinlich Nativ mit den vom System zur Verfügung gestellten Funktionen. Da ich aber Delphi benutze und Firemonkey als Framework, fällt das jedoch flach. Außer ich erstelle mehrere UI Varianten für iOS und Android. Was den Vorteil von 1x entwickeln und auf verschiedene Systeme Deployen etwas ad absurdum führen würde.

 

Das war jetzt im Prinzip nur Basis für die Textdarstellung und Listen. Jetzt kommen diverse Eigenheiten dazu die man bei Mobilen Geräten berücksichtigen darf. Das UI muss zwingend entkoppelt vom Rest sein. Du kriegst eine mobile App sofort vom System abgeschossen, wenn diese länger als ein paar Sekunden hängt. Also muss man alles was Zeit kostet in separate Threads auslagern. Die erste Version der Anwendung wurde vor ein paar Jahren gerne auf einigen Systemen als nicht responsive beendet und der Grund war, dass ich die 100kb große Zip Datei mit den Transponderlisten nicht in einem extra Thread gelesen habe. Was auf dem PC nur den Bruchteil einer Sekunde dauert, frisst auf dem Telefon gerne mal eine oder mehr Sekunden. Das Lesen der Liste in einem extra Thread verursacht jedoch ein weiteres Problem. Wenn der Nutzer die Anwendung zum ersten mal startet, öffnet sich die Einstellungsseite und man kann den Suchlauf starten. Klickt man schnell, ist aber die Datenbank mit den Transponderlisten noch nicht geladen. Also muss man eine Logik entwickeln die eine Mischung aus "Verlangsamung" des Klicktriebs von Nutzern ist (sprich Klickibunti Animationen der Listen von links, nach rechts - oben nach unten usw), sowie eine Indexdatei in der die Informationen stehen, welche man zwingend braucht und mit in die Zip mit den Transponderlisten packt.

Die Animationen haben also nicht nur einen kosmetischen Effekt :)

 

Was mich auch ziemliche Nerven gekostet hat ist, dass man Grafiken nicht in Threads erstellen kann/konnte. Im Ansatz geht das jetzt in aktuelleren Versionen von Delphi, aber damals ging das nicht. Also muss man dauernd zwischen UI und Threads synchronisieren. Nun laufen Threads auch im Hintergrund, wenn die Anwendung  nicht aktiv ist. Will man jetzt etwas im UI aktualisieren, crashed die App. Also muss man diese Eventualität abfangen und berücksichtigen. Was meinen Code anging lief das, aber ich nutze ja auch normale Firemonkeyroutinen und da ging das nicht. Das Debuggen dieser Fälle zog sich über Wochen, zumal kompilieren und der Deployvorgang gerne mal ein paar Minuten braucht und die IDE von Delphi sich nach 2-3x Deployen reproduzierbar verabschiedet. 

 

Ich komme jetzt besser nicht noch auf die Eigenschaften des neuen LLVM Compiler von Delphi zu sprechen. Ich sage nur PAnsiChar und Ansistring gibts nicht mehr, sowie ARC was bestimmte Konstrukte in unseren Basisklassen unmöglich zu benutzen gemacht hat und ich dutzende MB an Code anpassen durfte. 

 

 

Christian

 

 

 

  • Thanks 1
Link to comment

Richtig erkannt das Problem ist Firemonkey.

Damit wirst du nie eine zufriedenstellende Qualität erreichen.

 

Du kannst von den usern ja nicht verlangen deine App besser zu bewerten und über unzulänglichkeiten hinwegzusehen bloss weil es keine native App ist.

Das interessiert doch keinen. Wenn man ne App voller Fehler abliefert und die App am laufenden Band crashed, sind solche Bewertungen halt kein Wunder.

 

39 icons wegen Android? Android kann svg bis 4.0 zurück, ein icon für alles, geht mit Firemonkey evtl nicht.

 

Ständige API anpassungen? ich hab meine App seit ich sie für 2.1 Entwickelt habe genau einmal an eine neue Android Version anpassen müssen und auch nur weil ich ne Funktion missbraucht habe....

  • Thanks 1
Link to comment

@hackbart

 

Erst einmal vielen, lieben Dank für die unglaublich detaillierte Antwort und den tiefen Einblick in Entwicklung der mobilen Sat>IP App.

 

Leider macht aber genau dieser Einblick extrem wenig Hoffnung auf Besserung. ?

 

Ein paar Dinge würde ich gerne noch aufgreifen:

 

Am 20.6.2018 um 19:48 schrieb hackbart:

Beim Design habe ich mich an die damals geltenden Richtlinien für Apple, Google und Microsoft gehalten. Leider ändern alle 3 (gut Microsoft jetzt nicht mehr) ihre Richtlinien alle paar Monate

 

Das ist, gelinde gesagt, völliger Blödsinn. Zu absolut keinem Zeitpunkt dürfte die aktuelle UI unter Apples HI oder Googles MD Guidelines auch nur im Ansatz akzeptabel gewesen sein (Microsoft lassen wir da einfach mal raus). Meine Expertise liegt bei Android und hier gibt es seit Android 5.0 robuste Design Guidelines. Zwar werden die tatsächlich gelegentlich sanft überarbeitet, aber es handelt sich dabei bis heute nur um Klarifikation oder sanfte, evolutionäre Weiterentwicklung und die Grundprinzipien wurden in keinster Weise geändert - auch mit dem, was aktuell gerne als MD 2.0 firmiert wird, ändert sich im Kern wenig. Die meisten Änderungen wären für dich sogar von Vorteil, schließlich haben sich Apples und Googles Guidelines immer mehr angenähert (z.B. Stichwort Bottom Navigation).

 

SAT>IP Viewer fühlt sich hingegen fast so an, als hätte jemand versucht alle "DO NOTS!" sowohl der MD und HI Guidelines in einer einzigen App umzusetzen. Das Bedienprinzipp, das Verhalten des Android Back-Buttons, das Menü-Layout, das Scrolling, selbst die Animationen, es stimmt hier fast gar nichts.

 

Am 20.6.2018 um 19:48 schrieb hackbart:

So habe ich alleine 39 verschiedene Icongrößen für Android und iOS in der Anwendung. 

 

Das ist, wie von @VinoRosso bereits angesprochen, fast gruselig und dürfte auf gar keinen Fall so sein. Das macht einer Umsetzung von Dingen wie Adaptive Icons natürlich im Kern praktisch unmöglich.

 

 

Am 20.6.2018 um 19:48 schrieb hackbart:

Oftmals sind das völlig bekloppte Schnittstellenverschlimmbesserungen die nicht reproduzierbar sind.

 

Auch das darf eigentlich keine solchen Probleme bereiten. API Deprecation ist extrem selten und wird wenn dann lange angekündigt, dass sich eine API auf unterschiedlichen Android version völlig unterschiedlich verhielte wäre mich auch bis heute nicht bekannt. SAT>IP Viewer darf hier eigentlich nicht derart betroffen sein.

 

Das Problem ist hier wohl schlicht das Framework - und das macht nun einmal wenig Hoffnung.

 

Die kommenden Änderungen in Android 9 und am Play Store (z.B. Minimum API Target, Null-Toleranz gegenüber unresponsiven Apps) werden jedoch ultimativ erzwingen, dass die App besser werden muss oder als Projekt in der Form ultimativ aufgegeben wird.

 

 

Trotzdem noch einmal vielen Dank für deine Arbeit. Ich geb die Hoffnung trotz allem nicht auf, dass du die Probleme der App irgendwann in den Griff bekommst. Vielleicht hast du ja mal ein anderes Android Gerät zur Hand als billige China Ware mit Mediatek SoCs.

Edited by Gott
Link to comment

Kein Problem,

 

viele Nutzer wissen meist gar nicht wie viel Arbeit selbst in den kleineren Projekten steckt. 

Was die Icons angeht so ist das bei iOS und Android gang und gäbe:

Bildschirmfoto 2018-06-25 um 13.37.18.png

 

In X-Code sind es aktuell "nur" 18 Icons für ein Projekt. In Delphi sind es, da du ja auch noch die für Android verwalten musst ein paar mehr - je nach ausgewähltem Zielsystem:

Screenshot 2018-06-25 um 13.41.12.jpg

 

Von den Startbildern mal abgesehen, die ich jetzt mal unter den Tisch fallen lasse. Natürlich ändert sich die API unter iOS und Android vom Entwicklerstandpunkt häufig und auch wenn ich schon mehrmals Diskussionen mit Nutzern hatte die der Meinung sind, dass wenn Apple zum Beispiel bei einer Keynote erwähnt den 32bit Support ab dem nächsten Major Update in 6 Monaten zu entfernen genug Zeit bleibt die Produkte anzupassen, so sollte man bedenken das generell Softwareentwicklung nicht zwischen Tür und Angel entsteht.

Der DVBViewer wird seit 2002 entwickelt und der Sat>IP Viewer jetzt auch schon (zumindest offiziell) seit 2014. Da ist ein halbes Jahr Vorlauf nicht wirklich viel. Oftmals kam es in der Vergangenheit vor das die Programme in den Betas noch liefen und dann ab dem Goldmaster aus unerfindlichen Gründen nicht. Das Embarcadero Forum bzw. der Bugtracker ist voll davon. 

Nun erstellst du mit Delphi ja native Applikationen und nutzt dementsprechend auch Lowlevel API Schnittstellen und diese ändern sich insbesondere bei dem Hersteller mit dem angebissenen Obst überdurchschnittlich oft. Mir fällt jetzt außer UIView.safeAreaLayoutGuide nichts ein mit dem ich aktuell zu tun hatte, aber es nervt schon - wenn auf einmal die Statusleiste nicht richtig angezeigt wird und man sich dann durch die Onlinedoku durchkämpfen musst. 

So fliegt demnächst OpenGL gänzlich aus allen Apple Systemen und wird durch Vulcan abgelöst. Super für diejenigen die da mal schnell ihre komplette UI austauschen müssen. Bei mir bedeutet das zum Glück nur das ich meine abstrakte Renderklasse (mit knapp 8 Funktionen zum Initialisieren, Beenden, Zeichnen von Dreiecken und Laden von Texturen bzw. Shadern) durch eine andere Klasse mit exakt den gleichen Routinen für Vulcan ersetzen muss. Vorrausgesetzt die notwendigen Header wurden übersetzt. Dann braucht es einen neuen Compiler für die 64bit MacOS Systeme, da der alte aktuell nur 32bit kann. Wann Embarcadero den veröffentlicht bleibt abzuwarten. 

Zusammengeschraubt ist das ganze dann innerhalb von ein paar Tagen, aber dann kommt Testen und überprüfen. Oftmals treten auf einmal Probleme auf, die vorher nie ein Thema waren. Wurde das dann angepasst kämpft man je nach Reviewer gegen Windmühlen. Die erste Version vom Sat>IP Viewer wurde dutzende Male rejected, da bei Multimedianwendungen Apple ziemlich feinfühlig ist. Die Mac Version musste ich kastrieren, damit der Nutzer Aufnahmen nicht überall speichern darf, sondern nur unter "Eigene Filme\Sat>IP Viewer\". Streams sind sowieso tabu, deswegen dürfen diese nicht aufgezeichnet werden und Werbebilder müssen zwingend von dem jeweils aktuellen Telefon oder Tablet erstellt werden. Da überlegst du dir 3x, ob du eine stabile Version durch ein Update ersetzt :) 

 

Christian

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...