-
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
jennergruhle
Geoguru
.net geht net ... 
Ich denke, Windows Mobile 7 wird als Zielplattform extrem unbrauchbar werden, weil MS unbedingt ALLE Entwickler vor den Kopf stoßen (nein, mit Springerstiefeln treten) will - schließlich muss man alles wegwerfen (C, C++, Java) und mit dem unnützen Flash-Abklatsch Silverlight programmieren.
Aber ich denke auch, dass wir nicht um eine Trennung von GUI und Unterbau herumkommen. Zumal Android ja völlig anders an manche Dinge herangeht als man es von bisherigen Ansätzen her kennt.
Reizen würde es mich aber auch, da mitzumachen. Bin aber auch nur kurz über das "Hello, World"-Stadium hinaus - habe zumindest schon mal das komplette AndNav2 ausgecheckt, kompiliert und zum Laufen gebracht.
Wenn es zu einem so großem Umbau kommt, wird allerdings sicher mehr als nur 20-30% zu ändern sein - wenn ich mich richtig erinnere, sind doch gefühlte 99,999% des Codes von ewe abhängig.
Ich denke, Windows Mobile 7 wird als Zielplattform extrem unbrauchbar werden, weil MS unbedingt ALLE Entwickler vor den Kopf stoßen (nein, mit Springerstiefeln treten) will - schließlich muss man alles wegwerfen (C, C++, Java) und mit dem unnützen Flash-Abklatsch Silverlight programmieren.
Aber ich denke auch, dass wir nicht um eine Trennung von GUI und Unterbau herumkommen. Zumal Android ja völlig anders an manche Dinge herangeht als man es von bisherigen Ansätzen her kennt.
Reizen würde es mich aber auch, da mitzumachen. Bin aber auch nur kurz über das "Hello, World"-Stadium hinaus - habe zumindest schon mal das komplette AndNav2 ausgecheckt, kompiliert und zum Laufen gebracht.
Wenn es zu einem so großem Umbau kommt, wird allerdings sicher mehr als nur 20-30% zu ändern sein - wenn ich mich richtig erinnere, sind doch gefühlte 99,999% des Codes von ewe abhängig.
snaky
Geowizard
Das Problem wird sein, dass man sich über die GUI komplett neu Gedanken machen werden muss. Eine Bedienung mit Finger ist eben was ganz anderes, als mit Stift. D. h. man müsste bei jedem Screen neu überlegen, wie man den aufbauen will, was bei einem Druck auf Menu/ langer Druck auf einen Cache passiert usw.
pfeffer
Geowizard
"_neu_ überlegen" hihi - als hätte sich das mal jemand überlegt - das wäre ja schön ;-)
ok, jeder, der was neues eingebaut hat, hat sich sicher überlegt, wo er die Funktion hin haben will.
Ansonsten sehe ich nicht so schwarz, was die Trennung von GUI und Datenarbeit angeht - häufig ist das schon vom Grundsatz her getrennt, nicht über all, praktisch nie ganz konesquent, aber mehr als im Ansatz vorhanden, würde ich sagen.
Ich sehe das Problem eher darin, dass kaum Datenarbeit anfällt. Eigentlich besteht Cachewolf im Wesentlichen aus der GUI - naja, jedenfalls für mein Empfinden, aber so sieht's bei den meisten Programmen heute aus.
Naja, was soll's - CacheWolf auf Android zum Laufen zu bringen sollte mit vergleichsweise wenig Aufwand möglich sein, schließlich wird das ja in Java programmiert.
Gruß,
Pfeffer.
ok, jeder, der was neues eingebaut hat, hat sich sicher überlegt, wo er die Funktion hin haben will.
Ansonsten sehe ich nicht so schwarz, was die Trennung von GUI und Datenarbeit angeht - häufig ist das schon vom Grundsatz her getrennt, nicht über all, praktisch nie ganz konesquent, aber mehr als im Ansatz vorhanden, würde ich sagen.
Ich sehe das Problem eher darin, dass kaum Datenarbeit anfällt. Eigentlich besteht Cachewolf im Wesentlichen aus der GUI - naja, jedenfalls für mein Empfinden, aber so sieht's bei den meisten Programmen heute aus.
Naja, was soll's - CacheWolf auf Android zum Laufen zu bringen sollte mit vergleichsweise wenig Aufwand möglich sein, schließlich wird das ja in Java programmiert.
Gruß,
Pfeffer.
Man kann sogar bestehende Jars verwenden. So lange die halt nichts referenzieren, was es auf Android nicht gibt (z.B. den ganzen J2SE-GUI-Kram)
Aber so Sachen wie Spidern, Laden und Speichern von Caches, Berechnungen, Solver, Import/Export, das könnten ja alles in eine Cachewolf-Core-Jar (oder wie auch immer die heißen soll), die dann im Droidwolf Projekt wiederverwendet wird.
Aber so Sachen wie Spidern, Laden und Speichern von Caches, Berechnungen, Solver, Import/Export, das könnten ja alles in eine Cachewolf-Core-Jar (oder wie auch immer die heißen soll), die dann im Droidwolf
Projekt wiederverwendet wird.Wüsste ich jetzt nicht, aber ich habe auch erst ein mal an einem kleinen Android-Projekt gearbeitet.
Einerseits fehlen der Klassenbibliothek wie gesagt Teile, andererseits wurden nicht nur eigene (z.B. für die GUI und die Telefon- und Sensorfunktionen) ergänzt, sondern auch welche von Drittherstellern (z.B. der Apache httpclient).
Die API Doku gibts hier: http://developer.android.com/reference/packages.html
Grüße
Silas
Einerseits fehlen der Klassenbibliothek wie gesagt Teile, andererseits wurden nicht nur eigene (z.B. für die GUI und die Telefon- und Sensorfunktionen) ergänzt, sondern auch welche von Drittherstellern (z.B. der Apache httpclient).
Die API Doku gibts hier: http://developer.android.com/reference/packages.html
Grüße
Silas
MiK
Geoguru
Meine Kollegen mit Android-Phones haben immer Probleme mit der Akkulaufzeit. Weiß einer von Euch, wie lange verschiedene Android-Geräte mit aktiver GPS-Anwendung durchhalten? Ich fürchte, es gibt keine Nachfolge-Geräte für die WM-PDAs, mit denen man auch mal bis zu 6h Stunden cachen konnte.
Team SchwengaDelügs
Geocacher
Also, so hoppla die hopp wird das wohl nix, mit dem "portieren" .....
ich hab die woche über arg gebastelt ... war aber nich wirklich erfolgreich ..
allerdings ist es ein sehr interessantes Thema, sodass ich mit weiter damit
beschäftigen werde.... ich will mir nämlich auch ein Android Handy zu legen.
Wenn Vodafon endlich das "Vodafone 845" auf Markt wirft ....
schönen Samstag ... Gruß
Andy
ich hab die woche über arg gebastelt ... war aber nich wirklich erfolgreich ..
allerdings ist es ein sehr interessantes Thema, sodass ich mit weiter damit
beschäftigen werde.... ich will mir nämlich auch ein Android Handy zu legen.
Wenn Vodafon endlich das "Vodafone 845" auf Markt wirft ....
schönen Samstag ... Gruß
Andy
Moin,
gibt es denn Bestrebungen, die Trennung von Funktionalität und GUI irgendwie voranzutreiben, um möglicherweise doch irgendwann eine Android-Version hinzubekommen? Vielleicht sogar in Form eines Branches?
Leider habe ich auch nicht allzu viel Zeit und bin auch nicht gerade der Profi, was Java-Programmierung angeht... aber wenigstens das HelloWorld-Beispiel habe ich auf meiner Android-Emulation jetzt auch mal hinbekommen.. und die Programmierung der UI für Android sollte ja durch die XML-Variante vergleichsweise einfach möglich sein, so dass man ja mal die ein oder andere Funktionalität in ein DroidWolf Sample ziehen könnte... vorausgesetzt, man weiß, wo Funktionalität beginnt und GUI endet
gibt es denn Bestrebungen, die Trennung von Funktionalität und GUI irgendwie voranzutreiben, um möglicherweise doch irgendwann eine Android-Version hinzubekommen? Vielleicht sogar in Form eines Branches?
Leider habe ich auch nicht allzu viel Zeit und bin auch nicht gerade der Profi, was Java-Programmierung angeht... aber wenigstens das HelloWorld-Beispiel habe ich auf meiner Android-Emulation jetzt auch mal hinbekommen.. und die Programmierung der UI für Android sollte ja durch die XML-Variante vergleichsweise einfach möglich sein, so dass man ja mal die ein oder andere Funktionalität in ein DroidWolf Sample ziehen könnte... vorausgesetzt, man weiß, wo Funktionalität beginnt und GUI endet
Mal ne doofe Frage am Rande... irgendwelche Doku zu den Sourcen gibt es nicht zufällig? Ich habe mir jetzt zwar mal alles ausgecheckt und auch das Android SDK installiert, bin mir aufgrund meiner doch begrenzten Programmierkenntnisse nicht ganz sicher, ob ich wirklich gänzlich ohne Doku an einem dermaßen gewachsenen Projekt anfangen möchte, rauszufinden, wo Funktionalität und wo reine GUI in den Sourcen jeweils zu finden ist 
Zur Skizze:
Ich weiß jetzt nicht, was genau du mit den Pfeilen ausdrücken willst (ich vermute ein "von hier aus erreicht man"), würde aber Daten und Liste gefühlt eher in ein Android-typisches Menü, wo man üblicherweise die Einstellungen findet, packen. Gibt's eigentlich Android GUI Styleguides? Edit: Ja, gibts.
Ergänzung zur Moving Map:
Bei der Karte hat GeOrg die Möglichkeit, Kacheln im von Andnav2 genutzten Format von der SD-Karte zu verwenden. Andnav ist ja auch Open Source, sodass man sich da schön angucken können müsste, wie man das am Besten implementiert. Sowas wäre meiner Meinung nach eine sehr sinnvolle Erweiterung zum normalen Cachewolf-Funktionsumfang, da man so halt auf einen Rutsch OSM-Kartenmaterial für ganz Deutschland in verschiedenen Zoom-Stufen auf die Karte kopieren kann.
Allgemeines/Architektur:
Wenn man eine Android-Version wirklich angeht, könnte man in dem Rahmen natürlich schön den Bestandscode aufräumen. Ich stelle mir das so vor, dass man dann später unterschiedliche Pakete für die Kernfunktionalitäten hat und eben noch eins (oder mehrere) für die Android-GUI, Android-Extras (GPS, Compass, ...), ewe-GUI, ewe-Extras (GPS über COM), Java-Desktop-GUI (Swing oder so) und was sich sonst halt noch ergibt.
Grüße
Silas
P.S. Unter http://www.droiddraw.org/ gibts einen Webbasierten GUI-Designer, allerdings komme ich damit (auf Anhieb) nicht klar.
Man könnte auch mal einen Blick auf die quelloffenen Geocaching-Tools Geohunter, OpenGPX und GeoBeagle sowie auf die proprietären Cache'n'Go!, c:geo (wohl das beliebteste kostenlose im Moment) und GeOrg (wohl die meisten Funktionen im Moment) werfen und sich anschauen, wie dort jeweils die Menüführung gelöst wurde.
Ich weiß jetzt nicht, was genau du mit den Pfeilen ausdrücken willst (ich vermute ein "von hier aus erreicht man"), würde aber Daten und Liste gefühlt eher in ein Android-typisches Menü, wo man üblicherweise die Einstellungen findet, packen. Gibt's eigentlich Android GUI Styleguides? Edit: Ja, gibts.
Ergänzung zur Moving Map:
Bei der Karte hat GeOrg die Möglichkeit, Kacheln im von Andnav2 genutzten Format von der SD-Karte zu verwenden. Andnav ist ja auch Open Source, sodass man sich da schön angucken können müsste, wie man das am Besten implementiert. Sowas wäre meiner Meinung nach eine sehr sinnvolle Erweiterung zum normalen Cachewolf-Funktionsumfang, da man so halt auf einen Rutsch OSM-Kartenmaterial für ganz Deutschland in verschiedenen Zoom-Stufen auf die Karte kopieren kann.
Allgemeines/Architektur:
Wenn man eine Android-Version wirklich angeht, könnte man in dem Rahmen natürlich schön den Bestandscode aufräumen. Ich stelle mir das so vor, dass man dann später unterschiedliche Pakete für die Kernfunktionalitäten hat und eben noch eins (oder mehrere) für die Android-GUI, Android-Extras (GPS, Compass, ...), ewe-GUI, ewe-Extras (GPS über COM), Java-Desktop-GUI (Swing oder so) und was sich sonst halt noch ergibt.
Grüße
Silas
P.S. Unter http://www.droiddraw.org/ gibts einen Webbasierten GUI-Designer, allerdings komme ich damit (auf Anhieb) nicht klar.
Man könnte auch mal einen Blick auf die quelloffenen Geocaching-Tools Geohunter, OpenGPX und GeoBeagle sowie auf die proprietären Cache'n'Go!, c:geo (wohl das beliebteste kostenlose im Moment) und GeOrg (wohl die meisten Funktionen im Moment) werfen und sich anschauen, wie dort jeweils die Menüführung gelöst wurde.
Was spricht denn dagegen die bisherige Aufteilung größtenteils beizubehalten? Ich hatte mal angefangen, eine noch sehr rudimentäre GUI zu basteln mit den bisherigen Tabs im oberen Abschnitt des Bildschirms und hätte im darunter liegenden Teil dann jeweils die bisherigen Inhalte eingebaut. Also erstmal natürlich die Liste, die Details, die Beschreibung, Logs und Karte, welche ich auch wirklich häufig nutze. Ich kann ja mal nen Screenshot hochladen, wenn ich das angefangene Projekt auf meiner Platte wiederfinde (zeigt bisher aber leider nicht besonders viel, da meine Programmierkenntnisse nicht besonders gut sind).
Zudem hatte ich mal damit angefangen, den bisherigen Code an "Standard-Java" bzw. die android-Bibliotheken anzupassen... alle GUI-Elemente habe ich dabei erstmal weggelassen und mit den "normalen" Dingen wie Vektoren, Hashmaps, Comparators, ... angefangen. Wenn sich jemand dafür interessiert, kann ich das gern mal zur Verfügung stellen (aber nicht allzu viel Hoffnung haben, ich habe fürs Zurechtfinden deutlich mehr Zeit benötigt als für die Änderungen )
Zudem hatte ich mal damit angefangen, den bisherigen Code an "Standard-Java" bzw. die android-Bibliotheken anzupassen... alle GUI-Elemente habe ich dabei erstmal weggelassen und mit den "normalen" Dingen wie Vektoren, Hashmaps, Comparators, ... angefangen. Wenn sich jemand dafür interessiert, kann ich das gern mal zur Verfügung stellen (aber nicht allzu viel Hoffnung haben, ich habe fürs Zurechtfinden deutlich mehr Zeit benötigt als für die Änderungen
)
pfeffer
Geowizard
hmm - alles, was nicht GUI ist könnte man doch wahrscheinlich so lassen wie es ist und aus Ewe übernehmen, oder? - Naja, weiß nicht, vielleicht ist da in Ewe auch zu viel miteinander verwoben.
Aber Ewe besteht ja zu großen Teilen aus Java-Klassen, die auch auf anderen Java-Machinen laufen (sollten).
Das entscheidende Problem sind - meiner Meinung nach - die Hardwareschnittstellen, inkl. GUI. Deswegen scheint mir die Trennung von GUI und "backoffice" schon sinnvoll. Meiner Wahrnehmung nach besteht allerdings Cachewolf zu 80% aus GUI. Das meiste, was nicht GUI ist, ist auch schon unabhängig davon implementiert und dort, wo es das nicht ist, ist es vermutlich recht einfach, das zu ändern.
Also ich hätte Lust, mich mit ein paar anderen Programmieren mal ein Wochenende zu treffen und das anzugehen.
Gruß,
Pfeffer.
Aber Ewe besteht ja zu großen Teilen aus Java-Klassen, die auch auf anderen Java-Machinen laufen (sollten).
Das entscheidende Problem sind - meiner Meinung nach - die Hardwareschnittstellen, inkl. GUI. Deswegen scheint mir die Trennung von GUI und "backoffice" schon sinnvoll. Meiner Wahrnehmung nach besteht allerdings Cachewolf zu 80% aus GUI. Das meiste, was nicht GUI ist, ist auch schon unabhängig davon implementiert und dort, wo es das nicht ist, ist es vermutlich recht einfach, das zu ändern.
Also ich hätte Lust, mich mit ein paar anderen Programmieren mal ein Wochenende zu treffen und das anzugehen.
Gruß,
Pfeffer.
Hier der versprochene Screenshot.
Archiv meiner bisherigen Änderungen kann ich wie gesagt gerne Interessierten zur Verfügung stellen. Aber nicht zu viel erwarten. Ich hatte mal angefangen, auch die "normalen" ewe-Sachen auf Standard-Java zu portieren, da ich der Meinung bin, dass wenn schon auf Android portiert werden soll, auch gleich sämtliche ewe-Abhängigkeiten rausfliegen könnten (legacy sh.. ;-) ). Für einen geübten Programmierer ist das Ganze vermutlich ein Aufwand von 15 Minuten, was ich bisher gemacht habe.
Wenn da aber tatsächlich aktiv was gemacht werden soll, könnte ich möglicherweise noch ein paar weitere Leute gewinnen, sich daran zu beteiligen, die durchaus auch Erfahrung haben. Und wenn es sich irgendwie einrichten lässt, würde ich mich an einem Programmierwochenende auch gern beteiligen... und wenn nur zum Pizza holen
Archiv meiner bisherigen Änderungen kann ich wie gesagt gerne Interessierten zur Verfügung stellen. Aber nicht zu viel erwarten. Ich hatte mal angefangen, auch die "normalen" ewe-Sachen auf Standard-Java zu portieren, da ich der Meinung bin, dass wenn schon auf Android portiert werden soll, auch gleich sämtliche ewe-Abhängigkeiten rausfliegen könnten (legacy sh.. ;-) ). Für einen geübten Programmierer ist das Ganze vermutlich ein Aufwand von 15 Minuten, was ich bisher gemacht habe.
Wenn da aber tatsächlich aktiv was gemacht werden soll, könnte ich möglicherweise noch ein paar weitere Leute gewinnen, sich daran zu beteiligen, die durchaus auch Erfahrung haben. Und wenn es sich irgendwie einrichten lässt, würde ich mich an einem Programmierwochenende auch gern beteiligen... und wenn nur zum Pizza holen
