Strona używa cookies (ciasteczek). Dowiedz się więcej o celu ich używania i zmianach ustawień. Korzystając ze strony wyrażasz zgodę na używanie cookies, zgodnie z aktualnymi ustawieniami przeglądarki.    X

Android Wear — emulator w Visual Studio i pierwsza aplikacja w Xamarinie (C#)

Testy Motoroli Moto 360 2 w akcji Lenovo pokazały spory potencjał w aplikacjach na Android Wear. Zupełnym przypadkiem od jakiegoś już czasu grzebię się w Xamarinie, czyli platformie skierowanej do programistów .NET (C#) do tworzenia multiplatformowych aplikacji (nie tylko mobilnych). Z czystej ciekawości postanowiłem sprawdzić, jak wygląda pisanie oprogramowania na Android Wear od strony dewelopera .NET. W pierwszej kolejności potrzebny będzie nam...

Emulator

Prace nad przygotowaniem wpisu i aplikacji zacząłem jeszcze na fizycznym zegarku (więcej o testowanym Moto 360 2), ale niestety czas szybko zleciał i trzeba było oddać smartwatch. Na szczęście z pomocą przychodzą emulatory.

Microsoft udostępnił świetny dodatek Visual Studio Emulator for Android, który uruchamia dowolną wersję Androida na Windowsie. Dodatkowo całość oparta jest na Hyper-V, dzięki czemu emulator działać bardzo szybko, o kilka klas lepiej niż to co otrzymujemy w SDK od Googla na okienkach. Niestety...

Visual Studio Emulator for Android nie doczekał się jeszcze obsługi Android Wear, przez co trzeba na daną chwilę korzystać z emulatora dostarczonego wraz z SDK Androida. Najgorsze jest to, że na Windowsie jest spora ilość problemów z jego uruchomieniem.

Pobieranie plików

Zakładam, że już macie zainstalowanego Xamarina w Visual Studio.

W takim wypadku przechodzimy do Android SDK Managera (w Visual Studio menu Tools - Android). Tutaj klikamy na Tools-Android SDK Tools i Android SDK Platform-tools. Dodatkowo w wybranej wersji Androida (co najmniej 4.4, najlepiej wybrać najnowszą, w moim przypadku to 7.0, aczkolwiek warto mieć także wersję 6.0, która skompiluje nam projekt w VS) zaznaczamy potrzebne pakiety, pamiętając o Android Wear.

Konfiguracja emulatora

Przyszedł zatem czas na konfigurację emulatora Android Wear pod Visual Studio. Będąc już w IDE wybieramy z menu Tools - Android - Android Emulator Manager. Po uruchomieniu Android Virtual Device (AVD) Managera przechodzimy do zakładki Device Definitions.

Wybieramy dowolne urządzenie z Android Wear. Ze względu na to, że przyzwyczaiłem się już do okrągłego ekranu Moto 360 zaznaczam: Android Wear Round. Teraz stworzymy nową "maszynę wirtualną" na podstawie definicji zaznaczanego urządzenia klikając na przycisk "Create AVD..."

W nowym oknie sprawdzamy, czy mamy żądaną wersję Androida i urządzenia (w tym przypadku Android 7.0 i Android Wear). Musimy także wybrać odpowiedni skin emulatora i wersję procesora pod Android Wear, o tym ostatnim za chwilę. Warto zaznaczyć także "Use Host GPU", w moim przypadku brak tej opcji powodował nieprawidłowe wyświetlanie ekranu urządzenia na emulatorze.

CPU: ARM vs Intel Atom - Windows 10 Anniversary Update suxx

Emulować możemy dwa typu procesorów. Podstawowy to ARM z którym zapewne nie będzie żadnych problemów (poza tym, że jest wolny).

Najciekawszą opcją jest jednak emulator oparty na Intel Atom, dzięki temu, iż wspiera wirtualizację sprzętową i działa do 10x szybciej niż emulator ARM. Jest z nim jednak kilka problemów. Jeśli mamy w systemie aktywowane Hyper-V, to musimy je dezaktywować (i uruchomić ponownie system), najszybciej z linii komend:

bcdedit /set hypervisorlaunchtype off

Dodatkowo musimy mieć HAXM (Intel® Hardware Accelerated Execution Manager). Silnik wirtualizacji pobieramy tutaj: Intel® HAXM. Wszsytko było by piękne gdyby nie to, że wersja HAXM w obecnej wersji (6.0.3) gryzie się z Windows 10 Anniversary Update! Na daną chwilę, osoby z najnowszą aktualizacją do Windows 10, nie są w stanie skorzystać z HAXM, a co za tym idzie uruchomić emulatora bazującego na Intel Atom. Niestety w takim przypadku zostaje tylko wybór wolniejszego emulatora ARM.

Odpalamy emulator

Jeśli wszystko zrobiliśmy poprawnie, wówczas na pierwszej zakładce Android Virtual Device (AVD) Managera mamy stworzony emulator Android Wear:

Wystarczy tylko kliknąć na "Start" i "Launch", aby uruchomić nasz nowiutki emulator Android Wear:

W tym momencie możemy pobawić się systemem. Tu mała uwaga, w tym momencie wybraliśmy emulator z najnowszą wersją systemu, czyli... Android Wear 2.0!

Xamarin Android Wear w Visual Studio

Przyszedł czas na uruchomienie pierwszej aplikacji na naszym emulatorze Android Wear. Klikamy na File - New- Project i z okna wybieramy Wear App (Android). Możemy także w ramach testów i nauki pobrać jeden z dostępnych projektów na stronie Xamarina.

W projekcie wybierzmy także odpowiednią wersję Androida, która skompiluje nam projekt:

Z górnej belki wybieramy stworzony emulator:

i odpalamy nasz projekt

Pierwsze uruchomienie może trochę potrwać. IDE wrzuci na Android Wear prócz naszej aplikacji także niezbędne pakiety: Mono Shared Runtime i Xamarin.Android API Support, do prac deweloperskich. Po kilku chwilach naszym oczom ukarzę się pierwsza stworzona aplikacja na Android Wear:

Podsumowanie

Android Wear to dość świeża platforma, tym bardziej framework na Xamarina to niezmiernie nowa odnoga na tej platformie. Warto dodać, że aplikacje na Android Wear można pisać w C# tylko w czystym Xamarinie, nie użyjemy tutaj Xamarin.Forms. Postawienie emulatora może sprawić trochę problemów, ale uważam, że warto. Chętni powinni spróbować swoich sił z aplikacjami na Android Weara już teraz. Aplikacje na zegarek używają wielu tych samych kontrolek, co zwykłe aplikacja na Androida. W większości przypadków apki na Android Wear współpracować będę z tymi "większymi" na smartfonie. Do wymianach danych pomiędzy nimi służy Data API i Message API, ale to już temat na inny wpis...

 

windows programowanie urządzenia mobilne

Komentarze

0 nowych
Semtex   18 #1 29.08.2016 19:07

Tego nawet, chyba, Mordzio nie przebije :)

mordzio   15 #2 29.08.2016 20:33

@Semtex: W takim razie składam wniosek o wykluczenie djfoxera z konkursu! Niech da wygrać innym;)

Semtex   18 #3 29.08.2016 20:48

@mordzio: Hahah, jak nie drzwiami to oknem :D

dthlfwp   7 #4 29.08.2016 20:52

Dlaczego nie Android Studio? Te nowsze wersje są oparte o IntelliJ, nie Eclipse jak kiedyś. Ja tam VS nie lubię, wydaje mi się zbyt kobylaste.

bachus   20 #5 29.08.2016 21:13

@mordzio: jaki konkurs? Jest jakiś regulamin na ten miesiąc? ;-)

bachus   20 #6 29.08.2016 21:15

@djfoxer: jak tam DePesza na Androida? ;-)
A co do pierwszej aplikacji - co tak skromnie a nie chociaż: "WITAJ PANIE" ;-)

djfoxer   18 #7 29.08.2016 21:26

@Semtex: Poczekamy, zobaczymy :)

@mordzio: Nie ważne kto głosuje, ważne kto liczy głosy :P :D

@bachus: W danej chwili przerzucam w wolnym czasie Chemię w żywności na Androida w Xamarin.Forms. Teraz przy okazji testów zobaczyłem jak Android Wear działa na Xamarinie. DePesza na Andka to przyszłość, nie wiem czy byliby chętni :)

djfoxer   18 #8 29.08.2016 21:26

@dthlfwp: Prosty powód - C# i Xamarin :)

bachus   20 #9 29.08.2016 21:29

@djfoxer: ustalmy jedną rzecz - nie ma miejsca na dyskusję "czy", tylko "kiedy".
Społeczność czeka i liczy na Ciebie:-)
PS to pytanie retoryczne czy "byliby chętni"?

Czarny Romek   6 #10 29.08.2016 23:07

@djfoxer: Co to za powód? W czym to lepsze od Android Studio? IDE Visual Studio tak po prawdzie jest przecież gorsze.

P.S. do zegarka też wrzucisz 30MB bibliotek Xamarina? Na telefonie może i przejdzie, na zegarku uwazaj bo miejsca zabraknie

Autor edytował komentarz w dniu: 29.08.2016 23:08
  #11 30.08.2016 07:50

@Czarny Romek: Ty tak na serio? Nieogarniasz ze xamarin używający c# nie obsługuje android studia?

pulka103   6 #12 30.08.2016 08:35

@Czarny Romek: Nie zaczynaj kolejnej idiotycznej kłótni. VS nie jest gorsze od AS, C# nie jest gorszy od Javy i basta. Tak samo w drugą stronę. Konkurencyjne rozwiązania. Plusy, minusy i te sprawy. Kwestia wyboru ;)

djfoxer   18 #13 30.08.2016 08:41

@Czarny Romek: Ale to jest trywialne :) Programuję w .NET, więc bez sensu jest abym tykał się Android Studio :)

"IDE Visual Studio tak po prawdzie jest przecież gorsze" - daruj już takie dziecinne wojenki :)

  #14 30.08.2016 09:12

Jaki jest rozmiar takiej aplikacji?

davidns   7 #15 30.08.2016 09:22

warto dodać, że MonoDevelop jest dostępne na Linuksa

Autor edytował komentarz w dniu: 30.08.2016 14:30
_qaz7   6 #16 30.08.2016 10:20

@Czarny Romek: "Co to za powód?"

Jeśli już się chce komuś bawić w zegarki, to powodem VS i Xamarina jest choćby multiplatformowość - Apple Watch.


A co do Android Studio jako środowisko do pisania w ogóle pod Androida, to jest to zabawka tak długo jak Gradle będzie wspierał NDK eksperymentalnie a nie produkcyjnie.

__Tux__   13 #17 30.08.2016 10:40

@pulka103: "C# nie jest gorszy od Javy i basta" - M$ nie zrobił wsparcia na Linuksa (Mono nie jest od M$), to wiele wyjaśnia w sprawie bycia gorszym :-P .

Czarny Romek   6 #18 30.08.2016 12:37

@_qaz7: Tak, bo to co producent systemu Android - Google daje ci jako środowisko deweloperskie do tworzenia aplikacji na swój system to tylko "zabawka". Micro$oft zrobił (a raczej kupił) lepsze. W końcu wiadomo, że firma trzecia zrobi lepsze środowisko niż sam właściciel i twórca platformy.

Czarny Romek   6 #19 30.08.2016 12:49

@davidns: "warto dodać, że Xamarin Studio + MonoDevelop dostępne są na Linuksa"

Warto też dodać, że na Linuksie nie ma obsługi programowania pod platformy mobilne. Warto też dodać, że nie ma Xamarin Studio na Linuksa - jest tylko Mono Develop.

Autor edytował komentarz w dniu: 30.08.2016 12:57
_qaz7   6 #20 30.08.2016 14:05

@Czarny Romek: 'Tak, bo to co producent systemu Android - Google daje ci jako środowisko deweloperskie do tworzenia aplikacji na swój system to tylko "zabawka".'

Nie spinaj się, to raczej Google nie zrobił żadnego środowiska dla Androida.

Najpierw użył Eclipse dorzucając plugin ADT, a jak się okazało, że są nie na czasie, to użył IntelliJ IDE i dorzucił plugin do Androida, który w obecnej fazie rozwoju nie jest w stanie zaoferować tego co ADT w Eclipse.

Czarny Romek   6 #21 30.08.2016 14:24

@_qaz7: No jak dla ciebie Android studio to zabawka, a lepsze jest Eclipse z pluginem ADT, to już nie mam więcej pytań. Android Studio to nie jest bynajmniej InteliJ "pluginem do Androida", tylko fork InteliJ i całkiem oddzielny produkt, bardzo intensywnie rozwijany przez Google.
Najpierw było Eclipse, dopóki nie dopracowali swojego produktu, plugin do Eclipse pewnie już nawet nie jest rozwijany,

P.S. Nie widziałem, żeby ktoś narzekał na działanie NDK w Android Studio, a specjalnie szukałem w internecie.

Autor edytował komentarz w dniu: 30.08.2016 14:27
davidns   7 #22 30.08.2016 14:32

@Czarny Romek: Niestety, a miało być tak pięknie. Micro$oft i Xamarin zapowiadali taki super, wieloplatformowy i otwarty .NET, a wyszło jak zwykle czyli Window$ only

Autor edytował komentarz w dniu: 30.08.2016 14:33
_qaz7   6 #23 30.08.2016 16:38

@Czarny Romek: "Android Studio to nie jest bynajmniej InteliJ "pluginem do Androida", tylko fork InteliJ i całkiem oddzielny produkt, bardzo intensywnie rozwijany przez Google. "

-----Widzę, że bardzo lubisz Google, ale to ja mam rację, nie Ty:
https://developer.android.com/studio/releases/index.html
https://blog.jetbrains.com/idea/2013/05/intellij-idea-and-android-studio-faq/

Czarny Romek: "No jak dla ciebie Android studio to zabawka, a lepsze jest Eclipse z pluginem ADT, to już nie mam więcej pytań."

---Nie jest lepszy, tylko miał produkcyjne wsparcie dla NDK, Android Studio z Gradle ma je w fazie eksperymentalnej.

_qaz7   6 #24 30.08.2016 16:39

@davidns: i jest wieloplatformowy, tylko nie w sensie IDE tylko w sensie kodu - przecież o tym właśnie pisze djfoxer.

Czarny Romek   6 #25 30.08.2016 16:43

@_qaz7: Ok ale generalnie dalej nie rozumiem puenty. Uważasz, że lepiej używać Eclipse, bo Eclipse ma przewagę? Jakieś konkrety? Czy NDK w Eclipse działa lepiej?

_qaz7   6 #26 30.08.2016 17:58

@Czarny Romek: "Uważasz, że lepiej używać Eclipse, bo Eclipse ma przewagę? Jakieś konkrety? Czy NDK w Eclipse działa lepiej?"

----Nie, Eclipse z ADT jest od dawna dla Google "deprecated", natomiast w Android Studio wsparcie dla NDK jest eksperymentalne (od Q3 2015, wcześniej nie było go wcale)

A konkret to np. niewspieranie zależności jednocześnie dla bibliotek statycznych i dynamicznych, ale i inne. W Eclipse załatwiały wszystko dość oczywiste makefiles, w Android Studio trzeba czekać na to, by deweloperzy AS/Gradle dokładali wsparcie, które utracono wraz z przejsciem z Eclipse do AS.

djfoxer   18 #27 30.08.2016 18:15

@Roman syn Ryżu (niezalogowany): 7MB

@davidns: "Window$ only" - Windows i Mac OS X.

Czarny Romek   6 #28 30.08.2016 21:07

@_qaz7: Co to znaczy " niewspieranie zależności jednocześnie dla bibliotek statycznych i dynamicznych"? Dla mnie oczywiste jest build.gradle, a nie żadne makefiles. Rozumiem, że to kwestia przyzwyczajenia do starego i dlatego zrzędzisz. Maven z Eclipsa to gojwno w porównaniu z Gradle z Android Studio. Jeśli ogarniasz nieco angielski, to tu masz krótkie porównanie: https://gradle.org/maven_vs_gradle/

_qaz7   6 #29 31.08.2016 10:52

@Czarny Romek: "Jeśli ogarniasz nieco angielski, to tu masz krótkie porównanie: https://gradle.org/maven_vs_gradle/"

Porównanie gradle z mavenem nie dotyczy naszego tematu, nie rozmawiamy o Javie tylko NDK.

Gradle z obecnym wsparciem dla NDK nie pozwala, żebyś zbuildował sobie np. "third_party_static_module.a" , "third_party_dynamic_module.so" i dołączył jako zależności do własnego "main_native_module.so".