Größe der Android Anwendung

[v2afrank]

Hallo,
ich habe mir die Demo von XE 5 runtergeladen und eine simple Hello World Anwendung erstellt.
Was mir sofort auffiel ist, dass das Programm eine Größe von 21 MByte hat.
Das kann ja wohl nicht richtig sein. Oder ? Wo kann / muss ich Optimierungen einschalten um eine akzeptable Größe zu bekommen ?

[Der schöne Günther]

Also kleiner sind meine Hallo-Welt-Anwendungen unter Win32 auch nicht (zumindest in der Debug-Fassung) :wink:

[v2afrank]

Aber auch in der Releasefassung wirds nicht kleiner.
Ich musste auf meinem Handy erst einmal ein paar andere Anwedungen deinstallieren um mein hello World drauf zu bekommen.:cry:

[Phoenix]

Zitat:

Zitat von v2afrank (Beitrag 1228085)

Das kann ja wohl nicht richtig sein. Oder ? Wo kann / muss ich Optimierungen einschalten um eine akzeptable Größe zu bekommen ?

Bei dem Konzept das FireMonkey fährt ('true' native auf Basis des NDK) wirst Du nicht kleiner weg kommen.

Da 'normale' Android-Anwendungen auf Java basieren und dafür alles benötigte, inkl. der Dalvik runtime und der Plattform-nativen Controls, bereits auf dem Gerät vorhanden ist, sind die in aller Regel sehr klein.

FireMonkey benötigt, wie alle Delphi-Applikationen, seine eigene Runtime-Bibliothek (RTL), und muss natürlich seine eigenen FireMonkey-Komponenten alle auch nochmal mitbringen. Das braucht nunmal Platz.

Noch interessanter hierbei ist der Fakt, das es Android-Geräte mit ARM-Chips (die große Mehrheit), Intel-Chips (z.B. die Intel Education Tablets) und sogar MIPS-CPU's (miumiu tablets) gibt. Das heisst das man durch die Verwendung des NDK's jede Datei die ausführbaren Code enthält in fertigen Kompilaten für alle drei CPU's bereitstellen muss, will man nicht bestimmte Devices aussen vor lassen.

Deine Anwendung hat also vermutlich eher 'nur' 7MB (immer noch riesig) aber 7MB für 3 CPU-Typen ergibt halt die erwähnten 21 MB. Da freut sich jeder Android-User der Deine App 'mal schnell Unterwegs installieren' will.

Aber solange Du das NDK verwendest, wirst Du da aber auch nicht von weg kommen.

[v2afrank]

Ok. Das ist eine Eklärung die ich verstehe, aber nicht gut finde.
Gibt es denn keine Möglichkeit eine Arte Runtime Package zu installieren um dann die eigentliche Anwendung möglichst klein zu halten. Ich meine so etwas mal in einer anderen IDE für Android gesehen zu haben.

[mkinzler]

Zitat:

Deine Anwendung hat also vermutlich eher 'nur' 7MB (immer noch riesig) aber 7MB für 3 CPU-Typen ergibt halt die erwähnten 21 MB. Da freut sich jeder Android-User der Deine App 'mal schnell Unterwegs installieren' will.

Nein, den XE5 kann nur ARM32.

Zitat:

Ok. Das ist eine Eklärung die ich verstehe, aber nicht gut finde.
Gibt es denn keine Möglichkeit eine Arte Runtime Package zu installieren um dann die eigentliche Anwendung möglichst klein zu halten. Ich meine so etwas mal in einer anderen IDE für Android gesehen zu haben.

Das könnte unter Android theoretisch funktionieren, Delphi linkt aber immer alles, du müsstest das also händisch machen.

[Phoenix]

Zitat:

Zitat von v2afrank (Beitrag 1228097)

Ok. Das ist eine Eklärung die ich verstehe, aber nicht gut finde.

Embarcadero ist entweder tatsächlich der Meinung, das das sei, was die meisten Delphi-Kunden sich wünschen oder sie sind der Meinung, das das das ist, was sie am besten (=gewinnbringendsten) an die existierenden Delphi-Entwickler verkaufen können.

Und da sind viele Leute leider sehr dogmatisch. Entweder, Du bist ein FireMonkey-User und schluckst das (und musst es gut finden und bashst auf X-Code bzw. Java, weil man da ja viel Neues lernen und/oder alles/das meiste doppelt coden muss), oder aber Du nutzt kein FireMonkey und setzt auf native Technologien die es Dir erlauben, die Plattformen optimal für Deine Zwecke auszunutzen.

Zitat:

Zitat von v2afrank (Beitrag 1228097)

Gibt es denn keine Möglichkeit eine Arte Runtime Package zu installieren um dann die eigentliche Anwendung möglichst klein zu halten. Ich meine so etwas mal in einer anderen IDE für Android gesehen zu haben.

Wenn Du native Android-Anwendungen (also das richtige nativ wie Plattform-Nativ, nicht wie 'true' native :roll:), dann lässt sich da mit shared Libraries schon was machen. Aber das geht eben nur auf der Dalvik-Runtime.

[Phoenix]

Zitat:

Zitat von mkinzler (Beitrag 1228099)

Zitat:

Deine Anwendung hat also vermutlich eher 'nur' 7MB (immer noch riesig) aber 7MB für 3 CPU-Typen ergibt halt die erwähnten 21 MB. Da freut sich jeder Android-User der Deine App 'mal schnell Unterwegs installieren' will.

Nein, den XE5 kann nur ARM32.

Das heisst dann aber grundsätzlich, das viele Android-Tablet-User aussen vor sind und das die Anwendung - sofern dann Intel und MIPS-Support kommen - noch größer werden.

Ganz ehrlich: Ich weiss nicht, ob ich einfach nur still vor mich hinschluchzen soll oder ein Nervenzusammenbruch mit Heulkrampf die adäquate Antwort ist.

Mir tun echt alle Leute einzeln unwahrscheinlich Leid, die auf so ein Gefrickel reinfallen und da auch noch hinein investieren.

[v2afrank]

In meinen ersten kurzen Tests war ich vom Komfort von Delphi im Vergleich zu Eclipse oder dem Android Studio begeistert. Es funktionierte einfach. Ich konnte rechts mein Device oder den Emulator auswählen. Die Positionierung und auch die Zuweisung der Ereignisse funktionierte so einfach wie man es von Delphi gewohnt ist. Eben RAD, was ich von den anderen IDEs nicht behaupten kann.

Aber. Das Ergebnis muss stimmen. Was es hier meiner Meinung nach absolut nicht tut.
Für das Produkt werde ich erst einmal kein Geld ausgeben. Ich habe ja noch 30 Tage Testzeit, aber diese Große ist für mich ein KO Kriterium

[mkinzler]

Zitat:

Das heisst dann aber grundsätzlich, das viele Android-Tablet-User aussen vor sind und das die Anwendung - sofern dann Intel und MIPS-Support kommen - noch größer werden.

Dies kommt dann mit XEnnn :mrgreen:

Seit ca. 10 Jahren arbeiten sie an einer Front-/Backend Lösung des Compilers, der scheint aber nicht fertig zu werden.

[Phoenix]

Zitat:

Zitat von v2afrank (Beitrag 1228105)

Die Positionierung und auch die Zuweisung der Ereignisse funktionierte so einfach wie man es von Delphi gewohnt ist. Eben RAD, was ich von den anderen IDEs nicht behaupten kann.

Aber. Das Ergebnis muss stimmen. Was es hier meiner Meinung nach absolut nicht tut.

Es gibt Gründe, warum sich die .NET Welt mit Silverlight/WPF (MVVM) von Windows Forms (RAD) verabschiedet hat. Es gibt Gründe, warum sich die .NET Welt mit ASP.NET MVC von WebForms (RAD) verabschiedet hat. Es gibt Gründe, warum X-Code bei Mac- und iOS Anwendung das MVC-Pattern forciert. Es gibt Gründe, warum auf Android MVC- und MVVM-Pattern so stark getrieben werden.

Egal wo hin man blickt: Mobile Anwendungen, Web Anwendungen, selbst im Desktop-Bereich auf dem Mac, auf Linux und auf Windows mit oder ohne RT): Überall gehen die Entwicklungsumgebungen mit schnellen, großen Schritten weg von RAD und hin zu MVC / MVVM-Patterns, die automatisierbare Testbarkeit und Entkopplung / Austauschbarkeit von Code ermöglichen.

Ganz Gallien? Nein! Ein von unbeugsamen Delphianern bevölkertes Dorf hört nicht auf, dem technologischen Fortschritt widerstand zu leisten. (scnr)

[Der schöne Günther]

Und was ist dann unser Zaubertrank? :cheers:

[musicman56]

Vielleicht ein RAD-Studio das anstatt pascal-Code fertigen Java-Code produziert? Schlagt mich jetzt, wenn ich als absolut Unwissender in Sachen Android sowas von mir gebe. Aber, es wäre mein Wunsch :thumb:

[v2afrank]

Zitat:

Zitat von Phoenix (Beitrag 1228118)

Es gibt Gründe, warum sich die .NET Welt mit Silverlight/WPF (MVVM) von Windows Forms (RAD) verabschiedet hat. Es gibt Gründe, warum sich die .NET Welt mit ASP.NET MVC von WebForms (RAD) verabschiedet hat. Es gibt Gründe, warum X-Code bei Mac- und iOS Anwendung das MVC-Pattern forciert. Es gibt Gründe, warum auf Android MVC- und MVVM-Pattern so stark getrieben werden.

Das mag für viele Anwendungen absolut richtig sein. Aber darum ging es hier doch nicht.
Für mich war die Hoffnung da ein paar von uns genutzte Apps einfach zu entwickeln. Das denke ich würde funktionieren. Aber aufgrund der Größe der Anwendungen scheidet dieser Weg für mich aus.
Welches jetzt die "richtigere" Vorgehensweise ist für mich erst mal egal. So wie ich es sehe bleibt mir jetzt nur der klassische Eclipse / Android Studio Weg

[Phoenix]

Zitat:

Zitat von musicman56 (Beitrag 1228117)

Vielleicht ein RAD-Studio das anstatt pascal-Code fertigen Java-Code produziert? Schlagt mich jetzt, wenn ich als absolut Unwissender in Sachen Android sowas von mir gebe. Aber, es wäre mein Wunsch

Naja, es ist ja nun nicht so, das es sowas nicht schon gäbe...

[Union]

Zitat:

Zitat von Phoenix (Beitrag 1228113)

Zitat:

Zitat von v2afrank (Beitrag 1228105)

Die Positionierung und auch die Zuweisung der Ereignisse funktionierte so einfach wie man es von Delphi gewohnt ist. Eben RAD, was ich von den anderen IDEs nicht behaupten kann.

Es gibt Gründe, warum sich die .NET Welt mit Silverlight/WPF (MVVM) von Windows Forms (RAD) verabschiedet hat. Es gibt Gründe, warum sich die .NET Welt mit ASP.NET MVC von WebForms (RAD) verabschiedet hat. Es gibt Gründe, warum X-Code bei Mac- und iOS Anwendung das MVC-Pattern forciert. Es gibt Gründe, warum auf Android MVC- und MVVM-Pattern so stark getrieben werden.

Egal wo hin man blickt: Mobile Anwendungen, Web Anwendungen, selbst im Desktop-Bereich auf dem Mac, auf Linux und auf Windows mit oder ohne RT): Überall gehen die Entwicklungsumgebungen mit schnellen, großen Schritten weg von RAD und hin zu MVC / MVVM-Patterns, die automatisierbare Testbarkeit und Entkopplung / Austauschbarkeit von Code ermöglichen.

Ganz Gallien? Nein! Ein von unbeugsamen Delphianern bevölkertes Dorf hört nicht auf, dem technologischen Fortschritt widerstand zu leisten. (scnr)

Was widerspricht sich denn da? MVVm und RAD geht durchaus. Man muß es nur durchhalten und braucht natürlich ein Framework das dies performant unterstützt. Eine halbgare Lösung dafür gibt es ja schon , die heißt LiveBindings. Dann kann man RAD entwickeln (mit den lustigen Prototype-Datasource) und im Create des View (Form) wird dann ein generischer TBindSourceAdapter reingehängt.

[musicman56]

Zitat:

Zitat von Phoenix (Beitrag 1228121)

Zitat:

Zitat von musicman56 (Beitrag 1228117)

Vielleicht ein RAD-Studio das anstatt pascal-Code fertigen Java-Code produziert? Schlagt mich jetzt, wenn ich als absolut Unwissender in Sachen Android sowas von mir gebe. Aber, es wäre mein Wunsch

Naja, es ist ja nun nicht so, das es sowas nicht schon gäbe...

Meinst du damit Eclipse?

[Bernhard Geyer]

Zitat:

Zitat von musicman56 (Beitrag 1228133)

Zitat:

Zitat von Phoenix (Beitrag 1228121)

Zitat:

Zitat von musicman56 (Beitrag 1228117)

Vielleicht ein RAD-Studio das anstatt pascal-Code fertigen Java-Code produziert? Schlagt mich jetzt, wenn ich als absolut Unwissender in Sachen Android sowas von mir gebe. Aber, es wäre mein Wunsch

Naja, es ist ja nun nicht so, das es sowas nicht schon gäbe...

Meinst du damit Eclipse?

Wohl eher Intellij IDEA (oder auch Android Studio)

[mkinzler]

Nein er meint wohl Oxygene; ein Pascalcompiler, der Java-Bytecode erzeugt. Es gibt auch ein Projekt für FPC, welches ähnliches versucht.

[musicman56]

Hallo,

und zu was würdet ihr mir als absolutem Anfänger raten? Muss dazu sagen, ich habe neben Pascal von anderen Sprachen keinen Schimmer. Weil ich aber noch knapp 10 Jährchen bis zur Rente habe, muss ich mich wohl oder übel mit dem Thema Android-Apps - zumindest grundsätzlich - beschäftigen.

[sh17]

Puh, also ehrlich gesagt bin ich froh hier so schnell einen Nachteil des ganzen Delphi-Android-iOS-Dingens zu lesen. Und momentan mit Oxygene auf das "richtige" Pferd zusetzen. Auch wenn die Einarbeitung etwas höher liegt, man versteht dann wenigstens die Plattformkonzepte.

[Phoenix]

Zitat:

Zitat von musicman56 (Beitrag 1228142)

und zu was würdet ihr mir als absolutem Anfänger raten? Muss dazu sagen, ich habe neben Pascal von anderen Sprachen keinen Schimmer.

Was Neues zu lernen ist grundsätzlich nie falsch - egal wie lang es noch bis zur Rente ist ;-)

Wenn Android empfehle ich persönlich tatsächlich Java.
Ja, es ist eine neue Sprache, Ja, es ist ein neue Plattform mit eigenen Regeln, Ja, es ist eine neue IDE und Ja, die meisten Quellen dazu sind auf Englisch.

Aber:
Es gibt Tutorials zu Hauf. Man kann in der riesigen Community mal schnell eine Frage stellen und hat sofort Antwort. Man kann die offizielle Google-Dokumentation zu Rate ziehen.

Alles andere hat diese Vorteile nicht.

FireMonkey hat eine begrenzte Community, nicht jeder macht damit Android, das heisst nochmal weniger potentielle Helfer, die Doku ist Embarcadero-Typisch auch nicht so vollumfassend.

MonoDroid / PhoneGap legen nochmal auf die Android-Basis (mit der man sich Grundsätzlich auseinandersetzen sollte) nochmal zusätzliche Komplexität (sei es nur die Toolchain oder gar andere API's) drauf. Das muss man sich nicht antun.

Oxygene nimmt einem war die Sprache-Hürde ab und schleift alles andere 1:1 durch, aber da man sich hier trotzdem direkt mit der Plattform auseinandersetzt bleibt es einem nicht erspart, das Java-Zeug trotzdem lesen (und übersetzen) zu lernen. Und man steht Community-Technisch recht allein da, wenn man dann seinen Code für ne Frage copy&pasten will, ohne ihn zuerst in Java zurückzuübersetzen.
Wenn Du also nicht vor hast, im Business-Layer Plattformübergreifend zu Coden (was durchaus geht, aber die Hürde ist tatsächlich recht hoch, da man *sehr* Plattform-Agnostisch arbeien muss), dann wäre der imho beste Ansatz, sich auf die Ziel-Plattform einzulassen und mit einem der unzähligen Tutorials einer Java-Hello-World Anwendung zu beginnen.

[MEissing]

Zitat:

Zitat von v2afrank (Beitrag 1228089)

Aber auch in der Releasefassung wirds nicht kleiner.

Ein simples "Hello World" ist hier knapp 5 MByte groß.
Darüberhinaus wächst es (erwartungsgemäß) nur marginal.

[musicman56]

@Phoenix

Vielen Dank für deine Hinweise und Tipps. Du bestätigst was ich insgeheim schon vermutet habe. Mein größtes Problem ist, dass mir sehr viele Grundkenntnisse des Programmierens fehlen. Wenn man 20+ Jahre Pascal-Code schreibt, dann kann man das auch irgendwann mal, aber die Angst (oder die Hürde) vor einer neuen Sprache ist schon "stark ausgeprägt".

Insgeheim habe ich die letzten Monate schon auf Delphi für Android gehofft. Aber - wieder zum Thema des TE zurück - diese "Größenordnung" der .apk's :cyclops: schreckt mich noch mehr als die Angst vor Java. Also quasi "aus die Maus" mit Delphi und "ran an den Java-Speck".

Ich kann mir auch sehr gut vorstellen, dass Andere genauso enttäuscht sind :roll:

[arnof]

Zitat:

Zitat von mkinzler (Beitrag 1228107)

Zitat:

Das heisst dann aber grundsätzlich, das viele Android-Tablet-User aussen vor sind und das die Anwendung - sofern dann Intel und MIPS-Support kommen - noch größer werden.

Dies kommt dann mit XEnnn :mrgreen:

Seit ca. 10 Jahren arbeiten sie an einer Front-/Backend Lösung des Compilers, der scheint aber nicht fertig zu werden.

Welche Geräte gibt es denn mit Intel oder MIPS ? Ich hatte jetzt mal ein überteuertes Acer Tablet mit Atom und Android gesehen. Wenn Ihr euch mal Apps im Playstore anschaut, dann prüft dieser schon, ob es mit dem Gerät xyz geht oder nicht. Unter Windows sieht man dann den Hinweis:


"Diese App ist mit allen Ihren Geräten kompatibel."

oder

"Diese App ist mit einigen Ihrer Geräte kompatibel."

[RWarnecke]

Zitat:

Zitat von MEissing (Beitrag 1228169)

Zitat:

Zitat von v2afrank (Beitrag 1228089)

Aber auch in der Releasefassung wirds nicht kleiner.

Ein simples "Hello World" ist hier knapp 5 MByte groß.
Darüberhinaus wächst es (erwartungsgemäß) nur marginal.

Auch bei mir ist die APK-Datei nur 5 MB groß.

[Union]

Im Gegensatz zu den paar Kb die eine normale apk hat aber trotzdem noch 125x größer und auch langsamer.

[Der schöne Günther]

Ich bin verwirrt. Werden die Anwendungen noch auf Floppys und über 56k-Leitungen ausgeliefert?

Ich will die fast schon kochende Stimmung nicht noch weiter aufheizen, aber wo ist denn bitte das Problem bei fünf MB? Werden in dem Google App Store die Dateigrößen eingeblendet und ab fünf MB knallrot in Warnfarbe markiert?

Gab es das auch, als man hier das erste mal gesehen hat, dass .NET-Anwendungen viel kleiner sind als Delphi-Programme?

[Union]

Es ist ja auch eine Frage der Ladezeiten.

[RWarnecke]

Zitat:

Zitat von Smut (Beitrag 1228210)

Zitat:

Zitat von RWarnecke (Beitrag 1228207)

Zitat:

Zitat von MEissing (Beitrag 1228169)

Zitat:

Zitat von v2afrank (Beitrag 1228089)

Aber auch in der Releasefassung wirds nicht kleiner.

Ein simples "Hello World" ist hier knapp 5 MByte groß.
Darüberhinaus wächst es (erwartungsgemäß) nur marginal.

Auch bei mir ist die APK-Datei nur 5 MB groß.

Hast Du mal geguckt, wie groß andere Apps sind? 'Nur' 5 MB, unglaublich.

Ich habe aber nichts an Delphi eingestellt, sondern Delphi so standardmäßig gelassen.

Und in Zeiten von UMTS und LTE ist 5MB doch wirklich nur ein Klacks.

[MEissing]

Die "Facebook" App ist auf meinem Nexus 4 25 MByte groß/klein.
"TankenApp" knappe 15 MByte

Who cares?

[Frankkneffel]

Die APK ist sicherlich "nur" 5MByte groß.
Unter den Einstellungen / Anwendungen verbraucht die Hello World Anwendung 22 MByte. Dass ist mehr als der Amazon Store.
Bei meinem Handy mit arg begrenzten Ram ist das schon eine Hausnummer

[Bernhard Geyer]

Zitat:

Zitat von v2afrank (Beitrag 1228089)

Aber auch in der Releasefassung wirds nicht kleiner.
Ich musste auf meinem Handy erst einmal ein paar andere Anwedungen deinstallieren um mein hello World drauf zu bekommen.:cry:

So ein Ultra-Speicher-Spar-Handy hatte ich auch mal :stupid:

[jensw_2000]

Ladezeiten und Arbeitsspeicherverbrauch werden sich aber -wie fast überall- annähernd proportional zur Anwendungsgröße verhalten.
Ein "riesiges" Application Bundle mit "Hello World" Funktionalität ist genau der Fall, für den Google das NDK nicht vorgesehen hatte. s. Einleitung zum NDK

Und funktionell hüpft man wohl auch wieder auf einer Insel herum ...

[MEissing]

Verstehe den Einwurf nicht.

Bis auf eine erhöhte Komplexität, die es eben mit Delphi nicht gibt, sehe ich keine Gründe das NDK nicht einzusetzen.

Die meisten Spiele nutzen auch das NDK.... Es scheint also einen Bedarf zu geben.

Das mit der Delphi-Werkzeugkette dadurch auch ARC auf Android umgesetzt wurde, hat auch durchaus Vorteile bei speicherintensiven Anwendungen. Java Apps auf Android können nur maximal 24 MB (in einigen Situationen auch nur 16 MB) allokieren. Inklusive Ressourcen, wie Grafiken etc....

Und natürlich lassen sich auch von nativem (Delphi/Android) Code Java-SDK Funktionen aufrufen.

[jensw_2000]

Zitat:

Zitat von MEissing (Beitrag 1228259)

Verstehe den Einwurf nicht.

Bis auf eine erhöhte Komplexität, die es eben mit Delphi nicht gibt, sehe ich keine Gründe das NDK nicht einzusetzen.

Und die beiden Folgesätze?

Zitat:

In general, you should only use the NDK if it is essential to your app—never because you simply prefer to program in C/C++.

Typical good candidates for the NDK are self-contained, CPU-intensive operations that don't allocate much memory, such as signal processing, physics simulation, and so on.

[Daniel]

Wenn man von Hand eine Android-App erstellen möchte, kommt man mit Java und Eclipse bestimmt schneller zu Ziel, als wenn man sich von Hand mit dem NDK befassen muss. So sind o.g. Zitate zu verstehen. Die Delphi-IDE hingegen nutzt das NDK als Toolchain und der Entwickler hat damit gar nichts am Hut.
Man darf die Zielsetzungen nicht vernachlässigen: XE5 eröffnet dem Delphi-Entwickler die Plattform Android. Und dass eine NDK-App per se schlechter sein soll, ist bislang nicht belegt. Einmal auf dem Smartphone angekommen, stellt sich für den Anwender auch kein Unterschied zwischen NDK- und SDK-App dar.

[MEissing]

Zitat:

Zitat von Daniel (Beitrag 1228262)

Wenn man von Hand eine Android-App erstellen möchte, kommt man mit Java und Eclipse bestimmt schneller zu Ziel, ...

...wenn man denn Java kann/lernen_will.

[v2afrank]

So eine Nacht drüber geschlafen.

Ich habe mich sicherlich schlecht ausgedrückt. Wie Ihr bereits festgestellt habt ist die APK Datei ca. 5 MByte groß. Installiert braucht es auf meinem Handy gut 22 MByte. Das finde ich den richtigeren Vergleich. Wenn ich die Größe von zwei Dateien vergleichen möchte Zippe ich die normalerweise ja auch nicht und vergleiche dann das Ergebnis. Außerdem weiß ich normalerweise später nicht mehr wie groß die APK ist sondern sehe nur den Speicherverbrauch der Anwendung unter den Einstellungen von Android. Und da ist die Hello World nun mal mit eine der Größten.

Who Cares. Es scheint ja doch einige zu interessieren. Ich habe gestern einem Studenten der momentan bei uns am Arbeiten ist gezeigt wie einfach ein Hello World zu realisieren ist. Davon war er wirklich beeindruckt. Wir haben das dann auf sein Handy gespielt um ihm zu zeigen dass es da auch läuft. (Funktionierte einwandfrei). Später fing er allerdings an zu lachen und fragte nur warum die Anwendung denn so groß ist.
Auch haben noch viele die ich kenne einen stark begrenzenten Internetzugang und die achten vielleicht doch auf die Größe. Ich kann mich an eine Meldung vom Playstore erinneren die Sinngemäß lautete die Anwendung die ich herunterladen möchte ist sehr groß. Ob ich dass nicht lieber machen möchte wenn ich eine WLan Verbindung habe. Es scheint also doch eine Art Alarmzeichen zu geben.


Trotzdem, die Funktion ist ja gegeben und wenn ich eine App mit entsprechenden Funktionsumfang schreibe fragt sicherlich auch keiner mehr nach der Größe. Die Frage ist dabei höchsten noch wie die Größe sich zum Funktionsumfang im Vergleich zu anderen IDEs verhält.
Ich würde mit Delphi sicherlich keine Minianwendungen wie die Xte-Taschenlampe schreiben(, obwohl doch gerade der RAD Ansatz meiner Meinung nach für solche Anwendungen einzigartig ist). Bei diesen Anwendungen wird die Frage nach der Größe sicherlich gestellt werden
Zu umfangreicheren Anwendungen kann ich mir Delphi schon vorstellen, wobei man dann noch mal auf das Laufzeitverhalten achten muß. Bei dem Android-Shop habe ich mich noch nie gefragt warum der so groß ist

[Union]

Also eigentlich sollte das nicht so groß sein. Es sei denn, die Debug-Informationen werden DOCH auf das Gerät übertragen. Ich habe den Versuch mal gemacht und das lib<ProjName>.so file umbenannt (das ist 18MB groß). Die Anwendung läuft trotzdem.

/data/app/com.embarcadero.Helloworld-1.apk 5891586
/data/app-lib/com.embarcadero.HelloWorld-1/libHelloWorld.so 18033212