Zweifel an der weiteren Vorgehensweise – BVA goes Android?

Verfasst am: Dienstag, 15. Mrz. 2016 um 22:59

Seit nun fast 2 Jahren befindet sich bei uns ein Android-Tablet im Familienbesitz, mittlerweile haben sogar die Kinder eigene Geräte. Auch die alten Handys wurden mittlerweile durch Smartphones ersetzt. Nachdem ich durch ein kleines „Nebenprojekt“ auch erste Erfahrungen mit der Programmierung von Android-Anwendungen sammeln konnte, stellte sich mir die Frage, ob es nicht sinnvoll wäre, das BVASystem auf Android zu portieren. Praktisch wäre es sicher, da man direkt auf dem Sofa seine Fotos verwalten könnte.

Aber leider ist es mit meiner aktuellen Entwicklungsumgebung Delphi XE2 nicht möglich, für mobile Plattformen zu entwickeln. Bisher war aufgrund dieser Tatsache für mich das Thema Android beendet. Mittlerweile gibt es Delphi XE10 mit der dies möglich wäre, allerdings müsste ich dafür jede Menge Geld investieren. Außerdem müsste ich wohl das Framework VCL durch Firemonkey ersetzen. Der Aufwand dafür gleicht wohl einer Neuentwicklung, da das BVASystem fast ausschließlich auf speziellen selbstentwickelten VCL-Komponenten basiert. Einzig der Teil, der zur Datenhaltung und zur Kommunikation mit der Datenbank zuständig ist, könnte wohl weiterverwendet werden.

Alternativ könnte ich natürlich auch einfach ein zweites Projekt anfangen (z.B. mit dem Android Studio) und alles bzw. zumindest teilweise was ich bisher habe nachprogrammieren. Vorteil ist sicherlich, das ich dafür keinerlei Investitionen tätigen muss. Aber die Aussicht, alles doppelt programmieren zu müssen, ist irgendwie nicht so toll.

In den letzten Wochen habe ich daher viel recherchiert und ein ein wenig herumprobiert. Festgesetzt habe ich mich an einem Cross-Plattform Ansatz, der auf JavaFX basiert. Damit ist es mir zumindest gelungen, eine kleine Testanwendung zu programmieren, die sowohl auf einem Desktop PC, als auch auf einem Android-System lauffähig ist. Vorteil dabei ist sicherlich, das ich nur einmal programmieren muss, um beide Plattformen zu bedienen. Als großer Nachteil erweißt sich aber weiterhin, das ich quasi wieder bei fast null anfangen müsste.

Screenshot der Cross-Plattform-Testanwendung

Screenshot der Cross-Plattform-Testanwendung

Wie ich nun weiter vorgehen soll, weiß ich leider immer noch nicht genau. Fest steht allerdings, das ich das jetzige BVASystem nicht einfach einstellen will. Ich nutze es selbst ja mehrfach die Woche und so muss ich den Vorteil nutzen, das ich jede Sache, die mir nicht passt, ändern kann. Allerdings stellt sich die Frage, ob ich noch groß Energie in riesige Änderungen stecken sollte, oder ob ich die Zeit verkürze bis ich auf dem Sofa meine Fotos verwalte….

Tags: , , ,

3 Kommentare to “Zweifel an der weiteren Vorgehensweise – BVA goes Android?”

  1. Tom sagt:

    App Entwicklung ist doch schon wieder Schnee von gestern. Wenn du nicht immer 100mal nachfrimmeln willst, dann gehört das BVA ins Web mit einem ordentlichen Responsive Design sind dann gleich alle Plattformen (PC, Android, IPone, nächste Schnickschnack von morgen) bedient. Außerdem hat Oracle JavaFX zur Zeit etwas fallen gelassen. zB für ARM Plattformen kein JavaFX mehr. Wie da die weitere Entwicklung is steht in den Sternen.

  2. Marc Alinski sagt:

    „… gehört das BVA ins Web …“

    Wenn ich ehrlich bin, kann ich mir das überhaupt nicht vorstellen, wegen der Teile die nicht auf einem Server liegen. Lokale SQLite DB, ein Verändern der EXIF/ITPC-Daten und ev. eine Überwachung von Foto-Verzeichnissen ist da wohl nicht oder nur schwer möglich.

    Was JavaFX angeht magst du Recht haben. Ich habe mit JavaFXPorts eine Möglichkeit gefunden, JavaFX plattformübergreifend auf Desktop, Android, IPhone und Embedded zu nutzen. Ob dies der richtige Weg ist weiß ich nicht. Fraglich ist, ob der Ansatz performant genug ist. Mehr als ein etwas aufgeblähtes „Hello-World“ Programm habe ich ja nicht ausprobiert.

  3. Tom sagt:

    Du hast natürlich recht, das erfordert größere Konzeptuelle Änderungen, aber das ist mit Mobile Devices sowieso notwendig (vonwegen wo werden Photos überwacht, oder werden sie importiert) Aber eine SQLLite lokal brauchts dann idealerweise nicht mehr.

Einen Kommentar schreiben