Physikbuddha
Lt. Commander
- Registriert
- Aug. 2014
- Beiträge
- 1.061
Der TE war seit 4,5 Jahren hier nicht mehr online, ich glaube er wird dir nicht mehr antworten.
Ich kann dir zumindest von meinen Erfahrungen berichten. Ich habe auf Arbeit vor zwei Jahren mit einer App für einen Kunden angefangen. Da ich mich mit C# sehr gut auskenne, habe ich mich für Xamarin entschieden.
Die erste Version der App habe ich mit Xamarin.Forms erstellt. Funktioniert fast wie WPF, und auch da bin ich eigentlich ganz gut dabei. Falls dir das nichts sagt:
Du erstellst alles für die Apps nur einmal. Code, UI, ...
Die UI wird wie WPF mit XML-Schreibweise erstellt, per Datenbindung die Daten reingezogen.
Allerdings habe ich schnell die Grenzen kennen gelernt. Optische Bugs auf iOS oder Android, die ich teilweise nie lösen konnte. Dreckige Workarounds, damit die Apps "nativ" wirken.
Nativ heißt: Apple nutzt in iOS zum Beispiel oft Haarlinien als Separator zwischen Elementen. Da musste ich von nativen Apps einen Screenshot machen, um die Farbe herauszufinden. Dann konnte ich die Linie dreckig selber reinhacken.
Ich möchte an dieser Stelle auf diese Frage von mir auf Stackoverflow verweisen, die ich nie sauber lösen konnte. Das musste ich letztendlich mit einer Art statistikbasierten Ausnahmebehandlung umgehen. Was für ein Dreck. Sowas ist, oder zumindest war, Alltag mit Forms.
Teilweise konnte ich Wünsche nicht umsetzen wie: Da links ist ein Icon, mach das gleiche Icon doch bitte auch rechts rein. Es ging beim besten Willen nicht. Das rechte Icon war immer versetzt.
Vor einem Jahr haben wir dann die Version 2 rausgebracht und sind auf Xamarin.Native umgestiegen.
Jetzt erstelle ich die Benutzeroberflächen doppelt. Für iOS auf dem Mac mit Xcode im Interface Builder, für Android alles mit dem Android-AXML-Designer.
Doppelte Arbeit, aber ich kann alles nativ umsetzen und es schnackelt einfach wesentlich besser.
Dadurch dass ich jetzt freien Zugriff auf die Activities bzw. ViewController, und somit auf die nativen plattformspezifischen Funktionen habe, bin ich in der Umsetzung viel freier. Die App ist kleiner, und vor allem deutlich schneller geworden.
Wermutstropfen: Die Kompilierung für Android dauert teilweise recht lang. Manchmal startet die App nach einer Codeänderung beinahe instantly, manchmal kompiliert sie drei, vier, auch fünf Minuten. Ich empfehle wenigstens einen guten Quad-Core.
Außerdem bricht die Kompilierung gerne mit diversen Fehlern ab, wie "Temp-Datei kann nicht gelöscht werden", "Es kann keine Verbindung zum Debugger hergestellt werden", ... Neukompilieren hilft dann, aber es nervt.
Bei iOS habe ich diese Fehler nicht. Vergiss trotzdem nicht, dass du unbedingt einen Mac brauchst, sonst kannst du keine Apps für iOS erstellen. Bei Xamarin wird der Mac ins Netzwerk eingebunden, und du kannst unter Windows in VS programmieren. Kompiliert wird dann nur auf dem Mac übers Netzwerk.
Unterm Strich kann ich sagen: C# und iOS macht Spaß. Apples Programmierkonzepte machen (meistens) Sinn, und man kann ziemlich gut damit arbeiten. Ich muss mich nicht mit Swift oder gar Objective-C rumschlagen, aber kann trotzdem alle Swift-Tutorials im Internet mit ein bisschen Syntaxwissen umschreiben.
Android nervt, da die Hardware recht schnell limitiert und ruckelt, oder die Programmierkonzepte nerven. So haben ListViews keine native Unterstützung für Sections mit Rows. Activitywechsel kann nur über Intent-Pakete erfolgen, in denen du nur Werttypen wie
Das hat Apple wesentlich eleganter gelöst. Just my two cents.
Android würde ich aufgrund der ständigen Fehlermeldungen vielleicht also lieber richtig nativ umsetzen, Java unterscheidet sich ja nun kaum von C#. Allerdings hast du mit Xamarin ja den riesigen Vorteil:
Teilung des Logikcodes zwischen beiden Apps. Und das sind bei uns ca. 85 %. Da steckt so viel Hyper-Typer drin, dass ich den nie doppelt pflegen wollen würde.
Ist doch mehr geworden, als ich dachte.
Gruß vom Physikbuddha
Ich kann dir zumindest von meinen Erfahrungen berichten. Ich habe auf Arbeit vor zwei Jahren mit einer App für einen Kunden angefangen. Da ich mich mit C# sehr gut auskenne, habe ich mich für Xamarin entschieden.
Die erste Version der App habe ich mit Xamarin.Forms erstellt. Funktioniert fast wie WPF, und auch da bin ich eigentlich ganz gut dabei. Falls dir das nichts sagt:
Du erstellst alles für die Apps nur einmal. Code, UI, ...
Die UI wird wie WPF mit XML-Schreibweise erstellt, per Datenbindung die Daten reingezogen.
Allerdings habe ich schnell die Grenzen kennen gelernt. Optische Bugs auf iOS oder Android, die ich teilweise nie lösen konnte. Dreckige Workarounds, damit die Apps "nativ" wirken.
Nativ heißt: Apple nutzt in iOS zum Beispiel oft Haarlinien als Separator zwischen Elementen. Da musste ich von nativen Apps einen Screenshot machen, um die Farbe herauszufinden. Dann konnte ich die Linie dreckig selber reinhacken.
Ich möchte an dieser Stelle auf diese Frage von mir auf Stackoverflow verweisen, die ich nie sauber lösen konnte. Das musste ich letztendlich mit einer Art statistikbasierten Ausnahmebehandlung umgehen. Was für ein Dreck. Sowas ist, oder zumindest war, Alltag mit Forms.
Teilweise konnte ich Wünsche nicht umsetzen wie: Da links ist ein Icon, mach das gleiche Icon doch bitte auch rechts rein. Es ging beim besten Willen nicht. Das rechte Icon war immer versetzt.
Vor einem Jahr haben wir dann die Version 2 rausgebracht und sind auf Xamarin.Native umgestiegen.
Jetzt erstelle ich die Benutzeroberflächen doppelt. Für iOS auf dem Mac mit Xcode im Interface Builder, für Android alles mit dem Android-AXML-Designer.
Doppelte Arbeit, aber ich kann alles nativ umsetzen und es schnackelt einfach wesentlich besser.
Dadurch dass ich jetzt freien Zugriff auf die Activities bzw. ViewController, und somit auf die nativen plattformspezifischen Funktionen habe, bin ich in der Umsetzung viel freier. Die App ist kleiner, und vor allem deutlich schneller geworden.
Wermutstropfen: Die Kompilierung für Android dauert teilweise recht lang. Manchmal startet die App nach einer Codeänderung beinahe instantly, manchmal kompiliert sie drei, vier, auch fünf Minuten. Ich empfehle wenigstens einen guten Quad-Core.
Außerdem bricht die Kompilierung gerne mit diversen Fehlern ab, wie "Temp-Datei kann nicht gelöscht werden", "Es kann keine Verbindung zum Debugger hergestellt werden", ... Neukompilieren hilft dann, aber es nervt.
Bei iOS habe ich diese Fehler nicht. Vergiss trotzdem nicht, dass du unbedingt einen Mac brauchst, sonst kannst du keine Apps für iOS erstellen. Bei Xamarin wird der Mac ins Netzwerk eingebunden, und du kannst unter Windows in VS programmieren. Kompiliert wird dann nur auf dem Mac übers Netzwerk.
Unterm Strich kann ich sagen: C# und iOS macht Spaß. Apples Programmierkonzepte machen (meistens) Sinn, und man kann ziemlich gut damit arbeiten. Ich muss mich nicht mit Swift oder gar Objective-C rumschlagen, aber kann trotzdem alle Swift-Tutorials im Internet mit ein bisschen Syntaxwissen umschreiben.
Android nervt, da die Hardware recht schnell limitiert und ruckelt, oder die Programmierkonzepte nerven. So haben ListViews keine native Unterstützung für Sections mit Rows. Activitywechsel kann nur über Intent-Pakete erfolgen, in denen du nur Werttypen wie
int oder string verschicken kannst.Das hat Apple wesentlich eleganter gelöst. Just my two cents.
Android würde ich aufgrund der ständigen Fehlermeldungen vielleicht also lieber richtig nativ umsetzen, Java unterscheidet sich ja nun kaum von C#. Allerdings hast du mit Xamarin ja den riesigen Vorteil:
Teilung des Logikcodes zwischen beiden Apps. Und das sind bei uns ca. 85 %. Da steckt so viel Hyper-Typer drin, dass ich den nie doppelt pflegen wollen würde.
Ist doch mehr geworden, als ich dachte.
Gruß vom Physikbuddha
Und das nicht nur fürs kompilieren, der Emulator ist einfach grausig. Mit einem echtem Smartphone angeschlossen geht es um einiges besser, aber das Gesamtpaket in Xcode ist doch stimmiger.
