Top!
Hello
Die vierte Ausgabe der App Builders Konferenz richtete sich einmal mehr an iOS- und Android-Entwickler aus aller Welt. Veranstaltungsort war zum zweiten Mal der am Schweizer Südzipfel gelegene Ferienort Lugano. Auf zwei Tage verteilt wurden Vorträge zu verschiedensten Themengebieten geboten.
Guilherme Rambo, der sich vor allem durch zahlreiche Leaks im iOS-Bereich einen Namen gemacht hat, sprach über die Wichtigkeit der Privatsphäre von Nutzern. Gerade in den letzten Monaten ist das Thema Datensicherheit und Privatsphäre von Nutzern immer mehr in den Fokus gerückt.
Laut Rambo sollen nur die Daten gesammelt werden, die in einer App auch wirklich benötigt werden. Er wies in diesem Zusammenhang auch darauf hin, vorsichtig im Umgang mit SDKs zu sein, die man selbst nicht entwickelt hat. Ganz besonders dann, wenn diese Closed Source sind und somit keinen Einblick in den Code ermöglichen. Denn in eine App eingebundenen SDKs haben die gleichen Rechte wie die App selbst. Das kann der Zugriff auf die Kamera, aber auch auf die Kontakte oder den Standort sein. Wenn ebendiese Rechte vom Nutzer eingeholt werden, gilt es außerdem zu beachten, nicht sämtliche Rechte durch zahlreiche Popups beim erstmaligen Starten der App einzuholen.
Rambo betont, dass die Rechte nur dann eingefordert werden sollen, wenn dies auch wirklich notwendig ist, also erst in der konkreten Situation z. B. beim Aufnehmen eines Fotos. Mit ähnlichen Fragestellungen rund um Datenschutz und Souveränität bei mobilen Applikationen beschäftigen auch wir uns intensiv im Rahmen des Forschungsvorhabens DaSoMan - Daten-Souveränitäts-Manager.
Auch beim Logging sollte darauf geachtet werden, welche Daten geloggt werden. Einen Vorteil bietet das Apple-eigene os_log. Verwendet man dabei dynamische Strings, wie im nachfolgenden Beispiel, werden diese in Release Builds nur mit <private> gekennzeichnet.
os_log(.default, "API token generated: %d", token)
Möchte man dies aus einem bestimmten Grund umgehen, lässt sich wie unten zu sehen %{public}d verwenden.
os_log(.default, "API token generated: %{public}d",
token)
Janina Kutyn beleuchtete in ihrem Vortrag die Entwicklung von Benutzeroberflächen für verschiedene iOS-Geräte. Nachdem in den letzten Jahren immer mehr neue Gerätegrößen zur iOS-Familie hinzugekommen sind, gestaltet es sich immer schwieriger, eine UI zu entwickeln, die auf allen Geräten zugleich passend und ansprechend ist. Von Apple selbst gibt es im iOS SDK die Möglichkeit, auf Size Classes zurückzugreifen. Die verschiedenen Geräte werden sowohl in ihrer Höhe als auch in der Breite in Regular (groß) und Compact (klein) eingestuft. Doch inzwischen ist diese Einteilung eigentlich nicht mehr ausreichend, da sowohl das iPhone SE als auch das iPad Pro mit einem 12,9-Zoll-Bildschirm in der Höhe als Regular eingestuft werden.
Kutyn beschreibt, wie sie in einigen Projekten bereits eine eigene Alternative zu Size Classes definiert hat, abhängig von der Framehöhe und -breite eines Screens. Darauf kann dann beispielsweise in der Berechnung von Zellgrößen in einer UICollectionView zurückgegriffen werden. Es ist beispielsweise sinnvoll, auf kleineren Geräten weniger Spalten von Zellen anzuzeigen als auf großen iPads.
In dem Vortrag wurde anhand einer Beispiel-App gezeigt, wie man User Interfaces an verschiedene Gerätegrößen anpassen kann. Durch diese Darstellung wurde auch deutlich, wann es sinnvoll ist, UI im Code zu entwickeln und welche Vor- und Nachteile der Interface Builder bietet.
Gleich zwei Redner beschäftigten sich damit, wie Code für Business Logik in iOS und Android geteilt werden kann. Cecilia Humlelu beleuchtete das Thema aus Sicht des Streaming-Anbieters Spotify, während Nicolas Märki und Joseph El Mallah die Vorteile für kleinere Unternehmen beschrieben.
Der große Nutzen in beispielsweise der Verwendung von C++-Code liegt darin, dass dieser sowohl in iOS als auch in Android nativ verwendet werden kann. Während aber in iOS eine recht einfache Zwischenschicht im Code genügt, um zwischen C++ und Objective-C zu kommunizieren, gestaltet sich das in Android durch das nicht besonders intuitive Java Native Interface (JNI) etwas schwieriger.
Um diese Zwischenschichten nicht selbst schreiben zu müssen, gibt es Ansätze wie beispielsweise Djinni von Dropbox, mit Hilfe dessen die Schnittstellen zum C++-Code generiert werden können. Ein Nachteil bei der Verwendung von Djinni ist jedoch die Tatsache, dass zusätzliche Interface Definitionen benötigt werden. Zusätzlich hat Dropbox erst kürzlich den Support für Djinni eingestellt.
Weitere Möglichkeiten wie Business Logik geteilt werden kann, sind unter anderem J2ObjC und Kotlin Native. In ihrem Vortrag beleuchtete Humlel zudem, wie in Swift Code mit C- und C++- Klassen integriert werden kann. Auch in Swift gibt es dabei Möglichkeiten, Speicher zu optimieren, wenn auf Pointer-Ebene gearbeitet wird. Außerdem betrachtete die Spotify-Entwicklerin, wie sich C-, C++- und Objective-C-Frameworks in Swift-Apps integrieren lassen.
Auch wir praktizieren seit vielen Jahren die Crossplattform Entwicklung mit C++. Der von uns entwickelte Ansatz bezeichnen wir als Shared Component und sehen insbesondere bei komplexen und umfangreichen Apps große Vorteile bei dieser Vorgehensweise.
Auf YouTube sind alle Vorträge noch einmal zu sehen. Neben den genannten Vorträgen sind auch die Erfahrungen von GitHub-Mitbegründer Scott Chacon als Unternehmer sowie die Erklärungen von Brandon Williams, an welchen Stellen Swift-Protokolle noch limitiert sind, sind sehr zu empfehlen. Neben den zahlreichen Vorträgen fanden auch zwei Interviews statt, in denen der Director of Engineering von SoundCloud und der Head of Engineering von Travis CI über ihre Erfahrungen sprachen.
