chargEV - Ladestationen-Finder App für iOS

[kassiopeia]

Es bleibt aber dabei, falls alle ios-Nutzer die gleichen Einträge in GE machen die sie auch ohne Remus' App gemacht hätten entzweit sich hier nichts, es gibt lediglich einen Zusatznutzen für ios-user.
Und das gilt nicht nur für Benutzer, die in GE keine Einträge machen würden, sondern auch z.b. für solche die in GE nur Statusänderungen eintragen (wie ich). ich trage jede öffemtliche Ladung in die App ein, aber alle Statusänderungen auch direkt in GE...

[Fridgeir]

Es bleibt aber dabei, falls alle ios-Nutzer die gleichen Einträge in GE machen die sie auch ohne Remus' App gemacht hätten entzweit sich hier nichts, es gibt lediglich einen Zusatznutzen für ios-user.
Und das gilt nicht nur für Benutzer, die in GE keine Einträge machen würden, sondern auch z.b. für solche die in GE nur Statusänderungen eintragen (wie ich). ich trage jede öffemtliche Ladung in die App ein, aber alle Statusänderungen auch direkt in GE...

Es gibt eben die Nutzer, die sagen 'in Remus App oder gar nicht'; sonst hätte ich diese Diskussion nicht angestoßen; und wer sich die Mühe macht, im T+R Baustellen Thread das verfolgt, gibt es dazu klare Meinungen.

Aber bitte, macht wie ihr wollt. Ich werde zu gegebener Zeit daran erinnern, wo der Anfang vom Ende war.

Ich kann es nicht oft genug betonen, ich wünschte, wir müssten diese Diskussion nicht führen und Remus' sowie alle anderen App könnten endlich eine schnelle, leichte und vielleicht auch schicke Variante des Checkins ins GE-Verzeichnis via Schnittstelle realisieren.

[remus]

(..)
sowie alle anderen App könnten endlich eine schnelle, leichte und vielleicht auch schicke Variante des Checkins ins GE-Verzeichnis via Schnittstelle realisieren.

Das eigene Backend hätte ich so oder so benötigt, auch wenn die API von Anfang an eine Möglichkeit gehabt hätte. Das habe ich auch hier bereits damals schon elaboriert:

https://github.com/remuslazar/EVPlugFin ... In-Feature

Meine App sollte auch weiterhin nicht direkt mit GE "verheiratet" sein, aktuell wird auch OCM als Quelle angeboten und man kann auch Favoriten übergreifend speichern (z.B. auch Ladestationen aus OCM, welche im GE nicht verfügbar sind, Ausland z.B.). Es ist nicht ausgeschlossen, dass später noch weitere Datenquellen dazu kommen werden. Die Check-Ins sollten jedoch source-agnostic sein.

Für Check-Ins, die man einem GE Ladepunkt zuordnen kann, kann man eine bidirektionale Synchronisierung einrichten. Das würde dann aber nicht über die App direkt gehen sondern über eine sog. "Server-to-Server Verbindung". Heißt also, die App würde weiterhin die Check-Ins in das eigene Backend (CloudKit) ein pflegen, die Daten werden dann im Hintergrund synchronisiert. Klingt nach Mehraufwand, ist aber technisch besser und erlaubt ohne viel Aufwand hinterher Features wie Push z.B. - das würde dann auch für die GE-Meldungen funktionieren.

Sprich: der Windows-User trägt den GE Ladelog via Website ein und alle iOS User, welche diese Station als Favorit eingerichtet haben bekommen das per Push übermittelt innerhalb weniger Sekunden (ohne dass die App läuft oder im Hintergrund irgendwas machen muss).

[secuder]

Es bleibt aber dabei, falls alle ios-Nutzer die gleichen Einträge in GE machen die sie auch ohne Remus' App gemacht hätten entzweit sich hier nichts, es gibt lediglich einen Zusatznutzen für ios-user.

Doch, es entzweit sich, da Störungsmeldungen unsynchronisiert erstellt werden und womöglich auch unsynchronisiert gelöscht werden können. Da bilden sich unterschiedliche Datenstände aus.

Die Grunddaten (das Verzeichnis) bleibt natürlich, insofern sehe ich da jetzt nicht den Anfang vom Ende. Aber unschön ist es, aber das sehen ja wohl alle so.

Remus,
wenn ich das recht sehe, dann ist einer der Bedenken von Guy doch, dass er durch die Meldung über die App die Datenbank mehr oder minder unkontrolliert öffnen müsste wegen des indirekten Einloggens. Nun schreibst Du, dass die Daten sowieso gesammelt und damit letztlich sozusagen über einen Account kommen würden.
Vielleicht ist das für Guy ein gangbarer Weg, wenn er das Tor nicht weit aufstoßen muss, sondern nur einem "User"?

grüsse
secuder

[remus]

Doch, es entzweit sich, da Störungsmeldungen unsynchronisiert erstellt werden und womöglich auch unsynchronisiert gelöscht werden können. Da bilden sich unterschiedliche Datenstände aus.

nicht ganz, da ich mit einer sog. "last wins" Strategie arbeite, i.d.R. ist ja eh die neuste Meldung interessant. Die Historie spielt da keine große Rolle, wenn da ein oder zwei Einträge "verbogen" sind.

Remus,
wenn ich das recht sehe, dann ist einer der Bedenken von Guy doch, dass er durch die Meldung über die App die Datenbank mehr oder minder unkontrolliert öffnen müsste wegen des indirekten Einloggens. Nun schreibst Du, dass die Daten sowieso gesammelt und damit letztlich sozusagen über einen Account kommen würden.
Vielleicht ist das für Guy ein gangbarer Weg, wenn er das Tor nicht weit aufstoßen muss, sondern nur einem "User"?

Das habe ich alles bereits auch schon so vorgeschlagen. Wenn ich ehrlich bin, will ich auch gar nicht, dass sich die User mit dem GE-Daten in der App einloggen. Wie gesagt, die App sollte nicht mit GE verheiratet sein. Der Benutzer kann in der App einen eigenen Nickname setzen, sonst wird einfach ein "Hash" generiert (User-XXXXX). Diese Information würde man dann im GE anzeigen können. Der Ersteller kann weiterhin über die App diese Datensätze bearbeiten bzw. löschen, das würde die Synchronisation natürlich berücksichtigen.

Klar könnte der Benutzer einen "falschen" Nickname nutzen. Aber der Schaden würde sich ja im Grenzen halten. Warum sollte ein User sowas tun? Um CheckIns unter einem fremden Namen zu erstellen? Das macht doch keinen Sinn. Auch kann man Nicknames auch mehrfach nutzen, die Prüfung habe ich mit Absicht nicht eingebaut, weil das auch sonst für die Funktion nicht benötigt wird. Wenn also 10 User "ZOE" sind, dann ist es halt so.

[Hamburger]

Mit dem Wissen das die Rückmeldungen über die App zur Zeit nicht in das GE-Verzeichnis zurückgespielt werden können,
ist dem geneigten Nutzer dieser App und dieses Forums durchaus zuzutrauen zwischen
für andere Nutzer sehr wichtigen Informationen wie Störungen oder Erstnutzung von Ladesäulen (wichtig für Routenplanung etc)
und nice-to-have-Infos wie problemlosen Ladevorgängen zu unterscheiden.

Insofern dürfte für viele Nutzer gängige Praxis sein, tagsüber in der App zu melden und später wichtige Infos wie Störungen, Erstbestätigung oder notwendigen Korrekturen an Ladesäulen auch im GE-Verzeichnis einzutragen, wenn man eh am Rechner bzw im Forum unterwegs ist.

Möglicherweise gibt es hier Ausnahmen, aber deshalb gleich den Untergang der Datenqualität im GE-Verzeichnis zu menetekeln halte ich für weit übertrieben.

[Lotzekov]

Exakt und genau mein Gedanke - Danke!

Mit dem Wissen das die Rückmeldungen über die App zur Zeit nicht in das GE-Verzeichnis zurückgespielt werden können,
ist dem geneigten Nutzer dieser App und dieses Forums durchaus zuzutrauen zwischen
für andere Nutzer sehr wichtigen Informationen wie Störungen oder Erstnutzung von Ladesäulen (wichtig für Routenplanung etc)
und nice-to-have-Infos wie problemlosen Ladevorgängen zu unterscheiden.

Insofern dürfte für viele Nutzer gängige Praxis sein, tagsüber in der App zu melden und später wichtige Infos wie Störungen, Erstbestätigung oder notwendigen Korrekturen an Ladesäulen auch im GE-Verzeichnis einzutragen, wenn man eh am Rechner bzw im Forum unterwegs ist.

Möglicherweise gibt es hier Ausnahmen, aber deshalb gleich den Untergang der Datenqualität im GE-Verzeichnis zu menetekeln halte ich für weit übertrieben.

[corwin42]

Ich habe gerade mal die "Problemfälle" aus dem CheckIn Log der App mit den Störmeldungen im GE-Verzeichnis verglichen. Da sieht man schon, dass es da einige Abweichungen gibt.
Bei ein paar Einträgen wurde vorbildlich auch die Störung im GE-Verzeichnis eingetragen. Bei anderen fehlte die Störung im GE-Verzeichnis komplett oder war nicht aktuell (z.B. im GE-Verzeichnis "nur 22kW Anschluss defekt", in der App "komplette Säule ohne Strom" aus einem neueren Eintrag).

D.h. es läuft schon auseinander. Die App verleitet nun mal dazu, Störmeldungen nur in der App einzutragen anstatt im GE Verzeichnis.

Wir brauchen nicht darüber zu diskutieren, dass es das beste wäre, wenn es für das GE-Verzeichnis eine API gäbe. Das ist wohl allen klar.

Wäre es vielleicht eine (Übergangs-)Lösung, wenn die CheckIn Funktion der App eine öffentliche API bekommt, so dass auch andere Entwickler (meinetwegen von Android Apps) diese Funktion benutzen können? Sonst sehe ich schon demnächst die nächste App, die wieder ihre eigene CheckIn/LadeLog Funktion implementiert und das alles nur noch weiter aufgefächert wird.

[remus]

(..)
Wäre es vielleicht eine (Übergangs-)Lösung, wenn die CheckIn Funktion der App eine öffentliche API bekommt, so dass auch andere Entwickler (meinetwegen von Android Apps) diese Funktion benutzen können? Sonst sehe ich schon demnächst die nächste App, die wieder ihre eigene CheckIn/LadeLog Funktion implementiert und das alles nur noch weiter aufgefächert wird.

Diese "öffentliche API" gibt es im Prinzip schon, ich habe als "Proof-of-Concept" auch eine kleine JavaScript Applikation programmiert, welche auf diese API zugreift, um die Logins darzustellen. Diese App läuft nur im Browser, greift also direkt auf die API zu und kommt ohne "Server" aus.

Weiter oben habe ich aber aufgeführt, warum ein eigenes Backend für die App notwendig ist. Das trifft dann auch auf die Android-App zu, wenn diese coole Features, wie z.B. Favoriten und Push-Notifications implementieren möchte. Dann braucht die Android-App sowieso auch ein eigenes Backend (Firebase z.B.). Darauf wird man nicht verzichten können, auch wenn die GE API die entsprechende Schnittstelle bietet.

Wenn jedoch alle diese Apps das eigene Backend mit GE synchroneren können (sollte das später möglich sein), so hat man überall konsistente Daten.

Ich bin hier aber auch pragmatisch: wenn der Android-Entwickler auf mich zukommt, so wird man sicher eine Möglichkeit finden, dass man die Backends (erst mal) miteinander synchronisiert, das sollte auch dezentral möglich sein, das wird eine evtl. spätere Synchronisation mit GE sicher nicht ausschließen.

[remus]

Hi!

ich habe soeben Build 43 veröffentlicht. Hier das Changelog:

• HTML Entities werden nun überall korrekt dekodiert
• Liste der Ladepunkte überarbeitet: Custom Table-Header, dort wird jew. Bezugspunkt und Suchmittelpunkt bzw. Radius angezeigt, je nach Situation
• Die Notification Actions haben nicht immer korrekt funktioniert.

Und übrigens, ab jetzt steht das "Public Release" im Fokus: sowohl "kosmetische" Sachen (CI, Nav-Icons, App Icon, ..) als auch Usability/Hilfe/Onboarding stehen auf dem Plan.

In diesem Kontext würde ich mich dann recht kurzfristig bei euch melden! Ziel wird sein, die App gerade für "Neu-Einsteiger" maximal intuitiv bedienbar zu gestalten, das möchte ich mit Hilfe von A/B Tests heraus finden, in welche Richtung man hier gehen soll.


Ein schönes Wochenende!
Remus.