IOS als Android-Entwickler lernen

Als erfahrener Android-Entwickler war ich schon immer neugierig auf die iOS-Plattform. Ist Objective-C schwer zu lernen? Ist es wirklich viel einfacher, eine schöne Benutzeroberfläche in iOS zu erstellen?

Ich entschied, dass der beste Weg ist, eine App auf beiden Plattformen zu schreiben und zu vergleichen. Eine App, die ich tatsächlich starte, damit ich den gesamten Prozess von der Codierung über das Design der Benutzeroberfläche bis zur Verteilung erlebe. Das Ergebnis ist Heart Collage, das sowohl im Apple App Store als auch bei Google Play erhältlich ist.

Hier sind meine Gedanken, nachdem ich zwei Monate lang iOS gelernt habe.

Die Einrichtung

Ich habe eine universelle App in iOS 6 mit automatischem Layout und Storyboard geschrieben. Ich habe iOS 6 für die neuen Funktionen wie UICollectionView und UIActivityViewController ausgewählt. Das automatische Layout und das Storyboard sind von der Entscheidung für iOS 6 heruntergekommen. Da ich auf der neuesten Version war, kann ich auch die neuesten Tools nutzen.

Lernkurve

Die ersten drei Wochen waren schmerzhaft. Ich wusste nicht nur nichts, sondern es fehlte mir auch der Wortschatz, um Fragen zu stellen. Ich würde nach etwas suchen und fünf Stapelüberlauf-Threads finden, die alle irgendwie mit dem zusammenhängen, was ich brauchte, aber nicht wirklich. Es war wirklich frustrierend.

Aber in der dritten Woche änderten sich die Dinge. Zu diesem Zeitpunkt wusste ich, welche Klassen ich verwendete, und stellte daher allen meinen Bildmanipulationssuchen UIImage und den Navigationssuchen UINavigationController voran. Ich hatte auch ein grundlegendes Verständnis dafür, wie die Dinge organisiert waren, und konnte überfliegen und beurteilen, ob ein bestimmter Thread relevant war.

Sobald ich wusste, wie man Antworten im Internet findet, nahm die Entwicklungsgeschwindigkeit wirklich zu. Ich hatte das Gefühl, tatsächlich zu programmieren, anstatt gegen eine Wand zu gehen.

UI-Bearbeitung

Anfangs dachte ich, dass mich alle eckigen Klammern in Objective-C wirklich stören würden, aber ich habe mich ziemlich schnell an die Syntax gewöhnt. Was mich auslöste, war Interface Builder / Storyboard.

Sowohl in iOS als auch in Android gibt es zwei Möglichkeiten, das Layout anzugeben: XML und Code. Der Unterschied ist, dass Android lesbare XML hat. Nicht so sehr in iOS.

Beide Systeme verwenden eindeutige IDs, um auf die verschiedenen Komponenten zu verweisen. In Android definieren Sie die ID folgendermaßen:

Das Build-System sammelt alle ID-Tags und generiert eindeutige IDs in Java:

 öffentliche statische endgültige Klassen-ID { 

public static final int start_button = 0x7f08003b;

}}

Verwenden Sie findViewById, um auf eine Ansicht in Ihrem Code zu verweisen:

 Button startButton = (Button) findViewById (R.id.start_button); 

In iOS generiert das Storyboard direkt die eindeutigen IDs in der XML:

Um auf eine Ansicht in Ihrem Code zu verweisen, definieren Sie zuerst ein IBOutlet in Ihrer .h-Datei, gehen zum Storyboard und ziehen Ihre Ansicht mit der rechten Maustaste in den Ansichts-Controller. Dies setzt voraus, dass Sie dem Storyboard bereits mitgeteilt haben, dass dieses bestimmte Fenster mit diesem Ansichts-Controller verknüpft ist. Andernfalls wird das IBOutlet nicht angezeigt.

Nachträglich macht alles Sinn, aber als ich anfing, zog ich und zog und zog und konnte die Ansichten nicht verknüpfen. Manchmal habe ich vergessen, den View Controller anzugeben. Ein anderes Mal habe ich vergessen, das IBOutlet hinzuzufügen. In den späten Nächten habe ich vergessen, dass man mit der rechten Maustaste zieht und nicht nur zieht.

Der schwierigste Teil ist, dass ich meine Implementierung nicht mit Beispielcode vergleichen kann, da alles visuell ist. In Android würde ich das gesamte Projekt, Code und XML und alles unterscheiden, um herauszufinden, was ich vermisst habe. Das von Interface Builder / Storyboard erstellte XML ist überhaupt nicht diff-freundlich.

Eingebaute Komponenten

Sobald ich mich mit der Bearbeitung der Benutzeroberfläche vertraut gemacht hatte, konnte ich die verschiedenen Bildschirme für die App erstellen. Die Leute behaupten, dass die in iOS integrierten Komponenten viel schöner sind als Android, aber die Lücke hat sich seit Ice Cream Sandwich erheblich verringert. Sicher, das iOS UIPickerView ist immer noch viel angenehmer zu bedienen als das Android Spinner, aber die grundlegenden Komponenten wie Schaltflächen sind ziemlich gleichwertig.

Es gab eine Sache, die unter iOS viel, viel einfacher zu bedienen war als unter Android: die Kameravorschau. Herzcollage zeigt eine quadratische Kameravorschau, die Sie posieren können. Unter iOS kann ich in jedem Seitenverhältnis nach einem Vorschaufenster fragen, und das System schneidet den Kamera-Feed automatisch zu. In Android? Das System streckt den Kamera-Feed auf das Seitenverhältnis der Vorschau. Um eine quadratische Kameravorschau zu erstellen, musste ich das Vorschaufenster auf das gleiche Seitenverhältnis wie den Kameraeinzug einstellen und einige Teile so verdecken, dass es quadratisch erscheint. Es war wirklich involviert. Wer möchte schon einen verzerrten Kamera-Feed? Zuschneiden ist das Richtige.

Im Übrigen finde ich fast immer direkte Entsprechungen: ImageView-Maps zu UIImageView, TextView-Maps zu UILabel, ListView ist ungefähr UITableView und GridView ... nun, GridView ist interessant. Bis iOS 5 gibt es keine integrierte Rasteransicht. Sie müssen eine UITableView verwenden und die Zelle in jeder Zeile selbst gestalten. Ich war schockiert, als ich das hörte. Vermutlich bin ich von Android verwöhnt? Wir haben das seit Version 1! Glücklicherweise wurde UICollectionView in iOS 6 eingeführt, und im Gegensatz zu Android ist es in Ordnung, auf die neueste Betriebssystemversion abzuzielen, da die meisten Benutzer sehr schnell ein Upgrade durchführen.

Dies bringt uns zu der berühmten Fragmentierungsdebatte.

Zersplitterung

Es gibt zwei Arten der Fragmentierung: Betriebssystemversion und Geräteformfaktor.

OS Version

iOS ist definitiv besser gegen die Fragmentierung der Betriebssystemversion positioniert, da Apple der einzige Hersteller aller iOS-Geräte ist und den OTA-Zeitplan vollständig kontrolliert.

Geräteformfaktoren

Bis vor kurzem war der Geräteformfaktor ziemlich einheitlich. Es gibt Retina und Nicht-Retina, das war's. Unterschiedliche Dichte, gleiches Seitenverhältnis. Das gleiche Seitenverhältnis bedeutet, dass Sie weiterhin ein koordinatenbasiertes Layoutsystem verwenden und Ihre Ansichten in Interface Builder ausrichten können.

Bis zum iPhone5 war alles pfirsichfarben. Plötzlich gibt es ein anderes Seitenverhältnis, und Apple brauchte etwas Stärkeres als Federbeine und Federn. Die Lösung ist das automatische Layout.

Das automatische Layout ist eine deklarative Methode, um die Positionen Ihrer Ansichten anzugeben. Anstatt zu sagen, platzieren Sie dieses Bild 240 Pixel von oben, sagen Sie, vertikal zentrieren. Das System berechnet die xy-Koordinaten basierend auf Ihren Einschränkungen, sodass es sich gut an verschiedene Formfaktoren anpasst.

Das automatische Layout klingt auf dem Papier gut, ist aber in der Praxis sehr umständlich. In Interface Builder ziehen Sie Ihre Ansichten immer noch per Drag & Drop, und XCode versucht, Ihre Absicht zu erraten. Meistens wird es falsch verstanden, daher muss ich die automatisch generierten Einschränkungen entfernen und meine eigenen erstellen. Ich habe es auch im Code versucht, aber es ist sehr ausführlich und sehr leicht, Fehler zu machen. Das visuelle Format hilft ein wenig, aber die meiste Zeit möchte ich meine Ansichten zentrieren, und es gibt keine Möglichkeit, dies in ASCII anzugeben.

Dies ist die Zeit, in der ich Android wirklich sehr vermisse. Das System wurde vom ersten Tag an für die Verarbeitung mehrerer Formfaktoren entwickelt, und Sie werden von Anfang an mit Konzepten wie match_parent und wrap_content vertraut gemacht. Ich deklariere mein Layout in XML, buchstabiere die Beziehung zwischen den Ansichten mit lesbaren IDs und kann meine Regeln jederzeit leicht überprüfen, wenn ich eine Ansicht hinzufügen muss. Unter iOS bin ich immer zweifelhaft, wenn ich eine neue Ansicht eingebe. Was hat es mit den bestehenden Ansichten gemacht? Es ist so mühsam, sie einzeln durchzuklicken und alle Einschränkungen zu untersuchen.

Vielleicht gibt es einen besseren Weg. Aber alle meine iOS-Entwicklerfreunde begannen vor iOS 6, bevor das automatische Layout verfügbar war. Sie deklarieren ihre Ansichten im Code, berechnen die Frames von Hand und führen im Grunde ihre eigenen Layout-Algorithmen aus. Und es gibt keinen Grund zur Konvertierung, sobald Sie ein System eingerichtet haben. Ich bin also allein im Bereich des automatischen Layouts.

Absichten

Eine andere Sache, die ich an Android vermisse, ist das Intent-System. Sowohl für die Navigation als auch für die Integration.

Navigation

Bei der Herzcollage nehme ich Ihre Posen mit der Kamera auf und ersetze dann die Kameraaktivität durch die Ansichtscollagenaktivität mit dem Mosaik. Folgendes mache ich in Android:

 Intent intent = new Intent (dies ist ViewCollageActivity.class); 

startActivity (Absicht);

Fertig();

Mit anderen Worten, ich füge die Ansichtscollagenaktivität dem Aktivitätsstapel hinzu und entferne die Kameraaktivität, indem ich finish () aufrufe.

Ich habe sehr lange gebraucht, um herauszufinden, wie das in iOS geht. Im Storyboard schieben Sie meistens einen neuen Ansichts-Controller auf den Stapel, indem Sie einer Schaltfläche einen Übergang hinzufügen. Sie können auch einen manuellen Übergang drücken, was ich mache, nachdem die Kamera alle Fotos aufgenommen hat. Der schwierige Teil ist, wie kann ich den alten View Controller öffnen? Wenn ich zuerst drücke, befindet sich der alte Ansichts-Controller nicht mehr oben auf dem Stapel, sodass Sie ihn nicht mehr platzieren können. Wenn ich zuerst einspringe, befindet sich der alte Ansichts-Controller nicht mehr auf dem Stapel, und ich darf nicht nach einem Übergang fragen.

Dies ist der Moment, in dem ich bezweifle, ob es sinnvoll war, sich für ein Storyboard zu entscheiden. Es scheint für sehr einfache Navigationsanforderungen konzipiert zu sein, und selbst meine App mit vier Bildschirmen ist zu kompliziert dafür. Am Ende tauchte ich eine Ebene höher mit einer Flagge auf, um mich automatisch zum Anzeigen der Collage weiterzuleiten. Ein bisschen hacken, aber ich war zu tief im Storyboard, um alle Ansichten in xib zurückzuziehen und neu zu erstellen. Zumal ich keine Möglichkeit habe, die Layouts zu kopieren und einzufügen, muss ich alles erneut ziehen und ablegen.

Integration

Nachdem Sie eine Herzcollage erstellt haben, können Sie sie mit der App mit Ihren Freunden teilen. Dies ist super einfach für Android. Ich erstelle nur eine Absicht, die besagt, dass ich ein Image freigeben möchte, und das System generiert automatisch die Liste der installierten Apps, die damit umgehen können. Es ist eine elegante Möglichkeit, eine personalisierte und erweiterbare Erfahrung zu machen. Benutzer können ihre Collagen mit beliebigen Apps teilen, die sie bevorzugen, und ich muss nicht einmal wissen, dass sie diese App verwenden, geschweige denn einen neuen Integrationspunkt erstellen.

Für die Freigabe bietet iOS 6 eine ähnliche Funktionalität mit UIActivityViewController. Ich habe die Nachricht und das Bild eingerichtet und es wird eine Liste mit Optionen zum Teilen angezeigt. Der große Unterschied besteht darin, dass die Liste von Apple erstellt und vom Benutzer nicht erweitert werden kann. So wird jeder Sina Weibo als Option sehen, ob es ihm wichtig ist oder nicht.

Hier strahlt Android wirklich aus, die nahtlose Integration zwischen Apps und damit eine sehr personalisierte Erfahrung.

Verteilung

Beta-test

Endlich war meine App für den Beta-Test bereit. Yay!

Hier sind die Schritte für beide Plattformen:

Android

  1. Kompiliere die apk.
  2. Mailen Sie es an einige Freunde.
  3. Es gibt keinen dritten Schritt.

iOS

  1. Sammle UUID von Freunden.
  2. Erstellen Sie ein Bereitstellungsprofil über das iOS-Entwicklungsportal.
  3. Fügen Sie für jedes neue Testgerät eine UUID hinzu.
  4. Laden Sie das Bereitstellungsprofil vom iOS-Entwicklerportal herunter.
  5. Kompiliere ipa.
  6. E-Mail-Bereitstellungsprofil und ipa.

Der schmerzhafteste Teil ist, dass ich jedes Testgerät manuell im Bereitstellungsportal hinzufügen und dann auf meine lokale Festplatte herunterladen muss, um die IPA zu kompilieren. So langweilig.

Die Kehrseite ist jedoch, dass ich genau weiß, wer meine App ausführen kann, und dass ich mir keine Sorgen über Lecks machen muss. Für Android haben Sie nach dem Versenden einer Apk keine Ahnung, wohin sie führen wird. Und es gibt keinen guten Weg, um die Verbreitung einzuschränken.

Freisetzung

Und jetzt der letzte Moment - Release zum Speichern. Keine Angst um Android. Einfach hochladen, ungefähr eine Stunde warten und es ist live. Für iOS gibt es den Überprüfungsprozess.

Ich möchte Heart Collage vor dem Valentinstag veröffentlichen, also habe ich es Ende Januar eingereicht. Es sollte genügend Zeit geben, aber die mögliche Ablehnung hat mich gestresst. Ich war so erleichtert, als die App beim ersten Versuch seit sechs Tagen genehmigt wurde. Jubel!

Urteil

Ich habe hauptsächlich auf den Unterschied zwischen iOS und Android hingewiesen, aber letztendlich sind sie zumindest technologisch eher ähnlich als unterschiedlich. Das Urteil steht noch aus. Stimmt es, dass iOS-Benutzer eher bereit sind, für Apps zu bezahlen? Welche Plattform wird mehr Umsatz generieren? Das wird die treibende Kraft für meine Entscheidung sein, Zeit mit iOS oder Android zu verbringen, und die Zahlen sind immer noch nicht bekannt. Wird Heart Collage mehr Downloads für iOS oder Android erhalten? Wir werden sehen.

Dieser Gastbeitrag von Chiu-Ki Chan erschien ursprünglich auf ihrem Blog Square Island. Sie ist eine ehemalige Softwareentwicklerin bei Google und leitet jetzt ihre eigene mobile Entwicklungsfirma.

© Copyright 2021 | mobilegn.com