10 najczęstszych błędów popełnianych przez programistów Androida: samouczek programowania

Android. Czego nie lubić w tej platformie? Jest bezpłatny, można go dostosować, szybko się rozwija i jest dostępny nie tylko na telefonie lub tablecie, ale także na smartwatchu, telewizorze i samochodzie.

Dzięki najnowszej aktualizacji Lollipop programowanie na Androida wciąż się poprawia. Platforma nieco dojrzała od czasu pierwszego wydania AOSP i postawiła poprzeczkę dość wysoko. Zobacz, jak dobrze wygląda nowy wzór Material Design!

Istnieją tysiące różnych urządzeń, z różnymi rozmiarami ekranu, architekturami chipów, konfiguracjami sprzętowymi i wersjami oprogramowania. Niestety segmentacja to cena, jaką trzeba zapłacić za otwartość, a istnieją tysiące sposobów, w jakie Twoja aplikacja może zawieść na różnych urządzeniach, nawet jako zaawansowany programista Androida.

Niezależnie od tak ogromnej segmentacji, większość błędów jest faktycznie wprowadzanych z powodu błędów logicznych. Tym błędom można łatwo zapobiec, o ile dobrze zrozumiemy podstawy!

Oto samouczek programowania na Androida, który opisuje 10 najczęstszych błędów popełnianych przez programistów Androida.

Powszechny błąd nr 1: Programowanie na iOS

Ku mojej wielkiej radości ten błąd Androida jest obecnie znacznie mniej powszechny (po części dlatego, że klienci zaczynają zdawać sobie sprawę, że czasy, w których Apple wyznaczało wszystkie standardy projektowe, już dawno minęły). Ale wciąż od czasu do czasu widzimy aplikację będącą klonem iOS.

Nie zrozum mnie źle, nie jestem ewangelistą programowania na Androida! Szanuję każdą platformę, która posuwa świat mobilny o krok do przodu. Ale jest rok 2014, a użytkownicy korzystają z Androida już od dłuższego czasu i przyzwyczaili się do tej platformy. Przesuwanie im standardów projektowania iOS to straszna strategia!

O ile nie ma super dobrego powodu do łamania wytycznych, nie rób tego. (Google robi to przez cały czas, ale nigdy przez kopiowanie-wklejanie).

Oto niektóre z najczęstszych przykładów tego błędu w Androidzie:

1. Nie powinieneś robić statycznych zakładek, a one nie należą do dolnej części (wskazuję na Ciebie na Instagramie).
2. Ikony powiadomień systemowych nie powinny mieć koloru.
3. Ikony aplikacji nie powinny być umieszczane w zaokrąglonym prostokącie (chyba że jest to Twoje rzeczywiste logo, np. facebook).
4. Ekrany powitalne są zbędne poza początkową konfiguracją/wprowadzeniem. Nie używaj ich w innych scenariuszach.
5. Listy nie powinny mieć karetek.

To tylko kilka z wielu innych drobiazgów, które mogą zrujnować wrażenia użytkownika.

Częsty błąd nr 2: Programowanie na urządzenie z Androidem

Jeśli nie tworzysz aplikacji kiosku/promocyjnej dla jednego tabletu, prawdopodobnie Twoja aplikacja na Androida nie będzie dobrze wyglądać na każdym urządzeniu. Oto kilka wskazówek dotyczących programowania na Androida, o których należy pamiętać:

• Piksele niezależne od gęstości (dp) różnią się od zwykłych pikseli (px).
• Zasoby są uwzględniane wielokrotnie, aby uwzględnić różne gęstości i orientacje.
• Rysunki z dziewięcioma łatami są rozciągnięte tak, aby pasowały do ​​ekranu.

Istnieją dosłownie tysiące możliwych scenariuszy, ale po pewnym czasie wyrabiasz sobie zmysł, by je wszystkie objąć kilkoma przypadkami.

Nie masz tysięcy urządzeń? Żaden problem. Emulator Androida jest bardzo dobry w replikowaniu urządzeń fizycznych. Co więcej, wypróbuj Genymotion, jest szybki jak błyskawica i jest wyposażony w wiele różnych popularnych wstępnie ustawionych urządzeń.

Czy próbowałeś też obracać urządzenie? Całe piekło może się rozpętać…

Powszechny błąd nr 3: nieużywanie intencji

Intencje są jednym z kluczowych elementów Androida. Jest to sposób na przekazywanie danych między różnymi częściami aplikacji lub, jeszcze lepiej, różnymi aplikacjami w systemie.

Załóżmy, że masz aplikację galerii, która może udostępniać łącze do pobierania niektórych obrazów za pośrednictwem wiadomości SMS. Która z dwóch opcji wydaje się bardziej logiczna?

Opcja 1:

• Poproś o pozwolenie na SEND_SMS.

   <uses-permission android:name="android.permission.SEND_SMS" />

• Napisz własny kod do wysyłania SMS-ów za pomocą SmsManager .
• Wyjaśnij użytkownikom, dlaczego aplikacja galerii potrzebuje dostępu do usług, które mogą kosztować pieniądze, i dlaczego muszą udzielić tego pozwolenia, aby korzystać z Twojej aplikacji.

Opcja 2:

• Uruchom intencję SMS i pozwól aplikacji zaprojektowanej do obsługi SMS-ów wykonać pracę

   Intent sendIntent = new Intent(Intent.ACTION_VIEW); sendIntent.setData(Uri.parse("sms:" + telephoneNumber)); sendIntent.putExtra("sms_body", x); startActivity(sendIntent);

W przypadku jakichkolwiek wątpliwości najlepszym rozwiązaniem jest opcja 2!

Takie podejście można zastosować do prawie wszystkiego. Udostępnianie treści, robienie zdjęć, nagrywanie wideo, wybieranie kontaktów, dodawanie wydarzeń, otwieranie linków w natywnych aplikacjach itp.

O ile nie ma dobrego powodu, aby wykonać niestandardową implementację (np. aparat, który stosuje filtry), zawsze używaj Intencji w tych scenariuszach. Zaoszczędzi ci to dużo czasu na programowaniu i AndroidManifest.xml niepotrzebnych uprawnień.

Powszechny błąd nr 4: nieużywanie fragmentów

Jakiś czas temu w Honeycomb Android wprowadził pojęcie fragmentów . Pomyśl o nich jako o oddzielnych elementach konstrukcyjnych z własnymi (raczej złożonymi) cyklami życia, które istnieją wewnątrz Działania. Bardzo pomagają w optymalizacji dla różnych ekranów, są łatwo zarządzane przez ich rodzicielską aktywność, mogą być ponownie używane, łączone i ustawiane w dowolnym miejscu.

Uruchamianie osobnej aktywności dla każdego ekranu aplikacji jest strasznie nieefektywne, ponieważ system będzie starał się zachować je w pamięci tak długo, jak to możliwe. Zabicie jednego nie uwolni zasobów wykorzystywanych przez pozostałych.

Jeśli nie chcesz zagłębić się w rdzeń Androida i przeczytać ten artykuł, opowiadając się przeciwko używaniu fragmentów, powinieneś używać fragmentów, gdy tylko jest to możliwe. Zasadniczo mówi, że fragmenty i programy ładujące kursory mają dobry zamierzony cel, ale słabą implementację.

Powszechny błąd nr 5: blokowanie głównego wątku

Główny wątek ma jeden cel: utrzymanie responsywności interfejsu użytkownika.

Chociaż nauka stojąca za pomiarem szybkości klatek, którą nasze oczy/mózg mogą dostrzec, jest skomplikowana i zależy od wielu czynników, ogólna zasada jest taka, że ​​wszystko poniżej 24 kl./s z opóźnieniem większym niż 100 ms nie będzie postrzegane jako płynne.

Oznacza to, że działania użytkownika będą opóźnione, a zaprogramowana aplikacja na Androida przestanie odpowiadać. Pozbawienie użytkownika kontroli nad aplikacją prowadzi do frustracji, a sfrustrowani użytkownicy często dają bardzo negatywne opinie.

Co gorsza, jeśli główny wątek zostanie zablokowany na chwilę (5 sekund dla działań, 10 dla odbiorników transmisji), nastąpi ANR.

Było to tak powszechne w Androidzie 2.x, że w nowszych wersjach system nie pozwalał na wykonywanie połączeń sieciowych w głównym wątku.

Aby uniknąć blokowania głównego wątku, zawsze używaj wątków roboczych/w tle do: 1. połączeń sieciowych 2. ładowania bitmap 3. przetwarzania obrazu 4. zapytań do bazy danych 5. odczytu / zapisu SD

Powszechny błąd nr 6: wymyślanie koła na nowo

„OK, nie będę korzystał z głównego wątku. Napiszę własny kod, który komunikuje się z moim serwerem w wątku w tle.”

Nie! Proszę, nie rób tego! Połączenia sieciowe, ładowanie obrazów, dostęp do bazy danych, parsowanie JSON i logowanie społecznościowe to najczęstsze czynności, które wykonujesz w swojej aplikacji. Nie tylko twoja, każda aplikacja. Jest lepszy sposób. Pamiętasz, jak dojrzał i rozwinął się Android jako platforma? Oto krótka lista przykładów:

1. Użyj Gradle jako systemu budowania.
2. Użyj Retrofit / Volley do połączeń sieciowych.
3. Użyj Picassa do ładowania obrazu.
4. Użyj Gson / Jackson do parsowania JSON.
5. Użyj typowych implementacji do logowania społecznościowego.

Jeśli potrzebujesz czegoś zaimplementowanego, prawdopodobnie jest już napisane, przetestowane i powszechnie używane. Zrób podstawowe badania i przeczytaj kilka samouczków dotyczących programowania na Androida przed napisaniem własnego kodu!

Powszechny błąd nr 7: nie zakładanie sukcesu

Świetnie. Dowiedzieliśmy się, że istnieje lepszy sposób obsługi długotrwałych zadań i używamy do tego celu dobrze udokumentowanych bibliotek. Ale użytkownik nadal będzie musiał poczekać. To nieuniknione. Paczki nie są wysyłane, przetwarzane i odbierane natychmiast. Jest opóźnienie w obie strony, awarie sieci, gubienie paczek i niszczenie marzeń.

Ale to wszystko jest wymierne. Udane połączenia sieciowe są znacznie bardziej prawdopodobne niż nieudane. Po co więc czekać na odpowiedź serwera przed obsługą pomyślnego żądania? Nieskończenie lepiej zakładać sukces i radzić sobie z porażką. Tak więc, gdy użytkownik polubi post, liczba polubień jest natychmiast zwiększana i w mało prawdopodobnym przypadku niepowodzenia połączenia, użytkownik zostaje o tym powiadomiony.

W tym nowoczesnym świecie oczekuje się natychmiastowej informacji zwrotnej. Ludzie nie lubią czekać. Dzieci nie chcą siedzieć w klasie i zdobywać wiedzę, która ma niepewną przyszłość. Aplikacje muszą być dostosowane do psychologii użytkownika.

Powszechny błąd nr 8: niezrozumienie bitmap

Użytkownicy uwielbiają treści! Zwłaszcza, gdy treść jest dobrze sformatowana i ładnie wygląda. Na przykład obrazy są niezwykle ładną treścią, głównie ze względu na ich właściwość przekazywania tysiąca słów na obraz. Zużywają też dużo pamięci. Dużo pamięci!

Zanim obraz zostanie wyświetlony na ekranie, należy go załadować do pamięci. Ponieważ mapy bitowe są najczęstszym sposobem, aby to zrobić, udostępnimy przewodnik programowania dla systemu Android dla całego procesu:

Załóżmy, że chcesz wyświetlić na ekranie obraz, który właśnie zrobiłeś aparatem. Całkowita pamięć potrzebna do tego jest obliczana według następującego wzoru: memory_needed_in_bytes = 4 * image_width * image_height;

Dlaczego 4? Cóż, najczęstszą / zalecaną konfiguracją bitmapy jest ARGB_8888 . Oznacza to, że dla każdego narysowanego piksela musimy zachować w pamięci 8 bitów (1 bajt) dla kanału alfa, czerwonego, chciwości i niebieskiego, aby poprawnie go wyświetlić. Istnieją alternatywy, takie jak konfiguracja RGB_565 , która wymaga o połowę mniej pamięci niż ARGB_8888 , ale traci przezroczystość i precyzję kolorów (może dodając zielony odcień).

Załóżmy, że masz zupełnie nowe urządzenie z ekranem Full HD i aparatem 12 MP. Zdjęcie, które właśnie zrobiłeś ma rozmiar 4000x3000 pikseli, a całkowita pamięć potrzebna do jego wyświetlenia to: 4 bytes * 4000 * 3000 = 48 MB

48 megabajtów twojej pamięci RAM tylko dla jednego obrazu!? To dużo!

Weźmy teraz pod uwagę rozdzielczość ekranu. Próbujesz wyświetlić obraz 4000x3000 na ekranie, który ma 1920x1080 pikseli, w najgorszym przypadku (wyświetlanie obrazu na pełnym ekranie) nie powinieneś przydzielić więcej niż 4 * 1920 * 1080 = 8.3 MB pamięci.

Zawsze postępuj zgodnie ze wskazówkami dotyczącymi programowania systemu Android, aby efektywnie wyświetlać mapy bitowe:

1. Zmierz widok, w którym pokazujesz swoje obrazy.
2. Odpowiednio skaluj / przycinaj duży obraz.
3. Pokaż tylko to, co można wyświetlić.

Powszechny błąd nr 9: korzystanie z hierarchii głębokiego widoku

Układy mają prezentację XML w Androidzie. Aby narysować treść, należy przeanalizować XML, zmierzyć ekran i odpowiednio umieścić wszystkie elementy. Jest to proces czasochłonny i zasobożerny, który należy zoptymalizować.

W ten sposób działa ListView (i ostatnio RecyclerView).

Jeśli układ został raz napompowany, system użyje go ponownie. Ale i tak nadmuchanie układu musi nastąpić w pewnym momencie.

Załóżmy, że chcesz utworzyć siatkę 3x3 z obrazami. Jednym ze sposobów wykonania tego jest pionowy LinearLayout zawierający 3 LinearLayout o równej wadze, z których każdy zawiera 3 ImageViews o równej wadze.

Co otrzymujemy dzięki takiemu podejściu? Ostrzeżenie, że „zagnieżdżone wagi są złe dla wydajności”.

W świecie programowania na Androida jest takie powiedzenie, które właśnie wymyśliłem: „Przy niewielkim wysiłku całą hierarchię można spłaszczyć” .

W takim przypadku RelativeLayout lub GridLayout skutecznie zastąpi zagnieżdżone LinearLayouts .

Częsty błąd nr 10: nie ustawianie minSdkVersion na 14

Cóż, to nie pomyłka, ale to zła praktyka.

Android 2.x był kamieniem milowym w rozwoju tej platformy, ale niektóre rzeczy należy pozostawić w tyle. Obsługa starszych urządzeń zwiększa złożoność konserwacji kodu i ogranicza proces rozwoju.

Liczby są jasne, użytkownicy ruszyli dalej, deweloperzy nie powinni pozostawać w tyle.

Zdaję sobie sprawę, że nie dotyczy to niektórych dużych rynków ze starymi urządzeniami (np. Indie), a ustawienie minSdkVersion na 14 w aplikacji Facebook oznacza pozostawienie kilku milionów użytkowników bez ulubionej sieci społecznościowej. Ale jeśli zaczynasz od nowa i próbujesz stworzyć piękne wrażenia dla swoich użytkowników, rozważ wyeliminowanie przeszłości. Użytkownicy, którzy nie mają zasobów lub czują potrzebę uaktualnienia swojego urządzenia/systemu operacyjnego, nie będą mieli motywacji do wypróbowania lepszej wersji aplikacji na Androida i ostatecznie do wydania na nią pieniędzy.

Zakończyć

Android to potężna platforma, która szybko się rozwija. Oczekiwanie, że użytkownicy będą dotrzymywać tempa, może nie być rozsądne, ale jest to kluczowe dla programistów Androida.

Jeszcze ważniejsza jest świadomość, że Android działa nie tylko na naszych telefonach czy tabletach. Jest na naszych nadgarstkach, w naszych salonach, w naszych kuchniach iw naszych samochodach. Właściwe podstawy mają ogromne znaczenie, zanim zaczniemy się rozwijać.