von Lars Denis Kohl und Sebastian Lück

• Dies ist Teil 1, es gibt einen zweiten (Teil 2) dieses Artikels.

Dazu interessieren drei Teilgebiete.

• Erstens: Welche Möglichkeiten bieten die mobilen Geräte?
• Zweitens: Welche Plattform bietet die benötigten Möglichkeiten, und welche Risiken sind beim Betrieb zu berücksichtigen?
• Drittens: Welche Wege der Implementierung gibt es?

Zur ursprünglichen Frage: „Kann man die IBM i als Basis für mobile Anwendungen nutzen?“

Es gibt eine einfache Antwort: „Ja, auf jeden Fall!“

Erstens: Welche Möglichkeiten bieten die mobilen Geräte?

Die Auslieferung der Daten kann direkt von der IBM i (bzw. AS/400) erfolgen. Hierfür ist es notwendig, auf der Datenbankinstanz eine Schnittstelle zur Verfügung zu stellen. Diese kann als Anwendung z. B. in JAVA oder PHP realisiert werden. Für die Auslieferung der Ergebnisse der Datenbankabfragen nutzt man ein Format, beispielsweise XML oder JSON. Besonders JSON (JavaScript Object Notation) ist in der Implementierung sehr schnell umsetzbar.

Listing 1 JAVA Servlet Implementierung:
package com.matter8.eventmap.rest;
import java.io.IOException;
import javax.servlet.ServletException;
import javax.servlet.annotation.WebServlet;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import com.matter8.eventmap.database.*;
import com.matter8.eventmap.json.JsonMessage;
import java.io.*;
import java.sql.*;
import java.util.ArrayList;
/**
* Servlet implementation class sendOpener
*/
@WebServlet(„/sendOpener“)
public class SendOpener extends HttpServlet {
private static final long serialVersionUID = 1L;
/**
* @see HttpServlet#HttpServlet()
*/
public SendOpener() {
super();
// TODO Auto-generated constructor stub
}
/**
* @see HttpServlet#doGet(HttpServletRequest request, HttpServletResponse response)
*/
protected void doGet(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException {
// TODO Auto-generated method stub
System.out.println(request.getRequestURL());
System.out.println(„Anfrage“);
PrintWriter out = response.getWriter();
out.print(Message());
out.close();
}
/**
* @see HttpServlet#doPost(HttpServletRequest request, HttpServletResponse response)
*/
protected void doPost(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException {
// TODO Auto-generated method stub
//Server Antwort generieren
PrintWriter out = response.getWriter();
out.print(Message());
response.flushBuffer();
out.close();
}p
rivate String Message(){
String msg = ““;
// JSON Object bereitstellen
ArrayList head = new ArrayList();
ArrayList bodyKeys = new ArrayList();
ArrayList bodyValues = new ArrayList();
JsonMessage jm = new JsonMessage();
DBConnection dbcon = new DBConnection();
Connection con = dbcon.getConnection();
try {
Statement stmt = con.createStatement();
Statments st = new Statments();
//Datenbank abfrage
ResultSet HeadRs =
stmt.executeQuery(st.selectAktuellHeadByCustomer(„Lebensstern“));
HeadRs.next();
//zerlegen der Antwort des SQL Servers

head.add(HeadRs.getString(“name“));
head.add(HeadRs.getString(“type“));
Statement stmt1 = con.createStatement();
ResultSet BodyRs =
stmt1.executeQuery(st.selectBodyByCustomerId(HeadRs.getInt(“id“)));
HeadRs.close();
if(BodyRs != null){
while(BodyRs.next()){
bodyKeys.add(BodyRs.getString(“bodykey“));
bodyValues.add(BodyRs.getString(“bodyvalue“));
}
}else{
bodyKeys.add(“ “);
bodyValues.add(“ “);
}m
sg = jm.getMessage(head , bodyKeys, bodyValues, “none“);
//Fehlerbehandlung
} catch (SQLException e) {
e.printStackTrace();
return jm.onError(“No Data“);
}finally{
}
return msg;
}
}

Die Daten können dann entweder über den IBM WebSphere Applications Server oder eine eigene TCP/IP
Schnittstelle an das Endgerät übermittelt werden. Diese strukturierte Datenzusammenstellung wird dann auf
der Gegenseite wieder zerlegt.

In Listing 2 sieht man eine Implementierung in Objective-C.
// Created by denis kohl on 23.04.13.
// Copyright (c) 2013 denis kohl. All rights reserved.
//
#import “RequestOpener.h“
@implementation RequestOpener
@synthesize package,error,head,type,zeit,text;
- (id) initWithURL:(NSString *) url
{
//Initalisrung des des Obejkts
self = [super init];
//Vorbereitung des HTTP Requests
NSMutableURLRequest * request = [[NSMutableURLRequest alloc] init];
[request setHTTPMethod:@“GET“];
[request setURL:[NSURL URLWithString:url]];
NSOperationQueue *queue = [[NSOperationQueue alloc] init];
//Vorbelegung der Ausgabe
text = [NSString stringWithFormat:@“No network connection“];
zeit = [NSString stringWithFormat:@“19:00 - 02:00“];
//Ausführen der Abfrage
[NSURLConnection sendAsynchronousRequest:request queue:queue
completionHandler:^(NSURLResponse *response, NSData *data, NSError *err)
{
//Überprüfung der Rückgabe
if ([data length] > 0 && err == nil)
{
NSError * e = [[NSError alloc] init];
NSLog(@“Response: %@“, data);
//Parsen des JSON Objekts in Lokale Werte.
NSDictionary * jsonArray = [NSJSONSerialization
JSONObjectWithData:data options:NSJSONReadingMutableContainers|
NSJSONReadingAllowFragments error:&e];
error = [jsonArray valueForKey:@“error“];
NSDictionary * bodyDict = [jsonArray valueForKey:@“body“];
NSDictionary * headDict = [jsonArray valueForKey:@“head“];
if ([[headDict valueForKey:@“name“]
isEqual:@“Lebensstern“]&& [[headDict valueForKey:@“type“]
isEqual:@“Aktuell“]) {
text = [bodyDict valueForKey:@“text“];
zeit = [bodyDict valueForKey:@“zeit“];
}
}
}];
return self;
}
@end

Ein mobiles Gerät, z. B. Smartphone oder Tablet, kann die Möglichkeit bieten, dass Personen auf Informationen zugreifen können, auch fernab des Arbeitsplatzes oder sogar außerhalb des Büros. In der Regel wird das ermöglicht durch eine spezielle Anwendung – eine sogenannte App. Die angesprochenen mobilen Geräte sind hingegen von der Leistungsfähigkeit her nur vergleichbar mit preiswerten (also langsamen) Arbeitsplatz-gebundenen Desktop Geräten. Ein Vorteil im Vergleich von mobilen Geräten mit Desktop System liegt jedoch zumeist im günstigeren Preis. Einige Android-basierte Geräte sind für teilweise weit unter 300 Euro erhältlich.

Die Frage lautet: Ab wann macht ein Mehraufwand für Entwicklung, Gerätebeschaffung und Administration Sinn?

Eine generelle Antwort lässt sich hierauf so noch nicht geben.

Die Antwort ist: „Es kommt drauf an.“

Es kann Sinn machen, wenn Tätigkeiten vorhanden sind, die sich sehr häufi g wiederholen und normierbar sind, also beispielsweise durch Formulare abgebildet werden können. Besonders sinnvoll kann dieses werden, wenn zusätzliche weitere Optionen der genutzten mobilen Endgeräte verwendet werden können. Also z. B. Bluetooth, WLAN, GPS, Blitz, Kamera, Scanner, Bilderkennung, biometrische Eingaben (Unterschriften, Fingerabdrücke, …), usw. … Teilweise könnten so auch vollwertige Endgeräte (Desktops, Notebooks) ersetzt werden. Dies ist denkbar für Vertriebsmitarbeiter, Kundenbetreuer, Lagerdisponenten usw.

Neben der spezifischen Anwendung durch die App, sind natürlich auch Funktionen wie eMail, Office-Äquivalente oder sogar Notes-ähnliches möglich. Somit reicht es für viele dienstliche Belange aus. Dieser Vorteil lässt sich besonders gut für den Aussendienst ausspielen, da die Datensicherheit hier meist einfacher gewährleistet werden kann. Dies gilt allerdings eigentlich nur für Apple und eingeschränkt Blackberry und mobiles Windows (Windows RT, Microsoft Windows Phone 8). Bei Android muss man aufgrund der Veröffentlichungs- Politik von Apps über den Store „Google Play“ hier mit Abstrichen rechnen. Da neue Apps in der Regel nur über die Stores installierbar sind – vereinfacht dies die Administration gewaltig. Weiterhin sind normalerweise keine verbreiteten Malware Programme bzw. Viren bekannt – ausser bei Android.

Besonders bei Apple sind durch den Prüfprozess bei der Veröffentlichung kaum aggressive oder schädliche Inhalte möglich. Wann und wie man eine Anwendung für einen Endkunden plant, wird in einem gesonderten Artikel betrachtet.

Zweitens: Welche Plattformen sind aktuell verfügbar?

Es gibt derzeit vier große Anbieter für mobile Plattformen. Apple startete 2007 mit dem iPhone als erster Hersteller die mobile Plattform mit eigenem Entwicklungswerkzeug und Store, so daß eine Komplettlösung für mobile Applikationen entstand. Von Anfang an stand das Einbinden externer Entwickler im Mittelpunkt, da diese ihre Software (die Apps) über Apple vertreiben sollten. Das zugehörige Betriebssystem wird unter dem Namen iOS angeboten. Zu Spekulationen zur Namensähnlichkeit von iOS und IBM i enthalte ich mich.

Technisch gesehen ist iOS ein Derivat vom Berkley System Demon (BSD), genauer Free BSD. Somit ein Unix. Googles Android wurde im Oktober 2008 veröffentlicht. Android OS hat seine Wurzeln in der Linux Gemeinde. Allerdings wurde die Kompatibilität weitgehend aufgelöst – so weit, dass man es heute als eigenständiges Betriebssystem bezeichnet. Es gibt eine Vielzahl von Anbietern, die Android-basierte Geräte anbieten. Vom Highend Gerät Samsung S4 Galaxy bis hin zu unter 50 Euro Geräten. Der große Vorteil der breiten Hardwarevielfalt mit entsprechend weiter Akzeptanz und Verbreitung hat sich inzwischen als ernstzunehmendes Problem für die Android App Entwickler herausgestellt. Denn eine allgemeingültige Entwicklung einer App für beliebige Hardwarehersteller ist mit besonders schwer vorhersagbaren Kosten verbunden. Somit stehen die Entwickler bei der App Entwicklung vor großen Herausforderungen.

 

Kostenfaktor

Um den Kostenfaktor für die App Entwicklung einschätzen zu können, sind unterschiedliche Punkte zu betrachten. Sowohl was die Leistungswerte der Hardware angeht, wie auch schlichtweg das Vorhandensein von unterschiedlichen Hardware-Komponenten. Nahezu jeder Hardware-Hersteller ist inzwischen, um seine Hardware besser zu nutzen von der ursprünglichen Google Software Distribution in vielen wesentlichen Punkten abgewichen. Somit gibt es in der Praxis unterschiedliche „Androids“. Dies, die mangelnde Sicherheitsüberprüfung und der unterschiedliche Aufbau der Bedienelemente machen es für die Haus-interne Administration anspruchsvoll die gewünschten Standards einzuhalten oder zumindest zu erreichen.

Allerdings sind diese Android Geräte im Vergleich zu Apple Geräten meist günstiger in der Anschaffung. Bemerkenswert ist das überraschende Comeback des Unternehmens Blackberry. Die Modelle Q10 und Z10 gehören der Fachpresse nach mit zu den besten auf dem Markt verfügbaren Geräten. Zudem ist die überarbeitete Version des Blackberry OS inzwischen sogar dazu in der Lage, neben den ureigenen speziellen Blackberry Anwendungen auch Android Apps zu unterstützen.

Dann gibt es noch Microsoft. Windows RT und Windows Phone 8 sind der nächste Versuch von Microsoft in den Markt für mobile Endgeräte einzusteigen. Bei der Vertriebsplattform Windows Store hat Microsoft viele Aspekte vom Vorbild Apple iTunes Store übernommen, so dass man hier ähnliche Nutzungsbedingungen und Richtlinien für die Veröffentlichung vorfindet. Bevor man sich jetzt auf eine Entwicklung einer eigenen App einlässt, sollte man sich mit dem Thema Investitionsschutz befassen.

Plattformen mit Zukunft?

Welche Plattform wird voraussichtlich in 2–5 Jahren noch verfügbar sein? Wird das Betriebssystem und die Hardwareplattform jetzt und vorraussichtlich zukünftig weiterentwickelt? Wie sieht es mit der Anzahl und Verfügbarkeit von fähigen Entwicklern aus? Gibt es weitere Funktionen, die benötigt werden die in absehbarer Zeit umgesetzt werden sollen?

Allgemein kann man für die Verfügbarkeit einer Plattform zwei Kriterien für ihre Beurteilung heranziehen. Erstens die Anzahl der verfügbaren Apps und damit Flexibilität beim Einsatz der Geräte. Zweitens die Roadmap der Entwicklung des Betriebssystems und der dazugehörenden Hardware. Hier lag lange die größte Schwäche von Blackberry.

Dies wurde allerdings mit dem neuesten Release gelöst, da jetzt Android Apps verwendbar sind. Bei Microsoft ist die angesprochene Roadmap bis heute bislang noch nicht gut erkennbar. Die Software ist nach-wie-vor proprietär, und wird es vermutlich auch vorerst bleiben. Der Vorgänger, Windows Phone 7, wurde nach nicht mal einem halben Jahr wieder abgekündigt. Für die Entwicklung von Windows RT bzw. Windows Phone 8 Apps kann eine solche Abkündigung eine Katastrophe darstellen, da mit der Plattform auch der Markt verschwindet. So ein Vorgehen vermindert das Vertrauen der Entwickler in eine Plattform und lässt die Bereitschaft für vorweg notwendige Investitionen rapide sinken. Googles Android hat weltweit die höchste Durchdringung durch die Absatzzahlen der Geräte. Allerdings sollte man hier einen Blick auf die Käufer der Geräte werfen.

Im Gegensatz zu allen anderen Herstellern verteilen sich die Käufer von Android Geräten über das ganze soziale Spektrum. Dem entgegen adressieren Apple, und vor allem Blackberry, eher finanzstarke Käufer. Dies sieht man bei Betrachtung der Umsatzzahlen der AppStores. Und hier ist Apple führend. Durch den Weggang von Andy Rubin, den Begründer des Android Projektes ist deren Roadmap gefährdet. Der grösste Vorteil, den Android als Plattform bietet, ist dass Java als Programmiersprache genutzt wird. Dadurch gibt es eine Breite Basis an Entwicklern, die man für Projekte anwerben kann. Auch sind die Entwicklungswerkzeuge meist frei verfügbar. Apple hingegen positioniert sich enorm konversativ – egal was man von dem Unternehmen aus Cupertino hält. Solide sind sie, so dass man die Produkte mit dem angebissenen Apfel auf jeden Fall beachten sollte. Es scheint nicht zu erwarten, dass Apple in den nächsten zwei Jahren den Geschäftsbetrieb aus kaufmännischen Gründen einstellen müsste. Nachteilig stellt sich der sehr umständliche Prozess der Veröffentlichung dar, genauso wie die erzwungene Verwendung der proprietären Programmiersprache Objective-C und den beiden Frameworks Cocoa und Quarz.

In den letzten fünf Jahren hat sich eine beachtliche Entwicklergemeinschaft gebildet. Dies sieht man auch an den gewaltigen Zahlen der aktuellen Objective-C Projekte, aufzufi nden unter: http://www.tiobe.com/index.php/content/paperinfo/ tpci/index.html.

Einen Punkt sollte man hier noch bedenken: Um eine App für iPhone oder iPad zu entwickeln, benötigt man die Entwicklungsumgebung XCode von Apple, diese ist frei verfügbar. XCode ist aber nur auf einem Apple Computer lauffähig.

Drittens: Welche Wege der Implementierung gibt es?

Es gibt grundsätzlich drei Wege der Implementierung:

1. Man kann einfache Anwendungen, wie zum Beispiel eine Datenerfassung als HTML Anwendung aufbauen. Hierbei ist es nötig, eine explizite Serveranwendung zu entwickeln. Diese kann dann auch als Browser Anwendung für Desktops und Notebooks benutzt werden. Allerdings ist es damit absolut nicht möglich, lokale Ressourcen zu nutzen, wie z. B. Kameras, Speicher, Zusatzgeräte, die an das mobile Gerät angeschlossen sind. Weiterhin kann die Anwendung nicht über die Stores veröffentlicht werden. Vorteil ist, dass die Anwendung auf allen Endgeräten verfügbar ist.
2. Es gibt mehrere Frameworks, die entwickelt wurden um Plattform-unabhängige Apps zu erzeugen. Hier fallen allerdings nicht zu unterschätzende Lizenzkosten an. Die zwei bekanntesten sind Kony http://www.kony.com von der gleichnamigen Firma und IBM Worklight. Beide erlauben einen weitgehenden Zugriff auf die Ressourcen der mobilen Geräte. Das Endgerät ist immer an eine Server-seitige Anwendung angebunden. Weiterhin gibt es derzeit nur wenig Experten für beide Entwicklungswerkzeuge.
3. Als letzte Möglichkeit bleibt die native Entwicklung. Diese wird immer dann genutzt, wenn man entweder alle Ressourcen eines Endgerätes verwenden will oder wenn nur eine Plattform unterstützt werden muss, was gerade bei einer Haus-internen Anwendung der Fall ist.

Anfangs umriss ich, wann eine App-Anwendung sinnvoll erscheint. Nun einige Beispiele:

Derzeit gibt es bei einer der deutschen Autovermietungen eine Teststellung. Ziel ist es, den Übergabe- und Rückgabe-Prozess zu vereinfachen. Eingesetzt werden hier Apple iPads. Die Vorteile sind, dass die Kunden direkt auf dem Tablet unterschreiben können. Weiterhin ist es durch die Kamera möglich, Schäden sofort zu dokumentieren. Dies war bislang nur über die Verwendung einer Kompaktkamera möglich. Dann mussten die Bilder in Personal-aufwändiger Handarbeit den Verträgen hinzugefügt werden. Dieser Anwendungsfall (Usecase) kann wohl 1:1 auf Wohnungsverwaltungen, Warenübergaben und Besichtigungen übertragen werden.

Mögliche Anwendungen im Lagerbereich sind denkbar, aber es werden Zusatzgeräte benötigt (Barcode-Reader und ähnliches), diese können über Bluetooth mit dem Endgerät verbunden werden. Praktisch, denn Praxis- Tests zeigten, das die Datenerfassung durch die integrierte iPad-Kamera und die integrierte Bilderkennung viel zu langsam war.

Im Außendienst kann die Verbindung zwischen Kamera und Eingabegerät sehr interessant sein. Bilder, die den Zustand z. B. eines Fahrzeugs oder einer Warenlieferung dokumentieren, können sofort in einen Bericht oder Vertrag eingebunden werden.

Der letzte noch zu behandelnde wichtige Punkt ist die Kunden App. Also die Anwendung, die der Kunde direkt nutzt. Hier gibt es mehrere Möglichkeiten die umgesetzt werden können.

Erstens,

eine reine Werbe Anwendung. Dies wir zum Beispiel von Automobil Herstellern genutzt, z.B. um neue Modelle vorzustellen. Dies kann auch bei ähnlich komplexen Produkten sinnvoll sein. Die Produktinformationen können z. B. auch an eine Spiel gekoppelt werden.

Zweitens,

die App als Vertriebs- und Service-Instrument zu nutzen. Die App kann genutzt werden, um Termine zu vereinbaren, Produkte und Dienstleistungen zu bewerben, so dass ein Kunde z. B. einen Servicetermin direkt per Knopfdruck buchen kann. Gerade wenn eine engere Kundenbindung geschaffen werden soll, kann dies ein Mittel sein um einen kostengünstigen Weg zu wählen. Die App erzeugt hier auch ein einheitliches Format der Anfrage, so dass diese automatisch bearbeitbar wäre. Zudem können über die App sogenannte Push-Nachrichten auf das Endgerät transportiert werden, die auf aktuelle Angebote aufmerksam machen sollen. Zum Beispiel könnte ein Anbieter seine Kunden rechtzeitig auf den anstehenden saisonalen Reifenwechel aufmerksam machen.

Drittens

gibt es noch die Möglichkeit, dass schon mit dem Verkauf der App Umsatz erzielt werden kann. Es bieten verschieden Stahlhersteller deren Know-how via App an.

Weitere Möglichkeiten werden nicht aufgezählt, der Phantasie sind jedoch keine Grenzen gesetzt. ♦

PROGRAMMIERUNG IBM i und SmartPhones Lars Denis Kohl absolvierte das Studium der Informatik an der FU-Berlin und ist seit 2003 als freier Dozent tätig. Mit Schwerpunkt 2007-2011 ist er Tutor im Rahmen der IBM Akademische Initiative Deutschland sowie seit 2010 freier Entwickler und Projektmanager für mobile Anwendungen. Er ist Co-Founder und CTO der Matter 8 GmbH.