erste Gedanken OK?

  • Hallo EntwicklergemeInde


    nun bin ich entschlossen, mich aufzumachen und Android-Programmierung zu erlernen. Als Hintergrund habe ich viele Jahre professionelle Beschäftigung mit der eher ernsten Seite von Sytemtechnik, wenig Programmierung, bash, Rexx, PHP, Perl - bedarfsorientiert.


    Als erstes Projekt habe ich mir die Veröffentlichung eines Kantinenspeiseplans vorgenommen. Der Speiseplan existiert bereits im Web und wird dort erstellt aus einem PHP-Skript, das die Gerichte aus einer MySQL-DB liest.
    Jetzt gibt es mehrere Ansätze:
    1. Erstellen einer Ansicht in Java mit Zugriff auf besagte DB
    2. Hernehmen des HTML-Codes und darstellen dessen
    3. oder Inhalte Des HTML parsen und eine eigene Ansicht bauen.


    Ich möchte die Anfragen an den Server möglichst gering halten und eigentlich nicht direkt auf die DB zugreifen, deshalb tendiere ich zu 2. oder 3. und will die Inhalte nur aktualisieren, wenn das nötig ist, also nicht bei jedem App-Start, sondern einmal pro Woche (wenn der neue Plan erscheint)


    Frage an Euch: Sind die Gedanken bis hier OK?


    Dank und Grüße,


    BruderB

  • hey :)


    ich sitz auch schon seit einiger Zeit an einem solchen Plan, einfach aus spaß. So einfach ist es garnicht das alles ordentlich zu machen *gg*. Ich habe deinen dritten weg gewählt, einfach weil man dabei am meisten lernt. Gerade über die Oberflächenentwicklung in Android. Ich hab wenig Zeit für das Projekt und irgendwann gabs aufeinmal das Material design also hab ich die GUI wieder umbauen müssen, aber was solls, man lernt ja dabei was :)

  • So, ich komme voran: Inzwischen habe ich eine rudimentäre Ansicht des Speiseplans für einen Tag erstellt, in die ich Variablenwerte (Strings) einfügen kann und somit veränderlichen Inhalt präsentieren kann.


    Wenn ich in dem Tempo weitermache, ist die App nicht mehr in diesem Jahrhundert fertig... ;)


    Hinsichtlich meiner Eingangsfrage (wie kriege ich die Daten auf das Handy?) habe ich mich für einen vierten Weg entschieden: Ich bin glücklicherweise Herr des Servers, auf dem der Plan bereits im internet veröffentlicht wird. Ich plane, dort (auf dem Server) eine (xml?-)Datei zu erstellen, die die App auf das Handy runterlädt, wenn noch nicht vorhanden. Im Daitenamen sollte also die Kalenderwoche stehen und das Format der Datei sollte möglichst einfach weiterverarbeitbar sein.


    Die Datei plan41.xml könnte also aussehen wie im Anhang (Suffix geändert). Ist das eine gute Idee oder mache ich es mir unnötig schwer?


    Wo lege ich die Datei sinnvollerweise hin, wen ich sie heruntergeladen habe? Kann ich sie ähnlich wie die strings.xml direkt in /res/values hinterlegen, oder wird alles, was da steht, in Bytecode kompiliert?


    Danke im Voraus für Statements und Grüße,


    BruderB

  • Sehr gut, ich hätte nämlich spontan Weg #4 vorgeschlagen. :)


    Beziehungsweise wäre ich Weg #4a entlang geschlendert: Statt statischer XML Datei eine schöne dynamische JSON Datei.


    Die Anfrage an den Server würde dann lauten: GET https://kantine/tageskarte/?kw=41
    (Davon ausgehend, dass Dein Server automatisch die index.[php|py|rb] ausführt und Dein DNS 'kantine' entsprechend auflösen kann.)


    Hier kannst Du dann schön auf der Website arbeiten. Liegen beispielsweise noch gar keine Werte für KW41 bereit, liefert Dein Server ein HTTP404 zurück, am Besten mit der Fehlermeldung 'Noch keine Daten für KW 41'.


    Weiterhin kannst Du bei jedem Appstart prüfen, ob eine neue KW angefangen hat. Letzte abgerufene KW in den SharedPreferences ablegen, gucken ob bereits 'erster Tag der Woche' ist, und wenn ja und die Kalenderwochen unterscheiden sich, Anfrage starten.


    Und Du kannst zusätzlich das manuelle Update beim Herunterziehen der ListView einbauen. Dann umgehst Du einfach die Prüfung (schreibst die aktuelle KW aber natürlich trotzdem in die SharedPreferences).


    Selbstverständlich kannst Du für die fremdsprachigen Kollegen auch noch einen Parameter 'languageIdentifier' mitgeben und die Daten passend lokalisiert auf deren Telefone landen lassen.


    Der Clou: Orientierst Du Dich beispielsweise am JSON API Standard v.1, kannst Du mit weniger Overhead als im XML wirklich komplexe Objektstrukturen und -graphen übertragen.


    Deine Liste könnte beispielsweise so aussehen:


    Daraus baut Dir beispielsweise der GSON Parser dann eine schöne Mischung aus Dictionaries und Arrays und Du kannst das ziemlich schmerzfrei benutzen.


    Ablegen (wenn Du cachen möchtest) solltest Du sie entweder im öffentlichen Downloads Ordner oder im Datenordner Deiner App.
    Über die Funktionen Context.getCacheDir() und Context.getFilesDir() kommst Du an die internen Ordner, über Environment.getExternalStoragePublicDirectory(type) an die externen Ordner.


    In die res/values kannst Du die Daten jedenfalls nicht packen, da Dein Package digital signiert wird. Spielst Du in dem Ordner rum, ändert sich tatsächlich der Bytecode nach der Kompilierung und Deine digitale Signatur wird ungültig.


    Die Darstellung kannst Du simpel via ListView regeln.


    Die Hauptarbeit besteht hier eigentlich gar nicht so sehr in der App, sondern in den Vorüberlegungen. ^^
    Ein Jahrhundert wirst Du dafür sicherlich nicht brauchen.
    Bei mir wären es ohne JSON API Implementierung auf dem Server mit allen relevanten Tests ungefähr 20 Stunden, wobei natürlich Icon Design etc. fehlt.
    (Außer einem App Icon und weitere Icons wie 'vegetarisch', 'scharf' etc.pp. wie man sie von Lieferdiensten kennt, ist das ja nicht allzu viel.)


    Wichtig: Erleg Dir selbst ein Ziel auf, ab dem die App 'fertig' ist. "Wenn ich damit zufrieden bin" ist kein Ziel.
    Tatsächlich fällt Dir nämlich mitten drin ein, dass Du die Allergene zu den einzelnen Speisen mit ausgeben könntest. Und eine Detailansicht implementieren, auf denen diese Allergene aufgezeigt sind. Mit Icons. In unterschiedlichen Sprachen. Mit TalkBack Support für Blinde. Und einem Rating. Inklusive Kommentarfunktion.


    Irgendwann reichen dann auch drei Jahrhunderte nicht mehr aus. ^^

    Je mehr Käse, desto mehr Löcher.
    Je mehr Löcher, desto weniger Käse.
    Daraus folgt: je mehr Käse, desto weniger Käse.


    »Dies ist ein Forum. Schreibt Eure Fragen in das Forum, nicht per PN!«

  • Klar, eins nach dem anderen. :)


    Mit der Umsetzung des JSON API Standards entsprechend Deiner Anforderungen wirst Du sicherlich schon ein bisschen beschäftigt sein.
    Das ebnet Dir den Weg aber schon ganz gewaltig. :)

    Je mehr Käse, desto mehr Löcher.
    Je mehr Löcher, desto weniger Käse.
    Daraus folgt: je mehr Käse, desto weniger Käse.


    »Dies ist ein Forum. Schreibt Eure Fragen in das Forum, nicht per PN!«

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!