The Day After

Post on 14-Nov-2014

198 views 1 download

Tags:

description

Speaker: Lars Röwekamp und Danny Preußler (Groupon) Die eigene App ist finalisiert, ausgiebig getestet und seit „gestern“ im Google Play Store verfügbar. Wer allerdings glaubt, dass jetzt die Arbeit getan ist, der wird in dieser Session eines besseren belehrt. Dank Google Play Store Monitoring, Crash-Reporting Tools und proaktiven Einsammeln von User Feedback, bekommt der Android Entwickler mehr als ausreichend Mittel an die Hand, Informationen über das Laufzeitverhalten der eigenen App zu sammeln, um diese so auch nach dem Release noch weiter optimieren zu können. Werden diese Möglichkeiten geschickt kombiniert, kann man auch im Fehlerfalle eine gute User Experience erzeugen und erhält am Ende eine positive Nutzerbewertung im Store – was möchte man mehr.

Transcript of The Day After

Danny Preussler | Groupon GmbH Lars Röwekamp | open knowledge GmbH

The Day after

Quelle: https://www.flickr.com/photos/laihiu/4407979507/ Work hard ...

Quelle: http://www.flickr.com/photos/ilovelegends/211268672

... Play hard!

Quelle: http://www.flickr.com/photos/el_ramon/14080756354

Vacation

Waik up!

What the ... !

Quelle: https://c1.staticflickr.com/9/8053/8407563525_7b5af52459_z.jpg

Fehler erkennen Probleme beheben

Zum Upgrade motivieren KEINE negative Bewertung

Road to „Super App“ Quelle: https://www.flickr.com/photos/aigle_dore/5849712695/

In-App Logging

Crash Reporting

Rollout-Strategie

Update-Zyklen

App Monitoring

In-App Logging

Android Logging

e(String tag, String message) w(String tag, String message) i(String tag, String message) d(String tag, String message) v(String tag, String message)

wtf(String tag, String message)

LogCat

LogCat

Logs: main, system, event, radio

Log Level Kontrolle public class MainActivity extends Activity {

@Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState);

// home-brew log level control if (AppLog.isDebugEnabled()) {

Log.d(TAG, "onCreated called"); }

setContentView(R.layout.activity_main);

} }

Prepare for Release

Log Kontrolle public class MainActivity extends Activity {

private final static String TAG = "MainActivity"; private final static boolean DEBUG= true; @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState);

// home-brew logging control if (DEBUG) {

Log.d(TAG, "onCreated called"); }

setContentView(R.layout.activity_main);

} }

Log Kontrolle public class MainActivity extends Activity {

private final static String TAG = "MainActivity"; @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState);

// FALSE, enable with “adb shell setprob log.tag.MainActivity DEBUG“ if (isLoggable(TAG, Log.DEBUG)) { Log.d(TAG, "onCreated called");

}

setContentView(R.layout.activity_main); } }

ProGuard

Roboguice

Roboguice •  kein Debug & Verbose im Release •  autom. Loggen von Context-Infos •  bessere Performance •  Override Möglichkeiten

– Format – Log-File

Was, wann, wie loggen? •  Fehler grundsätzlich via e •  Probleme via w •  Business LifeCycle via i •  Component LifeCycle, Values etc. via d

•  WTFs via wtf

Was, wann, wie loggen? •  Ausreichend Kontext-Info loggen, um

einen Fehler, ein Problem, einen fachlichen Ablauf identifizieren und beheben zu können.

Ok, aber ... •  Wie komme ich an die „Logs“ meiner

App-User?

Crash Reporting

Worum geht‘s

Worum geht‘s •  Laufzeitinformationen sammeln •  Laufzeitinformationen senden •  Laufzeitinformationen auswerten

•  Unerwartetes User-Verhalten •  Unerwartete Werte in der App •  Allgemeines Exceptions •  Crashes

Womit geht‘s •  Google Developer Bordmittel

•  ACRA (plus ...) •  HockeyApp (plus ...) •  BugSense •  ...

Google Developer Console

Google Developer Console

Google Developer Console

Google Developer Console

Google Developer Console

Google Developer Console •  „gute“ Übersicht •  „nette“ Mischung an Informationen

•  keine Zuordnung Fehler/Geräte •  keine Zuordnung Fehler/Versionen •  nur Stacktraces ohne Zusatzinfo

ACRA

ACRA •  klinkt sich bei „Ausnahmen“ dazwischen •  erstellt „Crash Reports“ •  reichert „Crash Reports“ um Kontext an •  sendet „Crash Reports“ an Backend(s)

•  frei & open source

•  benötigt Internet-Permission

ACRA Kickstart

ACRA Modes •  Silent (default) •  Toast •  Notification •  Dialog

ACRA Modes - Silent

ACRA Modes - Toast

ACRA Modes - Notification

ACRA Modes - Dialog

ACRA Reports

ACRA Modes - MyReport

Android Intent mit ACTION_SEND auf

BTW eMail ist auch möglich:

ACRA Modes - MySender

ACRA Advanced Features •  eigene Report Key/Values •  Zugriff auf alle Logs inkl. Filter •  Zugriff auf DropBoxManager •  Konfiguration durch Nutzer (via Prefs) •  Versenden von Preferences •  Cought Exceptions / Silent Exceptions

ACRA Backends •  Google Forms •  ACRA Analyser (hosted & self hosted) •  ACRA Reporter (hosted & self hosted) •  BugSense (hosted) •  HockeyApp (hosted)

•  My ACRA Backend (home-brew)

ACRA Analyzer

ACRA Analyzer

ACRA & BugSense

ACRA & BugSense

ACRA MyBackend

http://yourserver.com/yourscript/fe24835f-8117-4639-bfea-f57c77205771

Unique Report ID

ACRA & Co. •  direktes Nutzerfeedback (ohne Google) •  Fehler/Device/Version Zuordnung

•  mehr Informationen •  qualifiziertere Informationen •  Informationen individuell anpassbar

•  Traffic-Aufkommen steuerbar

Rating aus der App heraus!

public void someMethod() { Uri uri = Uri.parse("market://details?id=“+ APP_NAME); Intent intent = new Intent(Intent.ACTION_VIEW, uri); startActivity(intent); }

Rollout •  „Dogfood“ builds •  Interne oder externe Beta-Phase!

Rollout •  Google Play Alpha/Beta Channel

Rollout •  Zutritt erfolgt über

Google Mail oder G+ Gruppen

Rollout

Rollout •  Vorteile:

– Tester bekommen normale Play-Store Updates

– Wenn Test beendet, wieder Teil der „normalen User“ ohne Deinstallation

Staged Rollout •  App geht nur an Teil der Nutzer:

5%, 10%, 20% 50% •  Kritische Fehler betreffen nur

Teilgruppe •  Langsames Steigern möglich

What does your app when it‘s not crashing?

Monitor your app!

Monitor your ratings •  Ratings ernst nehmen:

bester Kanal zu den Nutzern! Nächstes Feature ist vermutlich schon als Review gewünscht

Monitor your traffic •  Serverprobleme werden auf die App

geschoben •  App ist anders als Web!

Deinstalliert ist deinstalliert!

goodbye by woodleywonderworks, CC BY 2.0, https://www.flickr.com/photos/wwworks/5841979717

•  Nutzerverhalten verstehen lernen •  Welche Geräte und Android Versionen

sind eingesetzt

Monitor your app: Google Analytics

Monitor your app: Google Analytics

•  The number of active users are using their applications. •  From where in the world the application is being used. •  Adoption and usage of specific features. •  Crashes and exceptions. •  In-app purchases and transactions. •  And many other useful metrics...

Monitor your app: Google Analytics

GoogleAnalytics.getInstance(this) .reportActivityStart(this);

... .reportActivityStop(this);

Monitor your app: Google Analytics

•  Seit v4 Teil der Play Service •  EasyTracker nicht mehr unterstützt

aber: GoogleAnalytics.getInstance(this) .enableAutoActivityReports(..)

Monitor your app: New Relic

•  App Performance messen •  Netzwerk-Latenzen erkennen

z.B. auch in bestimmten Regionen •  In App Performance messen

Monitor your app: New Relic

Monitor your app: New Relic

Monitor your app: New Relic

Monitor your app: New Relic

Updates •  Balance zwischen zu oft und zu selten •  Balance zwischen

buggy (Hotfix Flut) und kaum gepflegt

Updates •  Fakt:

Jedes Update bringt Traffic „newsletters of mobile world“

•  Erfahrungswert: Update alle 2-6 Wochen

Updates

Kanban board by Sébastien Delest, CC BY 2.0, https://www.flickr.com/photos/seb314fr/8851499401

Updates •  Schnelle Entwicklungszyklen z.B. kurze

Scrums müssen nicht immer in Release münden aber releasebar sein!

•  Kanban sehr gut geeignet, ab bestimmtem Punkt wird releast

Updates •  Acntung!

Es dauert erfahrungsgemäß 2 Wochen bis >50% der Nutzer neue Version haben

Updates •  Vorsicht bei

gleichzeitigen Server-Updates!

•  Update ist schuld!

Bro

ken

iPho

ne 4

by

Dav

eOnF

lickr

, CC

BY

2.0,

http

s://w

ww

.flic

kr.c

om/p

hoto

s/rn

ddav

e/50

9402

0069

Updates •  Vorsicht bei neuen Berechtigung:

– Nutzer müssen zustimmen! à Kein Auto-Update!

– Nicht mit Hotfixes vermischen!

stamps by Joel Kramer, CC BY 2.0, https://www.flickr.com/photos/75001512@N00/2344294338

Updates •  Vorsicht bei neuen Berechtigung:

– Erfahrungsgemäß dauert es 2-3 Versionen(!) bis alle Nutzer geupdatet

– Jede Berechtigung kostet Nutzer!

goodbye by woodleywonderworks, CC BY 2.0, https://www.flickr.com/photos/wwworks/5841979717

Updates

•  Es werden immer ältere Versionen verbleiben!

Floppy Computer Disks by Intel Free Press, CC BY 2.0, https://

www.flickr.com/photos/intelfreepress/10963767235

Updates

•  Manuelles force update?

•  Message an Nutzer per API?

•  Versionen für alte Geräte bereitstellen?

STOP POLICE! by Highway Patrol Images, CC BY 2.0,

www.flickr.com/photos/special-fx/4545067655

Updates •  Tip: Automation Tests der alten

Versionen mittels Branch weiter laufen lassen um Probleme mit Serveränderungen zu erkennen

Thank you