Gphone.pl - Google Android, Apple Iphone, technologie mobilne

Kolejne video prezentujące pierwszego Quake’a działającego na urządzeniu pod kontrolą Androida :

Teraz pora na iPhone – Apple sięgnął nieco wyżej, po trzecią wersję – Quake 3. Sterowanie za pomocą czujników motorycznych – przechylając telefon poruszamy się po planszy, a dotykając ekranu – strzelamy.

Wyobraźmy sobie, co już niedługo będzie można zrobić z Google Earth na Androidzie, skoro udało się już zaimplementować sterowanie dotykiem :

Pojedynek Androida i iPhone powoli nabiera tempa, a Quake już w tej chwili stanowi swoisty odpowiednik pecetowego 3D Mark.

Google twierdzi, że Android jest nowoczesną, otwartą technologią. Stara się także zdobyć przychylność środowiska open-source. Jednak jak możemy przeczytać tutaj, w licencji SDK ukrytych jest kilka kruczków, stojących jawnie w sprzeczności z zasadami otwartego oprogramowania.

Z posta wynika m. in. :

• Nie można korzystać z kodu źródłowego zawartego w SDK
• Google twierdzi ze większość kodu będzie na Apache 2.0
• Google może cofnąć licencję, jeśli stwierdzi, że to co programiści tworzą za pomocą SDK jest sprzeczne z interesami Google

Wygląda na to, że Google Android jest tak otwarty, jak otwarta była Java zanim Sun zrobił ją w pełni open-source. Sun bardzo długo kontrolował Javę, lecz dopiero zmuszony przez społeczność podjął się jej uwolnienia. Google zapewne idzie tą samą drogą, pomimo oficjalnych zapewnień co do swojego przywiązania do społeczności open-source.

Czym jest zatem ta licencja na Android SDK? Wiadomo że Linux’owa część Androida jest na GPL, a także wiele bibliotek Javy pochodzi z projektów skupionych wokół Apache Foundation i korzysta z licencji Apache 2.0. Nie wiadomo jak będzie z kodem samego Google. Z pewnością w tej chwili SDK nie można uznać za prawdziwie open-source.

Poprzednio opisaliśmy, co tak naprawdę zamiast Javy siedzi wewnątrz Androida. Zważywszy na to, że sercem systemu jest Linux, nasuwa się pytanie, czy można tworzyć na niego aplikacje w językach innych niż Java? Ponadto, wokół samej Javy wyrosło sporo pomyślnych projektów integrujących ją z innymi językami programowania. Ponieważ urządzenia mobilne posiadają mało pamięci i nisko taktowane procesory, całkiem naturalne wydaje się poszukiwać rozwiązań opartych na C++ i C. Czy Android jako otwarta platforma umożliwia to wszystko?

C i C++

Podstawowym narzędziem programistycznym w każdym Linuxie (Unixie) jest oczywiście C. To właśnie w tym języku napisano nie tylko jądro systemu i sterowniki (moduły) ale także znaczną większość aplikacji, począwszy od powłoki i usług sieciowych, aż po środowiska graficzne (np. GNOME) i aplikacje użytkowe. Oprócz C ważną rolę w ekosystemie Linux’owym odgrywa także C++ (szczególnie w KDE).

Ponieważ Android jest w głębi duszy kolejnym Linux’em, wszystko powinno być możliwe . Aaron P. D’Souza podał przykład jak skompilować i uruchomić w emulatorze niewielki konsolowy program napisany w C++. Potrzebny jest jedynie specjalny pakiet GNU/ARM Linux (download). Podobne rozwiązanie opisuje Benno.

Niestety, tak napisane programy nie integrują się w ogóle z całą funkcjonalnością platformy. Nie mogą wyświetlać grafiki, ani tym bardziej wysyłać SMSów, odtwarzać muzyki czy przede wszystkim komunikować się z pozostałymi aplikacjami napisanymi w Javie. Można jednak zrobić w drugą stronę: typowa aplikacja Javowa może wywoływać kod napisany w C/C++ poprzez interfejs JNI. Davanum Srinivas opisuje cały proces krok po kroku. Dzięki temu, jeśli jakiś fragment aplikacji (np. obliczenia matematyczne, kompresja audio/video) zajmują zbyt wiele czasu, można pokusić się o zaimplementowanie go w C i wywoływać z poziomu Javy.

Jednak mariaż C z Androidem budzi kontrowersje. Na grupach dyskusyjnych rozstrząsa się sens i przydatność takich pomysłów. Przede wszystkim, o ile program napisany w C łatwo przygotować tak, aby działał w emulatorze, w rzeczywistości, aby z aplikacji można było korzystać na każdym telefonie, należałoby skompilować taki program na każde urządzenie osobno. Tak jest w przypadku systemu Symbian OS. Ponadto, Google specjalnie skoncentrował się na Javie po to, aby uniknąć problemów z kompatybilnością aplikacji i wyeliminować potrzebę tworzenia różnych wersji tej samej aplikacji na różne modele urządzeń.

Hatem Ben Yacoub z Open Handset Magazine poddał w wątpliwość takie próby.

Python, Jython

Niektórze narządzia wchodzące w skład SDK takie jak np activityCreator.py napisane są w Python’ie. Wiadomo też, że Python, obok Javy i JavaScript’u, jest jednym z ulubionych języków inżynierów Google. Czy można więc pisać aplikacje na Androida w Pythonie?

Pierwsze próby skompilowania Pythona na gphone’a podjął Marcelo Barros de Almeida, lecz nie udało mu się jak dotąd uruchomić interpretera ani interaktywnego shella. Ponadto aplikacje uruchamiane w środowisku Pythona, zamiast w JVM musiałyby się komunikować z platformą poprzez specjalne binding’i pomiędzy Pythonem a Javą, a właściwie Dalvik’iem.

Lepszym rozwiązaniem będzie tutaj użycie Jython’a - implementacji Pythona na JVM. Programy napisane w Jythonie mogą używać zarówno standardowych bibliotek Python’owskich, jak i tych dostepnych w Javie i nie potrzebują do tego żadnych bind’ingów. Kod napisany w pythonie jest tłumaczony do bytecode’u Javy. Ponadto Jython może pracować w trybie interpretera kodu źródłowego. Próbę uruchomienia Jythona na Androidzie podjął hdante, lecz także napotkał problem. Nic dziwnego, wcześniej opisywaliśmy już różnicę pomiędzy JVM a wirtualną maszyną Dalvik’a. W SDK w tej chwili brakuje pełnej implementacji Java Reflection API, a fundamenty języków dynamicznych takich jak Python opierają się o mechanizm reflection.

Podobne próby i rozważania na ten temat podjęto tutaj i tuaj.

Ruby i JRuby

Z tego samego powodu nie udaje się też użyć Ruby‘ego ani JRuby‘ego. Brak pełnej implementacji Javy w SDK powoduje java.beans.IntrospectionException i uniemożliwia uruchomienie programów napisanych w JRuby.

Groovy

Popularność Jythona i JRuby zainspirowała powstanie języka Groovy. Mówi się o nim, że tak wygladałaby Java, gdyby zaprojektowano ją dzisiaj. Groovy jest dynamicznym językiem przeznaczonym do pracy w JVM. Stanowi on doskonałe rozszerzenie Javy i świetnie sprawdza się w zastosowaniach webowych.

Niestety, podobnie jak poprzednie technologie, Groovy w dużej mierze opiera się o Reflecion. Ponadto operuje bezpośrednio na bytecodzie Javy, a nie na Dalvik’u. Z tego powodu tylko częściowo udało się dotychczas skompilowac okrojoną jego wersję. Skrypty jednak nie dają się uruchomić. Tutaj także brak java.beans.Inspector uniemożliwia integrację Groovy’ego z Androidem. Dyskusja tutaj.

Scala

Scala jest eksperymentalnym językiem programowania, który ostatnio zdobywa wielu zwolenników. Do niedawna można było pisać w niej programy na platformę .NET i J2SE oraz J2ME. W najnowszej wersji pojawił się target prosto na Androida!

Tutaj można znaleźć krótki opis jak napisać w Scali program i zainstalować go w emulatorze.

Tym samym Scala jest w tej chwili jedynym językiem dynamicznym z samej czołówki w pełni zaimplementowanym na Androidzie.

Inni gracze na boisku

Jest jeszcze wiele innych technologii, które programiści chętnie widzieliby dostępne na gphone’ach. Sun tworzy właśnie JavaFX Mobile (SavaJX), która ma szansę zastąpić J2ME. Adobe zapewne chciałby popularyzować swojego Flash’a i bazującego na nim AIR (więcej tutaj). Fani .NET i Mono szukają sposobu, aby także dołączyć do społeczności Androida, proponując różne pomysły na integrację. Biorąc jednak pod uwagę problemy z C i niekompatybilność Dalvika z JVM, integracja tych technologii na Androidzie może się okazać w najbliższym czasie niemożliwa.

A może JavaScript?

Tymczasem szybko rozwijający się projekt Google Gears, rozszerzający funkcjonalność aplikacji webowych uruchamianych po stronie klienta (tj. w przeglądarce) w połączeniu z GWT może przerodzić się w nową platformę zarówno dla aplikacji webowych, jak i mobilnych. Są już pierwsze porty GWT na Androida. Gears jest dostępne już w wersji dla Windows Mobile i zapewne już niedługo Google przeniesie je na swój system. Pozwoli to na budowanie aplikacji mobilnych przy użyciu techonologii AJAX, frameworków takich jak Dojo, JQuery, YUI i GWT. Jedna aplikacja będzie mogła działać zarówno na Windows Mobile, jak i Androidzie a nawet iPhone. Safari 3 jeszcze nie wspiera Gears, ale prace nad tym zostały już podjęte.

Google Gadgets są jednym z najważniejszych projektów Googla. Powszechne użycie Gears’ów pozwoliłoby na rozszerzenie ich funkcjonalności i przeminę w mikro-aplikacje o desktopowych możliwościach. Mogło by to poważnie zagrozić istnieniu MS Silverlight’a i Adobe Flex, a z pewnością Sun JavaFX, zarówno w świecie desktopów, jak i urządzeń mobilnych. Dlatego można się spodziewać dużego wkładu w Gears i Androida ze strony Google.

A co z J2ME?

Pozostaje jeszcze na koniec pytanie, co z instniejącymi aplikacjami napisanymi w technologii J2ME. Takiej aplikacji nie można od razu uruchomić na Androidzie. Są jednak projekty takie jak ME4SE, które uzupełniają J2SE o funkcjonalność ME. Stworzona przez Poliplus specjalna jego wersja ME4android pozwala przenieść aplikację J2ME tak, aby działała na Androidzie i Dalvik’u.

Wnioski

Wygląda na to, że jeszcze przez jakiś czas jedynym językiem programowania na Androida pozostanie Java. Google musi jeszcze zaimplementować kilka ważnych mechanizmów, których brak uniemożliwia użycie innych technologii. Ciekawe jednak, że ekipie zajmującej się językiem Scala udało się zrobić to, czego nie dokonali inni. Najbardziej obiecująca jest jednak perspektywa użycia Google Gears.

Otwartość Androida, ADC i wielka pompa, jaka towarzyszyła udostępnieniu pierwszych wersji SDK owocują ogromnym rozkwitem pomysłów. Widzieliśmy już nowatorskie aplikacje, takie jak Enkin czy Kudostar, powstałe w ramach konkursu ADC, które zapewne zmienią oblicze technologii mobilnych i podniosą poprzeczkę oczekiwań użytkowników co do aplikacji.

Pomysłowość developerów oraz determinacja Google w zdobywaniu zainteresowania Androidem wśród błyskotliwych programistów zaprowadzi nas być może do zupełnie nowatorskich rozwiązań. Podczas gdy w technologiach webowych zaciera się granica pomiędzy aplikacjami klienckimi a serwerami, pomiędzy desktopem a terminalem, podobny proces zachodzi pomiędzy PCtem a urządzeniami mobilnymi.

Jednym z dobitnych przykładów tego jest powstanie iJetty - popularnego, miniaturowego serwera web’owego Jetty w wersji dla Androida. Dzięki iJetty możemy własny telefon zamienić w serwer internetowy. Może on hostować aplikacje AJAXowe lub Comet, statyczne strony HTML a także usługi webowe, zaimplementowane jako Servlety w Javie. Pojawienie się iJetty nie przeszło w sieci bez echa.

Dzięki iJetty można będzie np. nosić swojego bloga i stronę internetową dosłownie we własnej kieszeni. Ale co ciekawsze, można będzie także kontrolować swój telefon zdalnie, przez internet, bez Bluetooth, IRDA czy USB, prosto ze swojej przeglądarki internetowej! Powstał nawet mały Google Gadget, dzięki któremu można wyświetlać ekran swojego telefonu bezpośrednio na stronie startowej iGoogle! Teraz zamiast podłączać telefon do komputera, można będzie po prostu przesłać do niego zdjęcia i muzykę tak, jakby się wysyłało maila. I w drugą stronę, równie łatwo będzie można ściągnąć z niego zdjęcia czy nakręcone wideo, a nawet zajrzeć do kontaktów czy wysłać SMSa. Jeśli telefon zagubi nam się w pokoju, można będzie się z nim połączyć i np. uruchomić MP3 Player, dzięki czemu szybko odnajdziemy telefon.

Z punktu widzenia programistów, sprawa jest jeszcze ciekawsza. Ponieważ jeszcze przez kilka lat połączenie z siecią z telefonu będzie miało dość ograniczoną przepustowość, developerzy chcieliby część kodu wykonywać bezpośrednio na urządzeniach, zamiast na serwerze, aby użytkownik nie musiał czekać na reakcje aplikacji zbyt długo. iJetty pozwoli na implementacje fragmentów usług po stronie klienta, dzięki czemu poprawi się user experience.

Wprowadzenie technologii webowych na platformy mobilne pozwoli na stworzenie bardzo zdecentralizowanych sieci P2P i komunikatorów opartych o wszechobecny protokół HTTP. Taki mobilny anonimowy FreeNet. Tego typu zdecentralizowane sieci odporne są na katastrofy. Internet udowodnił już wiele razy, że w razie kataklizmu doskonale nadaje się jako niezawodna platforma komunikacyjna, w przeciwieństwie do sieci GSM. Wykorzystując, oprócz połączeń internetowych przez GSM, WiFi oraz Bluetooth, można stworzyć rozproszoną, zdecentralizowaną, samo-organizującą się sieć. Urządzenia, którym udało się połączyć ze stacjami bazowymi telefonii komórkowej, mogłyby służyć jako routery i umożliwiać innym dostęp do sieci poprzez WiFi.

Oczywiście, zrobienie z telefonu prawdziwego serwera to kiepski pomysł: ograniczone zasoby pamięci, powony procesor i niska przepustowość wyczerpią baterie i zapchają system, jeśli będzie chciało z niego korzystać więcej niż zaledwie kilku odwiedzających naraz.

iJetty jest już aplikacją stabilną. Brakuje w niej jednak możliwości dynamicznego ładowania aplikacji webowych przygotowanych jako pliki .war. Nie działają też ClassLoader’y. Webtide i Google jednak zapowiadają rozwiązanie tych niedogodności w najbliższym czasie. Webtide jednak nie jest jedynym, który idzie w tym kierunku: Nokia stworzyła Raccoon – port popularnego serwera Apache na telefony komórkowe oparte o S60 3rd Edition. Więcej o Raccoon można przeczytać tutaj.

Producenci telefonów komórkowych testują prototypy pierwszej fali do certyfikacji FFC, modele do publicznej sprzedaży trafią zapewne już w 2008 roku – czy można mówić o walce Google vs Apple, gPhone vs iPhone? Dyskusja rozpoczęła się wraz z publikacją iPhone SDK (software development kit).

Czy powstanie walka na linii Android-Iphone? Czy producenci będą musieli wybierać między dwoma różnymi SDK determinującymi zastosowanie i funkcjonalność telefonu? Co wybiorą użytkownicy? Jaki będzie ruch obecnych dominantów takich jak Nokia, Sony Ericsson, Samsung, Siemens czy LG?

Z jednej strony, serwis AndroidGuys twierdzi że pierwsza generacja smartfonów korzystających z Androida będzie obarczona licznymi bugami problemami z jakością oraz niedużym wsparciem oprogramowania. Iphone też miał początkowe trudności, a bugi zdarzają się zawsze.

Droidworks wylicza istotne różnice między tymi dwoma platformami. Apple Iphone to tzw. high-end smartphone (chociaż nie wszyscy się z tym zgadzają) zintegrowany z oprogramowaniem charakterystycznym Maców oraz sklepem iTunes. Z kolei Android oparty jest na rozwiązaniach otwartych, łatwo skalowalnych. W skali globalnej zobaczymy zapewne więcej ‘telefonów Googla’ na rynkach rozwijających się (Indie, Chiny) głównie ze względu na cenę licencji, osprzętu, dystrybucję. Polska również może należeć do krajów, gdzie iPhone będzie drogim gadżetem a ‘zwykłe’ smartfony obsłużą Androida – na przykład nie wymaga on ani touchscreena ani pełnej klawiatury QWERTY (ale obsługuje).

Zaletą Apple’a jest dbałość o markę, jakość czy promocja, support. W Polsce firma nie jest rozpoznawana tak, jak na zachodzie – u nas dodatkowo czynnikiem jest cena. W USA, Anglii czy Niemczech użytkowników stać na dowolny gadget i o zakupie decydują inne cechy. Android może nie być tak rozpoznawalny, niektórzy posiadacze telefonów działających na SDK Googla mogą nawet nie wiedzieć, że posiadają “Googlefona” – różni producenci mogą stworzyć inne oprogramowanie oraz interfejs użytkownika, Android jest bardziej uniwersalny od iPhona. Google i Apple stawiają na inny model biznesowy i prawdopodobnie obie firmy zostaną zwycięzcami boomu telefonów komórkowych. Tylko kto straci?

Producentów Google Phone’a będzie wiele, Apple tylko jeden. Pojedynek nie jest bezpośredni, dotyczy nieco innego modelu dystrybucji i tworzenia sprzętu, oprogramowania. Ale czy użytkownicy będą posiadali dwie komórki – gadżet Apple’a oraz platformę Open Handset Alliance?

Dalvik – miasto na północnym wybrzeżu Islandii w którym żyje ok. 1500 osób. Jest typowym miastem portowym, dobrze rozwinięte jest tu rybołówstwo oraz przeróbka ryb, a także znajduje się niewielki przemysł. Zaopatrywany jest w ciepłą wodę z gorących źródeł. Mieści się tu urząd gminy oraz muzeum. W 1943 roku trzęsienie ziemi zniszczyło większość domostw w Dalvik.

- Wikipedia

Z wierzchu Java, pod maską Dalvik

Docelowym językiem programowania na Androida jest Java. Zwykle pliki z kodem źródłowym napisanym w Javie kompilowane są do plików .class, zawierających instrukcje dla wirtualnej maszyny. Instrukcje te nazywa się bytecode ‘em Javy (Java Bytecode). Kiedy uruchamiamy skompilowany program napisany w Javie, wirtualna maszyna (JVM) ładuje owe pliki do pamięci i uruchamia zawarty w nich kod. Jednak Android nie posiada JVM! Zamiast JVM, Google zdecydował się wyposażyć Androida w technologię Dalvik.

Java Reloaded

Dalvik to coś w rodzaju ulepszonej wirtualnej maszyny Javy. Java ma już swoje lata, ale od tego czasu fundamenty tej technologii nie zmieniły się. Kilkanaście lat doświadczeń z Javą i urządzeniami mobilnymi wykazały nieliczne, lecz bardzo ważne słabe punkty JVM. Sun nadal nie zdecydował się na podjęcie drastycznych kroków, aby te problemy rozwiązać. Skoro Sun nie skłania się do ulepszenia Javy jako platformy w najbliższym czasie, inżynierzy Google’a zdecydowali wziąć sprawy w swoje ręce i stworzyli własne rozwiązanie. Tak właśnie powstał Dalvik – nowoczesna wirtualna maszyna, przystosowana specjalnie do urządzeń mobilnych, gdzie szczególną uwagę należy zwrócić na małe zasoby pamięci, energii i niewielką prędkość procesorów.

Wśród narzędzi zawartych w SDK znajduje się kompilator. Kompilator ów nie tworzy jednak plików .class z bytecode’m Javy, lecz pliki .dex z bytecode’m Dalvik’a. Następnie skompilowane pliki, wraz ze strukturą katalogów i znajdującymi się w nich multimediami, zostają spakowane – zamiast do pliku .jar - do pliku .apk (Android Package). Tak przygotowana aplikacja uruchamiana jest przez wirtualną maszynę Dalvik’a.

Ma to swoje implikacje – zarówno plusy, jak i minusy. Do plusów należy zaliczyć z pewnością lepszą obsługę pamięci, lepszy Garbage Collector, większą wydajność. Z drugiej strony bytecode Dalvik’a nie jest w 100% kompatybilny z bytecode’m Javy. Nie zadziałają więc na Adnroidzie bardziej wyrafinowane sztuczki programistyczne, korzystające z Class Loader’ów czy Java Reflection API.

Prawie jak Java

Bezpośrednio przekłada się to na problemy z uruchomieniem na Androidzie projektów korzystających np. z języków takich jak Groovy, JRuby czy Jython. Ponadto pojawiają się problemy, jeśli chcemy użyć framework’ów IoC takich jak Spring, OSGi czy chociażby PicoContainer. Także iJetty - wersja popularnego, minimalistycznego serwera webowego Jetty, przygotowana specjalnie dla Androida – nie może w tej chwili samodzielnie instalować aplikacji webowych dostarczanych w plikach .war.

A więc Dalvik jest prawie jak Java. Jak wiadomo, prawie robi wielką różnicę i jeśli Google pragnie sukcesu Androida, będzie musiał podjąć pewne kroki. Na razie pojawiają się plotki o obietnicach, że w SDK pojawią się w ClassLoader’y takie jak w Javie, a także z czasem dostępne będzie też pełne wsparcie dla Reflection API.

A więc wielki konkurs Google’a rozpoznawany w sieci jako Android Developer Challenge I zamknięty! Do 14 kwietnia wpłynęło w sumie 1,788 zgłoszeń, z ponad 70 państw na całym świecie. Pierwsze aplikacje zgłaszano już na samym początku konkursu, ale to właśnie w ostatnich chwilach zgłoszono ich najwięcej: tuż przed deadline’m było ich ponad 170 na godzinę!

100 specjalistów wytypowanych przez Open Handset Alliance wybierze najlepsze aplikacje. 50 półfinalistów zostanie ogłoszonych już w maju, a każdy z nich dostanie 25 000 dolarów i awansuje do następnego etapu. Następnie 10 z nich wygra 100 tys i 10 dostanie 275 tys dolarów.

To daje razem nagrody w wysokości 5 milionów dolarów z przeznaczonych przez Google 10 mln. Drugie 5 mln zostaje bowiem pulą dla drugiej, jesiennej edycji ADC II. Więc ci, którzy nie zdążyli, bądź ich aplikacje nie były na tyle gotowe aby zaszokować jury, mają jeszcze szansę zdobyć nagrody!

A jakie są najciekawsze aplikacje? No cóż, przejrzenie chociażby połowy z ponad 1700 zgłoszeń zajmie zapewne sporo czasu, ponadto wiele z nich zostało dodanych w ostatniej chwili. Będziemy na bieżąco śledzić nowinki, ale już w tej chwili można wytypować kilku faworytów:

• Enkin o którym już pisaliśmy
• KudoStar – oceniaj lokalizacje i inne, dziel się nimi w Facebooku
• Wi-Fi Army- Massive Multiple Mobile Online Game :>
• SpaceBugs- prosty shooter
• Omnisoft Games- engine i zestaw gier 3D
• Parallel Kingdom- Coś jakby uproszczone Age of Empires na mapie Google
• NavXS- Dziel się kontaktami i lokalizacjami, bądź na bieżąco co i gdzie się dzieje!
• Pocket Journey- twórz własne mini-przewodniki turystyczne, dziel się z innymi

Jeśli jesteś ciekaw jak wyglądały ostatnie godziny i nastroje tuż przed deadline’m i tuż po nim, przeczytaj ten krótki reportaż.

W tym artykule zostanie przedstawione krok po kroku jak napisać prosty program na Androida przy użyciu Eclipse.
Opiszemy instalację podstawowych narzędzi, podamy przykładowy kod w javie i uruchomimy program w emulatorze.

Instalacja SDK

Oczywiście, przede wszystkim musimy mieć JDK w wersji co najmniej 5.
Android SDK można pobrać ze strony Google Android. Mamy do wybory różne wersje w zależności od systemu operacyjnego, jakiego używamy. SDK zajmuje niecałe 80 MB. Po ściągnięciu należy je rozpakować.

Załóżmy dla uproszczenia, że naszym systemem operacyjnym jest Windows XP a Android SDK rozpakowujemy w katalogu:


C:\android_sdk


Instalacja Eclipse

Eclipse IDE można ściągnąć tutaj.Najlepiej wybrać wersję z Web Tools Platform (WTP), ponieważ pozwoli to nam skorzystać w przyszłości z dodatkowych edytorów oferowanych przez ADT.

WST domyślnie wchodzi w skład zwykłego Eclipse IDE for Java Developers (80 MB),
Eclipse for RCP/Plug-in Developers (153 MB) oraz
Eclipse IDE for Java EE Developers (126 MB).

Po ściągnięciu należy je rozpakować, załóżmy że do katalogu:


C:\Eclipse


Po uruchomieniu Eclipse, wybieramy jakąś ścieżkę dla naszego projektu, a po inicjalizacji narzędzia pojawia się ekran powitalny. Po jego zamknięciu możemy przejść do instalacji ADT.

Instalacja i konfiguracja pluginu ADT

W menu wybieramy Help > Software Updates > Find and Install, po czym zaznaczamy Search for new features to install i klikamy Next.
Następnie wybieramy New Remote Site i wpisujemy :


https://dl-ssl.google.com/android/eclipse/


Po czym klikamy Finish. W następnym oknie zaznaczamy Android Plugin > Developer Tools.
W tym miejscu mała uwaga: ADT składa się w tej chwili z dwóch podzespołów. Pierwszy, podstawowy Android Developer Tools oraz dodatkowy Android Editors.

Ten drugi zawiera dodatkowe, opcjonalne edytory wspomagające pracę. Na razie nie będziemy z nich korzystać, ale warto zaznaczyć, iż wymaga on zainstalowanego wspomnianego wcześniej WST.

Klikamy Next, akceptujemy warunki licencji itd. aż dotrzemy do momentu, w którym możemy wreszcie rozpocząć całą instalację poprzez kliknięcie Install All.

Po instalacji ADT musimy jeszcze zrestartować Eclipse.

Teraz należy ustawić w ADT ścieżkę, gdzie będzie on szukał emulator i innych narzędzi Android SDK:

Wybieramy w menu Window > Preferences, następnie w oknie które się pojawi wpisujemy ścieżkę do SDK, np. :


C:\android_sdk


Zakładamy nasz pierwszy projekt

W menu wybieramy File > New > Android Project.

W oknie dialogowym nowego projektu wpisujemy np :

1. Project name: MojProjekt
2. Package name: com.moj.pakiet
3. Activity name: MojaActivity
4. Application name: MojaAplikacja

i klikamy Finish.

Teraz ADT stworzy nam gotowy projekt zawierający bardzo prosty przykłądowy kod, wraz ze wszytkimi plikami i struktura katalogów, potrzebnymi do uruchomienia programu.

W Package Explorer wyszukujemy MojProjekt > com.moj.pakiet > MojaActivity.java. Powinien on zawierać już przykładowy kod :


package com.moj.pakiet;

import android.app.Activity;
import android.os.Bundle;

public class MojaActivity extends Activity {
/** Called when the activity is first created. */
@Override
public void onCreate(Bundle icicle) {
super.onCreate(icicle);

setContentView(R.layout.main);
}
}

Wprowadźmy kilka zmian tak, aby wyglądał on następująco :


package com.moj.pakiet;

import android.app.Activity;
import android.os.Bundle;

import android.widget.TextView;

public class MojaActivity extends Activity {
/** Called when the activity is first created. */
@Override
public void onCreate(Bundle icicle) {
super.onCreate(icicle);

TextView tv = new TextView( this );
tv.setText( “Hurra!” );

setContentView( tv );

}
}

Uruchamiamy program

W menu wybieramy Run > Open Run Dialog po czym klikamy podwójnie na Android application.
Po lewej pojawi się formatka na której należy wpisać :

1. Name: Moja Pierwsza Aplikacja
2. Project > Browse: MojProjekt
3. Activity: com.moj.pakiet.MojaActivity

Po czym wybieramy Run. Teraz powinien uruchomić się emulator. Ładowanie systemu może potrwać nawet kilka minut, a na koniec powinien automatycznie zostać uruchomiony nasz program.

Jeśli dokonamy zmian w kodzie MojaActivity.java, nie musimy zamykać emulatora, aby przeładować nasz program. Wystarczy w emulatorze zamknąć naszą aplikację, w Eclipse zapisać zmiany i ponowanie uruchomić z menu za pomocą Run.
ADT automatycznie przekompiluje nasz program i wyśle do emulatora, dzięki czemu nie musimy go restartować.