Det er enkelt å lage en grunnleggende Android-app. Å lage en pålitelig, skalerbar og robust Android-app, derimot, kan være ganske utfordrende .

Med tusenvis av tilgjengelige enheter pumpet ut fra mange forskjellige produsenter, forutsatt at en enkelt kode vil fungere pålitelig på tvers av telefoner, er i beste fall naiv.

Segmentering er den største kompromissen for å ha en åpen plattform, og vi betaler prisen i valutaen for vedlikehold av kode, som fortsetter lenge etter at en app har passert produksjonsfasen.

Hvorfor Android feilrapportering betyr noe

Så, hva skjer når en Android-app krasjer eller blir ikke-responsiv ? Dialogboksen 'Tving lukk' dukker opp og lar brukeren få vite at noe har gått galt. Hvis appen ble lastet ned via Google Play, vil brukeren bli bedt om å rapportere krasj ved å sende en detaljert Android-krasjrapport (inkludert tid, telefonmodell, Android-versjon, stack-trace osv.) Som du (utvikleren) kan se i utviklerkonsollen, slik at du kan adressere den skyldige feilen.

Alt dette høres veldig fint ut - men det er et stort problem med Androids standard feilrapportering: brukere har ikke en tendens til å bruke det, og lar utviklerne være uklare om tilstanden til appene sine.

Alt dette høres veldig bra ut - men det er et stort problem med å bruke Androids standard feilrapportering: brukere pleier ikke å iverksette tiltak når appene deres krasjer; faktisk velger flertallet ikke å sende i Android-feilrapporter. Hvordan kan du da, som en samvittighetsfull utvikler , få pålitelig innsikt i appens krasj og svikt?

Vi presenterer ACRA

ACRA står for “Automated Crash Reporting for Android”. Det er et gratis bibliotek som lar deg løse problemet med manuell feilrapportering med noen få kodelinjer. Når du har implementert biblioteket og alt er riktig initialisert, vil du kunne trekke ut de samme Android-feilloggene som Googles standard (pluss en haug med ekstra tilpasningsalternativer) automatisk og uten at brukeren må iverksette tiltak.

Utover det lar ACRA deg velge hvordan du vil informere brukeren om et Android-krasj, med standard er stille bakgrunnsrapportering, og alternativer inkludert tilpassede dialoger.

Inntil nylig ble ACRA støttet av Google-regneark, noe som betydde at du var i stand til å motta alle rapportene dine i en enkelt fil, vert gratis på Google Drive-kontoen din. Dessverre Google ba om at vi ikke bruker dette alternativet i fremtiden, så vi sitter igjen med et par alternativer for å sende inn data om krasjrapporter, hvorav noen vi vil dekke i denne veiledningen:

• Standard e-post (krever fortsatt brukerinteraksjon).
• Tilpasset e-post / HTTP-klient (krever omfattende oppsett).
• Tilpasset back-end (med alternativer strekker seg fra gratis til kommersielle løsninger).

I denne artikkelen vil vi analysere en av disse løsningene: være vert for ACRA-rapportene dine på en Overskyet back-end og visualisere dataene med akralysator .

Sette opp en Cloudant back-end

Det første vi må gjøre er registrere en Cloudant-konto. Selvfølgelig er det en fangst: Cloudants tjenester er ikke helt gratis, men i henhold til deres prisside det er veldig lite sannsynlig at du vil overskride den månedlige grensen på $ 5 (med mindre du har en enorm brukerbase og massevis av feil i koden din).

Når vi har registrert oss, må vi forstå hvordan ting fungerer. På et høyt nivå vil back-enden vår bestå av to komponenter:

1. En lagringsdatabase eller, for å være mer presis, en Apache CouchDB . CouchDB lagrer dataene sine i JSON-format, noe som betyr at alle rapporter sendt fra Android-enheten må samsvare med formatet for å bli satt inn som en oppføring. En databaseinnsats er en enkel HTTP POST- eller PUT-forespørsel.
2. En webapp (for analyse) eller, for å være mer presis, en CouchApp . Dette er et enkelt JavaScript-program som lar deg kjøre spørringer og vise dataene som er lagret i CouchDB-forekomsten.

For at back-end skal fungere skikkelig, må vi konfigurere disse to komponentene. I teorien kunne vi bygge databasen og appen fra kilden , og bruk deretter et verktøy for å distribuere dem til back-end-men de gode folkene i ACRA har allerede gjort det for oss. Så den enkleste tilnærmingen er å replikere en ekstern database og en ekstern app.

La oss gå videre og replikere en tom ACRA CouchDB:

• Velg 'Replikering' -delen i Cloudant-dashbordet.
• Som kildedatabase velger du ‘Ekstern database’ med http://get.acralyzer.com/distrib-acra-storage som URL.
• Som måldatabase, velg ‘Ny database’ og gi den navnet “acra- {myapp}” (uten anførselstegn). Merk at parameteren {myapp} skal være unik for appen din, og at databasenavnet må starte med “acra-”.
• Klikk ‘Repliker’.

Dermed har vi replikert databasen for lagring av rapporter. Deretter må vi kopiere acralyzer CouchApp slik at vi kan visualisere dataene:

• Velg 'Replikering' -delen i Cloudant-dashbordet.
• Som kildedatabase velger du ‘Ekstern database’ med http://get.acralyzer.com/distrib-acralyzer som URL.
• Som måldatabase, velg ‘Ny database’ og gi den navnet “acralyzer”.
• Klikk ‘Repliker’.

Merk : å kopiere acralyzer-appen er valgfritt. Du trenger ikke det hvis du bare er interessert i å lagre din Android-krasjrapport, i stedet for å visualisere dataene (vi ser nærmere på acralyzer i neste del av denne Android-opplæringen). Hvis du føler deg trygg nok med JavaScript-ferdighetene dine, kan du til og med skrive din egen analyse-app! Men det er utenfor omfanget av dette blogginnlegget.

Det siste trinnet i den første installasjonsprosessen er å legge til sikkerhetstillatelser. Cloudant gir sitt eget sikkerhetslag over CouchDB med finere kontroll over individuelle rettigheter, så for å kunne skrive en rapport til databasen vår, må vi opprette en brukerkonto med skrivetillatelser:

• Velg 'Database' -delen i Cloudant-dashbordet.
• Klikk på tillatelsesdelen (låsikon) for acra- {myapp} -databasen.
• Klikk på ‘Generer API-nøkler’.
• Skriv ned det genererte brukernavnet og passordet (vi bruker dem senere).
• Legg til skrivetillatelser for det genererte brukernavnet.

Visualisere Android-krasjrapporter med acralyzer

Når den er replikert, kan du enkelt få tilgang til acralyzer-dashbordet ved å følge https://{myapp}.cloudant.com/acralyzer/_design/acralyzer/index.html#/dashboard. Jeg innrømmer: det er ikke det peneste analyseverktøyet der ute, men det tjener formålet.

Fra toppmenyen kan du velge hvilken database du vil visualisere (det er mulig å være vert for flere databaser for forskjellige apper i et enkelt prosjekt; dette vil påvirke brukskvoten din) og forhåndsvise dataene i hovedinstrumentet. For eksempel kan du:

• Plott antall rapporter etter tidsenhet (time, dag, måned osv.).
• Se fordelingen av rapporter etter Android-spesifikke beregninger (Android-versjon, SDK-versjon, appversjon, enhet osv.).
• Oppgi alle krasjrapporter (med detaljert stakksporing) eller se alle feil (her er en “feil” en gruppe identiske rapporter hentet fra forskjellige brukere).
• Forhåndsvis detaljer for en enkelt feil, og angi statusen som løst (hvis den er løst).
• Tøm gamle eller foreldede oppføringer.

Merk at Android-krasjberegningene som er tilgjengelige for visualisering, vil avhenge av rapportene vi velger å sende fra appen vår. ACRA tilbyr en rekke rapporter felt , hvorav noen kan være ganske store eller ikke helt relevante for feilretting. For de fleste prosjekter vil de nødvendige rapportfeltene være tilstrekkelige. Disse inkluderer:

• APP_VERSION_CODE
• APP_VERSION_NAME
• ANDROID_VERSION
• PACKAGE_NAME
• RAPPORT_ID
• BYGGE
• STACK_TRACE

Implementering av ACRA i Android-prosjektet ditt

Som tidligere nevnt i denne opplæringen, er implementering av ACRA veldig enkelt og krever bare noen få raske trinn.

Legg til avhengighet

Først må vi inkludere biblioteket som en avhengighet på en av følgende måter:

• Som en .krukke filen i mappen / libs.

• Som en avhengig avhengighet:

  ch.acra acra X.Y.Z

• Som grad avhengighet:

  compile 'ch.acra:acra:X.Y.Z'

Legg til applikasjonsklasse

Deretter må vi legge til en Android-applikasjonsklasse i prosjektet vårt (eller oppdatere en eksisterende klasse, da det bare kan være en forekomst) og erklære det i AndroidManifest.xml:

...

Og sett opp ACRA der:

@ReportsCrashes( formUri = 'https://{myusername}.cloudant.com/acra-{myapp}/_design/acra-storage/_update/report', reportType = HttpSender.Type.JSON, httpMethod = HttpSender.Method.POST, formUriBasicAuthLogin = 'GENERATED_USERNAME_WITH_WRITE_PERMISSIONS', formUriBasicAuthPassword = 'GENERATED_PASSWORD', formKey = '', // This is required for backward compatibility but not used customReportContent = { ReportField.APP_VERSION_CODE, ReportField.APP_VERSION_NAME, ReportField.ANDROID_VERSION, ReportField.PACKAGE_NAME, ReportField.REPORT_ID, ReportField.BUILD, ReportField.STACK_TRACE }, mode = ReportingInteractionMode.TOAST, resToastText = R.string.toast_crash ) public class MainApp extends Application { @Override public void onCreate() { super.onCreate(); // The following line triggers the initialization of ACRA ACRA.init(this); } }

Det er det! Du må selvfølgelig erstatte alle {myapp} plassholdere med faktiske verdier, samt verdier for formUriBasicAuthLogin og formUriBasicAuthPassword.

Som du kan se fra kodebiten ovenfor, bruker vi bare de obligatoriske rapportfeltene. Legg gjerne til andre felt som kan være relevante for søknaden din.

Du kan også velge å bruke PUT i stedet for POST. I så fall vil REPORT_ID blir lagt til slutten av former som parameter.

Til slutt kan du også velge hvordan brukeren blir informert om Android-appens krasj, standard er en stille bakgrunnsrapport. I vårt tilfelle velger vi å vise en Toast-melding som gir brukeren beskjed om at krasj er rapportert, og at en feilretting snart skal være tilgjengelig.

Trenger hjelp? Her er et eksempel på prosjekt

For å se ACRA i aksjon, har jeg satt opp acra_eksempel repo på GitHub. Den har en enkel app som initialiserer ACRA ved oppstart, og la deg krasje den ved å trykke på en knapp (som deretter utløser et unntak for nullpeker). Krasjdataene sendes til et eksempel på en Cloudant-database som kan visualiseres her .

For å se dataene, logg inn med følgende legitimasjon:

• Brukernavn: medo
• Passord: akraeksempel

Alternativer til ACRA

ACRA er ikke det eneste alternativet for automatisk rapportering av Android-feil. Siden krasj sannsynligvis vil skje, er det et stort B2D-marked (Business-to-Developer) der ute som prøver å tjene penger på løsningen.

Kritterisme , for eksempel, er en veldig moden plattform for krasjrapportering. Det ser bra ut, tilbyr en rekke alternativer for dataanalyse, og er veldig enkelt å integrere. Den eneste ulempen: pris , og den gratis prøveperioden er ganske begrenset når det gjelder antall aktive brukere, dager med datalagring og støtte). BugSense er en lignende tjeneste.

Etter min mening, derimot, Crashlytics er en overlegen løsning. Inntil nylig hadde Crashlytics en freemium-modell (med betalt premium-nivå); men nå (etter deres anskaffelse av Twitter ), alle tidligere premium-funksjoner er tilgjengelige for gratis . Det er ingen brukskostnader, avgifter eller grenser. Dette er den foretrukne måten å rapportere feil for mange høyt profilerte og høyt rangerte selskaper og utviklere, da det er veldig enkelt å bruke og tilbyr kraftige analyse- og visualiseringsverktøy. Det integreres til og med med mest populære IDEer som et plugin (f.eks. Eclipse, Android Studio), så det er så enkelt å legge til Crashlytics i appen din som å velge et prosjekt og trykke på en knapp. Disse pluginene lar deg også spore krasjrapporter fra IDE uten å måtte åpne en nettleser.

Så hvorfor bruke ACRA når det er andre alternativer der ute som ser bedre ut og tilbyr flere funksjoner for samme implementeringsarbeid? Jeg gir deg to grunner.

1. Alle disse andre alternativene er lukket kilde, proprietær programvare . Selv med en kurv full av EULA-er, kan du ikke være helt sikker hvordan dataene dine blir samlet inn og håndtert. På den annen side er ACRA og acralyzer open source-prosjekter som er vert på GitHub som du enkelt kan forkaste og skreddersy etter dine behov.

2. Datamobilitet . La oss si at du er misfornøyd med Cloudant. Det er en lek å replikere og migrere dataene dine til en annen back-end. Du er garantert at dataene forblir din .

Som med mange valg, koker denne ned til personlig preferanse og fortrolighet. Sjekk ut dette Google+ tråd for mer diskusjon om de forskjellige alternativene som er tilgjengelige for å gjøre appen din mer pålitelig.

For å konkludere

ACRA er en meget robust og svært tilpassbar bibliotek som kan brukes sammen med Cloudant og acralyzer for å oppnå gratis, automatisk krasjrapportering og grunnleggende analyse for appen din, alt for minimal implementeringsinnsats.

Å skrive pålitelig Android-kode krever mye erfaring og fremsyn, men ingen av oss er virkelig allvitende. Vær forberedt på uventede krasj og feil, og vær klar til fastsette det uventede så snart som mulig. Det er den typen arbeid som går med flotte produkter og gode brukeropplevelser.

I slekt: Gjør appen din lønnsom - utnytt mobilanalyser