Moin zusammen,
ich möchte euch gerne einmal auf den Aktuellen Stand bringen, was die P3.0-Problematik, die allgemeine Entwicklung von CSV und vor allem auch die öffentliche Veröffentlichung im Play Store anbelangt.
Ganz kurz vorweg: Das Update für den UI-Fix für P3.0 werde ich noch im Versionsthread 0.26.x veröffentlichen, da es sich ja streng genommen nur um einen Fix handelt. Da die folgenden Texte aber etwas sehr ausschweifend geworden sind, habe ich mich für einen neuen Thread entschieden. Hier geht’s eher allgemein um das, was zukünftig kommt, und weniger um eine spezielle Version. Diese größeren Änderungen werden auch noch einige Zeit brauchen, bis ich sie auf euch los lasse, ich möchte aber trotzdem schon mal etwas darüber diskutieren. Daher lasse ich vorerst beide Threads parallel laufen. Wenn ihr also über Themen der aktuellen Version sprechen wollt, seid ihm im oben verlinkten Thema besser aufgehoben
Updates für P3.0.3
Auf die technischen Details und Änderungen, die das Update für den CSV bedeuten, gehe ich hier detailliert ein:
Was bleibt ist die Tatsache, dass der Emulator inzwischen kaum noch als Referenz genutzt werden kann, wie Apps dann am Ende auf dem echten Auto aussehen. Es hat schon immer gewisse Diskrepanzen gegeben, aber bisher waren das immer nur Kleinigkeiten. Inzwischen ist der Emulator zwei Android-Versionen hinterher (Der läuft noch auf Android 10…), und da hat sich in Bereichen, die den User nicht direkt betreffen, schon einiges getan, was man beim Programmieren beachten muss. Glücklicher weise gibt es von Google einen AAOS 13 Emulator. Mit dem kann ich wenigstens die gröbsten technischen Sachen testen. Aber das ist natürlich alles andere als Ideal, wenn es um UI geht.
An der Stelle eine kleine Sidenote: Selbst von Google selber gibt es noch keinen AAOS 14 Emulator, und auch der 13er ist noch nicht so ewig lange Verfügar. macht euch da also keinen all zu großen Kopf, wenn AAOS etwas hinter dem, was man von Smartphones an Versionsnummern gewohnt ist, hinterher hängt
Was all diese Punkte betrifft werde ich mal meine Fühler Richtung Göteborg ausstrecken und versuchen in Erfahrung zu bringen, ob diese Konsequenzen bekannt waren, oder ob das Bugs sind, und vor allem wie es langsam mal mit aktuellen Emulatoren aussieht.
Veröffentlichung des CSV für jeden
Ein weiteres Thema, mit dem ich mich nun schon lange herumschlage, ist die Veröffentlichung des CSV im Play Store, damit sich jeder die App herunterladen kann. Wie die meisten von Euch sicher bereits wissen, ist das für eine solche App alles andere als einfach. Daher bin ich nach wie vor sehr dankbar, dass ich im regelmäßigen Kontakt mit dem ConX-Team von Polestar in Göteborg stehe.
Auch hier für die Lesefaulen das TL:DR: Polestar wird meine App nicht veröffentlichen, mich aber weiterhin so gut es geht bei technischen Fragen und beratend unterstützen. Aktuell gehen wir davon aus, dass eine Veröffentlichung im Play Store durchaus umsetzbar ist, und ich arbeite an einer entsprechenden Version, die aber in jedem Fall einen Kompromiss darstellen wird.
Der Plan war einmal, dass Polestar, ähnlich wie bei ABRP oder Vivaldi, als „Publisher“ des Car Stats Viewer auftritt. Dafür gabs auch schon viele Gespräche, auch mit Anwälten, und Entwürfe für Verträge, die das ganze geregelt hätten. Allerdings hat sich bereits seit Dezember abgezeichnet, dass das so leider nichts werden wird. Bereits bei einem Call im Dezember wurde darauf eingegangen, dass eine Veröffentlichung einer App, die während der Fahrt genutzt werden kann, nur auf Grundlage der Templates von Google erfolgen kann.
Für die, die nicht wissen, was es mit Templates auf sich hat: Das ist ein Framework, das vom Betriebssystem bereitgestellt wird, und sämtliche Limitationen durchsetzt, die die Fahrerablenkung minimieren sollen. Diese Templates werden z.B. von EVMap benutzt und sind technisch sehr nahe mit Android Auto verwandt. Tatsächlich können UIs, die für Android Auto programmiert wurden, nahezu unverändert mit AAOS verwendet werden. Diese Templates haben fest definierte Layouts, die nur bedingt gestyled werden können. Das ist z.B. auch der Grund, warum alle Medien-Apps zu 99% identisch aussehen.
Nun wäre ich also so oder so an diese Templates „gefesselt“ gewesen. Daher war da schon abzusehen: Wenn ich eine App bauen kann, die Polestar veröffentlichen würde, dann wäre der Weg zur eigenen Veröffentlichung auch nicht mehr weit. Gestern Vormittag hatte ich dann wieder einen Call mit Göteborg, und da habe ich dann die „Hiobsbotschaft“ erhalten, dass Polestar meine App als Third-Party-App nicht veröffentlichen wird. Das ist aber keine Einzelentscheidung zum CSV gewesen, sondern eine allgemeine Ausrichtung, für die sich Polestar nun entschieden hat. Auf weitere Hintergründe und Details dazu möchte ich an dieser Stelle aber nicht eingehen, um keine Gerüchte zu sähen oder interne Details preis zu geben.
Jedenfalls geht es nun dahin, dass Entwickler vermehrt dazu ermutigt werden sollen, ihre Apps selber zu veröffentlichen. Und die Situation ist heute auch eine andere, als es das noch vor einem Jahr war. Der Template Host bekommt regelmäßige Updates mit neuen Features, die immer mehr Möglichkeiten zur Individualisierung bieten, und die Kategorien im Play Store werden auch immer umfangreicher. Daher bin ich zuversichtlich, da etwas brauchbares auf die Beine stellen zu können. Dazu aber später mehr.
Darüber hinaus hat das ganze auch den Vorteil, dass ich vertraglich nicht an Polestar gebunden bin. Wir haben in einigen Gesprächen diskutiert, was mir wichtig wäre und womit ich mich unwohl fühlen würde. Da war schnell klar, das Polestar sehr daran interessiert war, dass sich beide Seiten mit so einem Vertrag wohl gefühlt hätten. Nichts desto trotz wären dort Dinge festgeschrieben worden wie z.B. die Mindestlaufzeit, die die App veröffentlicht bleiben müsste, wie weit im Voraus ich die App abkündigen müsste, wie umfangreich meine Support-Services sein müssten etc. pp… Für eine Privatperson, die das ganze als Hobby betreibt, war das dann schon etwas „gruselig“. In sofern bin ich ohne diesen Vertrag „frei“ und kann für mich selber entscheiden, wie, wann, wie lange und mit wie viel Zeitaufwand ich die App veröffentlichen möchte. Außerdem kann mir dann keiner mehr Vorgaben machen, dass die App „nicht wie Polestar“ aussehen darf. Das war immer so ein Thema, dass irgendwie anders klar werden muss, dass nicht Polestar drin ist, auch wenn es im Play Store drauf steht
Zwar ist es etwas schade, dass die Zusammenarbeit mit Polestar damit etwas geringer ausfällt, als es ursprünglich mal angedacht war, ich sehe das Ganze aber nicht als Rückschlag. Aktuell entsteht mir dadurch kein realer Nachteil und weiterer Kontakt wird von beiden Seiten ausdrücklich gewünscht. Also braucht ihr auch keine Mistgabeln und Fackeln raus holen, weil Polestar mich nicht mehr haben will Eher im Gegenteil. Aktuell macht es etwas den Anschein, dass ich da ein wenig in ein Android-Automotive-Netzwerk rein rutsche, wo ich noch nicht weiß, wie gut ich da als Amateur rein passe
Jedenfalls wird es dahin gehen, dass ich eine eigene Veröffentlichung der App im Play Store anstreben werden. Mit der IoT-Kategorie bin ich auch zuversichtlich, dass der CSV dort hinein passt und von Google akzeptiert wird. Immerhin ist das Auto auch ein „Thing“, das mit dem Internet verbunden ist, wofür die App eine Schnittstelle anbietet Grundvoraussetzung dafür ist aber die Verwendung der Templates. Was ich mir dafür überlegt habe und welche Kompromiss notwendig sein werden, erläutere ich im folgenden Abschnitt. Ohne Kompromisse wird es auf keinen Fall klappen, aber da werden wir schon was finden, womit die meisten leben können.
Die zukünftige Entwicklung des CSV
In den letzten Wochen habe ich mich bereits etwas an das Thema Template Host heran gewagt. Inspiriert wurde ich da etwas von der „The Weather Channel“-App. Diese benutzt einige Templates und Funktionen, die mir bis vor einiger Zeit nicht bekannt waren, und quasi für eine ernsthafte Umsetzung des CSV in Templates gefehlt haben.
Inzwischen habe ich einen Prototypen gebaut, der durchaus nahe an das heran kommt, womit ich als Kompromiss einverstanden wäre. Hier direkt schon mal Bilder der Hauptansicht:
- Der erste Tab stellt quasi den Tripcomputer dar. Dort werden die selben Daten angezeigt, die sonst in der oberen rechten Ecke zu sehen sind. Das sind denke ich die Daten, die grundlegend für die meisten am wichtigsten sind. Über den Button unten Links kann man den Triptypen ändern und den .anuellen Trip zurücksetzen.
- Für den zweiten Tab plane ich eine Ansicht, in der man die Echtzeitdaten einsehen kann, also Momentanleistung und -verbrauch, sowie (zumindest im Prototypen) nochmal den Status der verbundenen APIs. Die passen eh nicht mehr vollständig auf die erste Seite und kommen da dann ggf. wieder weg.
- Der dritte Tab verlinkt dann auf die Altbekannten Ansichten. Die bisherige Hauptansicht nennt sich in der Version dann „Dashboard“
Diese drei Ansichten sind dann die Ansichten, die während der Fahrt verfügbar sein werden. Alles, was bisher in der klassischen App verfügbar ist, kann während der Fahrt nicht betrachtet werden. Das ist eine in Stein gemeißelte Richtlinie von Google, an der sich auch vermutlich nie etwas ändern wird. Besonders beim Dashboard mit den Echtzeitdaten und dem Diagramm ist das sehr schade, aber leider unvermeidlich. Ich hoffe, das Google da kein Problem mit hat, wenn im Stand „normale“ App-Ansichten aufgerufen werden. Da sind die Vorgaben teilweise etwas undurchsichtig. Sollte das nicht der Fall sein, dann werde ich noch deutlich mehr Arbeit in das ganze stecken müssen als eh schon, um ein brauchbares Ergebnis zu erhalten.
Aktuell betrifft diese Limitierung auch noch die Einstellungen. Allerdings sollte es da auch keine große Sache sein, eine Templated-Version davon zu erstellen, über die das wichtigste weiter während der Fahrt zugänglich bleibt. Die Einstellungen sind ja grundsätzlich eher simpel aufgebaut.
In den Templates gibt es auch noch einiges, was ich mal ausprobieren will, was dann aber schon nahe an den Grenzen des „legalen“ heran kommt, oder sogar darüber hinaus geht. Z.B. ist es möglich, Kartenansichten einzufügen. Diese müssen aber nicht zwingend mit einer Karte gefüllt werden, sondern sind viel mehr eine Leinwand, die man mit einem Renderer mit beliebigen Inhalten füttern kann. Clever umgesetzt könnte man das vielleicht missbrauchen, um Visualisierungen und Diagramme darzustellen. Das wird aber vermutlich ein ziemlicher Aufwand und braucht Zeit. Zudem kann ich nicht abschätzen, wie gut Google das findet, wenn man eine Ansicht derartig Zweckentfremdet.
Andererseits wurde genau sowas in der Sample-App von Google gemacht. Das ist technisch gesehen eine Karte, in die Text gerendert wird:
Die Sache, an der ich mir aber im Moment noch am meisten die Zähne ausbeiße, ist, wie ich Daten-Updates in die UI rein bekommen. Die Templates sind überwiegend dazu gedacht, statische Inhalte anzuzeigen. Wenn also in de Tripdaten die Daten aktualisiert werden, müssen diese auch in der UI sichtbar gemacht werden. Dazu wird die UI für ungültig erklärt und die Daten werden neu angefordert. Das ganze hat aber eine stark begrenzte Frequenz, mit der das möglich ist. Sind zum Beispiel neue Daten in der UI angekommen, gibt es einen Timeout, wie schnell die UI wieder ungültig gemacht werden kann. Wechselt man in dieser Zeit den Trip-Typen, passiert gar nichts und der alte Trip-Typ bleibt bis zum nächsten Daten-Update unverändert.
Das alles sind aktuell noch Spekulationen basierend auf meinen bisherigen Tests und Beobachtungen. Was genau da nun dahinter steckt, weiß ich noch nicht. Die Dokumentation für Automotive-Apps, die die Templates benutzen, sind auch alles andere als Umfangreich, und vieles ist „learning by failing“ und anschauen von Code anderer Leute. Ich hoffe, dass mir meine Polestar-Kontakte da bei den technischen Fragen zukünftig weiterhelfen können. Sie haben jedenfalls zugesichert, ihr möglichstes zu tun.
Nun würde mich mal euer erster Eindruck zu dem Gezeigten/Erklärten interessieren. Wie dramatisch wäre es für euch, das Dashboard nicht während der Fahrt sehen zu können? Was wären für euch die wichtigsten Daten? Oder habt ihr gar Ideen, wie man Daten am ansprechendsten in solchen Standardansichten anordnen könnte?
ich habe für mich persönlich festgestellt, dass ich mittlerweile nur noch selten aktiv während der Fahrt die Daten bei CSV beobachte. Von daher wäre das schon ein Kompromiss, mit dem ich leben könnte. Mein Ziel ist es aber natürlich trotzdem, so nah wie möglich an das heran zu kommen, was wir heute haben
Und bevor jemand angst hat: In den Internen Tests wird es dabei bleiben, dass das Dashboard während der Fahrt sichtbar ist. Dort findet ja kein Review durch Google statt. Wer also in einem Test-Track ist, braucht sich keine Sorgen machen, solange der Maintainer weiter Updates veröffentlicht. Es geht hier in erster Linie um eine öffentliche Version, die ohne Teilnehmerbeschränkung von jedem, auch markenübergreifend, installiert werden kann.
So, hiermit dann vielen Dank für eure Zeit, und ich hoffe, meine Ausschweifungen haben euch nicht gelangweilt und zu viel Zeit eures Wochenendes geraubt