Android

[arbor95]

ich würde auch von EWE unabhängig werden wollen, zumal es da wohl an ein paar Stellen klemmt, aber dann fangen die kleinen Problemchen an : Convert, Vector, Hashtable, ... , mImage,.... xmlParser,...
Vieles ist sicher mit Fleiss erledigt, aber von ein paar Dingen habe ich keine Ahnung..

Meeting: nicht grundsätzlich dagegen!

 

[greiol]

könnte man in dem Rahmen natürlich schön den Bestandscode aufräumen.

um ehrlich zu sein, war mein erster gedanke eher:
nun da man einigermaßen weiß wie es gehen muss, den aktuellen code über board werfen und es sauber neu aufsetzen.

die code basis ist ja nicht wirklich schlecht, aber halt in den letzten jahren derart oft mit individueller handschrift (inkl. meiner versuche) erweitert bis verbogen worden, dass ein rewrite vermutlich die sauberste lösung ist.

 

[pfeffer]

ein generelles Neuschreiben halte ich für überflüssig. Ich meine sogar im Gegenteil ist der Code im Laufe der Zeit besser strukturiert worden. Sicher gibt es die ein oder andere Stelle, an der die Strutkur verbessert werden kann, aber das kann man machen, ohne alles neu zu schreiben.
Leider wissen wir auch immernoch nicht, wie alles geht. Ich glaube z.B. bei der XML-Sonderzeichenbehandlung haben wir es so, dass es offenbar einigermaßen funktioniert. Aber - soweit ich weiß - fehlt da ein klares System. Da hättest Du also recht, dass da System und Struktur rein sollte - aber im Moment weiß offenbar keiner der (aktiven) Entwickler genau wie.

Ich sehe es so: Wir müssen von Ewe nur soweit abstrahieren, wie es notwendig ist, um auf anderen Plattformen auch laufen zu können. Die Ewe-Vektor-Klasse dürfte auf allen Plattformen problemlos laufen, so dass ich denke, dass können wir lassen.
Was nicht läuft sind die Hardwareschnittstellen, insbesondere GPS und GUI.
Da brauchen wir eine Zwischenebene mit GUI-Abstraktionsklassen und eine GPS-Abstraktions-klasse.
Ich stelle mir die Abstraktionsklassen so vor: sie enthalten die notwendige Datenstruktur als Schnittstelle zum backend und sind ansonsten abstract. D.h. ein bestehender Einstellungsdialog wird um alle Routinen beraubt, so dass nur die Datenstruktur, die das backend benötigt, und/oder die abtracten Getter- und Setter-Methoden, die das backend benötigt, übrig bleiben. Von dieser abtracten klassen wird dann der Ewe-Dialog abgeleitet und eben der Android-Dialog. Man könnte vielleicht für Freaks sogar eine Commandozeilen-Version draus machen.

Ich kenne mich mit Android nicht aus. Sehe ich das richtig?

Gruß,
Pfeffer.

 

[Silas]

Bzgl. des Wegwerfens oder Refactoren sehe ich es ähnlich wie pfeffer. Die Erfahrung aus längeren Software-Projekten zeigt ohnehin, dass man ein Neuaufsetzen immer damit begründen könnte, dass man ja nun mehr Erfahrung, genauere Use Cases, neue Technik etc. hat. Das gilt aber während und nach dem Neuaufsetzen ganz genauso. Die einzige Variante ist hier ein permanentes Refactoring und Verbessern des Codes als Teil des Entwicklungsprozesses zu etablieren. Das schließt natürlich auch konzentriertere Redesigns, wie z.B. für das Unterstützen einer neuen Platform , ein.

Wegen der abstrakten Klassen: Ich würde sogar eher Interfaces bevorzugen, ist gefühlt sauberer. Wenn mehrere Implementierungen tatsächlich eine gemeinsame abstrakte Basisklasse haben sollen, kann diese immer noch das Interface implementieren. In den meisten Fällen wird aber Komposition vor Vererbung der Vorzug zu geben sein ;-) So sollte in pfeffers Einstellungsdialog-Beispiel meiner Meinung nach für die genannte Datenstruktur genauso eine eigene Klasse (Preferences?) wie für deren Laden und Speichern (PreferenceStorage? PreferencePersistency) vorgesehen werden, die halt in allen GUI-Implementierungen zum Einsatz kommt. Ob man bei der GUI aber tatsächlich noch irgend einen Bezug zwischen den Einstellungen in Android und Ewe herstellen kann/sollte, möchte ich mal dahingestellt lassen. I.d.R. werden wir hier unterschiedliche Bedienparadigmen (Mouse/Keyboard vs. Touchscreen) haben und daher auch keine eineindeutige Zuordnung der Klassen. Ich vermute also, bei der GUI werden wir gar keine Interfaces oder abstrakte Basisklassen brauchen. Beim GPS und ähnlichem dagegen schon.

Lust auf ein Entwicklerwochenende hätte ich auf jeden Fall, bin aber nicht sehr zuversichtlich, das zeitlich einrichten zu können

 

[arbor95]

Also sollte EWE auseinander genommen werden um vorhandenen Code weiternutzen zu können?
(also z.B. Convert, Double, Vector, Hashtable,... weiter von ewe nehmen?)

Das wäre ja im Prinzip "nur" die virtuelle Maschine nicht zu nutzen.
Oder ist es etwa sogar einfacher die virtuelle Maschine für Android zu schreiben?

 

[Silas]

Ich würde das nur in der Ewe-Variante von Ewe nehmen (klar ^^) und sonst halt die neueren Java-Varianten (wenn verfügbar) und wie bei GPS etc. im nutzenden Code nur Interfaces.

 

[pfeffer]

also, genau wie araber95 meint. Der Backend-Code muss ja weiterhin mit Ewe laufen.

Portierung der ewe-vm hatte ich auch schon überlegt. Aber die müsste dann für jedes Gerät wieder anders compiliert werden, je nach Prozessor usw. Ich vermute, dass es einfacher und leichter anpassbar ist, wenn wir die GUI für Android dann nur Android-java (+ewe-java) verwnden.

Gruß,
Pfeffer.

 

[arbor95]

Ausser der GUI ist aber auch noch das IO (file,web..) was nicht über ewe gemacht werden kann.

 

[pfeffer]

ohh - Mist, ja richtig.
Da sind dann wohl die abstrakten Zwischen-Klassen mit abstrakten Methoden notwendig, also z.B.
int AbstractionLayer.IO.FileOpen(String filename);

Gruß,
Pfeffer.

 

[Wutschkow]

So sehr ich die hier diskutierte Entwicklung begrüßen würde, ginge es doch deutlich über meine Fähigkeiten hinaus, dazu nennenswert beizutragen.

Allerdings möchte ich zumindest die Idee ins Spiel bringen, bei einer solch grundlegenden Überarbeitung auch die Möglichkeit in Betracht zu ziehen, CW so modular zu gestalten, dass man z.B. eine Desktop- und eine Mobilversion daraus erstellen kann.
Einige Funktionalitäten z. B. in den Bereich Import, Export, Verwaltung, Kartenmanagement usw. werden ja auf Mobilgeräten eher selten bis gar nicht genutzt.(Ausnahmen bestätigen wie immer die Regel ),.und gerade diese Funktionen scheinen mir tendenziell eher mehr zu werden. Durch den Verzicht auf solche "Module" könnte die "Mobilversion" vielleicht schlanker und auch optisch aufgeräumter werden.

Es muss ja auch nicht obligatorisch sein, dass man für den Desktop die Vollversion und für Mobilgeräte die abgespeckte Fassung verwenden MUSS. Vielleicht kann man es als Option hinbekommen, so dass jeder sich entscheiden kann, ob er mobil die volle oder die schlanke Version einsetzt.

Ich weiß, dass ist sicher nicht "mal ebenso" realisiert. Aber es ist ja auch nur ein Denkanstoss, denn vielleicht ist jetzt genau der richtige Zeitpunkt, eine solche (zukünftige?) Entwicklung in die Wege zu leiten oder ihr zumindest den Weg nicht zu verbauen?

Falls dieser Beitrag die Diskussion hier zu sehr in falsche Bahnen lenken könnte, kann er gerne als eigenes Thema abgetrennt werden. Ich denke aber, dass er als Denkanstoss zu diesem Thema hier rein gehört.

 

[Romanese]

z.B. eine Desktop- und eine Mobilversion daraus erstellen kann.

Diese Idee finde ich sehr gut.

Zusätzlich habe ich die Frage: Wie sieht es mit der Unterstützung von iPhone und iPad aus?

 

[greiol]

Zusätzlich habe ich die Frage: Wie sieht es mit der Unterstützung von iPhone und iPad aus?

Das Problem ist, dass bei den Smartphones und den zugehörigen SDKs jeder Hersteller sein eigenes Süppchen kocht
Android -> Java
iPhone -> Objective-C, C++
Symbian -> ?
MeeGo -> C++/Qt
WebOS -> Javascript
WindowsMobile -> Silverlight (ab 7)
Blackberry -> JavaME

Ein Toll anzubieten das auf all diesen Umgebungen läuft dürfte kaum zu machen sein.

 

[apfelmaus]

Allerdings möchte ich zumindest die Idee ins Spiel bringen, bei einer solch grundlegenden Überarbeitung auch die Möglichkeit in Betracht zu ziehen, CW so modular zu gestalten, dass man z.B. eine Desktop- und eine Mobilversion daraus erstellen kann.
Einige Funktionalitäten z. B. in den Bereich Import, Export, Verwaltung, Kartenmanagement usw. werden ja auf Mobilgeräten eher selten bis gar nicht genutzt.(Ausnahmen bestätigen wie immer die Regel ),.und gerade diese Funktionen scheinen mir tendenziell eher mehr zu werden. Durch den Verzicht auf solche "Module" könnte die "Mobilversion" vielleicht schlanker und auch optisch aufgeräumter werden.

Eine Trennung in zwei "verschiedene" Programme (Mobilversion und Desktopversion) halte ich für unnötigen overhead.
Vielleicht bin ich ja die berühmte Ausnahme aber Import (.gpx), Export (fieldnotes), Kartenmanagement mache ich auf meinem Mobilgeräte. Gerade im Urlaub cache ich gewöhnlich sehr viel und habe nur mein Handy um ins Internet zu kommen.
Im Zeitalter von Handyinternet flat rates für 10€, immer größeren Bildschirmauflösungen und 1 GHz CPUs wird man mit Mobilgeräten immer mehr machen wollen.

 

[Silas]

Die Trennung wird es zwangsläufig geben müssen, wenn wirklich eine Android-Version umgesetzt werden soll, da dessen GUI-Libraries auf dem Desktop nicht zur Verfügung stehen und umgekehrt.

 

[lahmer]

Die Trennung wird es zwangsläufig geben müssen, wenn wirklich eine Android-Version umgesetzt werden soll, da dessen GUI-Libraries auf dem Desktop nicht zur Verfügung stehen und umgekehrt.

Nicht zwangsläufig, wenn man tatsächlich GUI und IO durch Interfaces trennt und unterschiedliche Implementierungen der Interfaces anbietet. Mit einer mobilen und nicht-mobilen Version hat das ja aber erstmal nichts zu tun.
Ich sehe das allerdings als nicht ganz unproblematisch, alles über generische Interfaces zu lösen, wenn ich mir so anschaue, wo überall IO und GUI-Elemente verwendet werden

 

[pfeffer]

@lahmer: andere Lösungsvorschläge?
Eine Herausforderung ist es auf jeden Fall. Aber es wäre schon großartig, oder?

Gruß,
Pfeffer.

 

[Silas]

[...]
Nicht zwangsläufig, wenn man tatsächlich GUI und IO durch Interfaces trennt und unterschiedliche Implementierungen der Interfaces anbietet. Mit einer mobilen und nicht-mobilen Version hat das ja aber erstmal nichts zu tun.
Ich sehe das allerdings als nicht ganz unproblematisch, alles über generische Interfaces zu lösen, wenn ich mir so anschaue, wo überall IO und GUI-Elemente verwendet werden

Naja, wenn auch theoretisch denkbar, müsste man dafür dann aber in der Lage sein, die unterschiedlichen Implementierungen auch gleich aussehen zu lassen. Sonst hat man eben doch unterschiedliche GUIs. Die Sinnfrage dabei stelle ich hier mal gar nicht, aber das war ja auch nicht das (etwas abgedriftete) Diskussionsthema.

Ich plädiere jedenfalls mit Nachdruck (!) für dedizierte GUIs pro Plattform. Interface-implementierende Adapter machen meines Erachtens dagegen bei der Abstraktion von Hardware und Klassen aus der Class Library Sinn.

 

[pfeffer]

ja, so habe ich das auch gemeint. Eigene GUIs, die über definierte Schnittstellen mit dem über gleichen Backend "kommunizieren".

Was dann noch geklärt werden muss: Wie Einstellungen, die nur für eine GUI oder nur für bestimmte Hardware notwendig/sinnvoll sind, gespeichert werden sollen.
Zwei Abschnitte in der pref.xml? Einer, der vom Backend gelesen wird und einer, der von der GUI gelesen wird? oder einfacher zwei Dateien dafür?


Gruß,
Pfeffer.

 

[Silas]

Gute Frage. Für mehrere Dateien würde die einfachere Synchronisation via unison und Konsorten sprechen. Andererseits ändert man wohl eher selten Einstellungen (und dann auch noch gleichzeitig auf verschiedenen Geräten) und in einer Datei wäre es vermutlich übersichtlicher. Ich glaube, das ist aber keine besonders wichtige/grundlegende Frage.

 

[pfeffer]

naja, ich finde es schon eine wichtige Frage, was man macht, wenn die GUI oder die Hardware Informationen braucht / speichern muss, die das Backend nicht unterstützt. Aber in eine eigene pref_android.xml schreiben, finde ich eine gute Lösung. Vielleicht braucht man auch noch Klassen, die diese Informationen zwischen GUI-Klassen transportieren - da kommen sicher noch einige Schwierigkeiten auf uns zu.

Gruß,
Pfeffer.