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ą :-).
Tworzenie projektów na Androida wygląda podobnie jak inne. Podstawowy jest w Android → Android Project. Pola do ustawienia i ich znaczenie:
Po utworzeniu projektu warto zmienić jego ustawienia:
-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
.
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
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).
Można to zrobić z Netbeansa:
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
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.
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...
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.
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ę.