Android?! Czy ktoś nie podszył się tutaj pode mnie? Spokojnie, Windows i Windows Phone są zawsze dla mnie numerem jeden, ale pojawiła się myśl, by przyjrzeć się trochę konkurencyjnym platformom, czegoś zupełnie nowego się dowiedzieć i mieć pełniejszy obraz świata mobilnego. Trudno bym stał się nagle super-ekspertem od innych platform czy choćby ich fanem, ale robić notatki z poznawanych rzeczy, dzielić się wrażeniami, porównywać z Windows przecież mogę. Takie niezobowiązujące posty pisałbym sobie raz na jakiś czas (raczej nie w postaci jednego ciągu). Na pierwszy ogień chciałbym zmierzyć się z Androidem, po pierwsze dlatego, że jest najbardziej popularny (nurtuje mnie co się w nim większości podoba się), po drugie dlatego, że Javę i tak uważam za znacznie bardziej wygodną od Objective-C w iOS (choć ostatnio obok niego pojawił się Swift), a po trzecie trzy lata temu uczestniczyłem w szkoleniu z Androida, więc coś sobie przypomnę i będzie łatwiej (zobaczę może też co się zmieniło). Wiem, że nie muszę koniecznie używać Javy i mógłbym posłużyć się C# (Xamarin) lub HTML5 (Apache Cordova), ale przez szacunek dla przeciwnika najpierw chcę zobaczyć go w pełnej krasie, w jakiej widzą go ludzie z jego świata. Gdyby ktoś zaczął naukę pisania na Windows Phone od np. Apache Cordovy to uznałbym to za profanację.
Obejrzałem jakiś pierwszy kurs, co się dowiedziałem? Poniżej trochę notatek (jeszcze sprzed urlopu), które robiłem, gdy oswajałem narzędzia, by odpalić pierwsze dwa hello world. Czemu dwa? Od 2013 roku Eclipse nie jest już numerem jeden, Google stworzyło alternatywę w postaci Android Studio (na razie w wersji beta z ograniczoną funkcjonalnością). Intuicyjność i ergonomię oceniam nieco niżej niż w Visual Studio, bo w każdym przypadku trzeba coś było zrobić przed założeniem projektu (np. pobrać pakiety w menadżerze, powalczyć z konfiguracją emulatora i wsparciem sprzętowym, przestawić w designerze z najwyższej wersji API na swoją, aby nie mieć błędów itp.). Plusem jest szybkość instalacji i uniwersalność emulacji (a także spora konfigurowalność). Android Studio wgrywa się do ukrytego systemowego foldera, co może jest intuicyjne dla użytkowników Linux, ale nie Windows. Szkoda, że nawet następna wersja Androida 5 wymaga Javy 7, a nie najnowszej 8 (aktualny Android 4.4 wymaga dwie wersje wstecz, czyli Javy 6).
Środowisko
Android Developer Tools (ADT) Bundle
- Eclipse (od maja 2013 alternatywa - Android Studio)
- ADT Plugin (dodatek do Eclipse)
- Android SDK Tools
- Android Platform Tools
- Android Platform
- obrazy dla emulatora
Java Development Kit (JDK) - sprawdzić wersję wymaganą przez Android SDK
developer.android.com - odpowiednik MSDN / Windows / Windows Phone Developer Center
Obecne narzędzia wymagają Javy 6 (dwie wersje wstecz w stosunku do bieżącego wydania Java 8)
AVD (Android Virtual Devices) / emulatory
- obrazy tworzone na podstawie definicji
- definicje jako zbiór właściwości (charakterystyki ekranu, fizyczna klawiatura?, GPS?, właściwości podstawowej i frontowej kamery) odpowiadającym prawdziwym urządzeniom lub generycznemu zbiorowi
- można wprowadzać modyfikacje do niektórych charakterystyk
Android Virtual Device Manager – tworzenie i dostęp do AVDs, możliwość uruchomienia bezpośrednio z Eclipse (m.in ilość RAM, wersja systemu i API, obecność kamer, rozmiar wewnętrznej przestrzeni dyskowej oraz karty SD)
Create AVD - uups brak… obrazów, trzeba wiedzieć, że pobiera się je konfigurując pakiety do pobrania w Android SDK Manager
Przed odpaleniem obrazu można wybrać “Scale display do real size”, aczkolwiek u mnie ta opcja powoduje wyświetlanie dość małego okienka, więc z niej przestałem korzystać. Aha dostaję informację: “Failed to open Hax device”. Emulator się odpala, ale jednak szukam w czym rzecz. Nie miałem zainstalowanego pakietu Hax w menadżerze SDK, a także wybrałem zły typ obrazu dla mojej wirtualnej maszyny w menadżerze AVM (trzeba wybierać obraz ARM zamiast np. Intel Atom x86).
A, i co z klawiaturą sprzętową na emulatorze? Nie widzę jej. No, teraz wybrałem skórkę “Skin with dynamic hardware controls”, już widzę, ale… nie są aktywne, o czym jest informacja. Ale tak też jest na zdjęciu w szkoleniu, może to i logiczne, obecnie coraz mniej urządzeń z fizycznymi klawiszami poza wyłącz, głośność i coś jeszcze.
New Android Application Project
Uups… mimo wybrania API 19, dostaję komunikat że nie poradzono sobie z renderowaniem dla Androida L Preview (czyli 5). Znalazłem w sieci, że trzeba ikonę w designerze głównej aktywności przestawić na wybrany przez siebie poziom API. Czemu domyślnie podgląd ustawiany jest najwyższą wersję, skoro do tworzenia projektu wybrałem sobie 19 ?
No dobra, chcę zdebugować pierwszą aplikację na emulatorze podobnie jak w przewodniku. Klikam w pluskwę i … nic się nie dzieje. A, trzeba było zaznaczyć właściwy projekt w managerze pakietów, wybrałem debugowanie jako aplikacja Android, potwierdzam sposób logowania przy uruchamianiu i nareszcie mam zdeployowaną app-kę do emulatora!
Debugowanie fizycznego urządzenia wymaga:
- włączenia debugowania przez USB na telefonie
- na większości urządzeń z < Android 4.0: Settings –> Applications –> Debugging
- na większości urządzeń z Android 4.0 i 4.1: Settings –> Developer Options
- od Android 4.2 Developer Options domyślnie ukryte (odblokowanie: Settings –> About phone –> Build number (nacisnąć 7 razy)
- od Androida 4.2.2 specjalne zabezpieczenie (trzeba zaakceptować klucz RSA dla desktopa przy pierwszym połączeniu, potrzebne >= Android Platform Tools r.16.0.1)
- instalacji sterowników USB na komputerze
- większość developerskich telefonów (np. Nexus 1, Nexus 2) używa Google USB Driver (dostępny przez menadżer SDK)
- Galaxy Nexus (sterownik Samsunga)
- inne telefony: http://developer.android.com/tools/extras/oem-usb.html
- urządzenia z aktywnym ekranem (ustawienie Stay awake w Developer Options lub pobrać aplikację stay awake z Google Play, która to czyni)
Narzędzia
desktop | device
Eclipse –> ADB (Android Debug Bridge) Server –> | ADB Daemon –> App
logcat OS logcat
DDMS (Dalvik Debug Monitor Server)
http://developer.android.com/tools/help/index.html
ADB Command Line Utility [install]\sdk\plaform-tools
adb devices, kill-server, start-server
kopiowanie plików między desktopem a urządzeniem, instalacja/deinstalacja aplikacji
http://developer.android.com/tools/help/adb.html
Linux shell na urządzeniu (shell, shell komenda)
wiele urządzeń/ADVDs
- -d – tylko urządzenie (np. adb –d shell ps)
- -e - tylko AVD
- -s identyfikator (przy wielu tego samego rodzaju)
Logcat
- Eclipse, adb
- android.util.Log
- Silent
- Assert: Log.wtf
- Error: Log.e
- Warning: Log.w
- Info: log.i
- Debug: Log.d
- Verbose: Log.v
- bufory:
- main (Eclipse), events (wszystkie systemowe zdarzenia), radio (aktywność radiowa: np. komórka, Wi-Fi)
- adb logcat –b nazwa
DDMS
- debugowanie, lista podłączonych urządzeń/emulatorów, ich procesy, narzędzia, Logcat view
- procesy muszą być debugowalne, aby być widoczne
- system w wersji debug na emulatorach - wszystkie procesy są widoczne
- standardowy system na większości urządzeń - proces musi być oznaczony jako debugowalny
- narzędzia:
- proces: zużycie pamięci (heap - ogólnie, alokacja - szczegółowo dla obiektów), aktywność wątków (callstacki), aktywność sieciowa
- urządzenie/AVD: system plików (nawigacja, kopiowanie do i z komputera, usuwanie pliku/foldera, tworzenie folderu), screen capture, kontrola AVD (sieć: status, prędkość, dane, opóźnienie; telefon dzwoniący, SMS, lokalizacja geograficzna, pobierane danych z GPS)
- http://developer.android.com/tools/debugging/ddms.html
Projekt
- Nazwa projektu rzutuje na pakiet klas i identyfikator w Google Play (wymagana unikalność pakietu)
- Ikona startowa - domyślna, z clipartu (kolor, kształt, obramówka), z tekstu
- Atywność
- UI: blank, fullscreen, master/detail (na tabletach dwie kolumny, na telefonach jedna)
- Nazwa: nazwy klasy Java
- Nazwa layoutu: nazwa zasobu XML
- Typ nawigacji: none, fixed tabs + swipe, scrollable tabs + swipe, dropdown
- Elementy w Eclipse (Android Studio ma inną strukturę projektu)
- pliki Java (folder src, struktura pakietu)
- zasoby (folder res, struktura zasobów)
- layout - pliki XML
- menu – pliki XML
- values
- values
- dimens.xml
- strings.xml
- styles.xml
- values-sw600dp
- values-sw720dp-land
- values-v11
- values-v14
- …
- values
- drawable - obrazki, animacje
- drawable-hdpi
- drawable-ldpi
- drawable-mdpi
- …
- AndroidManifest.xml
R.layout.activity_main
skrócone źródła
<RelativeLayout xmlns:android=”…”
xmlns:tools=”…”
android:layout_width=”match_parent”
android:paddingBottom=”@dimen/activity_vertical_margin”
tools:context=”.MainActivity”>
<TextView
android:layout_width=”wrap_content”
android:text=”@string/hello_world”/>
</RelativeLayout>
<menu xmlns:android=”…”>
<item
android:id=”@+id/action_settings”
android:title=”@string/action_settings”/>
</menu>
<manifest xmlns:android=”…”
package=”…”
android:versionCode=”1”
android:versionName=”1.0”>
<uses-sdk
android:minSdkVersion=”8”
android:targetSdkVersion=”19” />
<application
android:allowBackup=”true”
android:icon=”@drawable/ic_launcher”
android:label=”@string/app_name”
android:theme=”@style/AppTheme”>
<activity
android:name=”…”
android:label=”…”
<intent-filter>
<action android:name=”…”/>
<catgory android:name=”…”/>
</intent-filter>
</application>
</manifest>
Budowanie projektu
Plik wynikowy *.apk
Android Asset Packaging Tool (aapt) tworzy:
- R.java
- Skompilowane zasoby
Pliki *.java (nasze i generowane) są kompilowane do *.class
Pliki *.class są zamieniane przez narzędzie dex na *.dex (kompatybilne z Android Runtime)
Appkbuilder ze skompilowanych zasobów i plików *.dex tworzy plik *.apk
Kiedy R.java się nie generuje?
- Build Automatically – opcja
- Clean projekt
- Błędy w plikach XML
Android Studio
- nowe IDE od 2013, bazuje na JetBrain IntelliJ IDEA Community Edition
- te same narzędzia z Android SDK
- nie zawiera w sobie zintegrowanego DDMS (otwiera w osobnym oknie)
- http://developer.android.com/sdk/installing/studio.html
- ta sama wersja JDK, co Eclipse
- Miejsce wgrania: ukryty domyślnie folder systemowy Windows ~\AppData\Local\Android\android-studio
- Gardle - system buildów
- AndroidManifest - tylko edytor tekstowy
- Większa produktywność
- Większe podobieństwo do Visual Studio
- Settings -> Appearance -> skórka Darcula (nowoczesny „czarny” wygląd z prezentacji)
Wersjonowanie Androida
Wydanie ma dwa indentyfikatory:
- Platform version - zbiór aplikacji, właściwości, zachowań (X.Y lub X.Y.Z)
- API Level - zbiór właściwości udostępnionych developerom (numer int)
Każda wersja platformy wspiera określony level API, a ten sam level API może znaleźć się w kilku wersjach platformy
1.0/1 - 1.6/4 - na początek, zaadaptowane przez większość miłośników gadżetów
2.0/5 - 2.3.7/10 - bardziej przyjazne, początek adaptacji użytkowników
3.0.x/11 – 3.2/13 - tylko na tablety, bardzo ograniczona adaptacja
4.0/14 – 4.4/19 - tablet & telefon, znacznie lepszy UX, szeroka adaptacja
4.4W/20 - Android Wear, zegarki
L Preview /20 - Preview Android 5
Odeszły: 1.0 – 1.5, 2.0 – 2.0.1, 3.0 – 3.1.x, 4.0 – 4.0.2
Maj 2013:
15: 55.9% (w miarę najnowszy)
13: 56% + 0.1%
10: 94.4% + 38.4% (w miarę najwięcej userów)
7: 99.9% + 5.5%
4: 100% + 0.1%
http://developer.android.com/about/dashboards/index.html
Zarządzanie poziomami API
- AndroidManifest.xml uses-sdk (minimalna i najwyższa przetestowana wersja - target, opcjonalnie najwyższa wersja, którą życzymy sobie wspierać – max, ostatnia jest przydatna, gdy chcemy robić różne wersje aplikacji na różne zakresy API)
- Kompilator (w większości przypadków kompiluje się z najniższą wspieraną wersją API, choć można i z wyższą, ale trzeba pilnować czy nie mamy niezabezpieczonych wywołań wyższej wersji API)
- W zależności od maksymalnego poziomu na nowszych urządzeniach/emulatorach może wyświetlać się nowszy interfejs, przy zachowaniu dostępu do najniższej wersji API
- Android SDK Manager - powinniśmy używać najnowszych Revision Level dla danego poziomu API
Brak komentarzy:
Prześlij komentarz