Mobile meets Enterprise

Arne Limburg | open knowledge GmbH

Mobile meets Enterprise

Arne Limburg

Head of Architecture and Technology

open knowledge GmbH

@ArneLimburg

@_openknowledge

www.openknowledge.de

Meine Person

„You know what? We need an App!“

„Why me!“

„iPhone, Android, Black Berry,

Symbian, Windows Mobile, ...?

Feature Phone, Smartphone, ...?

WHAT THE HECK?“

„Which way to choose?“


„And put it in the

„Du sollst kein (i)OS neben mir haben!“

„Warum eigentlich nicht?“

74,9 81,0

14,4 12,9 2,0 3,6 4,1 1,7 4,5 0,6 0

20

40

60

80

100

Q3 2012 Q3 2013

Mar

ktan

teil

ne

ue

r D

evi

ces

(in

%)

Smartphone Betriebssysteme

Smartphone Shipment weltweit

Android iOS Windows BlackBerry Andere

(Quelle: IDC Smartphone Tracker)

39,4 56,5 58,1

39,6

1,0 3,3 0,4 1,0 0,2 0

20

40

60

80

100

Q1 2012 Q1 2013

Mar

ktan

teil

ne

ue

r D

evi

ces

(in

%)

Tablet Betriebssysteme

Tablet Shipment weltweit

Android iOS Windows Windows RT Andere

(Quelle: IDC Smartphone Tracker)

FACTS: Part 1

„The Native App Story“

a.k.a.

„Only the Best“

„Entwicklung auf Basis von Plattform-

spezifischen SDKs und Sprachen.“

„Nativer Zugriff auf Plattform- bzw.

Device-Features.“

„Sowohl im Online- als auch im

Offline-Modus verwendbar“

„Optimierte Performanz durch Nutzung

nativer APIs und direktem OS-Zugriff.“

Native Mobile Application

„Optimal zugeschnittene Tools direkt von

der Quelle und 3rd Party Anbietern.“

„Best mögliche Monetarisierung dank

eigenem App-Store.“

„Coole und vor allem echte

Mobile Community“

„No Fake - just Real.“



PROS:

• Native Look & Feel

• (fast) unbegrenzter Zugriff auf Plattform-Features

• best mögliche Perfomanz durch optimierte APIs

• kaum Grenzen bzgl. App-Design

Native


CONS:

• teuer, da jede Plattform einzeln bedient werden muss

• Kenntnisse in verschiedenen Tools/Plattformen notwendig

• kleinerer Pool an Entwicklern je Plattform

• wenig Möglichkeiten zur Wiederverwendung von Code

teuer

Lohnt sich das? Alternativen?

FACTS: Part 2

„The Mobile Web Story“

a.k.a.

„One Size fits All“

Canvas Element

Video Element

Geolocation Element

Offline Web

„Basiert auf Web-Technologien, wie

HTML 5, CSS 3 und JavaScript.“

Mobile Web Application

„Mobile Web Browser als Ablauf- und

Web Server als Auslieferungsplattform.“

„Bedingt sowohl im Online- als auch

im Offline-Modus verwendbar“

„Optimierung durch unterschiedliche

Views für unterschiedliche Plattformen

bzw. Device-Typen.“

Mobile APP

is not

Mobile Web

PROS:

• bekannte Sprache(n) & Technologien

• einheitliche Code-Basis

• Browser based Development

• einfaches Deployment

• große Reichweite

• Industriestandard, kein Plattform-Lock

• große Developer-Community

Community



CONS:

• Browser Fragmentation

• limitierter Zugriff auf Device-Capabilities

• keine Verteilung über App-Stores

• nicht immer als „App“ installierbar

• teilweise ungenügende Performanz

• eigenes Monetarizierungskonzept notwenig

Fragmentation


475 HTML5

Compability

Test Cases


„Die Entwicklung der Financial Times

iPad App hat 24 Monate gedauert. Die

Portierung auf Android noch einmal

12 Monate.“


Wer bin ich und was kann ich?:

• via Device Capabilities Database

• Zugriff online und/oder offline

• in der Regel recht aktuell

• zum Teil nicht ganz billig

• bitte nicht selber machen

• Wurfl, DotMobi, DetectRight, …

http://mobilehtml5.org/



„WHAT THE HECK - die Zweite“

Best of …

FACTS: Part 3

„The Hybrid App Story“

a.k.a.

„Best of both Worlds“

Hybrid Mobile Application

Variante A)

Code und UI Templates werden in native Binaries übersetzt

und als App installiert.

Variante B)

Code und UI Templates werden in Binary-Shell verpackt und

zur Laufzeit durch eine Runtime - z.B. einen „nacked Browser“ -

interpretiert.




„Entwicklung auf Basis von Web-Technologien,

wie HTML 5, CSS 3 und JavaScript.“

„Native App-Shell als Proxy inkl. Zugriff

auf etliche Device-Capabilities.

„Einmal schreiben, aber je

Plattform konfigurieren, bauen und

in den jeweiligen Store stellen.“

„Installation als App auf dem Device“


„Nutzt HTML 5 & Friends deutlich über die

angedachten Browser-Features hinaus.“

„Neue Plattformen können mit kleinem

Budget angegangen werden.“

„Cross-Platform Tools bedienen

den gesamten Lifecycle.“

„Nimmt dem Entwickler das Problem der

Browser-Fragmentierung ab.“


Die Idee

der Mehrwert

Die Capabilities


PROS:

• bekannte Sprache(n) & Technologien

• einheitliches Toolset & Know-how

• Zugriff auf etliche Plattform-Features

• Synchronisation von Release verschiedener Plattformen

• installierbare, verkaufbare App-Store App

• allgemeine Code-Basis für alle Plattformen

• geringe Kosten für weitere Plattformen


GRÜNDE FÜR NUTZUNG:

Wichtig: „Zugriff auf weitere Plattformen“1) 2)

Unwichtig: „zusätzliche Monetarisierung“

1) Umsetzung für neue Plattformen kostet nativ oftmals 50% und mehr

2) Anzahl unterstützter Plattformen 2011 = 3.2 / 2012 = 3.8 (4.5 mit CPT)


CONS:

• separate Konfiguration für jede Plattform

• komplizierterer Build-/Deployprozess

• gebunden an App-Store Regeln

• neue Plattform-Features werden erst spät(er) adaptiert

• verminderte Performanz gegenüber Native Apps


Should I

stay,

or should I

go?


GRÜNDE FÜR ABSPRUNG:

Top 10 - No 1: „Lack of Performance“

Top 10 - No 2: „Lack of new Features“

„The Native App Story?“

„The Mobile Web Story?“

„The Hybrid App Story“?

Best „Tool“ for the job!


„What do ya wanna do with it?“

Yahoo! Seven Mobile Modes

(„Seven Mobile Modes“ by Yahoo!, 2013)

Yahoo! Seven Mobile Modes

(„Seven Mobile Modes“ by Yahoo!, 2013)

The Mobile Day

Was will ich überhaupt anbieten?

Was ist der Mehrwert meiner App?

Content, offline, ...

Gutscheine, Location, ...

Kamera, Location, offline

„Depends ...!“

„Which way to choose?“

Was ist der Mehrwert meiner App?

> Always On

> Geolocation

> Offline Data

> Address Book

> Camera

Mobile Benefits

> Always On

> Geolocation

> Offline Data

> Address Book

> Camera

Mobile Benefits mobile meets enterprise

Client-Server Communication

HTTP

> Performance?

> Bitrate?

> Memory?

> Battery Life?

> Security?

Performance & Bitrate

mobile meets enterprise

REST over HTTP

The Server

The Server: JAX-RS

@Path("cart") public class ShoppingCartService { @GET @Path("items/{number}") @Produces("application/xml") public ShoppingCartItem getShoppingCartItem( @PathParam("number") Integer no) { return ... } }

Performance & Bitrate

BTW: Use JSON!

@Path("cart") public class ShoppingCartService { @GET @Path("items/{number}") @Produces("application/json") public ShoppingCartItem getShoppingCartItem( @PathParam("number") Integer no) { return ... } }

The Client

The Client: HTTPClient

HttpClient client = new DefaultHttpClient(); HttpGet httpGet = new HttpGet(url); HttpResponse response = client.execute(httpGet); HttpEntity entity = response.getEntity(); if (entity != null) { InputStream in = entity.getContent(); ... }

The Client: No Network on UI Thread!

public interface ShoppingCartService { @GET("cart/items") public List<ShoppingCartItem> getShoppingCartItems(); @GET("cart/items/{number}") public ShoppingCartItem getShoppingCartItem( @Path("number") Integer no); }

The Client: Retrofit

The Client: Retrofit

RestAdapter adapter = new RestAdapter.Builder() .setServer("http://www.openknowledge.de") .build(); ShoppingCartService service = adapter.create(ShoppingCartService.class); ShoppingCartItem item = service.getShoppingCartItem(5);

The Client: Retrofit async

service.loadShoppingCartItem(5, new Callback<ShoppingCartItem>() { public void success(ShoppingCartItem item, Response response) { ... } public void failure(RetrofitError error) { ... } });

JSON-Parsing auf Client & Server: Jackson

Security

HTTPS

Self-signed Certificate

AssetManager assetManager = getAssets(); InputStream in = assetManager.open("ca.cert"); CertificateFactory cf = CertificateFactory.getInstance("X.509"); Certificate ca = cf.generateCertificate(in); String keyStoreType = KeyStore.getDefaultType(); KeyStore keyStore = KeyStore.getInstance(keyStoreType); keyStore.load(null, null); keyStore.setCertificateEntry("ca", ca);


String algorithm = TrustManagerFactory.getDefaultAlgorithm(); TrustManagerFactory tmf = TrustManagerFactory.getInstance(algorithm); tmf.init(keyStore); SSLContext context = SSLContext.getInstance("TLS"); context.init(null, tmf.getTrustManager(), null); HttpsURLConnection connection = (HttpsURLConnection)url.openConnection(); connection.setSSLSocketFactory( context.getSocketFactory()); return connection.getInputStream();


AssetManager assetManager = getAssets(); InputStream in = assetManager.open("ca.cert"); CertificateFactory cf = CertificateFactory.getInstance("X.509"); Certificate ca = cf.generateCertificate(in); String keyStoreType = KeyStore.getDefaultType(); KeyStore keyStore = KeyStore.getInstance(keyStoreType); keyStore.load(null, null); keyStore.setCertificateEntry("ca", ca); String algorithm = TrustManagerFactory.getDefaultAlgorithm(); TrustManagerFactory tmf = TrustManagerFactory.getInstance(algorithm); tmf.init(keyStore); SSLContext context = SSLContext.getInstance("TLS"); context.init(null, tmf.getTrustManager(), null); HttpsURLConnection connection = (HttpsURLConnection)url.openConnection(); connection.setSSLSocketFactory(context.getSocketFactory()); return connection.getInputStream();

http://developer.android.com/training/articles/security-ssl.html

Private Preferences

public class ShoppingCartActivity extends Activity public SharedPreferences getPrivatePreferences() { return getSharedPreferences("private.pref", MODE_PRIVATE); } ... }

Server to Client aka Push

Server to Client

Long-Polling SSE

WebSockets

The Server

The Server: Websockets

@ServerEndpoint("cart") public class ShoppingCartEndpoint { @OnMessage public void receiveUpdate(Session session, String message) { ... session.getBasicRemote().sendText(answer); } }

The Client

WebSocketConnection connection = new WebSocketConnection(); connection.connect(uri, new WebSocketHandler() { public void onTextMessage(String message) { ... connection.sendTextMessage(answer); } public void onOpen() { ... } public void onClose(int code, String reason) { ... } };

The Client: Autobahn

Websockets

Selten benötigt

Wenig Daten

Serverlast

Server to Client

Push

POST

Google Cloud Services

Google Cloud Messaging

register (receive id)

send registration id

POST with registration ids

notify

Google Play Services

Retry

Multicast

Aber: Vendor-Lock

App Store Alternativen

Mobile Strategy

> Native Experience ermöglichen

Device Capabilities nutzen <

> Nicht Web Auftritt kopieren

Performance optimieren <

> Weniger ist oft mehr!

Tech follows Features!

User Experience matters!

Vielen Dank für Ihre Zeit. Kontakt: open knowledge GmbH Bismarckstr. 13 26122 Oldenburg [email protected] @ArneLimburg @_openknowledge

Questions & Answers