D: 4,

90 EU

R A:

5,60

EUR

CH: 9

,80 C

HF B

enel

ux: 5

,80 E

UR

ISSN

2191

-697

7

Java

aktu

ell Javaaktuell

01-2015 | Frühling | www. ijug.eu

Praxis. Wissen. Networking. Das Magazin für EntwicklerAus der Community — für die Community

419

1978

3049

0301

iJUGVerbund

PraxisMehr Typsicherheit mit Java 8

ProgrammierenDer selbe GUI-Code für Desktop, Web und native mobile App

SAP HANAWas für Java-Anwendungen drin ist

Fünf Jahre Java aktuell

4 |

Inha l t

Wege zum Aufbau von modernen Web-ArchitekturenHappy Birthday Java aktuell

14

5 Das Java-TagebuchAndreas Badelt

8 JavaOne 2014: Alles im LotPeter Doschkinow und Wolfgang Weigend

9 Fünf Jahre Java aktuell, die Community gratuliert

12 Unbekannte Kostbarkeiten des SDK Heute: Informationen über die Virtual Machine und die ProgrammausführungBernd Müller

14 <Superheld/>-Web-Applikationen mit AngularJSJoachim Weinbrenner

20 Login und Benutzerverwaltung: Abge-sichert und doch frei verfügbarMartin Ley

24 Software-Erosion gezielt vermeiden Kai Spichale

29 Desktop, Web und native mobile App mit demselben GUI-CodeRené Jahn

33 Das FeatureToggle Pattern mit TogglzNiko Köbler

38 Mehr Typsicherheit mit Java 8Róbert Bräutigam

44 Alles klar? Von wegen! Der faule Kontrolleur und die AssoziationsmaschineDr. Karl Kollischan

48 Apps entwickeln mit Android StudioGesehen von Björn Martin

49 SAP HANA — was für Java-Anwen-dungen drin istHolger Seubert

53 Entwicklung mobiler Anwendungen für BlindeMandy Goram

57 Eventzentrische ArchitekturenRaimo Radczewski und Andreas Simon

62 „Spiel, Spaß, Spannung und ab und zu auch Arbeit …“Jochen Stricker

63 So wird Testen groovyKai Spichale

Groovy-Entwickler argumentieren, dass Java in die Jahre gekommen sei

So wird Testen groovy

63

09

| 53

www.ijug.euiii

iii iiiiii

Java aktuell 1-2015

Entwicklung mobiler Anwendungen für BlindeMandy Goram, TREvisto GmbH

Mobile Endgeräte wie Smartphones und Tablets sind im Laufe der letzten Jahre zu einem nahezu unverzichtbaren und nützlichen Begleiter im Alltag geworden – schnell einen Begriff recherchieren und sich mithilfe einer App oder eines Online-Dienstes in einer unbekannten Stadt orientieren. Die Großzahl der Apps ist jedoch nicht barrierefrei gestaltet und somit nahezu unzugänglich für Blinde und stark Sehbeeinträchtigte. Dieser Artikel richtet sich an Designer sowie Entwickler und erläutert die Accessibility-Funktionalitäten von Android.

Für Blinde und stark Sehbeeinträchtigte sind die visuelle Wahrnehmung und die Aufnah-me visueller Informationen nicht gegeben beziehungsweise sehr stark eingeschränkt. Daher können Darstellungen und Inhalte ei-ner Anwendung nicht in der klassischen Art und Weise vermittelt werden. Man benötigt alternative Mechanismen in der Mensch-Computer-Interaktion und muss diese in geeigneter Weise implementieren.

Bei mobilen Endgeräten bieten sich meist die Sprach- und Tonausgabe sowie Vibrati-

onsmechanismen an. Für die Aufbereitung und Wiedergabe von inhaltlichen Informati-onen stehen in diesem Fall auditives, hapti-sches und taktiles Feedback zur Verfügung. Bei auditivem Feedback handelt es sich im Wesentlichen um Sprach- und Sound-wiedergabe. Unter Haptik versteht man die Berührung und aktive Erkundung von Oberflächen. Dadurch können Formen und oberflächliche Strukturen erkannt werden, etwa die Dimensionen und die Form eines mobilen Endgerätes. Die taktile Wahrneh-

mung ist unter anderem durch die Empfin-dung von Temperatur, Festigkeit, Schmerz oder Vibration geprägt, beispielsweise bei einer Auswahlbestätigung durch eine kurze Vibration.

Das haptische Feedback, im Englischen auch „Forced Feedback“ genannt, spielt bei der Entwicklung virtueller Realitäten eine bedeutende Rolle und wird zur aktiven Kraftrückkopplung verwendet. Bei Smart-phones und Tablets steht hingegen das tak-tile Feedback im Vordergrund. Daher haben

54 |

Mobi le Anwendungen für B l inde

von Zeichen ohne aufwändige Implementie-rung und ohne Transformation der Informa-tionen. Tabelle 1 gibt einen Überblick zu den wichtigsten bereitgestellten Funktionen und Verbesserungen in Android.

Wie eine zusammengefasste Statis-tik vom August 2014 zur Verbreitung der Android-Versionen zeigt, laufen mehr als 75 Prozent aller Android-Geräte mit einer Version 4.0 oder höher (siehe Abbildung 1). Somit können die meisten Geräte mit bar-rierefreien Apps arbeiten, die die Standard-Funktionalitäten des API verwenden.

Bedienhilfen „Out of the box”Es ist nicht viel Aufwand erforderlich, um eine App für die Screenreader oder die Sound- beziehungsweise Vibrationswiedergabe zu-gänglich zu machen. Werden zur Erstellung der App Standard-Komponenten verwendet,

entsprechende Mechanismen ihren Weg in das Android-API gefunden.

Accessibility in AndroidDas Android-API bietet mittlerweile um-fangreiche, weit entwickelte Schnittstellen und Konzepte zur Entwicklung barriere-freier Anwendungen an. Da diese Funktio-nalitäten erst nach und nach über das API bereitgestellt wurden, war die barrierefreie Entwicklung in den Anfangsjahren sehr auf-wändig und aufgrund der unterschiedlichen Geräte sehr unzuverlässig. Während bis zur Version 2.3. („Gingerbread“) lediglich die Screenreader „TalkBack“, „Spiel“ und „Mo-bileAccessibility“ zur Verfügung standen und mit der Version 3.1. („Honeycomb“) nur die Web-Zugänglichkeit verbessert wurde, gibt es seit 4.0 („Ice Cream Sandwich“) we-sentliche Verbesserungen und Neuerungen im Accessibility-API. Es steht beispielsweise der „Explore by Touch“-Modus zur Verfü-gung, der View-Komponenten gezielt selek-tieren kann und eine sprachliche Beschrei-bung wiedergibt. Die Funktionen stehen in Verbindung mit dem mittlerweile zentralen Screenreader „TalkBack“. Dazu später mehr.

Mit der Version 4.1 („Jelly Bean“) kamen durch das Accessibility-API weitere sehr nützliche Funktionen, die eine einfache, barri-erefreie Entwicklung ermöglichen. So stehen Funktionen zur Gesten-Überwachung und -Steuerung bereit, um auf einfachem Wege neue Gesten zu implementieren. Zudem wird erstmals die Verwendung von Braille-Tastaturen durch das Betriebssystem direkt ermöglicht. Dazu sind Braille-Services via „BrailleBack“ in den „TalkBack“-Modus inte-griert. Dies ermöglicht die Ein- und Ausgabe

können die von Android bereitgestellten Me-chanismen einfach darauf zugreifen. „Talk-Back“, „SoundBack“, „KickBack“ und „Braille-Back“ sind robuste Schnittstellen zwischen dem Gerät und dem Anwender, wodurch dem Entwickler eine aufwändige Eigenent-wicklung erspart bleibt. Bei der Verwendung eigener Nicht-Standard-Komponenten in der View muss aber gegebenenfalls ein eigener Feedback-Mechanismus entwickelt werden. Konkret kann es sich dabei um spezielle Ges-ten oder Sprachausgaben handeln.

Die zentrale Accessibility-Komponente ist „TalkBack“. Die Funktionen sind über das Menü „Bedienhilfen“ aktivierbar. Ab der Version 4.0 kann bereits beim ersten Start eines Geräts dessen Aktivierung erfolgen; dadurch ver-ändern sich die Steuerung und der Auswahl-prozess des Geräts grundsätzlich. Der Modus sowie dessen spezielle Erweiterungen ermög-

Version Accessibility-FunktionalitätenDonut (1.6), Eclair (2.1), Froyo (2.2), Gingerbread (2.3) Bereitstellung von Screenreadern („TalkBack“, „Spiel“, „MobileAccessibility“)

Honeycomb (3.0) Verbesserte Web-Zugänglichkeit

Ice Cream Sandwich (4.0) Explore by touch (Sprachwiedergabe der Komponenten-Beschreibung)Aktivierung „TalkBack“ bei erstem Systemstart möglichSystemweite Schriftgrößen-Anpassung

Jelly Bean (4.1) Überwachung und Steuerung komplexer GestenUnterstützung von Braille-Services via „BrailleBack“Zoom von Bildschirm-AusschnittenTraversieren von TextenAnpassung der Navigation (Fokussieren von Objekten)Ausstattung von Widgets mit logischen Modellen

Jelly Bean (4.3) Verarbeitung von Tastatureingaben„Copy & Paste“-Funktion Verbesserte Web-Zugänglichkeit

Tabelle 1: Accessibility-Funktionalitäten der Android-Versionen

Abbildung 1: Verbreitung der Android-Versionen

| 55

www.ijug.euiii

iii iiiiii

Java aktuell 1-2015

lichen Blinden eine selbstständige Bedienung des Android-Geräts über permanentes Feed-back des Betriebssystems an den Anwender. Dadurch können verschiedene Einstellungen vorgenommen und einzelne Apps ausgewählt werden. Wie sich eine ausgewählte App nach dem Start verhält, hängt aber im Wesentlichen von deren Implementierung ab. Wurden barri-erefreie Elemente nur unzureichend oder gar nicht berücksichtigt, ist die Bedienung durch einen Blinden nicht möglich und die inhaltliche Erschließung sehr schwer bis unmöglich.

Zugänglichkeit von OberflächenelementenTalkBack verwendet die „contentDescription“ eines View-Elements, um Informationen zum Inhalt und zum Aufbau einer View wiederzu-geben (siehe Listing 1). Ist diese für ein Element gesetzt, kann der Screenreader sie auslesen. Das Setzen kann sowohl für Standard- als auch für eigene Komponenten erfolgen. Bei rein op-tischen View-Elementen sollte diese allerdings nicht gesetzt werden. Dadurch wird verhindert,

dass inhaltlich irrelevante Elemente angespro-chen werden. Dies könnte bei einem Blinden zu Irritationen und Verwirrung führen, da er selbst die Bedeutung nicht ohne entsprechen-de Rückmeldungen erfassen kann.

Bei EditBoxen muss für eine entspre-chende Funktionalität anstelle der „content-Description“ ein „android:hint“ verwendet werden. Dadurch erfolgt bei Auswahl eines Eingabefelds die Wiedergabe von Feldbe-zeichnung und -inhalt (siehe Listing 2).

Für den „Explore by Touch“-Modus ist es wichtig, dass die View zugängliche Kom-ponenten besitzt. Hierfür muss jede an-wählbare Komponente „focusable = true“ deklariert haben. Dies kann im XML-File gesetzt sein (siehe Listing 3) oder nachträg-lich im Code geändert werden. Dazu können die Methoden „setFocus“, „isFocusable“ und „requestFocus“ zum Einsatz kommen.

Zur Anwahl eines Elements durch den Anwender verfügt der „Explore by Touch“-Modus über eine spezielle Gesten-Steue-rung. Mit einer einfachen Wischgeste wird

das nächste fokussierbare Objekt in der View ausgewählt. Die Werte „nextFocus-Right“, „nextFocusDown“, „nextFocusLeft“ und „nextFocusUp“ verfeinern die Ansteue-rung einzelner Elemente.

Sprachausgabe und SprachsteuerungMan ist jedoch nicht ausschließlich auf den Screenreader angewiesen, um Komponenten und Inhalte vorlesen zu lassen. Die Text-to-Speech-Schnittstelle (TTS) integriert indivi-duelle Sprachausgaben in die Anwendung. Dazu ist ein Objekt mit einem vorzulesenden Text zu erzeugen und wiederzugeben; die Verwendung von „TalkBack“ entfällt. Je nach Zweck kann die Wiedergabe von Text durch eine aktive Interaktion des Anwenders mit der Anwendung erfolgen oder zeitgesteuert ablaufen. Diese Feinheiten sind ganz dem Entwickler überlassen (siehe Listing 4).

Es geht aber auch umgekehrt mit Speech-to-Text (STT). Der SpeechRecognizer wan-delt Sprache in Text um. Im Zuge dessen las-sen sich unter anderem Sprachkommandos integrieren, die eine Sprachsteuerung der Anwendung erlauben. Der SpeechRecogni-zer hat jedoch einen entscheidenden Nach-teil, er benötigt eine Internet-Verbindung zum Server. Das API stellt damit lediglich eine Service-Schnittstelle zur Verfügung. Ist das mobile Endgerät offline, kann die Funk-tion nicht verwendet werden.

Eine Alternative dazu ist das Projekt „po-cketsphinx“. Es wurde für leichtgewichtige mobile Anwendungen entwickelt und ist eines der wenigen Projekte zur Spracher-kennung und -steuerung, das auch offline verwendet werden kann. Die Programm-Bibliothek lässt sich in ein Android-Projekt integrieren und ohne Internet-Anbindung ausführen. Die Integration in die App ge-staltet sich zunächst etwas aufwändig. Erst mal muss man die Bibliothek überhaupt zum Laufen bekommen, dann sind Grammatiken und das Wörterbuch selbst zu erstellen. Ein Tool unterstützt beim Anlegen des Wort-schatzes, indem es die Informationen für „pocketsphinx“ lesbar in eine Datei übersetzt.

Allgemeines Oberflächen-DesignNeben der eigentlichen Implementierung und Ausgestaltung des Codes spielt bei der Ent-wicklung barrierefreier Anwendungen auch das Design der Oberfläche eine bedeutende Rolle. Dabei gilt es, die Verwendung von Freitext-Feldern weitestgehend zu vermeiden, sofern diese nicht zwingend erforderlich sind. Bei dis-

<Button android:id=”@+id/play_button” android:contentDescription=”@string/play”/>

Listing 1: „contentDescription“ eines View-Elements

<EditText android:id=”@+id/search_criteria” android:hint=”@string/search_hint” android:inputType=”text” />

Listing 2: „android:hint“ eines Textfelds

<Button android:id=”@+id/focus_button” android:focusable=”true” android:nextFocusUp=”@id/edit” ... />

import android.speech.tts.TextToSpeech;import android.speech.tts.TextToSpeech.OnInitListener;…textToSpeech = new TextToSpeech(context, this); textToSpeech.setLanguage(Locale.GERMANY);textToSpeech.speak(“Hallo!”, TextToSpeech.QUEUE_FLUSH, null);…

Listing 4: Wiedergabe mittels TTS

Listing 3: Setzen von „focusable“ im XML-File

56 |

Mobi le Anwendungen für B l inde

kreten Werten sollten vor allem Checkboxen oder Radiobuttons zum Einsatz kommen. Das unterstützt auch einen normalen Anwender bei der Bedienung der App und vermeidet fehler-hafte Eingaben und Systemzustände.

Generell sollte die Anwendung nicht mit In-formationen überladen werden. Zudem ist eine einfache und übersichtliche Navigationsstruk-tur sehr wichtig. Jede View sollte genau eine Aufgabe erfüllen, etwa die Eingabe eines Such-kriteriums oder das Anlegen eines Kontakts. Um auch Sehbeeinträchtigte bei der Bedienung zu unterstützen, sollten Schriftgrößen indivi-duell vergrößerbar sein und wichtige Informati-onen zumindest eine angemessene Textgröße besitzen. Darüber hinaus ist die Verwendung von Kontrasten sehr wichtig, um auch Farb-fehlsichtigen die inhaltliche Zuordnung einfach zu ermöglichen. Diese Gestaltungsgrundsätze beruhen auf den allgemeinen Forderungen zur ergonomischen und benutzerfreundlichen Ge-staltung von Anwendungssoftware.

FazitDas Android-API bietet mittlerweile sehr umfangreiche Möglichkeiten zur barriere-freien Entwicklung von Apps. Nur wenige beziehungsweise gar keine Funktionen

müssen dafür eigens entwickelt werden. Es ist also nicht notwendig, eine App speziell nur für Blinde zu implementieren.

Bestehende Anwendungen können durch kleine Anpassungen der View-Elemente barrierefrei gestaltet werden, ohne die bis-herigen Funktionen einzuschränken. Ledig-lich bei der Abwärtskompatibilität zu älteren Android-Versionen sind gegebenenfalls Me-chanismen eigenständig zu integrieren. Wie die aktuelle Statistik zeigt, kann jedoch der Großteil der Endgeräte die meisten Accessi-bility-Funktionalitäten verwenden.

Es gibt also keinen Grund, die Barriere-freiheit bei der Entwicklung von Android-Apps außer Acht zu lassen. Das API kommt dem Entwickler sehr weit entgegen und bietet auch dem Anwender für den norma-len Einsatz der Anwendung einen echten Mehrwert, wie die Sprachausgabe, die Vor-lesefunktionen und die Sprachsteuerung. Ein einfaches und intuitives Oberflächen-Design trägt zudem zur Benutzerfreundlich-keit und Bedienbarkeit bei, was letztendlich allen Anwendern zugutekommt.

Weiterführende Links1. http://developer.android.com/guide/topics/ui/

accessibility/apps.html

Mandy Gorammandy.goram@trevisto.de

http://ja.ijug.eu/15/1/19

2. https://developer.android.com/tools/testing/testing_accessibility.html

3. https://support.google.com/accessibility/android/#topic=6007234

4. http://cmusphinx.sourceforge.net/wiki/tutorial android

Enterprise Apex: Die Neuerungen von Apex 5.0

Application Express (Apex) ist als Teil der Oracle-Datenbank seit mehr als zehn Jahren verfügbar und wird in etlichen IT-Landschaf-ten in großem Stil eingesetzt. Einige Neue-rungen von Apex 5.0 eignen sich besonders für „Enterprise Apex“.

Der Page Designer ist mit Abstand die auffälligste Änderung in der neuen Version und betrifft ausnahmslos alle Apex-Ent-wickler. Über diese große Neuerung hinaus bringt Apex 5.0 noch eine Menge neuer Funktionen für den Unternehmenseinsatz.

Das Universal Theme und die Theme-Styles erlauben es, einer Apex-Anwendung unter-schiedliche „Look & Feels“ zuzuweisen, ohne das Theme austauschen zu müssen. Der HT-ML-Code der Templates wird nicht geändert.

Vielmehr wird dem Theme ein Style zugewie-sen, der im Wesentlichen aus CSS-Angaben besteht. Mit diesen CSS-Angaben lassen sich Farbe, Schriftart, Linienbreite und mehr än-dern. Die Templates bleiben unberührt.

Bisher waren die statischen Dateien eines Apex-Workspaces in Bilder, CSS und sonstige statische Dateien unterteilt. Nun sind sie zu-sammengefasst. Entwickler können zudem zu jeder Datei einen Verzeichnispfad hinterlegen: Das ist sehr nützlich, wenn mehrere Dateien hochgeladen werden, die sich gegenseitig mit relativen URL-Pfaden referenzieren. Auch können statische Dateien als „.zip“-Dateien hochgeladen und innerhalb von Apex automa-tisch entpackt werden. Dafür nutzt das Ent-wickler-Tool das PL/SQL-Paket „Apex_ZIP“,

das auch das Ein- und Auspacken von ZIP-Archiven in der Datenbank ermöglicht.

Ein weiteres PL/SQL-Paket dürfte nicht nur für Apex-Entwickler hochinteressant sein: „Apex_JSON“ gibt dem Anwender eine PL/SQL Schnittstelle zur Arbeit mit JSON-Daten. Diese kann auf 12c-Datenbanken mit der neuen JSON-Funktionalität auf SQL-Ebene kombiniert werden.

Einen umfassenden Einblick in die neuen Funktionen von Apex 5.0 gibt die vom Apex-Entwicklerteam gepflegte Liste der neuen Funktionen (siehe „https://apex.oracle.com/pls/apex/f?p=65339“) sowie das Statement of Direction (siehe „http://www.oracle.com/technetwork/developer-tools/apex/applica-tion-express/apex-sod-087560.html“).

Mandy Goram ist eine erfahrene Front- und Back-End-Entwicklerin. Sie arbeitet als IT-Beraterin für die TREvis-to GmbH in Nürnberg. Ihre aktuellen Schwerpunkte sind Daten-Analyse und Stammdaten-Management (MDM). Privat be-schäftigt sie sich unter anderem mit der Entwicklung von Android Apps und der Thematik "Usability".