Einstieg in die Android-Entwicklung

[arnof]

kommt immer auf die Art der Anwendung an, ich mache vieles mit Datenbanken!

Wenn ich sehe was das für eine Arbeit ist mit Java das entsprechend zu machen, da hat man in Delphi schon einiges schneller zusammen (unabhängig von der Version).

Für Systemnahe Projekte ist Java sicher die logische Wahl!

[vagtler]

Zitat von arnof:

[...] Für Systemnahe Projekte ist Java sicher die logische Wahl!

Da bin ich nicht ganz d'accord. Für systemnahe Projekte wäre die NDK-Entwicklung mittels C/C++ sicher die logische Wahl, für übliche "native" App-Entwicklung auf Android besteht dann durchaus die Wahl zwischen Java und C#.

Und mit dem auf IntelliJ IDEA basierenden kommenden ADK ist man auch schon durchaus komfortabel unterwegs.

[Morphie]

C# auf Basis von Mono? (Mono for Android, Xamarin?)

[Phoenix]

Zitat von vagtler:

Für systemnahe Projekte wäre die NDK-Entwicklung mittels C/C++ sicher die logische Wahl

Veto.

Siehe hier: http://developer.android.com/tools/sdk/ndk/index.html

Zitat von Google:

Before downloading the NDK, you should understand that the NDK will not benefit most apps. As a developer, you need to balance its benefits against its drawbacks. Notably, using native code on Android generally does not result in a noticable performance improvement, but it always increases your app complexity. 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++.

[Daniel]

Ich würde sagen, das kommt auf die Definition von "systemnah" an. Auch der verlinkte Absatz sagte ja nur, dass man nicht pauschal und ohne Grund zum NDK greifen sollte.

[mkinzler]

@vagtler Und wenn NDK, dann ist es egal ob C++ oder Delphi oder warum sollte dann C++ hier besser sein als Delphi?

Zitat von arnof:

Wir dürfen ja dazu nichts sagen

Lese dir deine NDA nochmal genau durch

Sebastian hat da halt die selbe Meinung wie sein Kollege/Chef http://blogs.remobjects.com/blogs/mh/2013/08/12/p6194

Für (Delphi-)Entwicker die auch (schon) für iOS entwickeln hat die gemeinsame Codebasis unter Verwendung von FM mobil natürlich Vorteile.

[cookie22]

Zitat von mkinzler:

Für (Delphi-)Entwicker die auch (schon) für iOS entwickeln hat die gemeinsame Codebasis unter Verwendung von FM mobil natürlich Vorteile.

Die Frage ist doch wohl wie FM für Android funktionieren wird. Wenn man von dem ausgeht, was uns Emba bisher so geboten hat, bin ich da weniger optimistisch.

Zum Einstieg ist Java wohl gut geeignet und mit IntelliJ IDEA hast du ne wirklich tolle IDE, mit der das Entwickeln richtig Spass macht.

[mkinzler]

Warten wir es ab.

[cookie22]

Ich würde mich freuen, wenn es endlich mal wieder ein solides Produkt gäbe.

[Phoenix]

Zitat von mkinzler:

Sebastian hat da halt die selbe Meinung wie sein Kollege/Chef http://blogs.remobjects.com/blogs/mh/2013/08/12/p6194

Nur zur Info: Ich bin seit über einem Jahr schon nicht mehr offiziell Evangelist bei RO.

Aber als Web- und Mobil-Entwickler, und als Technologieberater, der ich neben meiner Arbeit bei Smarthouse immer noch bin, habe ich etliche Gründe, warum FMX so ziemlich der grundlegend falscheste Ansatz ist den man überhaupt fahren kann in meinem Blog festgehalten:

http://dotnetninja.de/2013/04/why-fi...-of-its-being/
http://dotnetninja.de/2013/07/why-fi...ng-the-second/

Wir haben schon viele Ansätze gesehen und auch etliche ausprobiert. Das einzige was sich am Ende bewährt hat, war jeweils möglichst Plattform-Nativ zu arbeiten.

Das kann durchaus auch über andere Sprachen und native bridges gehen (wie z.B. Xamarin und wie es auch PhoneGap zum Teil erlaubt), das mag Oxygene sein das inzwischen Plattform-Native Backends für so ziemlich alles andere anbietet, und das mag gerne auch FPC oder Delphi sein, solange auf die einzelnen Zielplattformen eingegangen wird und das inhärente Plattform-Konzept für den User jeweils spezifisch aufbereitet wird.

Einheitsbrei funktioniert aus Erfahrung mit einer Userbasis von mehreren Hundertausenden nicht. Die Phonegap-Apps die überall gleich aussehen funktionieren dort, wo sie wenigstens einigermassen nativ aussehen und funktionieren noch relativ gut, schneiden in den AppStores der anderen Plattformen aber unterirdisch ab.

Mal davon abgesehen, das man auf Android im Gegensatz zu iOS nicht wirklich viel Umsatz machen kann, hat es sich für bisher jeden Kunden mehr als gelohnt, den zusätzlichen Aufwand einer echten nativen App in Kauf zu nehmen:

Bei keinem einzigen Kunden hat eine Einheitliche App, über alle Plattformen verteilt, ihre Entwicklungskosten wieder eingespielt. Bei jedem Kunden der hingegen auf native Apps pro Plattform gesetzt hat, wurde das Ziel auf jeder Plattform erreicht.

Diese Erfahrung werden hier einige auch noch machen. Mehr als vor dem falschen Ansatz warnen kann ich hier nicht. Und ich sage es nochmal: Ich rede hier ausschliesslich von einer jeweils guten, auf die Plattform zugeschnittenen User Experience, also dem GUI. Wie viel Code in der Businesslogik zwischen den Plattformen geshared wird, ist davon vollkommen unberührt. Nur je besser die UX auf einer Plattform designed wurde, je besser sie sich in das Grundkonzept des Devices integriert, desto erfolgreicher ist die App.