Closed h-johan closed 3 years ago
Danke für die Verbesserung. Konnte es erstmal nur überfliegen, aber so wie ich das sehe wird aktuell nur eine ID gespeichert?
Hier müsste man auch die ID des zweiten Standortes sichern können (MediumWidget) z.B als JSON. Andernfalls wird bei der Verwendung des MediumWidgets ab und zu nur ein Standort anzeigen. Sowas wie :
{ dataId0: 'XXXXX', dataID1: 'YYYYY' }
Ich überlege mir mal was. Dann kann man auch das setzen der CacheID entfernen.
Ich bin jetzt davon ausgegangen, dass der User nur ein Widget ohne Parameter anlegt, da ja jedes Widget ohne Parameter dann das gleiche zeigt. Wenn Parameter im Widget eingetragen werden werden, werden natürlich die Daten dafür geladen. Nur wenn ein Widget keine Location gesetzt hat, wird auch die dataid der Abfrage in die Cache Datei geschrieben. Das sollte jetzt auch beim Medium Widget kein Problem sein, wenn man seinen Heimatort für die erste Spalte und nix für die zweite einträgt
Also es geht exklusiv um Widgets, die keine Location gesetzt haben. Da wird dann geschaut ob Last Location caching aktiviert ist und anschließend die Datei ausgelesen. Das ist ja auch immer nur ein Wert.
Hab noch einen kleinen Fehler gefunden, durch das Label „Offlinemodus“ nie angezeigt wurde. Aktualisierte Version im Anhang.
Kleines Widget
Unkonfiguriertes kleines Widget:
Gibt es kein Internet sieht das Widget so aus:
Mit meinen Änderungen würde es auf dem letzten Standort basierend so aussehen:
Mittleres Widget
Das wäre ein unkonfiguriertes mittleres Widget. Beide Spalten sind Location based:
Dieses Widget hat die Konfiguration 0,53.517059,8.119750,WHV,03405
. Die erste Spalte ist also konfiguriert, die zweite Location based.
Ohne Internet würde das Widget jetzt so aussehen:
Mit meinen Änderungen würde es so aussehen. Basierend auf meinem letzten Standort:
Aber ich denke mal die Unterscheidung „Offlinemodus“ und „kein gps signal“ kann eig raus also hier nochmal ohne: incidence.zip
Gibt es eine Möglichkeit, selber branches und prs zu erzeugen, dann würde ich das ja commiten, so ist das echt ätzend, neuen Code zu schicken. Will ja nicht direkt Forken.
Ich überlege mir mal was. Dann kann man auch das setzen der CacheID entfernen.
Das problem dabei wäre ja, dass der dann eine Zuordnung zu dem Widget machen muss, wenn man mehrere hat. Da wäre doch ne gute Lösung, in der Widget configuration dem Widget als ersten Parameter eine Widgetnamen Variable zu setzen also sowas wie
Home & Work;0,1.23,12.34,Home;1,12.34,1.23,Work
Dann könnte man in der Cache Datei sowas wie:
{
"widgetId": "Home & Work",
"widgetData": [
{
"posId": 0,
"dataId": 12345
},
{
"posId": 1,
"dataId": 54321
}
],
"read": "yyyy-MM-dd“
}
Speichern.
read
damit man dann die Leichen von gelöschten oder umbenannten Widgets loswird.
Dann könnte man bei jeder erfolgreichen Abfrage die dataId für das widget abspeichern (wenn sich was geändert hat) und so offline drauf zugreifen.
Gibt es eine Möglichkeit, selber branches und prs zu erzeugen, dann würde ich das ja commiten, so ist das echt ätzend, neuen Code zu schicken. Will ja nicht direkt Forken.
Geht erstmal leider nur über einen Fork.
Das problem dabei wäre ja, dass der dann eine Zuordnung zu dem Widget machen muss, wenn man mehrere hat. Da wäre doch ne gute Lösung, in der Widget configuration dem Widget als ersten Parameter eine Widgetnamen Variable zu setzen also sowas wie
Das stimmt, glaube zwar das die meisten max. 2 Standorte haben. 2+ müsste man aber trotzdem irgendwie abdecken. Das mit der WidgetID ist eine möglich Lösung.
Also ich verwende zum Beispiel mehrere kleine Widgets für die Kreise meiner Umgebung in einem Stack, da wäre es ja ohne Zuordnung zum Widget, nicht möglich, die korrekten Daten abzufragen. Aktuell ist das über den widgetparamerer kein Problem. Finde die aktuelle Lösung eigentlich auch nicht allzu kompliziert.
Mich hat nur gestört, dass das Widget, das auf meinem Standort basiert sehr oft die Fehlermeldung angezeigt hat, gerade wenn ich mein iPhone lange im sleep hatte. Dann schnell zu gucken ist dann halt nicht möglich.
Das caching für ganze Widgets, würde ja deutlich mehr Arbeit erfordern, und wäre in nem Eigenem issue denke ich mal besser aufgehoben.
Ich habe mal einen PR von meinem Fork erzeugt... (sry bin noch recht neu auf github)
Eine neue Version mit caching ohne parameter ist online. Auch mit der Unterstützung für mehrere Widget / Kombinationen. Gerne testen.
Du loggst den R-Wert noch, denke nicht, dass das beim Benutzer noetig ist. Ansonsten siehe: https://github.com/rphl/corona-widget/issues/71#issuecomment-733629902
Doch der wird geloggt in der JSON für D.
Mache das hier mal zu, wenn es noch Fehler/Probleme zum caching gibt, gerne wieder aufmachen.
Ohne eingestellte Parameter sehe ich sehr oft die Fehlermeldung. Mein Vorschlag wäre ein standardmäßig deaktivierter „Location Cache“, der - wenn aktiviert - eine Datei anlegt, die die cacheid, der letzten erfolgreichen Abfrage zwischenspeichert, und dann, wenn kein gps vorhanden ist, erst versucht auf diese datei und dann auf die verknüpfe cacheid Datei zuzugreifen, um das Widget zu erzeugen.
Hab mal das Location caching eingebaut. Funktioniert soweit ganz gut. Es wird die dataID nur für eine abfrage gecached, die keine parameter im Widget definiert hat. Wenn also kein Widget ohne Parameter eingerichtet ist, wird auch nichts gecached. incidence.zip
Originally posted by @holyjohan in https://github.com/rphl/corona-widget/issues/6#issuecomment-727636434