Beiträge von Sven Steiner

Ich kann bei deinem Text leider nicht erkennen, ob du hier ein Hobby-Projekt für Freizeit-Programmierer oder eine Firma mit Gewinnabsicht gründen willst.
Ich will dir ja nicht gleich den Wind aus den Segeln nehmen, aber das klingt mir alles ein bisschen nach "Hey, ich hab gehört mit Free2Play kann man ordentlich Kohle scheffeln und will auch was davon abhaben".
Du redest zwar von Gewerbe, aber kannst du auch Entwickler und Designer bezahlen, bis das Projekt Gewinn einfährt? Deine 6 Monate klingen ja schon sehr optimistisch, rechne eher mal mit ca einem Jahr, bei 10 oder mehr Angestellten. Wenn du denen ein Gehalt finanzieren willst, plus dem was so an laufenden Kosten anfällt, solltest du schon über ein siebenstelliges Kapital verfügen. Ohne Festgehalt wirst du da sicher niemanden finden, der Zeit opfert nur um vielleicht irgendwann mal ein paar Euros daraus zu bekommen. Dafür muss man nicht feige sein, sondern einfach nur vernünftig

Momentan versucht so ziemlich jeder so viele Free2Play-Spiele wie möglich auf den Markt zu werfen. Sich da aus der ganzen Masse heraus hervozuheben geht auch kaum, ohne da noch zusätzlich ordentlich Kohle für Werbung auszugeben. F2P funktioniert einfach nur mit einer großen Nutzerbasis, und neue Teilnehmer am Markt, die noch keiner kennt haben es da schwer, Nutzer zu finden.

Versuch lieber ein Hobby-Projekt zu gründen, an dem Leute in ihrer Freizeit arbeiten, ohne irgendwem zu versprechen, daß alle nach x Monaten ihr Geöd bekommen werden.

Ob XML oder JSON ist schon fast eher Geschmacks-Frage. Wenn es um Performance bei großen Dateien (also mehrere zig bis hunderte MB) geht würde ich eher XML mit einem SAX-Parser empfehlen (wobei ich da gerade nicht weiß ob es sowas auch bei Java/Android schon mitgeliefert gibt. Notfalls eben eine externe Lib suchen)
Ansonsten liest man XML per DOM ein, was halt dafür sorgt daß das komplette Dokument im Speicher liegt. Bei kleinen ist das ziemlich egal, aber bei großen Dokumenten ist SAX deutlich schneller und braucht weniger Speicher, da es das XML immer nur STück für STück liest. Dafür kann DOM das Dokument besser validieren und man weiß sofort beim Laden, ob das XML gültig ist oder nicht. Bei SAX muss man selbst die Daten prüfen und ggf das Einlesen abbrechen. JSON dürfte in Sachen Performance und Speicher ähnlich liegen wie XML mit DOM.
Das PLIST Format mag ich persönlich eigentlich gar nicht, weil es über den Syntax von XML nochmal einen zusätzlichen Syntax drüber stülpt. Das ist sicher praktisch für einfache Daten (Properties-Dateien eben), bei komplexeren Datenstrukturen tut man sich da aber keinen Gefallen, da würde ich ein eigenes XML-basiertes Format vorziehen. Zumal PLIST bei großen Dateien wieder die selben Nachteile hat wie DOM.

Binärdateien sind ansich schonmal deutlich kleiner als jede Art von textbasierten Formaten. Ein Format zu entwickeln ist ansich nicht sooo schwer, problematisch wird es allerdings wenn man so ein Format erweitern muss. Bei XML kann man z.B. jederzeit ein neues Tag einfügen oder ein element mit "version='2'" o.ä. markieren, bei Binärdaten ist das deutlich schwerer.
Den großen Vortel von Binärformaten, nämlich die geringe Größe, kann man aber auch erreichen indem man seine XML oder JSON zum Versand komprimiert (Java hat schon Klassen, um Daten mit dem Zip-Algorithmus zu komprimieren). Textbasierte Dateien lassen sich normalerweise sehr gut komprimieren. Wenn man etwas Arbeit hineinsteckt kann man auch mehrere hundert MB komprimierte XML-Dateien übertragen, Stück für Stück entpacken und einlesen, ohne daß dafür mehr als ein paar kB RAM verbraucht werden
Falls man das HTTP-Protokoll zur Übertragung nutzen kann (mittels Webserver auf der Server-Seite und HttpRequest-Klassen beim Client) bekommt man sogar die Kompression frei Haus ohne etwas dafür zu tun.

Hallo

das hört sich ja schonmal ganz gut an, dann werd ich das einmal weiter verfolgen und versuchen daraus einen Prototyp zu bauen

Beim Login würdest du also hergehen und die App-Activity starten, die dann versucht auf den Server zuzugreifen. Falls keine Login-Daten vorhanden oder abgelaufen wird die Login-Activity gestartet die dann wieder das Ergebnis zurück zur App liefert?
Klingt soweit einleuchtend - danke für die Hilfe

Hallo

Ich bin gerade dabei eine neue Android-App zu planen. Da mir bisher die nötige Erfahrung beim Entwickeln von Android-Apps fehlen hoffe ich hier einige Anregungen zu finden, wie ich meine App her aufbauen könnte.

Grob gesagt soll das ganze ein Frontend für eine Web-App werden. Den grundlegenden Aufbau habe ich mir bisher ähnlich vorgestellt, wie z.b. die GMail oder Playstore Apps funktionieren: links ein aufklappbares Menü, über das ich die einzelnen Seiten anwählen kann, in denen dann der entsprechende Content dargestellt wird. Im AndroidStudio habe ich dazu schon ein Navigation Drawer Activity Beispiel gesehen, welches dieses Verhalten abbildet.
Meine Frage wäre hier nun, ob das schon einmal der richtige Weg ist, oder ihr etwas anderes empfehlen würdet. Da einzelne Seiten ggf auch durch Graphiken etc. viel Inhalt beinhalten können, wäre es z.B. auch interessant, ob bei einem solchen Aufbau Android noch die Möglichkeit hat, inaktive Seiten zu schließen, wenn der Speicher knapp wird, wie z.B. jederzeit eine Activity geschlossen werden kann.

Ein anderer Punkt wäre noch, wie man am besten einen Login handhabt. Lege ich die Login-Activity als Start-Activity fest, und lasse diese die eigentliche App aufrufen, oder ist meine App die Start-Activity und öffne per Intent die Login-Activity, wenn ich feststelle, daß ich keinen gültigen Login habe oder dieser abgelaufen ist?
Idealerweise möchte ich mich als Benutzer ja einmalig einloggen, und beim nächsten Start der App direkt wieder den Inhalt sehen, am Besten auch auf der Seite, auf der ich die App zuletzt verlassen habe.

Ich hoffe meine Fragen waren soweit verständlich. Danke schonmal für eure Hilfe