CFW: Problem mit ftrobopy-Apps im Store beim Release

Community-Firmware (cfw), Selbstbaucontroller (TX-Pi, ftduino, usw.), usw.
Forumsregeln
Bitte beachte die Forumsregeln!
Benutzeravatar
MasterOfGizmo
Beiträge: 2720
Registriert: 30 Nov 2014, 07:44

Re: CFW: Problem mit ftrobopy-Apps im Store beim Release

Beitrag von MasterOfGizmo » 27 Dez 2016, 22:32

Lars hat geschrieben:In der professionellen Framework-Entwicklung geht man daher API-weise vor.
Ganz so einfach liegt der Fall hier nicht. Die API-Erweiterung von ftrobopy ist komplett rückwärtskompatibel, wenn ich das recht verstehe. Aber gleichzeitig wird in der neuen Firmware der Dienst abgeschaltet, den wir via ftrobopy bisher genutzt haben. Und nun geht es um die Frage, ob man ftrobopy so baut, dass es sich den alten Apps gegenüber trotzdem so verhält wie früher oder eben nicht.

Früher hat man "localhost" angegeben, wenn ftrobopy auf dem TXT lief und sich mit dem eigenen Netzwerkdienst verbinden wollte. Ab firmware 0.9.3 gibt man an der Stelle nun "direct" an. Localhost geht nicht mehr, weil es diesen Netzwerkdienst nicht mehr gibt. Und nun geht die Diskussion eigentlich um die Frage, ob man den aus dem Netzwerk bekannten Begriff "localhost" auch dann noch verwenden darf, wenn am Ende gar keine Netzwerkverbindung zustande kommt. Ich bin der Meinung ja, kann man, da das Verhalten von außen betrachtet eh nicht zu unterscheiden ist. Die Gegenstimmen sagen nein, wenn es keine Netzwerkverbindung ist, die dort schlussendlich genutzt wird, dann soll man das auch nicht localhost nennen.

Und genau diese Frage wurde gestellt und eben auch sofort mit Taten entschieden, so dass nun alle Apps geändert werden müssen.
Arduino für fischertechnik: ftDuino http://ftduino.de, ftDuino32 http://ftduino.de/32

Benutzeravatar
MasterOfGizmo
Beiträge: 2720
Registriert: 30 Nov 2014, 07:44

Re: CFW: Problem mit ftrobopy-Apps im Store beim Release

Beitrag von MasterOfGizmo » 27 Dez 2016, 22:34

richard.kunze hat geschrieben: Huh? Als ich das gestern das letzte mal probiert hatte lief die Radio-App noch prima...
Die Radio-App benutzt nicht ftrobopy zur Sound-Ausgabe. Es geht um die Ausgabe der üblichen TXT-Sounds aus der alten Firmware.
Arduino für fischertechnik: ftDuino http://ftduino.de, ftDuino32 http://ftduino.de/32

Benutzeravatar
MasterOfGizmo
Beiträge: 2720
Registriert: 30 Nov 2014, 07:44

Re: CFW: Problem mit ftrobopy-Apps im Store beim Release

Beitrag von MasterOfGizmo » 27 Dez 2016, 22:37

richard.kunze hat geschrieben: Der fliegt beim Directory-Scan auf die Nase
Raphael schrieb, dass er auf keiner Firmware-Version läuft. Also habe ich ihn erstmal entfernt. Wenn er nicht stabil funktioniert muss er warten, bis ich mal wieder Zeit für ihn habe ...
Arduino für fischertechnik: ftDuino http://ftduino.de, ftDuino32 http://ftduino.de/32

richard.kunze
Administrator
Beiträge: 583
Registriert: 26 Dez 2015, 23:49
Wohnort: Rhein-Main-Gebiet

Re: CFW: Problem mit ftrobopy-Apps im Store beim Release

Beitrag von richard.kunze » 27 Dez 2016, 22:41

MasterOfGizmo hat geschrieben:Das Stichwort ist alle. Denn dieser Ansatz skaliert m.E. nicht und genau deshalb hätte ich das gerne vorher besprochen. Ihr müsste jedes mal wieder alle Apps anfassen wenn eine nicht-kompatible Änderung in einer einzelnen Api kommt.
Der Punkt ist einmalig, und zwar weil sich die Syntax des Felds 'firmware' geändert hat. Früher war das irgendein adhoc definierter Text-String, jetzt ist es ein Text-String, den semantic_version.Spec() parsen kann. Und das muss man dann halt auch mal anpassen.

Die Semantik für 'firmware' ist übrigens noch exakt dieselbe wie in https://github.com/ftCommunity/ftcommun ... -first-app beschrieben: "firmware is the firmware version number this app has been tested for. Currently only 0.9 exists. Later this will allow ranges like 0.9-1.1". Jetzt ist es halt "later", und die Syntax erlaubt sogar mehr als simple Bereiche. Und der Store beachtet das Feld jetzt auch tatsächlich mal.

Torsten
Beiträge: 308
Registriert: 29 Jun 2015, 23:08
Wohnort: Gernsheim (Rhein-Main-Region)

Re: CFW: Problem mit ftrobopy-Apps im Store beim Release

Beitrag von Torsten » 27 Dez 2016, 22:45

Also ich denke inzwischen, dass es wirklich das Beste wäre, den TxtControlMain-Prozess zum jetzigen Zeitpunkt noch nicht per default abzuschalten sondern damit noch zu warten bis der "direct"-Modus voll abwärtskompatibel zum alten sockel-gebundenen "localhost"-Modus ist.

Torsten

jona2004
Beiträge: 149
Registriert: 10 Jun 2011, 22:30

Re: CFW: Problem mit ftrobopy-Apps im Store beim Release

Beitrag von jona2004 » 27 Dez 2016, 22:45

Hallo,
zwei kurze Bemerkungen
Wie von Richard gesagt klemmte MP3 mit dem build von gestern Mittag, weil listdir auf directories stösst, die es nicht lesen kann. Ich habe das auf os.walk umgestellt. funktioniert, allerdings werden auch die sounds vom launcher gefunden (click, delete, ...) das ist noch ein bischen hässlich. Wenn Interesse am code besteht bitte melden.
Mit dem gestrigen build funktionierte die Radio App.
heute habe ich nichts neues gebaut, da im Moment ja viel dynamic drin ist :D
Grüsse Joachim

Benutzeravatar
MasterOfGizmo
Beiträge: 2720
Registriert: 30 Nov 2014, 07:44

Re: CFW: Problem mit ftrobopy-Apps im Store beim Release

Beitrag von MasterOfGizmo » 27 Dez 2016, 23:00

Torsten hat geschrieben:Also ich denke inzwischen, dass es wirklich das Beste wäre, den TxtControlMain-Prozess zum jetzigen Zeitpunkt noch nicht per default abzuschalten sondern damit noch zu warten bis der "direct"-Modus voll abwärtskompatibel zum alten sockel-gebundenen "localhost"-Modus ist.
Äh, nee. Genau deshalb ist das Apps-Repository jetzt so schön aufgeräumt. Jetzt kommen die Änderungen und dann schauen wir, was von den alten Apps wieder zum Laufen gebracht wird und was keiner mehr braucht.
Arduino für fischertechnik: ftDuino http://ftduino.de, ftDuino32 http://ftduino.de/32

Benutzeravatar
ski7777
Beiträge: 870
Registriert: 22 Feb 2014, 14:18
Wohnort: Saarwellingen

Re: CFW: Problem mit ftrobopy-Apps im Store beim Release

Beitrag von ski7777 » 27 Dez 2016, 23:01

richard.kunze hat geschrieben:
MasterOfGizmo hat geschrieben:Sound wird in 0.9.3 dann auch nicht mehr unterstützt? Schade.
Huh? Als ich das gestern das letzte mal probiert hatte lief die Radio-App noch prima...
Dia Radio-App nutzt ja auch das direkte SPI System, was Till für den MP3-Player entwickelt hat.

richard.kunze
Administrator
Beiträge: 583
Registriert: 26 Dez 2015, 23:49
Wohnort: Rhein-Main-Gebiet

Re: CFW: Problem mit ftrobopy-Apps im Store beim Release

Beitrag von richard.kunze » 27 Dez 2016, 23:30

MasterOfGizmo hat geschrieben: Bisher stand da "0.9" was im Klartext "benötigt mndestens Firmware 0.9" heissen sollte. Das stimmt ja auch nach wie vor für alle Apps. Jetzt wollt ihr auch eine Maximal-Version per "<" angeben können. Aber das ist m.E. in der Praxis kaum sinnvoll, denn das weiss der App-Entwickler in der Regel ja gar nicht, dass in einer späteren Firmware-Version mal Inkompatibilitäten auftreten werden. Das passiert nur im umgekehrten Fall (wie dem aktuellen), dass ein Framework geändert wird und einem bewusst wird, dass bestimmte Apps damit nicht mehr laufen werden.
Deshalb passt in so einem Fall dann auch derjenige die Manifeste an, der die Änderung in der Firmware gemacht hat.

Und nein "0.9 und später" stimmt eben genau nicht mehr für alle Apps. Apps, die ftrobopy benutzen, laufen ohne Anpassung nur mit den Firmware-Versionen ">=0.9.0, <0.9.3". Und die angepassten Apps laufen dann entweder wieder mit allen Firmware-Versionen (wie aktuell Brickly) oder eben in der einen Version mit ">=0.9.0, <0.9.3" und in der anderen dann mit ">= 0.9.3". Manchmal lohnt sich Rückwärtskompatibilität um jeden Preis nämlich auch nicht.

Und in genau diesen Fällen haben wir mit genau diesem Mechanismus dann wenigstens die Möglichkeit, dafür zu sorgen dass trotzdem jede aktuell verbreitete Firmware-Version eine funktionierende Version der App bekommt. Die Variante für die älteren Firmware-Versionen bekommt dann halt eventuell keine Updates mehr - aber das ist ja auch kein Beinbruch. Dann aktualisiert man halt die Firmware, um die neueste Version der App laufen lassen zu können.
MasterOfGizmo hat geschrieben:Aber in dem Fall _alle_ betroffenen Apps anzufassen gibt m.E. wenig Sinn.
Was willst Du denn stattdessen tun? Die Firmware bis in alle Ewigkeit mit jeder irgendwann mal existierenden App kompatibel halten? Das läuft früher oder später (eher früher) auf ein grausliches Dickicht von zig nebeneinander her existierenden API-Varianten raus, die letztendlich alle dasselbe machen - nur halt immer ein klein wenig anders. Das Paradebeispiel für sowas sind die diversen Windows-APIs - Microsoft versucht nämlich exakt das.

Oder schlägst Du vor, beim nächsten mal auch wieder gleich alles zu löschen wo möglicherweise eine Anpassung erforderlich werden könnte?
MasterOfGizmo hat geschrieben:Ich lasse mich gerne eine besseren belehren. Konkrete Frage also: Was soll ein App-Autor in Zukunft als maximale Firmware-Version im manifest eintragen?
Gar nichts. Das macht derjenige, der vor einem neuen Firmware-Release die Apps testet. Oder - falls das tatsächlich mal zu viele werden so dass das nicht mehr skaliert - dann macht das derjenige, der auf den Bugreport "App XY tut mit Firmware Version Z nicht mehr" reagiert. Und der macht das dann auch nur, wenn er die App nicht so anpassen kann dass sie mit allen Firmware-Versionen läuft, und in der Regel dann auch nur für eine Übergangszeit, in der eben mehr als eine Version der App parallel gebraucht werden kann/soll.
MasterOfGizmo hat geschrieben:Meines Erachtens gibt es keine sinnvolle Antwort auf diese Frage. Er könnte bestenfalls von jedem verwendeten Framework angeben, welche Version er erwartet. Dann kann man bei inkompatiblen Framework-Updates auf Framework-Seite testen, ob es nicht geht oder nicht. Aber das weiss nur jedes Framework für sich, ob die aktuelle Version zur Version xyz, die eine App erwartet, kompatibel ist oder nicht. Aber das endet schnell in einer kompletten Verwaltung aller Abhängigkeiten.
Das "Framework" für Apps ist die Community-Firmware. Und die Möglichkeit, "an[zu]geben, welche Version er erwartet" habe ich da gerade eben eingebaut...

Den Versions- und Abhängigkeitsverhau halbwegs kleinzuhalten ist übrigens einer der Gründe, warum die CFW "im Stück" aktualisiert wird und nicht (wie bei den "grossen" Linux-Distribution üblich) häppchenweise über eine Paketverwaltung. Damit haben wir nämlich effektiv nur genau die eine Abhängigkeit der Apps von der Firmware-Version, und nicht zig individuelle Abhängigkeiten von allen verwendeten Frameworks.

Und in der Praxis werden wir in den Apps maximal zwei oder drei Versionen der Firmware parallel unterstützen müssen - zumindest solange wir den Leuten ausreichend Grund dafür geben, die CFW auf ihren TXTs halbwegs aktuell zu halten.

richard.kunze
Administrator
Beiträge: 583
Registriert: 26 Dez 2015, 23:49
Wohnort: Rhein-Main-Gebiet

Re: CFW: Problem mit ftrobopy-Apps im Store beim Release

Beitrag von richard.kunze » 27 Dez 2016, 23:33

ski7777 hat geschrieben:
richard.kunze hat geschrieben:
MasterOfGizmo hat geschrieben:Sound wird in 0.9.3 dann auch nicht mehr unterstützt? Schade.
Huh? Als ich das gestern das letzte mal probiert hatte lief die Radio-App noch prima...
Dia Radio-App nutzt ja auch das direkte SPI System, was Till für den MP3-Player entwickelt hat.
Ach so. Wäre das dann eventuell eine Möglichkeit, ftrobopy im Direct-Mode wieder Sound beizubringen?

Benutzeravatar
ski7777
Beiträge: 870
Registriert: 22 Feb 2014, 14:18
Wohnort: Saarwellingen

Re: CFW: Problem mit ftrobopy-Apps im Store beim Release

Beitrag von ski7777 » 27 Dez 2016, 23:36

Könnte man machen, aber da schwebt mir etwas mit alsa vor.
Ich würde Sounds mit aplay, mpg123, oder so abspielen, durch eine virtuelle Soundkarte leiten und dann via arecord mit stdout in den SPI schicken. Leider konnte ich snd-aloop nicht zum laufen bringen.

Raphael

richard.kunze
Administrator
Beiträge: 583
Registriert: 26 Dez 2015, 23:49
Wohnort: Rhein-Main-Gebiet

Re: CFW: Problem mit ftrobopy-Apps im Store beim Release

Beitrag von richard.kunze » 27 Dez 2016, 23:58

ski7777 hat geschrieben:Könnte man machen, aber da schwebt mir etwas mit alsa vor. Ich würde Sounds mit aplay, mpg123, oder so abspielen, durch eine virtuelle Soundkarte leiten und dann via arecord mit stdout in den SPI schicken.
Prinzipiell eine gute Idee. Aber...
ski7777 hat geschrieben:Leider konnte ich snd-aloop nicht zum laufen bringen.
... das klingt jetzt nicht so, als würde das demnächst funktionieren.

Während txt_sound_cat zwar nicht so schön sein mag wie ein "echter" Audiotreiber. Aber es hat den unbestreitbaren Vorteil, dass es bereits da ist und auch funktioniert.

Benutzeravatar
ski7777
Beiträge: 870
Registriert: 22 Feb 2014, 14:18
Wohnort: Saarwellingen

Re: CFW: Problem mit ftrobopy-Apps im Store beim Release

Beitrag von ski7777 » 27 Dez 2016, 23:59

Ich will ja das arecord-stdout dann in txtsbdcat leiten

richard.kunze
Administrator
Beiträge: 583
Registriert: 26 Dez 2015, 23:49
Wohnort: Rhein-Main-Gebiet

Re: CFW: Problem mit ftrobopy-Apps im Store beim Release

Beitrag von richard.kunze » 28 Dez 2016, 00:17

ski7777 hat geschrieben:Ich will ja das arecord-stdout dann in txtsbdcat leiten
Also dann letztendlich ftrobpoy->alsa->txt_snd_cat?

Nee, das macht so keinen Sinn. Alsa über txt_snd_cat ist eine halbwegs vernünftige Krücke, um generischen Sound auf dem TXT zum laufen zu bringen ohne einen Kernel-Treiber schreiben zu müssen. Aber ftrobopy muss man eh anfassen um da Sound im Directmode hinzubekommen, und da dann den Umweg über Alsa zu gehen ist ziemlich sinnfrei. Vor allem, weil wir momentan effektiv sowieso nur jeweils eine App gleichzeitig laufen haben die irgendwas mit der Hardware macht und es damit auch egal ist, das Alsa mehrere Soundquellen mixen und multiplexen kann. Wir haben eh nur immer höchstens eine gleichzeitig.

Das würde nur Sinn ergeben, wenn wir die Soundunterstützung irgendwann mal per Kernel-Treiber realisieren. Sollte zwar eigentlich durchaus machbar sein - die Hauptarbeit (nämlich rauszufinden was man wie an die Hardware schicken muss) hat MoG in txt_snd_cat ja schon erledigt. Was bleibt ist, sich mal anzuschauen wie ein Sound-Treiber im Kernel auszusehen hat und das entsprechend umzusetzen. Das ist bei mir allerdings jetzt nicht allzuweit oben auf der Prioritätenliste.

Lars
Beiträge: 564
Registriert: 25 Okt 2016, 21:50

Re: CFW: Problem mit ftrobopy-Apps im Store beim Release

Beitrag von Lars » 28 Dez 2016, 09:25

Hallo zusammen,
richard.kunze hat geschrieben:Deshalb passt in so einem Fall dann auch derjenige die Manifeste an, der die Änderung in der Firmware gemacht hat.
hmpf - stelle Dir ein solches Vorgehen mal bei einem App-Store mit Hunderttausenden von Angeboten vor - das ist nicht durchführbar. Und ein automatisiertes Vorgehen wäre ja auch nicht sinnvoll etwa bei einer Änderung, die sich nur auf ganz wenige Apps oder die sich auch mal gar nicht auf bereits geschriebene Apps auswirkt.
richard.kunze hat geschrieben:Manchmal lohnt sich Rückwärtskompatibilität um jeden Preis nämlich auch nicht.
Man überlegt sich schon beim Entwurf eines Aufrufes oder eines API, wie man es möglichst zukunftssicher gestaltet. Im hier diskutierten Beispiel der Verbindung mit dem "eigentlichen" MCU-Prozeß war der stringförmige Parameter für die Zieladresse schon mal gar keine schlechte Idee. Ich hätte noch dafür gesorgt, daß man auch eine (komma)separierte Liste von Zieladressen übergeben kann, die der Reihe nach bis zum Erfolg durchprobiert werden, neben der Möglichkeit, sowas wie "auto" zu übergeben. Nett wäre dann noch "ftstandards" als Synonym für die IP-Adressen, die Fischertechnik ab Werk für Bluetooth und USB vergeben hat. Dieser Aufruf würde dann wirklich beinahe jedes Szenario abdecken.

Bei Einführung neuer Verhaltensweisen dürfte man die durch "auto" oder "ftstandards" abgedeckten nicht ändern, sondern nur durch entsprechend neue Begriffe zugänglich machen. Dann erübrigt sich der ohnehin heikle und von vielen Entwicklern schlicht nicht erwünschte Eingriff in ihre Codes.
richard.kunze hat geschrieben:Und in genau diesen Fällen haben wir mit genau diesem Mechanismus dann wenigstens die Möglichkeit, dafür zu sorgen dass trotzdem jede aktuell verbreitete Firmware-Version eine funktionierende Version der App bekommt.
Wenn ich es richtig verstanden habe, schaltet die Vorgabe einer maximal zulässigen Version die App erstmal ab. Ich hätte da allenfalls das Veröffentlichungsdatum der App mit Veröffentlichungsdatum der Firmware verglichen und im Falle einer jüngeren Firmware *einmalig* einen Warnhinweis eineblendet, der auf die Möglichkeit von Inkompatibilitäten hinweist.
richard.kunze hat geschrieben:
MasterOfGizmo hat geschrieben:Aber in dem Fall _alle_ betroffenen Apps anzufassen gibt m.E. wenig Sinn.
Was willst Du denn stattdessen tun?
Für die Pflege einer App ist grundsätzlich deren Hersteller zuständig. Eventuell könnte man beim erstmaligen Einstellen in den Store sich die Genehmigung dafür einholen, eine aktualisierte Version automatisiert zu erstellen, wenn eine jüngere Firmware den alten Code ohne Verhaltensänderung oder gar Fehlern ausführen kann.
richard.kunze hat geschrieben:Die Firmware bis in alle Ewigkeit mit jeder irgendwann mal existierenden App kompatibel halten?
Im Prinzip schon. Softwareentwicklung ist halt ein richtiger Beruf und APIs müssen wie jeder einzelne Aufruf sorgfältig entworfen werden, dann sind inkompatible Änderungen auch deutlich weniger wahrscheinlich als Du es jetzt befürchtest.

Klar ist aber auch, daß sich die Community-Firmware noch in einer relativ wilden Aufstiegszeit befindet und jeder App-Hersteller mit etwas heftigeren Bewegungen rechnen muß.
richard.kunze hat geschrieben:Das läuft früher oder später (eher früher) auf ein grausliches Dickicht von zig nebeneinander her existierenden API-Varianten raus, die letztendlich alle dasselbe machen - nur halt immer ein klein wenig anders. Das Paradebeispiel für sowas sind die diversen Windows-APIs - Microsoft versucht nämlich exakt das.
Warum wohl? Weil die Existenz einer API für sie wirtschaftliche Bedeutung hat, bei der es sich nicht empfiehlt, die Hersteller passender Anwendungen nachhaltig zu verärgern. Davon abgesehen empfand ich es nie als störend, daß es beispielsweise neben dem GDI auch noch DirectX als weiteren Weg zur Bildschirmgraphik gibt. Oder bei Linux nun Wayland *allmählich* X-Windows ablöst.

Mit freundlichen Grüßen
Lars

Benutzeravatar
ski7777
Beiträge: 870
Registriert: 22 Feb 2014, 14:18
Wohnort: Saarwellingen

Re: CFW: Problem mit ftrobopy-Apps im Store beim Release

Beitrag von ski7777 » 28 Dez 2016, 09:28

Lars hat geschrieben:
richard.kunze hat geschrieben:Deshalb passt in so einem Fall dann auch derjenige die Manifeste an, der die Änderung in der Firmware gemacht hat.
hmpf - stelle Dir ein solches Vorgehen mal bei einem App-Store mit Hunderttausenden von Angeboten vor - das ist nicht durchführbar. Und ein automatisiertes Vorgehen wäre ja auch nicht sinnvoll etwa bei einer Änderung, die sich nur auf ganz wenige Apps oder die sich auch mal gar nicht auf bereits geschriebene Apps auswirkt.
So läuft es bei Google/Apple/MS auch. Da kannst du für jede App je nach Android-Version, Architektur, sogar für jedes Gerät einzeln Versionen hochladen. Zusätzlich gibts auch noch einen Beta-Ring, in dem es nicht besser aussieht.

Raphael

Benutzeravatar
MasterOfGizmo
Beiträge: 2720
Registriert: 30 Nov 2014, 07:44

Re: CFW: Problem mit ftrobopy-Apps im Store beim Release

Beitrag von MasterOfGizmo » 28 Dez 2016, 10:25

Lars hat geschrieben: hmpf - stelle Dir ein solches Vorgehen mal bei einem App-Store mit Hunderttausenden von Angeboten vor - das ist nicht durchführbar.
Es hat ja schon bei den paar vorhandenen Apps nicht geklappt. sie anzufassen, ohne sie zu beschädigen. Wenn man einfach nur per Copy'n Paste arbeitet, dann löscht man halt leicht eine Funkionalität, bei der der Entwickler sich was gedacht hat.

Ich schaue mal, dass ich meine Apps nach Sylvester irgendwann woanders ablege, dann kann man sie noch per Web-Interface manuell installieren und sie tauchen nur nicht mehr im App-Store auf.
Arduino für fischertechnik: ftDuino http://ftduino.de, ftDuino32 http://ftduino.de/32

Lars
Beiträge: 564
Registriert: 25 Okt 2016, 21:50

Re: CFW: Problem mit ftrobopy-Apps im Store beim Release

Beitrag von Lars » 28 Dez 2016, 11:00

Hallo ski7777,
ski7777 hat geschrieben:
Lars hat geschrieben:
richard.kunze hat geschrieben:Deshalb passt in so einem Fall dann auch derjenige die Manifeste an, der die Änderung in der Firmware gemacht hat.
hmpf - stelle Dir ein solches Vorgehen mal bei einem App-Store mit Hunderttausenden von Angeboten vor - das ist nicht durchführbar. Und ein automatisiertes Vorgehen wäre ja auch nicht sinnvoll etwa bei einer Änderung, die sich nur auf ganz wenige Apps oder die sich auch mal gar nicht auf bereits geschriebene Apps auswirkt.
So läuft es bei Google/Apple/MS auch. Da kannst du für jede App je nach Android-Version, Architektur, sogar für jedes Gerät einzeln Versionen hochladen.
Ja, aber wenn ich eine App für Android 5.0 hochlade, verschwindet sie doch nicht für die Nutzer der Folgeversionen 5.1, 5.2 usw. So daß man nicht "ausschließlich für", sondern "nutzbar ab Android 5.0" spezifiziert hat. Und bei "normalen" Windows-Anwendungen *kann* der Installer oder aber auch die Anwendung selbst Versionsprüfungen durchführen, *muß* es aber offenkundig keineswegs, denn selbst heute mit Windows 10 kracht es gelegentlich noch.

Mit freundlichen Grüßen
Lars

Benutzeravatar
MasterOfGizmo
Beiträge: 2720
Registriert: 30 Nov 2014, 07:44

Re: CFW: Problem mit ftrobopy-Apps im Store beim Release

Beitrag von MasterOfGizmo » 28 Dez 2016, 11:08

Was ich gut gefunden hätte (in der Reihenfolge):
  • Die Firmware-Änderungen werden so durchgeführt, dass zunächst allen Apps unverändert weiter laufen. Auch wenn dafür ein "Hack" nötig ist, den man ja auch später, wenn sich die neue Firmware mal etabliert hat wieder entfernen kann.
  • Wenn ein API-Bruch nötig ist wäre ich als App-Entwickler gerne frühzeitig informiert worden, dann hätte ich alle meine Apps rechtzeitig angepasst, so dass sie weiterhin auf allen Firmware-Versionen laufen. So wie ich es jetzt mit "Brickly" getan habe.
Mein Plan ist, alle Apps bis zum Release der 0.9.3 so zu verändern, dass sie auf allen Firmware-Versionen laufen. Dazu werde ich sie alle in ein separates Repository verlegen. Beginnen werde ich nachher mit denen, die noch im alten verblieben Repository sind, da sie nach wie vor unabhängig von der Firmware-Version sind. Das hat den Vorteil, dass die beplanten Firmware-Änderungen problemlos durchgeführt werden können ich mich aber gleichzeitig nicht um die verschiedenen Repositoriy-Branches kümmern muss. Das möchte ich unbedingt vermeiden.
Arduino für fischertechnik: ftDuino http://ftduino.de, ftDuino32 http://ftduino.de/32

Benutzeravatar
PHabermehl
Beiträge: 2429
Registriert: 20 Dez 2014, 22:59
Wohnort: Bad Hersfeld

Re: CFW: Problem mit ftrobopy-Apps im Store beim Release

Beitrag von PHabermehl » 29 Dez 2016, 00:02

Hallo Jungs,
toll, daß Ihr über die Feiertage so aktiv wart. Als "Außenstehender" kann ich aber nur bedingt verstehen, was hier so abgeht, und hab da mal 'ne Frage:

Der AppStore meines TXT ist bis auf drei Apps leer. Das scheint mit einem Update der Community-Firmware zusammenzuhängen.
-> Gibt es das Update für "Anwender" irgendwo? Auf Github unter dem Link, der in der deutschen Kurzanleitung auf den "latest release" zeigt, ist die 0.9.2 zu finden.
-> Gibts Brickly noch? (So wie ich verstanden habe, ja, irgendwo...)

Gruß
Peter
https://www.MINTronics.de -- der ftDuino & TX-Pi Shop!

viele Grüße
Peter

Antworten