Devoxx 2014. Meine Eindrücke

Diesen November durfte ich mit einigen Namics-Kollegen die Entwicklerkonferenz Devoxx in Antwerpen besuchen. Die Devoxx konzentriert sich auf Java, Android und Web-Technologien und gilt mit ca. 3500 Teilnehmern als größte Konferenz ihrer Art. Die Auswahl der Referenten ist hochkarätig: Google, Oracle und Pivotal schicken jeweils ihre Kernentwickler zur Devoxx, um die neusten Entwicklungen selbst vorzustellen.

Folgende Vorträge möchte ich kurz anreissen:

Android Development Tools

Das Android Studio und das Gradle Android Plugin sind zwar immer noch in der Beta-Phase, jedoch gibt es keinen Grund mehr, die alte Eclipse-Suite zu verwenden. Neben kleinen Verbesserungen in der IDE, wie beispielsweise den neuen Übersetzungseditor, den umgeschriebenen AVD Manager und den Introspection-Annotationen, gaben die Entwickler auch einen kleinen Ausblick auf ihre künftige Arbeit. So wollen die Entwickler primär die API stabilisieren, und gleichzeitig die Gradle-Performance beim Laden von Projekten erhöhen. Eine Publikumsfrage nach einer Alternative zu Java wurde leider nicht beantwortet.

HTTP 2.0 comes to Java.

Das auf SPDY basierende HTTP 2.0 Protokoll wird mit der Servlet API 4.0 Einzug ins JDK finden. In diesem Vortrag fasst Edward Burns (JSR-369 Spec-Lead) die wesentlichen Änderungen von HTTP 2.0 zusammen (Multiplexing, Server Push, Header Compression), und präsentierte anschliessend Fragmente der neuen geplanten API. Erwähnenswert sind noch die neuen HTTP-Client-Klassen HttpRequest und HttpRequestGroup, die bisherige Drittlibraries (wie den Apache HttpClient) ablösen werden. Mehr zu diesem Vortrag finden Sie in diesem Slidedeck.

Java 8, 9 and beyond – Ask the experts

Brian Goetz (der Architekt der Java-Sprache) und Stuart Marks stellten sich den über Twitter eingereichten Fragen des Publikums. Auf die Frage, ob die Rückwertskompatibilität von Java eine Last („burden“) sei, antwortete Goetz, das diese Rückwertskompatibilität eher als Rahmenbedingung („constraint“) gewertet werden sollte. Oracle hat den Anspruch, dass der Java-Code, der vor über 15 Jahren geschrieben wurde, auch weiterhin funktioniert. Die Rückwertskompatibilität von Java sei definitiv ein Mehrwert, der sich von anderen Sprachen absetzt. Änderungen an der Sprache werden nur sehr vorsichtig und unter langem Abwägen eingebaut. Scheinbar simple Anfragen z.B. nach Literalen für Listen können nicht einfach eingebaut werden, da bspw. nicht klar sei, welche List-Klasse nun wirklich instanziert werden sollte (LinkedList, ArrayList, Stack ?). Insgesamt ein sehr spannender Vortrag, der Einblicke in das Denkmodell der Java-Architekten bot. Meine (zugegebenermaßen leicht abstruse) Frage nach „Automatic Reference Counting“ für Java wurde leider nicht beantwortet.

Java Posse Podcast

Dieser beliebte Java Podcast wurde in den letzten beiden Jahren nur spärlich aktualisiert, da sich die Podcaster in unterschiedliche Richtungen entwickelten und eigene Podcasts gründeten (The ScalaWags und Android Developers Backstage). Immerhin: Auf dieser Devoxx haben sie jedoch die allerletzte Folge vor Livepublikum aufgenommen und ein Résumé der letzten 10 Jahre gezogen. Sehr spaßig.

Java Posse - Live at Devoxx 2014

 

Fazit

Der Besuch der Devoxx hat sich definitiv gelohnt: Die Veranstaltung bietet spannende Inhalte, hochkarätige Speaker und ist gut organisiert. Jedoch bietet die angemietete Fläche im Metropolis Antwerpen nicht genügend Platz für 3500 Personen. Lange Schlangen und viel Gedränge in den Gängen waren die Folge. Hier sollten sich die Organisatoren für nächstes Jahr etwas einfallen lassen.

Windows Phone 8 im Dauertest

Startbildschirm eines Windows Phone 8 Geräts

„Wow, ist das Scrolling flüssig!“. Diesen Satz höre ich immer dann, wenn ich jemanden mein Nokia Lumia 820 zeige: Das Scrolling ist butterweich und die Bildschirmübergänge durchdacht animiert. Die kantige Oberfläche wirkt frisch und hebt sich angenehm von Android und … Weiterlesen

Veröffentlicht unter Mobile

Flexible iOS-Views

Aus Sicht eines App-Entwicklers ist die vergleichbare geringe Anzahl von Displaygrössen eine der grössten Stärken der iOS-Plattform. Es gibt nur zwei Formfaktoren (iPhone und iPad) mit jeweils einfacher und doppelter Pixeldichte. Für Entwickler ist diese reduzierte Anzahl an Displaygrössen von Vorteil, da der Design- und Testaufwand gegenüber anderen Plattformen überschaubar bleibt.

Warum flexible Views?

Trotz der geringen Anzahl an Displayausprägungen sollten iOS-Entwickler nicht in die Versuchung kommen, sämtliche Positions -und Grössenangaben in den Views hartzucodieren. Insbesondere mit der Plattform unerfahrenere Programmierer neigen gerne dazu. Spätestens dann, wenn sich die Anordnung von einzelnen View-Fragmenten bei der Rotation des Geräts ändern soll, wird es mit hartcodierter Positionierung haarig. Und wer weiß – eventuell etabliert Apple mit dem iPhone 5 eine neue Displaygrösse, die im Seitenverhältnis von den bisherigen Modellen abweicht. Eine sorgsame Umsetzung der View-Struktur ist also unerlässlich, um die App auch langfristig an neue Anforderungen oder Geräte anpassen zu können.

Wie lösen Android und BlackBerry-SDK das Problem?

Blicken wir zunächst kurz über den Tellerrand und betrachten, wie das BlackBerry- und Android-SDK das Problem lösen: Beide bieten sog. LayoutManager an, um flexible Views zu realisieren. Aber was genau macht ein LayoutManager? Grob gesagt ist er ein Container, der mehrere Views zusammenfasst und positioniert. Er kann gleichzeitig auch die Grösse seiner Subviews festlegen, sie aber vorher nach der präferierten Grösse fragen. Erst nach Abschluss dieser Layoutphase wird das Zeichnen eingeleitet.

Das BlackBerry-SDK stellt für LayoutManager die abstrakten Manager-Klasse zur Verfügung. Es gibt zwar einige konkrete Implementierungen im SDK, allerdings habe ich in meinen letzten BlackBerry-Projekten die Erfahrung gemacht, dass diese den seltesten Fällen ausreichen. Man muss also sehr häufig eigene Manager schreiben. In der Android-Welt leitet man dagegen von der ViewGroup-Klasse ab, sofern die Standardimplementierungen wie GridLayout nicht ausreichen.

Was bietet iOS?

Kommen wir nun zum iOS-SDK. Hier gibt es keine dedizierte LayoutManager-Klasse. Eine Trennung zwischen Container und View findet somit nicht auf Klassenebene statt. Stattdessen ist jede View gleichzeitig ein Container. Die für Views verantwortliche Klasse UIView bietet mit „layoutSubviews“ und „sizeThatFits:“ Methoden an, um einen vollwertigen LayoutManager zu realisieren. Bevor eine View gezeichnet wird, ruft das Framework layoutSubviews auf. Sobald sich die Größe der View (z.B. durch Rotation des Geräts) ändert, wird erneut layoutSubviews aufgerufen, damit die Subviews sich an die neue Grösse anpassen können. Für ganz einfache flexible Positionierungen muss man jedoch nicht immer layoutSubviews implementieren. Stattdessen kann man die aus dem InterfaceBuilder bekannten AutoSizing-Flags nutzen (auch bekannt als „struts & springs“), mit denen man die Abstände zum Rand der View fixieren kann. Aber sobald ein sog. Reflow-Verhalten gefordert ist oder die Views sich abhängig von der Orientation des Geräts neu positionieren müssen, führt kein Weg an einer layoutSubviews-Implementierung vorbei.

Beispiel

Das nachfolgende Beispiel soll das Zusammenspiel von layoutSubviews und sizeThatFits: demonstrieren: Auf einem Screen soll sowohl eine Toolbar (ToolbarView) als auch ein Inhaltsbereich (BodyView) platziert werden. Die Höhe der Toolbar soll dabei immer 20% der Bildschirmhöhe einnehmen und oberhalb der BodyView liegen. Die BodyView soll die verbleibende Bildschirmfläche nach unten ausnutzen.

View im Landscape-Modus: 20% für den Header ergeben 150 Punkte.

View im Portrait-Modus: 20% für den Header ergeben 201 Punkte.

 

Damit das funktioniert, erstellen wir eine RootView, die die ToolbarView und BodyView als Subviews enthält. Diese RootView implementiert layoutSubviews folgendermassen:

- (void) layoutSubviews {
  // Frage die Toolbar, welche Grösse sie
  // von der Gesamtfläche einnehmen möchte.
  CGSize toolbarSize = [self.toolbarView sizeThatFits:self.bounds.size];
  CGRect toolbarFrame =
    CGRectMake(0,0, toolbarSize.width, toolbarSize.height);
  [self.toolbarView setFrame:toolbarFrame];

  // Die BodyView bekommt die restliche Fläche.
  CGFloat bodyWidth = self.bounds.size.width;
  CGFloat bodyHeight = self.bounds.size.height - toolbarSize.height;
  CGRect bodyFrame =
    CGRectMake(0, toolbarFrame.size.height, bodyWidth, bodyHeight);
  [self.bodyView setFrame:bodyFrame];
}

 

Betrachten wir nun die Implementierung der sizeThatFits: Methode der ToolbarView:

- (CGSize) sizeThatFits:(CGSize) size {
  CGFloat myWidth = size.width;
  CGFloat myHeight = size.height * 0.2;
  return CGSizeMake(myWidth, myHeight);
}

 

Fazit

Alle Plattformen nutzen das LayoutManager-Prinzip für die Umsetzung von flexiblen Views. Das iOS-SDK bietet zwar keine dedizierte Klasse dafür, aber ermöglicht mit dem Zusammenspiel von layoutSubviews und sizeThatFits: dennoch die einfache Umsetzung von eigenen LayoutManagern.

Veröffentlicht unter Mobile