Zautomatyzowane raporty o awariach Androida z ACRA i Cloudant

Tworzenie podstawowej aplikacji na Androida jest łatwe. Z drugiej strony stworzenie niezawodnej, skalowalnej i solidnej aplikacji na Androida może być dość trudne.

Z tysiącami dostępnych urządzeń wypompowanych od wielu różnych producentów, założenie, że pojedynczy fragment kodu będzie działał niezawodnie na telefonach, jest w najlepszym razie naiwne.

Segmentacja jest największym kompromisem w przypadku otwartej platformy, a cenę płacimy w walucie za utrzymanie kodu, które trwa długo po tym, jak aplikacja przeszła etap produkcji.

Dlaczego raportowanie błędów Androida ma znaczenie

Co się dzieje, gdy aplikacja na Androida ulega awarii lub przestaje odpowiadać? Cóż, pojawia się okno dialogowe „Wymuś zamknięcie”, informujące użytkownika, że ​​coś poszło nie tak. Jeśli aplikacja została pobrana przez Google Play, użytkownik zostanie poproszony o zgłoszenie awarii, wysyłając szczegółowy raport o awarii Androida (w tym czas, model telefonu, wersję Androida, ślad stosu itp.), który Ty (programista) możesz wyświetlić w Konsola programisty, umożliwiająca usunięcie błędu sprawcy.

To wszystko brzmi bardzo ładnie, ale jest poważny problem z używaniem domyślnego raportowania błędów Androida: użytkownicy zwykle nie podejmują działań, gdy ich aplikacje ulegają awarii; w rzeczywistości większość decyduje się nie wysyłać raportów o błędach Androida. Jak więc możesz, jako sumienny programista, uzyskać rzetelny wgląd w awarie i awarie swojej aplikacji?

Przedstawiamy ACRA

ACRA to skrót od „Automated Crash Reporting for Android”. Jest to darmowa biblioteka, która pozwala rozwiązać problem „ręcznego raportowania błędów” za pomocą kilku linijek kodu. Po zaimplementowaniu biblioteki i prawidłowym zainicjowaniu wszystkiego będziesz mógł wyodrębnić te same dzienniki błędów Androida, co domyślne Google (plus kilka dodanych opcji dostosowywania) automatycznie i bez konieczności podejmowania działań przez użytkownika.

Poza tym ACRA pozwala wybrać, w jaki sposób chcesz poinformować użytkownika o awarii systemu Android, z domyślnym cichym raportowaniem w tle i alternatywami, w tym niestandardowymi oknami dialogowymi.

Do niedawna ACRA była wspierana przez Arkusz kalkulacyjny Google, co oznaczało, że można było otrzymywać wszystkie raporty w jednym pliku, hostowanym bezpłatnie na koncie Dysku Google. Niestety, Google poprosiło, abyśmy nie używali tej opcji w przyszłości, więc mamy kilka alternatyw dla wysyłania danych raportu o awariach, z których niektóre omówimy w tym samouczku:

• Standardowy e-mail (nadal wymaga interakcji użytkownika).
• Niestandardowy klient poczty e-mail/HTTP (wymaga rozbudowanej konfiguracji).
• Niestandardowy back-end (z opcjami od rozwiązań darmowych po komercyjne).

W tym artykule przeanalizujemy jedno z tych rozwiązań: hosting raportów ACRA na zapleczu Cloudant i wizualizację danych za pomocą acralyzer.

Konfigurowanie zaplecza Cloudant

Pierwszą rzeczą, którą musimy zrobić, to zarejestrować konto Cloudant. Oczywiście jest pewien haczyk: usługi Cloudant nie są całkowicie bezpłatne, ale zgodnie z ich cennikiem jest bardzo mało prawdopodobne, że przekroczysz miesięczny limit 5 USD (chyba że masz ogromną bazę użytkowników i mnóstwo błędów w swoim kodzie).

Po zarejestrowaniu musimy zrozumieć, jak to działa. Na wysokim poziomie nasz back-end będzie składał się z dwóch komponentów:

1. Baza danych pamięci masowej, a dokładniej Apache CouchDB. CouchDB przechowuje swoje dane w formacie JSON, co oznacza, że ​​wszystkie raporty wysyłane z urządzenia z systemem Android muszą być zgodne z formatem, aby mogły zostać wstawione jako wpis. Wstawienie bazy danych to proste żądanie HTTP POST lub PUT.
2. Aplikacja webowa (do analizy) lub mówiąc dokładniej CouchApp. Jest to prosta aplikacja JavaScript, która umożliwia uruchamianie zapytań i wyświetlanie danych przechowywanych w instancji CouchDB.

Aby nasz back-end działał poprawnie, musimy skonfigurować te dwa komponenty. Teoretycznie moglibyśmy zbudować bazę danych i aplikację ze źródła, a następnie użyć narzędzia do wdrożenia ich na naszym zapleczu — ale dobrzy ludzie z ACRA już to za nas zrobili. Najprostszym podejściem jest więc zreplikowanie zdalnej bazy danych i zdalnej aplikacji.

Przejdźmy dalej i zreplikujmy pustą bazę danych ACRA CouchDB:

• Wybierz sekcję „Replikacja” na pulpicie nawigacyjnym Cloudant.
• Jako źródłową bazę danych wybierz „Zdalna baza danych” z adresem URL http://get.acralyzer.com/distrib-acra-storage.
• Jako bazę docelową wybierz „Nowa baza danych” i nazwij ją „acra-{myapp}” (bez cudzysłowów). Pamiętaj, że parametr {myapp} powinien być unikalny dla Twojej aplikacji, a nazwa bazy danych musi zaczynać się od „acra-”.
• Kliknij „Replikuj”.

W ten sposób pomyślnie zreplikowaliśmy bazę danych do przechowywania raportów. Następnie musimy zreplikować acralyzer CouchApp, abyśmy mogli zwizualizować dane:

• Wybierz sekcję „Replikacja” na pulpicie nawigacyjnym Cloudant.
• Jako źródłową bazę danych wybierz „Zdalna baza danych” z adresem URL http://get.acralyzer.com/distrib-acralyzer.
• Jako docelową bazę danych wybierz „Nowa baza danych” i nazwij ją „acralyzer”.
• Kliknij „Replikuj”.

Uwaga : replikacja aplikacji acralyzer jest opcjonalna. Nie będziesz go potrzebować, jeśli interesuje Cię tylko przechowywanie raportu o awariach Androida, a nie wizualizacja danych (przyjrzymy się bliżej acralyzerowi w następnej sekcji tego samouczka Androida). Jeśli czujesz się wystarczająco pewnie ze swoimi umiejętnościami JavaScript, możesz nawet napisać własną aplikację analityczną! Ale to wykracza poza zakres tego wpisu na blogu.

Ostatnim krokiem procesu konfiguracji początkowej jest dodanie uprawnień bezpieczeństwa. Cloudant zapewnia własną warstwę bezpieczeństwa nad CouchDB z dokładniejszą kontrolą nad indywidualnymi prawami, więc aby zapisać raport do naszej bazy danych, musimy utworzyć konto użytkownika z uprawnieniami do zapisu:

• Wybierz sekcję „Baza danych” na pulpicie nawigacyjnym Cloudant.
• Kliknij sekcję uprawnień (ikona kłódki) dla bazy danych acra-{myapp}.
• Kliknij „Generuj klucze API”.
• Zapisz wygenerowaną nazwę użytkownika i hasło (wykorzystamy je później).
• Dodaj uprawnienia do zapisu dla wygenerowanej nazwy użytkownika.

Wizualizacja raportów o awariach Androida za pomocą acralyzer

Po replikacji pulpit nawigacyjny acralyzer jest łatwo dostępny, klikając https://{myapp}.cloudant.com/acralyzer/_design/acralyzer/index.html#/dashboard . Przyznam: nie jest to najładniejsze narzędzie analityczne, ale spełnia swoje zadanie.

Z górnego menu możesz wybrać bazę danych, którą chcesz wizualizować (możliwe jest hostowanie wielu baz danych dla różnych aplikacji w jednym projekcie; wpłynie to na limit wykorzystania) i podgląd danych w głównym panelu. Na przykład możesz:

• Wykreśl liczbę raportów według jednostki czasu (godzina, dzień, miesiąc itp.).
• Zobacz rozkład raportów według danych specyficznych dla Androida (wersja Androida, wersja SDK, wersja aplikacji, urządzenie itp.).
• Wyświetl wszystkie raporty o awariach (ze szczegółowym śladem stosu) lub wyświetl wszystkie błędy (tu „błąd” to grupa identycznych raportów pochodzących od różnych użytkowników).
• Wyświetl podgląd szczegółów pojedynczego błędu i ustaw jego status jako rozwiązany (jeśli został naprawiony).
• Usuń stare lub nieaktualne wpisy.

Pamiętaj, że dane o awariach Androida dostępne do wizualizacji będą zależeć od raportów, które zdecydujemy się wysłać z naszej aplikacji. ACRA oferuje różnorodne pola raportów, z których niektóre mogą mieć dość duży rozmiar lub mogą nie być całkowicie związane z naprawianiem błędów. W przypadku większości projektów wymagane pola raportu będą wystarczające. Obejmują one:

• APP_VERSION_CODE
• APP_VERSION_NAME
• ANDROID_VERSION
• NAZWA_PAKIETU
• REPORT_ID
• ZBUDOWAĆ
• ŚLAD STOSU

Wdrażanie ACRA w projekcie Android

Jak wcześniej wspomniano w tym samouczku, wdrożenie ACRA jest bardzo łatwe i wymaga tylko kilku szybkich kroków.

Dodaj zależność

Najpierw musimy dołączyć bibliotekę jako zależność na jeden z następujących sposobów:

• Jako plik .jar w folderze /libs.

• Jako zależność od mavena:

   <dependency> <groupId>ch.acra</groupId> <artifactId>acra</artifactId> <version>XYZ</version> </dependency>

• Jako zależność Gradle:

   compile 'ch.acra:acra:XYZ'

Dodaj klasę aplikacji

Następnie musimy dodać do naszego projektu klasę Android Application (lub zaktualizować istniejącą klasę, ponieważ może być tylko jedna instancja) i zadeklarować ją w AndroidManifest.xml:

 <application android:name=".MyApp" android:theme="@style/AppTheme"> ...

I skonfiguruj tam ACRA:

 @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); } }

Otóż ​​to! Oczywiście musisz zastąpić wszystkie symbole zastępcze {myapp} rzeczywistymi wartościami, a także wartościami dla formUriBasicAuthLogin i formUriBasicAuthPassword .

Jak widać z powyższego fragmentu kodu, używamy tylko wymaganych pól raportu. Możesz dodać wszelkie inne pola, które mogą być istotne dla Twojej aplikacji.

Możesz także użyć PUT zamiast POST. W takim przypadku REPORT_ID zostanie dołączony na końcu tego former jako parametr.

Na koniec możesz również wybrać sposób informowania użytkownika o awarii aplikacji na Androida, przy czym domyślnym jest cichy raport w tle. W naszym przypadku wybieramy wyświetlanie komunikatu Toast, informującego użytkownika, że ​​awaria została zgłoszona, a naprawa błędu powinna być dostępna wkrótce.

Potrzebuję pomocy? Oto przykładowy projekt

Aby zobaczyć ACRA w akcji, skonfigurowałem repozytorium acra_example na GitHub. Zawiera prostą aplikację, która inicjuje ACRA przy uruchomieniu i pozwala ją zawiesić, naciskając przycisk (co następnie wyzwala wyjątek zerowego wskaźnika). Dane o awarii są przesyłane do przykładowej bazy danych Cloudant, którą można tutaj zwizualizować.

Aby wyświetlić dane, zaloguj się za pomocą następujących poświadczeń:

• Nazwa użytkownika: medo
• Hasło: acraprzykład

Alternatywy dla ACRA

ACRA nie jest jedyną opcją automatycznego raportowania błędów Androida. Ponieważ awarie na pewno się zdarzają, istnieje duży rynek biznes-deweloper (B2D), który próbuje spieniężyć swoje rozwiązania.

Na przykład Crittercism to bardzo dojrzała platforma do zgłaszania awarii. Wygląda świetnie, oferuje wiele opcji analizy danych i jest bardzo łatwy w integracji. Jedyny minus: cena, a bezpłatny okres próbny jest dość ograniczony pod względem liczby aktywnych użytkowników, dni przechowywania danych i wsparcia). BugSense to podobna usługa.

Moim zdaniem jednak Crashlytics to lepsze rozwiązanie. Do niedawna Crashlytics miało model freemium (z płatnym poziomem premium); ale teraz (po ich przejęciu przez Twitter) wszystkie funkcje wcześniej premium są dostępne za darmo. Nie ma żadnych kosztów użytkowania, opłat ani limitów. Jest to preferowany sposób raportowania błędów dla wielu znanych i wysoko postawionych firm i programistów, ponieważ jest bardzo łatwy w użyciu i oferuje potężne narzędzia analityczne i wizualizacyjne. Integruje się nawet z najpopularniejszymi IDE jako wtyczka (np. Eclipse, Android Studio), więc dodanie Crashlytics do Twojej aplikacji jest tak proste, jak wybranie projektu i naciśnięcie przycisku. Te wtyczki umożliwiają również śledzenie raportów o awariach z IDE bez konieczności otwierania przeglądarki.

Po co więc używać ACRA, gdy istnieją inne alternatywy, które wyglądają znacznie lepiej i oferują więcej funkcji przy tym samym wysiłku wdrożeniowym? Podam dwa powody.

1. Wszystkie te inne opcje to zamknięte oprogramowanie, zastrzeżone oprogramowanie . Nawet mając koszyk pełen EULA, nie możesz być pewien, w jaki sposób Twoje dane są gromadzone i przetwarzane. Z drugiej strony ACRA i acralyzer to projekty typu open source hostowane na GitHub, które można łatwo rozwidlić i dostosować do swoich potrzeb.

2. Mobilność danych . Załóżmy, że nie jesteś zadowolony z Cloudant. Replikacja i migracja danych do innego zaplecza to pestka. Masz gwarancję, że dane pozostaną Twoje .

Podobnie jak w przypadku wielu wyborów, ten sprowadza się do osobistych preferencji i znajomości. Zajrzyj do tego wątku Google+, aby uzyskać więcej informacji na temat różnych dostępnych alternatyw zwiększających niezawodność Twojej aplikacji.

Podsumowując

ACRA to bardzo solidna i wysoce konfigurowalna biblioteka, której można używać wraz z Cloudant i acralyzerem, aby uzyskać bezpłatne, zautomatyzowane raportowanie o awariach i podstawowe analizy dla Twojej aplikacji, a wszystko to przy minimalnym wysiłku wdrożeniowym.

Pisanie niezawodnego kodu na Androida wymaga dużego doświadczenia i dalekowzroczności, ale nikt z nas nie jest naprawdę wszechwiedzący. Przygotuj się na nieoczekiwane awarie i błędy oraz przygotuj się na naprawienie nieoczekiwanych tak szybko, jak to możliwe. To rodzaj pracy, która przekłada się na świetne produkty i wspaniałe wrażenia użytkowników.