Android beispielsweise bietet für die Programmeinstellungen bereits fertige Lösungen, die auch wirklich einfach umzusetzen sind (ich werde bei Gelegenheit mal eine rudimentäre Beispiel-GUI hochladen). In diesem wird es wohl kaum möglich sein, alles Plattform-unabhängig gleich zu lassen, da die Einstellungen nicht in einer "externen" XML-Datei, sondern im "internen" Programmspeicher abgelegt werden. (Möglicherweise könnte aber auch das irgendwie über ein PreferenceFileHandler bzw. Interface ermöglicht werden... aber so richtig im Klaren bin ich mir darüber nicht).
-
Willkommen im Geoclub - dem größten deutschsprachigen Geocaching-Forum. Registriere dich kostenlos, um alle Inhalte zu sehen und neue Beiträge zu erstellen.
Android
- Ersteller Robin888
- Erstellt am
pfeffer
Geowizard
wow - GUI machst Du schon mal? - Großartig!
Dann müssen ja "nur noch" die Interfaces gemacht werden, was halt Arbeit ist, aber keine besonderen Schwierigkeiten machen sollte.
Zu den Einstellungen:
Mir erscheint es sinnvoll die GUI (und Hardware?) spezifischen Einstellungen im jeweiligen Betriebssystem so zu speichern, wie es das vorsieht. Das kann dem Backend völlig egal sein.
Alle Informationen, die das Backend braucht und auf allen Plattformen gemacht werden müssen, würde ich in der pref.xml belassen.
Ist das so sinnvoll?
Gruß,
Pfeffer.
Dann müssen ja "nur noch" die Interfaces gemacht werden, was halt Arbeit ist, aber keine besonderen Schwierigkeiten machen sollte.
Zu den Einstellungen:
Mir erscheint es sinnvoll die GUI (und Hardware?) spezifischen Einstellungen im jeweiligen Betriebssystem so zu speichern, wie es das vorsieht. Das kann dem Backend völlig egal sein.
Alle Informationen, die das Backend braucht und auf allen Plattformen gemacht werden müssen, würde ich in der pref.xml belassen.
Ist das so sinnvoll?
Gruß,
Pfeffer.
Spontan würde ich sagen, dass es auch dem Backend herzlich egal sein kann wie und wo die Informationen gespeichert werden, so lange es die Möglichkeit hat welche anzufordern oder zum persisitieren wegzugeben.pfeffer schrieb:
Eine Interfacedefinition und ein Setter für das Interfaceobjekt sollten ausreichend sein. Dann kann jeder Plattform für sich entscheiden ob Konfigdaten nun in eine Registry gehören, ins Filesystem oder an eine ganz andere Stelle.
pfeffer
Geowizard
hm. könnte man so machen. Ich hätte jetzt das Parsen der pref.xml im Backend belassen.
Ich würde nur abstrahieren an den Stellen, an denen es notwendig ist, damit die gemeinsame Codebasis möglichst groß ist.
Im Endeffekt wird das an jeder Stelle neu zu entscheiden sein. Das könnte man gut bei einem Programmierwochenende besprechen und machen. Ich mache dafür in den nächsten Tagen mal einen eigenen Thread auf.
Aber bleiben wir hier bei den Präferenzen.
Gruß,
Pfeffer.
Ich würde nur abstrahieren an den Stellen, an denen es notwendig ist, damit die gemeinsame Codebasis möglichst groß ist.
Im Endeffekt wird das an jeder Stelle neu zu entscheiden sein. Das könnte man gut bei einem Programmierwochenende besprechen und machen. Ich mache dafür in den nächsten Tagen mal einen eigenen Thread auf.
Aber bleiben wir hier bei den Präferenzen.
Gruß,
Pfeffer.
In meinen Augen gibt es gute Gründe für beide Varianten: greiols Variante ist eingängiger und gefühlt "sauberer". Wenn ich per Code mit den Prefs hantieren muss, will ich doch nicht überlegen, ob diese oder jene jetzt plattformspezifisch ist oder nicht. Außerdem kann sich sowas ja auch mal ändern.
Pfeffers Variante dagegen bietet den Vorteil, dass man per Dateiaustausch Einstellungen übertragen kann, XMLs kann man außerdem bei Konflikten zwischen den Einstellungen zweier Installationen gut mergen.
Das Argument des möglichst großen gemeinsamen Codes ist meiner Meinung nach keines: Man kann zwischen das Interface IPreferences und den Implementierungen J2SEDesktopPreferences und AndroidPreferences ja noch die abstrakte Klasse PreferencesBase einziehen, in der gemeinesamer Code gehalten wird. Außerdem sind solche Einstellungen-Klassen ja i.d.R. sehr generisch (ohne die vorhandene Implementierung wirklich zu kennen), sodass hier eh nicht viel Code zu erwarten wäre.
Auch wenn wir jetzt erstmal nur über zwei zu unterstützende Plattformen reden, sollte die Architektur natürlich auch weitere unterstützen. Hier käme bei pfeffers Variante dann das folgende Problem ins Spiel: Was ist, wenn eine Einstellung für mehrere aber nicht alle Plattformen relevant ist: Wie wird diese dann gespeichert? Bei der kurz skizzierten Variante mit der Vererbungshierarchie könnte es dann einfach eine weitere abstrakte Klasse PlatformXandYPreferenceBase geben, die IPreferences implementiert und PlatformXPreferences und PlatformYPreferences beerbt, während PlatformZPreferences das Interface direkt implementiert.
Bleibt in meinen Augen aus Architektursicht folglich kein valides Argument für eine pref.xml mit den gemeinsamen Einstellungen. Aus Nutzersicht aber würde ich diese nachwievor gern per copy/paste bzw. dateisystembasierten Sync-Tools wie unison übertragen können. So etwas könnte man jedoch über einen generischen Einstellungen-Export und -Import realisieren, der im Zweifelsfalls Einstellungen, die die aktuelle Plattform nicht kennt, ignoriert (das müsste dann noch nicht mal plattformspezifisch implementiert werden!).
So viel zu meinen 0,02 €, ich würde also die um die abstrakte Basisklasse und evlt. später Export/Import erweiterte greiol-Variante wählen.
Aber natürlich entscheidet letztendlich dann der, der den Code schreibt. Dieser Thread kann nur zur Diskussion und Meinungsbildung dienen.
Viele Grüße
Silas
Pfeffers Variante dagegen bietet den Vorteil, dass man per Dateiaustausch Einstellungen übertragen kann, XMLs kann man außerdem bei Konflikten zwischen den Einstellungen zweier Installationen gut mergen.
Das Argument des möglichst großen gemeinsamen Codes ist meiner Meinung nach keines: Man kann zwischen das Interface IPreferences und den Implementierungen J2SEDesktopPreferences und AndroidPreferences ja noch die abstrakte Klasse PreferencesBase einziehen, in der gemeinesamer Code gehalten wird. Außerdem sind solche Einstellungen-Klassen ja i.d.R. sehr generisch (ohne die vorhandene Implementierung wirklich zu kennen), sodass hier eh nicht viel Code zu erwarten wäre.
Auch wenn wir jetzt erstmal nur über zwei zu unterstützende Plattformen reden, sollte die Architektur natürlich auch weitere unterstützen. Hier käme bei pfeffers Variante dann das folgende Problem ins Spiel: Was ist, wenn eine Einstellung für mehrere aber nicht alle Plattformen relevant ist: Wie wird diese dann gespeichert? Bei der kurz skizzierten Variante mit der Vererbungshierarchie könnte es dann einfach eine weitere abstrakte Klasse PlatformXandYPreferenceBase geben, die IPreferences implementiert und PlatformXPreferences und PlatformYPreferences beerbt, während PlatformZPreferences das Interface direkt implementiert.
Bleibt in meinen Augen aus Architektursicht folglich kein valides Argument für eine pref.xml mit den gemeinsamen Einstellungen. Aus Nutzersicht aber würde ich diese nachwievor gern per copy/paste bzw. dateisystembasierten Sync-Tools wie unison übertragen können. So etwas könnte man jedoch über einen generischen Einstellungen-Export und -Import realisieren, der im Zweifelsfalls Einstellungen, die die aktuelle Plattform nicht kennt, ignoriert (das müsste dann noch nicht mal plattformspezifisch implementiert werden!).
So viel zu meinen 0,02 €, ich würde also die um die abstrakte Basisklasse und evlt. später Export/Import erweiterte greiol-Variante wählen.
Aber natürlich entscheidet letztendlich dann der, der den Code schreibt. Dieser Thread kann nur zur Diskussion und Meinungsbildung dienen.
Viele Grüße
Silas
Wie wäre es denn einfach mit etwas wie java.util.prefs.Preferences? Das kennt für die Plattform auf der die Software läuft schon einen Weg Konfigurationen sinnvoll zu speichern.
In einer "reinen" Java-Implementierung wäre das vermutlich am einfachsten.
In einer "reinen" Java-Implementierung wäre das vermutlich am einfachsten.
arbor95
Geoguru
Wir sollten vielleicht erst mal diskutieren ob ewe-VM als Basis bestehen bleiben soll.
Da es ja schon eine ewe-VM für Java gibt ist hier der Aufwand für die Portierung vielleicht am geringsten.
Bezüglich der GUI müssten dann vielleicht nur ein paar AWT Dinge auf die Android GUI umgestellt werden. Den genauen Überblick habe ich da nicht.
Da es ja schon eine ewe-VM für Java gibt ist hier der Aufwand für die Portierung vielleicht am geringsten.
Bezüglich der GUI müssten dann vielleicht nur ein paar AWT Dinge auf die Android GUI umgestellt werden. Den genauen Überblick habe ich da nicht.
Wutschkow
Geomaster
Wir hatten hier kürzlich eine Umfrage, wer welches Betriebssystem im Einsatz hat:Silas schrieb:
http://www.geoclub.de/viewtopic.php?f=40&t=47929
OK, die aktuellen Zahlen hängen sicherlich auch damit zusammen, das CW im Moment nun mal praktisch nur auf WinMobile mobil läuft. Trotzdem wären das eine Menge Leute, denen man die frohe Botschaft beibringen müsste, dass sie ab Rev XYZ zwingend ein neues Android-Smartphone benötigen.
Nur mal so als Anregung für die Diskussion...
pfeffer schrieb:
Zur GUI: Ich habe damit angefangen, da mal etwas zu basteln, damit ich selbst sehe, was machbar ist... bisher existiert allerdings noch nicht allzu viel (was zum einen an meinen beschränkten Programmierkenntnissen liegt, zum anderen an der fehlenden Zeit). Ich versuche noch diese Woche mal noch einen Screenshot mit Menü und Preferences hochzuladen.
Zu den Preferences: Bei Android ist es halt so, dass die Bearbeitung und Speicherung der Einstellungen direkt mit der GUI verknüpft ist. Wenn man also die "einfache" Möglichkeit der Einbindung der Einstellungen nutzen möchte, werden die Daten auch intern gespeichert. Möglicherweise gibt es da aber auch passende Callbacks um ein Schreiben in die externe pref.xml umzusetzen (die Doku zu derartigen Dingen ist bei Android leider nicht besonders gut). Ich persönlich halte es aber auch nicht für unbedingt notwendig, dass die Einstellungen immer in die pref.xml geschrieben werden.
apfelmaus
Geocacher
Dem gegenüber stehen die WinMobile Nutzer, die sich eine neues Handy zulegen, entweder weil der zwei Jahresvertrag mit dem Provider zu Ende ist oder das jetztige Smartphone defekt ist.Wutschkow schrieb:
So toll CacheWolf auch ist, deswegen würde ich mir kein neues WinMobile 6.5 Gerät holen. Aktuell ist eher Android angesagt.
So.. hier die versprochenen Screenshots, welche eine Fortführung des bereits früher geposteten Screenshots der Hauptansicht sind. Zu sehen ist einmal eines der Tabs (Details) inklusive Menü. Außerdem die erste Seite, sobald man Einstellungen im Menü gewählt hat und noch den eigentlichen Einstellungsdialog am Beispiel der allgemeinen Einstellungen.
Anhänge
Genau so sehe ich das auch. Mein Windows-Mobile PDA hat jetzt etwa 3,5 Jahre auf dem Buckel. Wenn es das zeitliche segnen sollte, werde ich es nicht durch ein weiteres WM-PDA ersetzen. Das ist einfach eine Sackgasse.apfelmaus schrieb:
Wenn es zu dem Zeitpunkt CacheWolf für Android gibt - super. Wenn nicht, werde ich irgendein anderes Tool benutzen müssen. Und das obwohl CacheWolf im Moment mein All-in-One Tool ist.
OP
Robin888
Geomaster
Mir geht's ehrlich gesagt ähnlich.
Ich hatte gehofft, mein 3,5 Jahre altes WinMobile-Gerät durch ein cooked ROM so fit zu bekommen, daß es noch solange "hält", bis der Android-Port fertig ist.
Das hat leider nicht so richtig funktioniert. Und der ersatzweise durchgeführte Hardreset hat das Gerät auch nicht wieder wirklich flotter gemacht. :-(
Also steht bei mir ein neues Gerät an und Android ist wirklich interessant. Aber cachen ohne den Wolf? Ich hab' schon überlegt mein altes Gerät als Rechenmaschine weiterzubenutzen und das neue Gerät als Navi bis der Cachewolf auf Android läuft. %-)
Robin(888)
Ich hatte gehofft, mein 3,5 Jahre altes WinMobile-Gerät durch ein cooked ROM so fit zu bekommen, daß es noch solange "hält", bis der Android-Port fertig ist.
Das hat leider nicht so richtig funktioniert. Und der ersatzweise durchgeführte Hardreset hat das Gerät auch nicht wieder wirklich flotter gemacht. :-(
Also steht bei mir ein neues Gerät an und Android ist wirklich interessant. Aber cachen ohne den Wolf? Ich hab' schon überlegt mein altes Gerät als Rechenmaschine weiterzubenutzen und das neue Gerät als Navi bis der Cachewolf auf Android läuft. %-)
Robin(888)
Bilbowolf
Geowizard
Ich habe inzwischen auch ein Android, nen Galaxy S 
Auf dem Galaxy benutze ich Geohunter.
Mein Winmobile habe ich auch noch bei Multis im Einsatz.
So ganz nebenbei: Ich persönlich glaube CacheWolf muss in die nächste Generation und wir müssen uns von Ewe verabschieden.
Auf dem Android würde in den Wolf komplett anders aufbauen und mich nicht nach der "Ewe" - GUI richten.
Auf dem Galaxy benutze ich Geohunter.
Mein Winmobile habe ich auch noch bei Multis im Einsatz.
So ganz nebenbei: Ich persönlich glaube CacheWolf muss in die nächste Generation und wir müssen uns von Ewe verabschieden.
Auf dem Android würde in den Wolf komplett anders aufbauen und mich nicht nach der "Ewe" - GUI richten.
pfeffer
Geowizard
das fände ich sehr schade.
Ich zumindest habe kein Android-Gerät und plane auch nicht, mir eins zu kaufen. Wenn ich das so richtig gehört habe, dann sind die auch erheblich eingeschränkt: man muss sie erstmal "rooten", damit man das Programme auf die SD-Karte installieren kann. Sowas wollte ich eigentlich nicht haben.
Ich denke, die entscheidende Frage ist, ob Ewe auf Windows 7 Mobile laufen wird. Falls nein, dann ist Ewe langfristig tot. Falls doch, sehe ich keinen Grund, diese Platform zu verlassen.
Ihr könnt ja mal eine optimale GUI für Android entwerfen - vielleicht lässt sich das ja mit dem Ewe-Backend vereinbaren. Lahmer hat ja schon damit angefangen.
Gruß,
Pfeffer.
Ich zumindest habe kein Android-Gerät und plane auch nicht, mir eins zu kaufen. Wenn ich das so richtig gehört habe, dann sind die auch erheblich eingeschränkt: man muss sie erstmal "rooten", damit man das Programme auf die SD-Karte installieren kann. Sowas wollte ich eigentlich nicht haben.
Ich denke, die entscheidende Frage ist, ob Ewe auf Windows 7 Mobile laufen wird. Falls nein, dann ist Ewe langfristig tot. Falls doch, sehe ich keinen Grund, diese Platform zu verlassen.
Ihr könnt ja mal eine optimale GUI für Android entwerfen - vielleicht lässt sich das ja mit dem Ewe-Backend vereinbaren. Lahmer hat ja schon damit angefangen.
Gruß,
Pfeffer.
Wutschkow
Geomaster
Es wird kein Windows 7 Mobile geben. Statt dessen gibt es Windows 7 Phone. Das ist ein komplett neu entwickeltes System und definitiv NICHT abwärtskompatibel (siehe hierzu auch http://de.wikipedia.org/wiki/Windows_Phone_7#Software-Entwicklung.2FAnwendungskompatibilit.C3.A4t)pfeffer schrieb:
Zumindest in der ersten Version wird es nicht mal multitasking-fähig sein, d. h. wenn ein Anruf reinkommt, wird Cachewolf beendet usw. (Wobei das bei den erstem iPhones im Prinzip auch so war, oder?)
Und da EWE ohnehin nicht mehr weiter entwickelt wird, wird es wohl auch niemand für Windows 7 Phone portieren, denke ich.
Bilbowolf schrieb:Ich habe inzwischen auch ein Android, nen Galaxy S
Auf dem Galaxy benutze ich Geohunter.
Mein Winmobile habe ich auch noch bei Multis im Einsatz.
So ganz nebenbei: Ich persönlich glaube CacheWolf muss in die nächste Generation und wir müssen uns von Ewe verabschieden.
Auf dem Android würde in den Wolf komplett anders aufbauen und mich nicht nach der "Ewe" - GUI richten.
Das war doch aber genau der Plan bei der Trennung von GUI und Funktionalität... wenigstens in der Theorie... die GUI für Android könnte (und muss) sich dann von der bisherigen durchaus unterscheiden, die eigentliche Funktionalität von Cachewolf könnte aber erhalten bleiben.
Ich habe auch mal versucht, Cachewolf mitsamt EWE auf Android zu testen, allerdings funktioniert das nicht so richtig out-of-the-box. Ich für meinen Teil hatte Probleme mit nicht-EWE-Imports für die regulären Ausdrücke und mit den EWE-Imports für die Handhabung von XML. Mal schauen, ob ich da noch irgendwie weiterkomme. Wenn sich da jemand mit Programmier-Erfahrung versuchen möchte, bin ich natürlich für Hilfe immer dankbar und stelle auch gern den aktuellen Stand meines kleinen Projektes zur Verfügung.
Kalli
Geowizard
lahmer schrieb:
Das hört sich doch recht vielversprechend an, insbesonders sind diese Probleme keine Showstopper, sondern sollten lösbar sein.
Bei mir geht allerdings die Motivation für Android zur Zeit gegen null, da ich mir in absehbarer Zukunft kein Handy kaufen werde und für paperless mittlerweile ein Oregon nutze. Die Richtung ist aber OK, da es in Zukunft wohl keine klassischen PDA's mehr geben wird und Handies dem am Nächsten kommen. Wahrscheinlich schleppt auch der eine oder andere auch sein Android-Pad in den Wald.....