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.
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?
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:
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 .
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:
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:
Dermed har vi replikert databasen for lagring av rapporter. Deretter må vi kopiere acralyzer CouchApp slik at vi kan visualisere dataene:
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:
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:
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:
Som tidligere nevnt i denne opplæringen, er implementering av ACRA veldig enkelt og krever bare noen få raske trinn.
Først må vi inkludere biblioteket som en avhengighet på en av følgende måter:
Som en avhengig avhengighet:
ch.acra acra X.Y.Z
Som grad avhengighet:
compile 'ch.acra:acra:X.Y.Z'
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.
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:
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.
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.
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.
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