Firemonkey vs. Xamarin

[Phoenix]

Zitat:

Zitat von cookie22 (Beitrag 1263416)

Zitat:

Zitat von MEissing (Beitrag 1263354)

Wer mehr will, kann sich ja mal den C++Builder anschauen.

Verkauft sich der C++ Builder überhaupt noch? Ich frag das hier nicht um irgendwie zu flamen oder sonst etwas, aber nutzt nicht jeder der unter Windows mit C++ arbeitet VS + QT?

Ich glaube, als DPler haben wir da einen gewissen vorbelasteten Standpunkt. Wenn ich das aber richtig verstanden habe ist die C++ Builder Gemeinde um einiges größer als die Delphi-Gemeinde, die Jungs sind nur nicht so Publikumswirksam in Foren etc. organisiert.

[mquadrat]

Wir verwenden für Apps aktuell die Paarung: Ionic + Angular + Cordova/Crosswalk (Sprich: Hybrid Apps)

Auf iOS alles wunderbar, auf Android < 4 problematisch bis nicht vertretbar, ab 4 mit Crosswalk auch gut auf Android.

[vagtler]

Zitat:

Zitat von MEissing (Beitrag 1263354)

[...] Die Kunden rennen uns die Bude ein, weil wir es so machen, wie wir es machen. [...]

Gibt es da auch belastbare Zahlen zu?

[Robotiker]

Zitat:

Zitat von Phoenix (Beitrag 1263421)

Zitat:

Zitat von cookie22 (Beitrag 1263416)

Verkauft sich der C++ Builder überhaupt noch? Ich frag das hier nicht um irgendwie zu flamen oder sonst etwas, aber nutzt nicht jeder der unter Windows mit C++ arbeitet VS + QT?

Ich glaube, als DPler haben wir da einen gewissen vorbelasteten Standpunkt. Wenn ich das aber richtig verstanden habe ist die C++ Builder Gemeinde um einiges größer als die Delphi-Gemeinde, die Jungs sind nur nicht so Publikumswirksam in Foren etc. organisiert.

Ich bin mir nicht sicher. Habe zu Schulzeiten mit Delphi und Borland C++ angefangen und bin beruflich im Embedded/Automotive/Automatisierungsbereich unterwegs. Traditionell arbeiten da viele PC-seitig mit dem C++ Builder, weil sich das von Borland C++ her kommend so ergeben hat. MS hatte zu frühen C++ Zeiten nicht den besten Ruf.

Heute sehe ich bei vielen Firmen doch eher VS oder Qt Creator, seltener Netbeans oder EclipseCDT. Wenn C++ Builder, dann meist 5 oder 6. Jemand der FireMonkey einsetzt, ist mir da noch nicht begegnet.

Wenn man in C++ Cross Plattform arbeitet, nervt die Rückständigkeit des 32 Bit Compilers von Emba dann doch sehr. Der 64-Bit Compiler basiert zwar auf Clang, aber da auch nicht auf der aktuellen Version. Außerdem, wenn man auf jedem Linux Clang umsonst hat und Google heftig an Clang für VS schraubt, warum soll man den dann noch zusätlich kaufen ?

Wenn Emba jede Menge neue C++ Entwickler die Türe einrennen, ist das schön für sie. Es hält das Produkt am Leben. Aber mir begegnen die nicht, offenbar ist das eine ganz andere Zielgruppe.

[Bernhard Geyer]

Zitat:

Zitat von Phoenix (Beitrag 1263421)

Ich glaube, als DPler haben wir da einen gewissen vorbelasteten Standpunkt. Wenn ich das aber richtig verstanden habe ist die C++ Builder Gemeinde um einiges größer als die Delphi-Gemeinde, die Jungs sind nur nicht so Publikumswirksam in Foren etc. organisiert.

Bezweifle ich das die C++-Builder-Gemeinde relativ groß ist.
Da werden schon viele über die Jahr richtung QT/VS/... gewechselt sein.

[greenmile]

Das denke ich leider auch. Ich finde im Umfeld relativ selten einen CBuilder auf einem Desktop. Größtenteils sind es Visual Studios. Traurig finde ich, dass viele von Delphi kommen.

[Dejan Vu]

Zitat:

Zitat von greenmile (Beitrag 1263437)

... Traurig finde ich, dass viele von Delphi kommen.

Wenn man nicht religionsartig einer IDE/Programmiersprache anhängen, sondern objektiv das jeweils beste Werkzeug auswählen würde, wäre man nicht traurig, sondern höchstens erstaunt oder bemerkenswert.

Ich habe kein persönliches Verhältnis zu einer Programmierumgebung. Es ist ein Werkzeug und es muss mir die Arbeit erleichtern. Ich will produktiv sein und mit der Zeit mitgehen können. Wiederkehrende, eintönige Arbeiten muss es mir abnehmen. Bietet mir das Werkzeug das nicht, wechsle ich. Dies war der Hauptgrund, vor 15(?) Jahren *zu* Delphi zu wechseln.

Sollte ich bei meiner Arbeitsstelle durch Sachzwänge an eine mir nicht besonders genehme IDE gebunden sein, dann finde ich mich damit ab oder schule um und wechsle die Arbeitsstelle. Aber 'traurig' wäre ich höchstens, wenn ich meinen Chef nicht davon überzeugen könnte, ein besseres Werkzeug einzusetzen.

PS: Das ist kein Delphi-Bashing, denn ich kenne die aktuellen Versionen gar nicht und weiß deshalb nicht, wie gut, oder wie grausam diese sind. Es ist vielmehr ein Plädoyer für mehr Objektivität im Umgang mit Werkzeugen allgemein.

[MEissing]

Zitat:

Zitat von vagtler (Beitrag 1263426)

Zitat:

Zitat von MEissing (Beitrag 1263354)

[...] Die Kunden rennen uns die Bude ein, weil wir es so machen, wie wir es machen. [...]

Gibt es da auch belastbare Zahlen zu?

http://www.embarcadero.com/de/press-...elopment-tools
http://www.embarcadero.com/de/press-...demand-doubles

[Dejan Vu]

Es ist immer unglücklich, bei 'belastbaren Zahlen' die eigene Marketingabteilung zu zitieren. ;-) Die würden auch eine Verdoppelung der Verkaufszahlen von 1 auf 2 als '100% Growth' verkaufen. Dazu sind sie schließlich da (und falsch ist es ja nicht).

Aber +34% gesamt, und +100% in Japan und Brasilien ist ja auch nett. Und vorher waren das bestimmt mehr als 3.

[D-User]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1263435)

Bezweifle ich das die C++-Builder-Gemeinde relativ groß ist.

soweit ich erinnere, hat ehemals Borland C++-Builder früher immer nach Delphi bedient, zudem sind die Beispiel-Codeschnipsel für Delphi immer um ein Vielfaches mehr.
Daraus schliess ich dass C++ Builder sehr deutlich weniger Installs hatte als Delphi.

Der wesentlichste Vorteil des C++-Builder gegenüber anderen C++-Tools war/ist ja aus meiner Sicht dass man die Delphi-Komnponenten verwenden kann.

[MEissing]

Zitat:

Zitat von Dejan Vu (Beitrag 1263448)

Es ist immer unglücklich, bei 'belastbaren Zahlen' die eigene Marketingabteilung zu zitieren. ;-)

Hey... du fragst den Hersteller..... der wird keine "schlechten" Zahlen präsentieren wollen </private Meinung>

[mkinzler]

Zitat:

Zitat von MEissing (Beitrag 1263452)

Zitat:

Zitat von Dejan Vu (Beitrag 1263448)

Es ist immer unglücklich, bei 'belastbaren Zahlen' die eigene Marketingabteilung zu zitieren. ;-)

Hey... du fragst den Hersteller..... der wird keine "schlechten" Zahlen präsentieren wollen </private Meinung>

Vorsicht, diese Aussage könnte (falsch?) interpretiert werden. :mrgreen:

[Sherlock]

Wenn es stimmt, das FMX-apps deutlich mehr Strom fressen, dann dürfte das hier ein kleiner Stolperstein werden: http://www.heise.de/newsticker/meldu...b-2238474.html
Klein, weil (unter iOS zumindest) Apps im Hintergrund ohnehin nicht sooo viel machen dürfen.

Sherlock

[vagtler]

Zitat:

Zitat von Sherlock (Beitrag 1263515)

[...] Klein, weil (unter iOS zumindest) Apps im Hintergrund ohnehin nicht sooo viel machen dürfen. [...]

Naja, zumindest LBS sind damit dann quasi ein Ding der Unmöglichkeit. Könnte für den ein oder anderen in Zukunft nicht uninteressanten Use Case ein absoluter Show Stopper sein.

[jensw_2000]

Zitat:

Zitat von Sherlock (Beitrag 1263515)

Wenn es stimmt, das FMX-apps deutlich mehr Strom fressen, dann dürfte das hier ein kleiner Stolperstein werden: http://www.heise.de/newsticker/meldu...b-2238474.html
Klein, weil (unter iOS zumindest) Apps im Hintergrund ohnehin nicht sooo viel machen dürfen.
Sherlock

Das ist ganz human gelöst. Abschießen hört sich da etwas "grob" an :)
Ich habe das bei einer Navi App zum ersten mal gesehen. Lässt man Diese aktiv im Hintergrund laufen und vergisst Sie, dann sagt iOS irgendwann nach längerer Zeit "Die App <Navi...> wurde im Hintergrund angehalten, um Akku zu sparen. Mehr passiert da nicht.

FM Apps, die normal im Hintergrund sind und keine Rechenzeit anfordern, werden davon vermutlich nicht betroffen sein. Die spielen im Hintergrund ja keine OpenGL Fullscreen Animation ab (Andere nennen das Cocoa Style UI).

Problematisch ist es im Businessbereich, wenn die Apps im Vordergrund Akku fressen wie S.. .

Ich habe damals einen MDE Client (mobile Datenerfassung) für ein Unternehmen geschrieben, dass ich zuerst mit FMX lösen wollte. Das ging garnicht. Abgesehen von den FMX Problemen damals, war das Arbeiten mit der FMX App auch unmöglich. Ein iPad Akku war in wenigen Stunden Dauerbenutzung leer. Der Kunde hätte für seine 10 "Datenerfasser" 20 iPads kaufen müssen, damit alle Leute durch die Schicht kommen. :wink:
FMX habe ich dann sehr schnell komplett verworfen.
Mit einer echten Cocoa App halten die iPad Akkus jetzt 2-3 Tage. Das ist ein andere Schnack.

Klar. Solche Probleme treffen keinen FMX Entwickler, der die 1000ste "Ja/Nein/Vielleicht Zufallsgenerator App" schreibt oder einen Einheiten Konverter oder Mehrwertsteuerrechner usw.
Diese Sachen werden von den Usern nur wenige Sekunden benutzt und dann bis zum nächsten mal beendet. Das sind aber aus meiner Sicht keine echten Business Apps.

[greenmile]

Das Strom-Problem kann ich bestätigen. Ich hatte mich erst gewundert, wieso der Akku von nem 2 Wochen alten iPad Air über Nacht leergesaugt war (Abends 19 Uhr hatte es noch 87%, morgens um 7 Uhr waren es nur noch 4%). Die App lief im Hintergrund, das iPad-Display war aus. Die Anwendung hat nix gemacht, also nur eine Form mit eingen Labels, Buttons, das war's.

Unter Android isses nicht ganz so krass, allerdings nervt es, dass man dort theoretisch Anwendungen beenden kann, es aber in der Praxis kaum funktioniert.

[Phoenix]

Zitat:

Zitat von greenmile (Beitrag 1263523)

Unter Android isses nicht ganz so krass, allerdings nervt es, dass man dort theoretisch Anwendungen beenden kann, es aber in der Praxis kaum funktioniert.

Das Problem stellt sich nicht, wenn man sich auf seine Ziel-Plattform einlässt und sich an die Gegebenheiten der Umgebung hält. Die App-Lifetime wird dort nunmal vom OS kontrolliert, und wenn man seine Anwendung darauf anpasst und damit rechnet, dann kommt auch was raus was sich sauber auf Android einfügt und sich nicht wie ein (bösartiger) Fremdkörper aufführt.

[greenmile]

Zitat:

Zitat von Phoenix (Beitrag 1263528)

Zitat:

Zitat von greenmile (Beitrag 1263523)

Unter Android isses nicht ganz so krass, allerdings nervt es, dass man dort theoretisch Anwendungen beenden kann, es aber in der Praxis kaum funktioniert.

Das Problem stellt sich nicht, wenn man sich auf seine Ziel-Plattform einlässt und sich an die Gegebenheiten der Umgebung hält. Die App-Lifetime wird dort nunmal vom OS kontrolliert, und wenn man seine Anwendung darauf anpasst und damit rechnet, dann kommt auch was raus was sich sauber auf Android einfügt und sich nicht wie ein (bösartiger) Fremdkörper aufführt.

Unter Android lassen sich App's beenden und viele nutzen das. Ist nunmal so, selbst einige Google-eigenen Programme lassen sich beenden. Es war vielleicht mal oder ist auf dem Papier immer noch so dass man die App's nicht beenden kann/soll. Aber in der Praxis kann man App's beenden, zumindest unter Android. Und nur weil man es "halt nicht macht" entschuldigt in meinen Augen nicht, dass es FMX nicht kann.

[Phoenix]

Das ist die *einzige* Sache, bei der sich FMX mal wenigstens einigermassen Plattform-Konform verhält, und das wird dem dann angekreidet :roll:

[greenmile]

It's not a bug, it's a Feature :-D

[stahli]

Ich bleibe mal hier im Thread obwohl es nicht 100%ig passt...

Gerade sehe ich mich mal unter C# um und das sieht wirklich sehr durchdacht aus.
Wer mal schnell über den Delphi-Tellerrand schauen will sollte sich mal den zweiten Kurs auf der folgenden Seite ansehen: http://channel9.msdn.com/Series/Visu...uer-Einsteiger.
Das wirkt m.E. schon sehr aufgeräumt.

Zumindest bin ich jetzt der Meinung, dass ich nicht so zwanghaft am gewohnten festhalten hätte sollen (und vermutlich Geld, Zeit und Ärger hätte sparen können) ...

[Wunni]

Zitat:

Zitat von stahli (Beitrag 1264509)

Ich bleibe mal hier im Thread obwohl es nicht 100%ig passt...
...

Zumindest bin ich jetzt der Meinung, dass ich nicht so zwanghaft am gewohnten festhalten hätte sollen (und vermutlich Geld, Zeit und Ärger hätte sparen können) ...

Das ist richtig! Visual Studio ist aktuell die beste IDE und mit dem Packagemanager Nuget noch viel mehr...
Noch heute gibt es Updates für VS2010, obwohl es schon lange VS2012 und VS2013 gibt. Du kannst Dein VS also auch noch Jahre später nutzen und bleibst nicht auf Fehlern und unvollständigen Implementierungen sitzen!
Ich habe fast 2 Jahrzehnte die Delphi Fahne hochgehalten und mir nicht vorstellen können, dass es etwas besseres gibt. Nach dem Blick über den Tellerrand musste ich feststellen, dass eigentlich fast alles was ich getestet habe besser ist. Ob Visual Studio, Xamarin, Lazarus mit Cross-Compilern oder XCode mit Objective-c.

Wenn jetzt noch der Compiler für .NET Native kommt und Apple sein Swift herausbringt wird es mich nicht einmal viel bzw. garnichts kosten.
Eigentlich war es garnicht Delphi, was mich immer so überzeugte, sondern die Lösungen und Ideen von Anders Hejlsberg...

[fgsoftware]

@stahli @Wunni


Spekulation: Microsoft will sich Xamarin einverleiben


http://www.mycsharp.de/wbb2/thread.php?postid=3755866

:bounce2:

[Phoenix]

Zitat:

Zitat von fgsoftware (Beitrag 1264531)

@stahli @Wunni
Spekulation: Microsoft will sich Xamarin einverleiben
http://www.mycsharp.de/wbb2/thread.php?postid=3755866
:bounce2:

Da ist nichts dran. Miguel Deicaza verkauft nicht, auch wenn Microsoft es vermutlich gerne hätte.

Die Gerüchte stammen vom Frühjahr und es wurde spekuliert, das das auf der BUILD angekündigt würde, aber da wurde nichts draus. Microsoft ist sich der Macht und der Möglichkeiten von Xamarin durchaus bewusst und kooperieren daher sehr intensiv mit Xamarin.

Sowohl Roslyn als auch ASP.NET vNext zum Beispiel werden offiziell gegen Mono getestet. Microsoft stellt viele der Windows Phone 8 Libraries als Mono-Taugliche PCL's auch für Android und iOS mit Xamarin zur Verfügung.

Die Zukunft sieht also sehr rosig aus.

[Harry Stahl]

Zitat:

Zitat von Wunni (Beitrag 1264524)

Ich habe fast 2 Jahrzehnte die Delphi Fahne hochgehalten und mir nicht vorstellen können, dass es etwas besseres gibt. Nach dem Blick über den Tellerrand musste ich feststellen, dass eigentlich fast alles was ich getestet habe besser ist. Ob Visual Studio, Xamarin, Lazarus mit Cross-Compilern oder XCode mit Objective-c.

Wie unterschiedlich doch die Eindrücke sein können. Mit Xamarin habe ich zwar keine Erfahrungen, aber mit Lazarus sehr wohl. Grundsätzlich finde ich es beeindruckend, was die Lazarus-Gemeinde da zustande gebracht hat. Wenn man etwas für Linux entwickeln will (was sich allerdings bei ca. 1,6% Marktanteil kaum lohnt), ist es schön, dass man Lazarus verwenden kann, auch für OSX X kann man brauchbare Ergebnisse erzielen.

Aber im direkten Vergleich zu Delphi nach meiner Einschätzung:

Delphi ist Lazarus in der aktuellen Version XE6 um Lichtjahre voraus.

Wer mit Lazarus arbeiten will, muss Kampfkraft und Durchhaltevermögen mitbringen. Das gilt sowohl für die Installation und auch für die Benutzung von Lazarus. Kompatibilitätsbrüche gab es auch in der Vergangenheit bei Lazarus. Die Indys für Lazarus gibt es seit Jahren und haben seit Jahren nicht richtig funktioniert. Um neue Komponenten zu installieren, die ganze Entwicklungsumgebung neu kompilieren? Ein Unding.

Was man für Android mit Lazarus machen kann, ist auch noch äußerst bescheiden, auch hier kommt Lazarus nicht im Ansatz an die Möglichkeiten von Delphi ran. Es fehlen bei Lazarus auch über die Crosscompile-Systeme viele Komponenten, die Delphi schon lange hat.

IOS-Programme direkt in Lazarus entwickeln? Fehlanzeige (nur über X-Code-Verbindungen und das alles sehr umständlich und bescheiden).

Zu Xamarin: Da C#: Keine Sache für mich, mit C werde ich mich nicht mehr anfreunden.
Visual Studio: Aus diesem Grunde ebenfalls keine Alternative für mich.

Man sieht: Auch wenn man über den Tellerrand blickt, kann man sehr wohl glücklich und zufrieden mit Delphi sein.

OK, über die Produktpolitik kann man reden. Kaufanreize sollten über neue Funktionen und Fähigkeiten kommen und nicht über Zwang zur Fehlerkorrektur. Für mich ist das zwar kein Ding, da ich mir sowieso jede neue Delphi-Version hole. Bestimmte Produkte muss ich aber zeitweise mit älteren Delphi-Versionen weiterentwickeln, z.B. weil es noch keine benötigten Drittkomponenten für die neueren Delphi-Versionen gibt. Insofern haben auch Anwender, die immer die neueste Delphi-Version haben ein berechtigtes Interesse an der Fehlerkorrektur für ältere Delphi-Versionen.

Aber das ist lange noch kein Grund, mich von Delphi zu verabschieden. Im Gegenteil, ich sehe, dass Delphi sich rapide entwickelt, neue Fähigkeiten, viele Demos, viele Videos zur App-Entwicklung, immer auf dem neuesten Stand bei IOS und Android. Ich bleibe dabei und freue mich auf das was da noch kommt.:thumb:

[jensw_2000]

Zitat:

Zitat von Harry Stahl (Beitrag 1264612)

immer auf dem neuesten Stand bei IOS und Android.

Räusper ...

Ganz vorsichtig gefragt.
Du kennst als überzeugter Delphi FMX Entwickler wirklich den neuesten Stand bei der iOS Entwicklung?
Dann beschäftigst Du dich aber viel mit Xcode, Objective-C und Swift.
Oder breschränkt such das Know How nur darauf, den ansatzweise passenden iOS Skin zur Hand zu haben?

[jensw_2000]

Zitat:

Zitat von MEissing (Beitrag 1263046)

Wir unterstützen durchaus Community-Mitglieder mit kostenfreien Versionen..... wenn diese denn auch konstruktiv und positiv etwas zur Community beitragen.

Hey,
das habe ich von Delphi 3 bis XE2 gemacht.
Abgeledert wurde ich dennoch von Jahr zu Jahr.

[greenmile]

Zitat:

Zitat von jensw_2000 (Beitrag 1264616)

Oder breschränkt such das Know How nur darauf, den ansatzweise passenden iOS Skin zur Hand zu haben?

Entwicklung hat nur indirekt etwas mit der Oberfläche an sich zu tun, die ist erstmal nur für Input/Output zuständig. Wichtig ist die Logik im Programm und die kann von C#, C oder sonstwoher kommen. Der Weg ist das Ziel und ich muss als FMX Skeptiker leider zugeben: Mit XE6 geht das schnell und einfach. Bekomme ich mit keiner anderen Sprache so schnell hin. Hört sich hart an, ist aber so. Ich habe in 4 Wochen ein umfangreiches Projekt (kein Hello World) für Windows, Mac, iOS und Android erstellt. Ja, hier und da sieht es nicht nativ aus und das ist natürlich unschön, aber hey: Hat sich WinAmp an die Guidelines gehalten? Netscape? Die Top 10 der Appstore-App's? Das interessiert doch fast niemanden. Aber, und das ist wichtig: Alles läuft und ich musste nicht irgendeine # Sprache dazu lernen. Was will ich mehr?

Einzig die Produktpolitik von Embar stört massiv. Mich trifft es nicht ganz so hart, weil ich jede Version dank Wartung bekomme. Aber manche Bugs sind peinlich und ich frage mich, wie sowas durch die QS rutschen konnte. Aber Delphi an sich ist mit XE6 wieder rund(er) geworden. Muss ich ja leider zugeben. Ich verdiene mein Geld indirekt mit Delphi und einfacher/mehr würde es auch mit Java, C, C# oder sonstwas nicht werden, im Gegenteil: Der Aufwand ist immens höher.

Ich habe eher das Gefühl das händeringend nach Gründen und Erklärungen gesucht wird, weshalb Delphi zum 1000ten Mal kurz vor dem Tod steht. C# ist besser. Lazarus ist besser. Java ist besser. Haben wir alles schon gehört. Objektiv betrachtet sprechen für mich nur 3 Dinge gegen Delphi:

A: Die Qualität (da ist MS nunmal um längen besser)
B: Die Update-Politik (alte Versionen werden nicht mehr gepflegt)
C: Microsoft Entwicklungsumgebungen und Sprachen sind die Zukunft. Dank A: und B:

Lazarus nehme ich, sorry, nicht ernst, das ist ein sicherlich spannendes, aber nicht Produkt einsetzbares Hobby-Projekt. Ich ziehe meinen Hut, es ist wirklich sehr sehr spannend. Aber arbeiten möchte ich damit nicht. Habe ich x-mal versucht (auf der Suche nach einer Alternative zu Delphi) und ganz schnell wieder verworfen. Da gilt für mich: Habe ich das Geld, dann hole ich das Original. Ansonsten Lazarus.

[vagtler]

Zitat:

Zitat von Harry Stahl (Beitrag 1264612)

[...] Da C#: Keine Sache für mich, mit C werde ich mich nicht mehr anfreunden. [...]

Nur mal kurz angemerkt: C# ist näher an Delphi als an C.

[Phoenix]

Zitat:

Zitat von greenmile (Beitrag 1264622)

Ja, hier und da sieht es nicht nativ aus und das ist natürlich unschön, aber hey: Hat sich WinAmp an die Guidelines gehalten? Netscape? Die Top 10 der Appstore-App's? Das interessiert doch fast niemanden.

Doch. Schau Dir die Top 10 Selling der Apps (nicht Games) der jeweiligen Plattformen doch mal intensiver an, und auch deren jeweilige Konkurrenten.

Für jede dieser Apps wird es sicher etliche Alternativen geben, die ein besseres Featureset haben, billiger sind oder sonst besser. Aber diese Alternativen halten sich nicht so sehr an die jeweiligen Plattform-Guideleines.
Was ist das Ergebnis? Obwohl die Apps die sich an die Guidelines halten teurer und schlechter sind, verkaufen sie sich um längen besser. Weil sie genutzt werden.

Umkehrschluss: "Das interessiert doch fast niemanden" ist einfach falsch. Es interessiert sogar die breite Masse, und das sind nunmal die, von deren Geld ein App-Entwickler lebt.

[Daniel]

Zitat:

Zitat von Phoenix (Beitrag 1264627)

Umkehrschluss: "Das interessiert doch fast niemanden" ist einfach falsch. Es interessiert sogar die breite Masse, und das sind nunmal die, von deren Geld ein App-Entwickler lebt.

Wie kommst Du zu dieser Aussage?
http://www.apple.com/de/itunes/charts/paid-apps/

Eine App muss "gut" bedienbar sein - mit den klassischen UI-Guidelines hat das aber nur noch am Rande zutun. Kaum eine der im o.g. Link gelisteten Apps verfügt über eine klassische Oberfläche, die den Guidelines entspricht. Und das sind die kostenpflichtigen Apps.

[jensw_2000]

Zitat:

Zitat von Daniel (Beitrag 1264628)

Zitat:

Zitat von Phoenix (Beitrag 1264627)

Umkehrschluss: "Das interessiert doch fast niemanden" ist einfach falsch. Es interessiert sogar die breite Masse, und das sind nunmal die, von deren Geld ein App-Entwickler lebt.

Wie kommst Du zu dieser Aussage?
http://www.apple.com/de/itunes/charts/paid-apps/

Eine App muss "gut" bedienbar sein - mit den klassischen UI-Guidelines hat das aber nur noch am Rande zutun. Kaum eine der im o.g. Link gelisteten Apps verfügt über eine klassische Oberfläche, die den Guidelines entspricht. Und das sind die kostenpflichtigen Apps.

Habe sie jetzt fast alle durchgeklickt. Bei sehr vielen "Nicht-Game Apps" ist gut zu sehen, dass die UI auf Cocoa Touch basiert. Ob das unter dem Strich dazu geführt hat, dass diese Apps zum Topseller geworden sind?
Who knows ...

Meine persönlichen Erfahrungen aus meinen Kundenprojekten / Auftragsarbeiten sind:
Das eine FMX Projekt musste ich nach viel investierter Arbeit komplett verwerfen, weil die FMX "Rendered iOS Skin OpenGL UI" unverhältnismäßig viel Strom verbraucht hat. Der Kunde hätte die App daher nie produktiv nutzen können.
Bei einer anderen App kam der Kunde mit seinem iPhone zu mir und zeigte mir eine App die auf dem UIPageViewController basiert, und wollte eine "Katalog App" mit genau so einem coolem echt anfühlendem Curl Effekt und den leicht transparenten "Blatt Rückseiten". Das war mit FMX damals nicht lösbar. Heute vermutlich auch nicht (zumindest mit vertretbarem Zeitaufwand).
Beide Projekte waren nach dem Konsumieren von ein paar iOS Einsteiger Entwicklervideos sehr komfortabel umsetzbar. Mit Oxygene, echter Cocoa Touch UI und Pascal als Sprache.

[Phoenix]

^^ What he said. :thumb:

[vagtler]

Zitat:

Zitat von jensw_2000 (Beitrag 1264633)

[...] Mit Oxygene, echter Cocoa Touch UI und Pascal als Sprache.

:thumb:

[Wunni]

Zitat:

Zitat von Harry Stahl (Beitrag 1264612)

Zitat:

Zitat von Wunni (Beitrag 1264524)

Ich habe fast 2 Jahrzehnte die Delphi Fahne hochgehalten und mir nicht vorstellen können, dass es etwas besseres gibt. Nach dem Blick über den Tellerrand musste ich feststellen, dass eigentlich fast alles was ich getestet habe besser ist. Ob Visual Studio, Xamarin, Lazarus mit Cross-Compilern oder XCode mit Objective-c.

Wie unterschiedlich doch die Eindrücke sein können. Mit Xamarin habe ich zwar keine Erfahrungen, aber mit Lazarus sehr wohl. Grundsätzlich finde ich es beeindruckend, was die Lazarus-Gemeinde da zustande gebracht hat. Wenn man etwas für Linux entwickeln will (was sich allerdings bei ca. 1,6% Marktanteil kaum lohnt), ist es schön, dass man Lazarus verwenden kann, auch für OSX X kann man brauchbare Ergebnisse erzielen.

Aber im direkten Vergleich zu Delphi nach meiner Einschätzung:

Delphi ist Lazarus in der aktuellen Version XE6 um Lichtjahre voraus.

Wer mit Lazarus arbeiten will, muss Kampfkraft und Durchhaltevermögen mitbringen. Das gilt sowohl für die Installation und auch für die Benutzung von Lazarus. Kompatibilitätsbrüche gab es auch in der Vergangenheit bei Lazarus. Die Indys für Lazarus gibt es seit Jahren und haben seit Jahren nicht richtig funktioniert. Um neue Komponenten zu installieren, die ganze Entwicklungsumgebung neu kompilieren? Ein Unding.

Was man für Android mit Lazarus machen kann, ist auch noch äußerst bescheiden, auch hier kommt Lazarus nicht im Ansatz an die Möglichkeiten von Delphi ran. Es fehlen bei Lazarus auch über die Crosscompile-Systeme viele Komponenten, die Delphi schon lange hat.

IOS-Programme direkt in Lazarus entwickeln? Fehlanzeige (nur über X-Code-Verbindungen und das alles sehr umständlich und bescheiden).

Zu Xamarin: Da C#: Keine Sache für mich, mit C werde ich mich nicht mehr anfreunden.
Visual Studio: Aus diesem Grunde ebenfalls keine Alternative für mich.

Man sieht: Auch wenn man über den Tellerrand blickt, kann man sehr wohl glücklich und zufrieden mit Delphi sein.

OK, über die Produktpolitik kann man reden. Kaufanreize sollten über neue Funktionen und Fähigkeiten kommen und nicht über Zwang zur Fehlerkorrektur. Für mich ist das zwar kein Ding, da ich mir sowieso jede neue Delphi-Version hole. Bestimmte Produkte muss ich aber zeitweise mit älteren Delphi-Versionen weiterentwickeln, z.B. weil es noch keine benötigten Drittkomponenten für die neueren Delphi-Versionen gibt. Insofern haben auch Anwender, die immer die neueste Delphi-Version haben ein berechtigtes Interesse an der Fehlerkorrektur für ältere Delphi-Versionen.

Aber das ist lange noch kein Grund, mich von Delphi zu verabschieden. Im Gegenteil, ich sehe, dass Delphi sich rapide entwickelt, neue Fähigkeiten, viele Demos, viele Videos zur App-Entwicklung, immer auf dem neuesten Stand bei IOS und Android. Ich bleibe dabei und freue mich auf das was da noch kommt.:thumb:

Die Leistung der Lazarus Gemeinde kann man gar nicht hoch genug bewerten. Deine Probleme kann ich nicht nachvollziehen, wahrscheinlich basieren die noch auf einer 0.9.irgendwas. Es gibt verschiedene Möglichkeiten zur Installation und die funktionieren bei mir alle, ob mit den Setups, SVN und selbst compilieren oder auf dem Mac mit "fink"... oder mit CodeTyphon. Ich wollte mit dem Blick über den Tellerrand auch nicht andeuten, dass eine 1.0 Lazarus genau einer 14.0 Delphi entspricht! Obwohl es für Lazarus PAS4IOS gibt, habe ich mich zur iOS Entwicklung für das "kostenlose" XCode/Objective-C/Swift entschieden. Man nimmt einfach für jede Augabenstellung das am besten geeignete Werkzeug.

Fassen wir einmal zusammen:
- du hast Probleme mit Lazarus gehabt
- du kennst Xamarin nicht
- du holst Dir sowieso jede Delphi Version (Strom kommt auch aus der Steckdose)
- du möchtest Dich nicht mit C# anfreunden
- du siehst in Lehrvideos und Demos eine Weiterentwicklung von Delphi

Ich kann aus den Aussagen weder einen Blick über den Tellerrand, noch ein großes Plus für Delphi ableiten.
Sehr gerne hätte ich mit Delphi weiter gearbeitet, aber "Pay for Bugfixes" und die sehr guten Entwicklungsumgebungen anderer Hersteller haben mich eines besseren belehrt.
Diese Erfahrungen wollte ich dem Fragesteller bei seiner Entscheidung mit auf den Weg geben. Es sollte Dich nicht davon abhalten, weiter mit Delphi zu arbeiten!

[Sherlock]

Gerade die Demos, die bei jedem Delphi-Release gerne gebracht werden, empfinde ich mittlerweile nur noch als störend. Leicht getunte "Hello world"s, die lediglich an der Oberfläche kratzen. Wenn man dann mal eines der neuen Features für ein echtes Projekt nutzen möchte, stößt man oft schneller an die Grenzen als einem lieb ist.

Es wäre genial, wenn man sich bei Embarcadero mal die Zeit nähme, eine richtige Anwendung zu entwickeln. Meinetwegen die Fisch-Datenbank um zahlreiche Features erweitert. Die simplen 4-Zeiler, die da immer als Demos geboten werden, sind einfach realitätsfern. Es zeigte sich ja bei FMX schon sehr schnell, daß die Performance sehr zu wünschen übrig ließ. Hätte man bei Emba das Ziel vor Augen gehabt, eine etwas größere Demo vorführen zu müssen, wäre FMX zum Erscheinungsdatum sicherlich weniger wacklig gewesen.

Sherlock

[Dejan Vu]

Zitat:

Zitat von Sherlock (Beitrag 1264646)

Es wäre genial, wenn man sich bei Embarcadero mal die Zeit nähme,...

Wortwahl-Fail ;-) Besser: Es wäre zwingend notwendig....

[stahli]

Zitat:

Zitat von Sherlock (Beitrag 1264646)

Es wäre genial, wenn man sich bei Embarcadero mal die Zeit nähme, eine richtige Anwendung zu entwickeln.

Genau das hatte mir David I auf mein (nachdem mir Emba Germany nicht helfen konnte) persönlich an ihn gerichtetes Feedback zu XE3 Ultimate hin vor 1 1/2 Jahr auch versprochen. Seitdem habe ich auch auf mehrfache Nachfragen und Erinnerungsversuche keine Antwort mehr erhalten.

Ich hatte auch einen m.E. ganz sinnvollen Vorschlag vorgebracht, was als ernsthaftes Testprojekt die Nutzbarkeit der Dephi-Features unter Beweis stellen könnte. Es hätten dadurch die Mängel erkannt werden können und man würde sehen, was mit FMX alles möglich wäre.
Es wäre doch konsequent, wenn ein anerkannter Softwarehersteller, sein eigenes Produkt (mit dem man extrem einfach extrem geniale Programme schreiben kann) für eine (extrem geniale) QC nutzen würde ... :wink:

[vagtler]

Zitat:

Zitat von stahli (Beitrag 1264660)

[...] Es wäre doch konsequent, wenn ein anerkannter Softwarehersteller, sein eigenes Produkt (mit dem man extrem einfach extrem geniale Programme schreiben kann) für eine (extrem geniale) QC nutzen würde ... :wink:

Das stimmt, aber lass uns doch wieder von Embarcadero resp. Delphi sprechen... :duck:

[mquadrat]

Ich bin mal gespannt wie der Plan für AppMethod ausschaut. Aktuell scheint man ja das Kundenpotential eher bei den C++ Entwicklern zu sehen, was unter Umständen gar nicht mal so falsch ist. Auch der Ansatz nicht bei FMX stehen zu bleiben, sondern ein gesamtes Ökosystem aufzuziehen erscheint mir richtig. Die IDE schaut jetzt modern aus, allerdings fehlen noch immer einige Komfort-Features. Wenn Delphi da einfach mitgezogen wird, fände ich das gut.

Wenn ich mich allerdings zwischen AppMethod und Xamarin entscheiden müsste, würde immer Xamarin gewinnen. Nuget inklusive aller enthaltenen Packages ist einfach ein zu gutes Argument. Selbst wenn Emba jetzt auch einen Package-Manager bringt, bleibt immer noch das Problem, dass er bestückt werden muss.