Bestehende App erweitern vs. Neue App

Wenn du den Playstore mit noch mehr überflüssigen Apps fluten willst würde ich die extra App Variante nehmen.
Ansonsten wäre ich definitiv für eine App. Die Sprache musst du doch nicht in den Einstellungen wählen lassen, das sucht sich Android selbst. Oder du fragst den User einfach zuerst.

Liebe Grüße Maximilian

Keine sehr schmeichelhafte Formulierung...... und auf eine App mehr oder weniger kommt es wirklich nicht an.

Aber zum Thema: Schwierige Frage.... wie wirkt sich der Neuheitsbonus wirklich für deine App aus? Und wie hoch ist die Differenz zu einer App die schon ein gutes Statement hat und einige Downloads?? Was hattest du denn bislang in der Developer Console eingetragen? Hast du die anderen Länder da bislang ausgelassen? Gibts dann vielleicht den Bonus auch, wenn man die Länder aktiviert?

Was wenn jedes so denkt? Jeder kann etwas dafür tun, den Playstore etwas übersichtlicher zu halten.

Liebe Grüße Maximilian

lol du hast auch viele free und paid Apps. das lässt sich mit iap auch lösen um, wie du es sagst, den Markt nicht mit überflüssigen Apps zu fluten.

nett ist echt was anderes. weiter helfen könntest du damit sicher nicht.

Free und Paid ist was ganz anderes... hier gibt es um eine extra App für jede Sprache. Bitte unterstelle mir nicht so ein Zeug. Aber jetzt Schluss damit, ist ja unnötig hier.

Außerdem habe ich eine ganz normale Antwort gegeben im Gegensatz zu dir eben hier. ;)

Also ich würde dem TE wirklich empfehlen alles in EINE App zu packen. So muss er erstens nur eine pflegen und zweitens gehen die Downloads ebenfalls als auf eine App.

Liebe Grüße Maximilian

Sorry aber du hast in deiner Antwort seine App als "überflüssig" hingestellt.

Das sehe ich nicht grade als nett an

Falls es nicht so gemeint war, sorry, aber kam so rüber

Tut mir leid, wenn ihr das so verstanden habt, war nicht meine Absicht. Ich fand nur die 2. Version der App (mit dem kleinen Unterschied, dass diese eine andere Sprache hat) überflüssig. War nicht auf die App selbst bezogen.

Liebe Grüße Maximilian

1000 Fragen für eine Sprache rechtfertigen doch keine neue App. Meine größte DB einer Android App hat 80MB - da merkst Du nix von Performance Einschränkungen. Pack alles in eine DB und gut ist. Jede Frage ist dann einer Sprache zugeordnet, alle Fragen liegen übersetzt vor - das ist MickyMaus Datenbank Design.

... und bzgl. schlechte Bewertung in einer Sprache etc. Das ist in meinen Augen rumtrickserei. Stell Dich dem Voting Deiner Kunden mit einer einzigen App. Wenn Du schlechte Bewertungen bekommst dann hast Du etwas falsch gemacht. Bessere dann nach oder lass es sein.

Meine 2 Cent.

Ohne für eine der beiden Wege partei ergreifen zu wollen, aber wenn ich hier immer lese "unnötige App" , "rechtfertigen keine App":
Niemand braucht eine Rechtfertigung für eine App und keine App die mehr als einer Person gefällt ist unnötig. Es gibt keine "Mindestgrenze" oder sonst etwas. Davon würde ich mich nicht beirren lassen.

Wenn es danach ginge, müssten ganz andere Apps erstmal aus dem Markt fliegen, angefangen von den ganzen Pups-Apps über die zig tausend Busen, Arsch und Porno-Apps, welche alle nur Slideshows sind, bis hin zu den ganzen "Duplikaten" von bestehenden Apps. Und ein Problem werden zu viele Apps nur, weil der Play-Store so bescheiden ist, damit hat sich Google in meinen Augen bislang am meisten blamiert.

@Thema: Ich würde wahrscheinlich die App so umbauen, dass ich die andere Sprache als Add-On nachladen kann, besser wäre natürlich, wenn man bei so etwas von Anfang an die "Engine" von den Fragen getrennt hätte, aber manchmal macht man so eine Entscheidung ja erst später.

+1

ABER

Wenn es nur um Entwicklerfragen rund um AppsPerSprache oder eine App, Datenbank oder Dateien, nachladen oder mit Update ausliefern, etc. ginge dann hätte der Thread hier wahrscheinlich eine andere Resonanz erzeugt.

Die aktuelle Resonanz ist in meinen Augen durch den Fokus des Posters auf "Neuheitsbonus", "ob ich es überhaupt [... mit einer weiteren App ...] schaffe, gerankt zu werden", "Total Downloads", "Auch optisch ist ja schöner, eine App mit 100.000+ Downloads zu haben statt 50.000+ zweimal", "Retention Rate", etc. entstanden.

Das ist das was ich in meiner Antwort als "Rumtrickserei" bezeichnete. Hier geht es nicht um die Technik rund um "wie baue ich geschickt eine mehrsprachige Quiz-App" die meinen Usern überall auf der Welt gefällt" - hier geht es rein um die "Kosmetik" (nicht im UI Sinne).


Deshalb mein Kommentar das es meiner Meinung nach keinen vernünftigen technischen Grund gibt der gegen eine einzelne App spricht.

— geändert am 08.07.2012, 10:13:35

Banker?

SCNR

Ich finde seine Bedenken bzgl. ..... sagen wir mal "Marketing und Market-Optimierung" durchaus gerechtfertigt. Ich hab seine andere App mir jetzt nicht angesehen und weiß nichtmal ob er dafür Geld haben will oder ob Werbung drin ist, aber man baut doch seine App um entweder
a) Geld zu verdienen
b) weil man Spaß daran hat
c) weil man sie selber gerne hätte und es gab sie nicht
oder im Idealfall d) a-c zusammen ;-)

Und deswegen möchte man ja möglichst gut im Store dastehen.... meiner Meinung nach wird hier (und in anderen Entwicklerforen) viel zu wenig darüber gesprochen, denn was nützt die super App wenn sie keiner findet. Um so trauriger, dass gerade die ganzen Müll-Apps sehr viel Erfahrung in dem Bereich aufbauen und damit viel häufiger im Store gefunden werden als die guten Apps. Leider überzeugt dann nämlich nicht die Quali der App sondern einfach das "können" im Marketing. Von daher fände ich es sehr gut, wenn erfahrene seriöse Entwickler sich in dem Bereich mehr austauschen würden..... aber da die anderen hier bestimmt auch mitlesen bringt das wohl leider wenig. So, musste ich mal kurz loswerden, vorallem wenn ich dann wieder so ne Assi-App sehe die nen € oder mehr kostet und mehr als 10.000 Downloads hat, krieg ich immer so nen Hals.... aber naja, ist ja Angebot und Nachfrage....

bzgl. dem Add-On, da gibt es mehrere Möglichkeiten, man kann nachladen (auch mit Market-Unterstützung) oder die Add-Ons "quasi" als eigene App anbieten und dann nachladen (kaufen/runterladen).

du kannst dateien zum nachladen direkt per google play bewerkstelligen.

ich las 1000 datensätze zu überspielen sollte 5 sek dauern. das kommt mir etwas lang vor. nutzt du transaktionen? das beschleunigt alles extrem.

Kommt mir auch etwas lang vor. Bei meiner Smiley App dauert es etwa fünf Sekunden, 1000 Datensätze inkl. Bitmaps (insgesamt etwa 20 MB Daten) einzulesen und darzustellen...

Herzliche Grüße

Carsten

<Grins, hab nen EUR gewonnen>. Zurück zum Thema.


Die Transaktion alleine ist nicht alles.

* Generiere für die am häufigsten mit Inserts beschossene Tabelle ein PreparedStatement. Und am Ende "commite". Ich garantiere Dir Steigerungen in gigantischem Ausmaß. Offensichtlich hat SQLite keinen Optimizer der Statements erkennt die als Kandidaten für PreparedStatements geeignet wären um diese dann selbst zu verwalten (korrigiert mich bitte - aber das sind meine Erfahrungen). Also musst Du das selbst machen. Da jedes SQL Statement durch den Precompiler muss sparst Du mit jedem weiteren identischen Zugriff, den Du bereits vorbereitet (prepared) hattest, Performance - desto mehr Inserts, desto mehr Zeit gespart. Nur am Rande - das erfordert natürlich den Einsatz von ParameterMarkern '?'.

* Nun zum Speicher Deines Freundes: Transaktionen werden je nach Datenbanksystem unterschiedlich genutzt. Oftmals wandern die Inserts nur in das sogenannte Transaction-Log während die DB selbst unverändert bleibt. Damit ist der Isolation Level fast vollkommen egal da meist "Read Committed" zum Einsatz kommt. Die Datenbank ignoriert dann einfach das Transaction-Log bei parallelen Lese-Zugriffen (die auf einem Mobilsystem ohnehin selten sind) und ist sehr schnell. Andere Log-Verfahren schreiben die Inserts direkt in die DB. Die Android Version und die darin enthaltene SQLite Version entscheiden das Verfahren. Über PRAGMAs könntest Du das anpassen. Das würde ich aber unterlassen da Du nicht alle SQLite Versionen da draußen kennst.

Bei Inserts sind die Daten beim ersten Verfahren in einer parallelen Datei - dem Transaction Log. Am Ende wird "commited" und die Inserts wandern vom Transaction-Log in die Datenbank. Während der Transaktion sind die Inserts einmal auf der Platte und zwar in der Größe des Transaction-Log. Während des Commit sind die einzufügenden Daten kurzfristig zweimal auf der Platte. Beim zweiten Verfahren sind die Inserts ausschließlich in der DB und das Transaction-Log ist leer.

Ab dem Commit, oder dem nächsten Checkpoint, wird das Transaction-Log recyceled - wenn nicht gerade parallele Zugriffe das verhindern. Das gibt dann üblicherweise kurze Aussetzer - tendiert aber auf einem Mobilsystem mangels paralleler Zugriffe auf Deine App-Datenbank gegen 0.

Na ja, und was macht der Entwickler in diesem Fall? Genau, er schaut sich sein einzufügendes Datenvolumen an, setzt das ins Verhältnis zum üblichen Platz auf einem Mobilsystem und lässt einen Zähler mitlaufen. Nach 'n' Inserts wird dann halt "commited" und es geht weiter. SQLite macht ebenfalls ein automatisches Checkpointing - bei 1000 Pages (nicht Records) - und das wirst Du mit textbasierenden Inserts schnell erreichen.

Nicht verschweigen möchte ich Dir, das bei Verfahren 1 am Ende, bei der letzten Transaktion, eine nahezu komplett durch die Inserts gefüllte Datenbank PLUS der letzte Durchlauf im Transaction-Log liegen.

Das, oder die 1000 Pages vor dem automatischen Checkpointing, haben bei Deinem Kumpel versagt. Ich weiß nicht die aktuelle Page Größe von SQLite (4KB?). Deinem Kumpel hätten dann also 4MB gefehlt ... EDIT: oder er hatte einfach keinen Platz für Deine gesamten Daten - auch ohne zusätzliches Transaction-Log.


Lange Rede, wenig Sinn: Verwende Transaktionen sowie PreparedStatements mit ParameterMarkern und commite regelmäßig nach 'n' Inserts.

— geändert am 08.07.2012, 19:02:52