Używanie Netbeansa do programowania na Androida

Wczoraj pisałem o tym jak przygotować Netbeansa do programowania na Androida. Tym razem parę moich notatek odnośnie tworzenia, uruchamiania i testowania projektów. Czyli o tym jak uczynić Twoją pracę nieco bardziej komfortową :-).

Nowe projekty

Tworzenie projektów na Androida wygląda podobnie jak inne. Podstawowy jest w Android → Android Project. Pola do ustawienia i ich znaczenie:

  • Project Name: Ładna nazwa [to jest to co jest widoczne na ekranie urządzenia, czyli powinno być krótkie, ale wyróżniające]
  • Project Location: ... [cokolwiek]
  • Package Name: com.your.domain.backwards.nameOfTheApp [powinno być globalnie (w sensie całej Ziemi) unikatowe]
  • Activity Name: MainActivity [może zostać domyślna]

Po utworzeniu projektu warto zmienić jego ustawienia:

  • PPM na nazwie projektu → Properties
  • "Run"
  • Emulator options: -no-boot-anim

To przyśpiesza znacząco uruchomienie emulatora, ale można też np. przeskalować sobie okienko (przydatne na laptopie), czyli wpisać coś w rodzaju: -dpi-device 150 -scale .7 -no-boot-anim.

Uruchamianie projektów

Uruchamiać można normalnie (z paska narzędziowego, albo F6) - emulator (AVD) uruchomi się automatycznie. Przy pierwszym uruchomieniu projektu często następuje timeout. Trzeba wtedy jeszcze raz uruchomić projekt (już po tym jak emulator w pełni wystartuje). Projekt można też normalnie debugować (i debugowanie odpala się normalnie z paska narzędziowego i CTRL + F5).

Emulator można też uruchomić wcześniej z linii poleceń: ...\android-sdk\tools\emulator.exe -avd DroidName -dpi-device 150 -scale .7 -no-boot-anim

Sprawdzanie rejestru LogCat, czyli o co biega?!

Co to jest LogCat

Odpalasz apkę i nagle pada? Nie ma problemu - użyj LogCat.

LogCat łączy się z uruchomionym urządzeniem (także z emulatorem) i śledzi różnego rodzaju wiadomości (error, info, debug i parę innych). Te wiadomości mogą być albo wysyłane przez komponenty systemowe (zwykle jako informacje o błędach po wywaleniu się aplikacji) lub wysyłane ręcznie (np. z informacjami pomagającymi w debugowaniu).

Otwieranie LogCat

Można to zrobić z Netbeansa:

  • wybierz z menu Window -> Output -> ADB Log,
  • albo dodaj sobie przycisk do paska narzędziowego (przyda się!).

LogCat używany w Netbeans może czasem tracić połączenie z i nie będzie możliwości ponownego podłączenia się do niego. To głównie dlatego wart mieć ten przycisk (zamknięcie i otworzenie LogCat pomoże).

Możesz także uruchomiać LogCat ręcznie. Dla "lokalnych" instalacji pod Windowsem pełna ścieżka polecenie to (po prostu wciśnij [Windows]+R i wklej poniższe): %LOCALAPPDATA%\Android\android-sdk\tools\monitor.bat

ALBO przy instalacja dla "wszystkich użytkowników": C:\Program Files (x86)\Android\android-sdk\tools\monitor.bat

Jak wysyłać wiadomości do LogCat

Klasa android.util.Log ma klika metod m.in.: Log.i, Log.d, Log.e. Wszystkie mają podobne parametry: Log.i(TAG, "message");

Osobiście zmienną TAG ustawiam tak by identyfikowała daną klasę (zwykle po prostu wpisuję nazwę klasy z prefiksem specyficznym dla mojej aplikacji). Możesz jednak użyć czegokolwiek (nie ma to formalnego znaczenia). To po prostu coś co pomoże w filtrowaniu wiadomości. Dla przykładu jeśli tagi mają format "enux.NazwaKlasy", to mogę w łatwy sposób wyfiltrować moje wiadomości wpisując "enux.*". Tak, to jest RegExp.

Układy i frameworki

Natywny układ

To jest słaba strona NB Android - ie ma edytora typu WYSIWYG. Z drugiej strony nie widziałem żadnego naprawdę użytecznego. Edytor w Eclipse pozwoli co prawda na wrzucenie sobie różnych elementów na ekran, ale żeby ułożyć je sensownie i tak, koniec końców, musisz pogrzebać w źródłowym XML.

Także niestety, nie ma WYSIWYG, ale w nowszych wersjach NBAndroid jest dostępny podgląd stworzonego układu, który działa bez konieczności kompilacji całego projektu. Podgląd możesz otworzyć w menu Window → Output → Android Layout Preview.
Za pierwszym razem będzie się trochę uruchamiać, ale efekt jest w 100% zgodny z tym co by się miało na urządzeniu. W razie gdyby obrazek się nie odświeżał, można przełączyć "Theme" (opcje dostępne dla Android 4.1 i nowszych).

Jeśli chcesz wypróbować coś lżejszego, to ciekawy jest DroidDraw. nie jest co prawda zbyt dokładny i nie obsługuje niektórych elementów, ale za to jest bardzo szybki. Do prototypowania wystarczy. Ważne, żeby - ZANIM zacznie się tego używać - ustawić sobie we właściwościach Javy uprawnienia do kopiowania do schowka, bo inaczej śliczny layout trzeba będzie sobie przepisywać ręcznie...

Alternatywy

Natywne budowanie układów w Androidzie nieco ogranicza Twoje opcje, zwłaszcza jeśli porównasz to z tym co daje HTML i CSS. Cóż, lat postępu nie da się nadgonić w ciągu jednego dnia. Próba stworzenia bardziej skomplikowanego, a przy tym elastycznego układu może spowodować siwienie ;-). Tak się składa, że akurat dla Androida układ Twojej aplikacji musi być bardzo elastyczny - różnych urządzeń z tym systemem jest mnóstwo. Nie chodzi tu tylko o rozciągliwość. Jeśli masz ambitne plany, to układ aplikacji powinien się także zmieniać wraz z wielkością ekranu.

Zasadniczym elementem alternatyw jest WebView. Czyli w zasadzie taka zagnieżdżona przeglądarka internetowa. Różnych frameworków, które dają dostęp do pełnego stosu webowego (HTML, CSS, JS), jest sporo. Oczywiście w dalszym ciągu możesz używać Javy do rzeczy, które nie są zaimplementowane, albo te które chcesz usprawnić.

Możesz na przykład spróbować PhoneGap. Wszystkie podane przez mnie zasady budowania i testowania się przydadzą. W tym wypadku możesz nie tylko tworzyć układ, ale wręcz testować w swojej ulubionej przeglądarce. Na pewno będzie Ci o wiele łatwiej jeśli masz już doświadczenie w webdeveloperce. To podejście daje Ci także znaczącego kopa jeśli zdecydujesz się wydać aplikację na iOS i inne mobilne systemy operacyjne.

Czyli co wybrać?

W skrócie - to zależy :-). Jeśli zechcesz pójść na całość i robić wszystko natywnie, to aplikacja będzie mogła być sprawniejsza. Musisz przy tym pamiętać, że z każdym wspieranym systemem koniecznych będzie coraz więcej ludzi. Systemów jest dużo. Do większości konieczne jest korzystanie z niezależnych narzędzi, a większość dużych graczy ma nie tylko swoje własne SDK (klasy), ale także zupełnie różne języki programowania.

Czyli jeśli masz duży zespół - możesz pójść natywną ścieżką i wspierać wiele platform. W przeciwnym wypadku pozostaje, albo znaczące ograniczenie liczby platform, albo wejście w jakąś bardziej przekrojową alternatywę.