Kategorie
Bez kategorii

Czym pisać i w jakim języku?

Trochę się naszukałem, a może i „przeszukałem„, w sieci. Czego szukałem? Narzędzia, środowiska programistycznego, kompilatora i… W skrócie to szukałem „czegoś„, co by mi się spodobało i było wygodne do pisania aplikacji dla Androida. Szczególnie aplikacji multimedialnych, aplikacji graficznych, gierek. Oczywiście – profesjonaliści piszą w Javie pod Eclipse-m (a prawdziwi twardziele to chyba kompilują projekt z linii poleceń za pomocą batch-y). No może ten trend się zmieni, gdyż w połowie maja ’13 Google opublikowało Android Studio – nowe środowisko do tworzenia aplikacji – też w języku Java. Android Studio to połączenie SDK (bibliotek) ze środowiskiem IntelliJ IDEA. Jest to wersja testowa (early access preview) i jako taka ma prawo mieć swoje narowy. Ja czym prędzej (już 16. maja) ściągnąłem instalator i uruchomiłem Studio… Hm… Z wyglądu o wiele prostsze od Eclipse’a (cóż może być bardziej skomplikowane?). Ale w działaniu to Studio jest jeszcze w fazie bardzo „preview”. Błyskawicznie rozprawiło się z zasobami Windows i zamknięcie programu było możliwe dopiero po dłuższej gimnastyce z menedżerem aplikacji. Jeszcze poczekajmy, co się w wygugla z tego Studia.

W każdym bądź razie mam za sobą kilka eksperymentów „językowośrodowiskowych” zakończonych niepowodzeniem. Najpierw umordowałem się z HTML5. Nie tędy droga dla aplikacji, które z grafiki korzystają w sposób dynamiczny – przynajmniej dopóki ktoś nie wymyśli szybszych przeglądarek internetowych. Może w Firefox OS to będzie sprawniej działać, ale nie pod Androidem. Zwłaszcza gdy tablet lub smartfon jest, jakby to delikatnie ująć, o już mam – z niższej półki. Może będzie śmigać, gdy odpalimy aplikację w HTML-u na tabliczce z czterordzeniowym prockiem i solidną kartą graficzną… Może i będzie, ale ile osób zdąży się zniechęcić nie mając tak wypasionego sprzętu.

Pierwszy nie Javowy i nie html-owy programik napisałem w… Basic-u. Jednak RFO-Basic okazał się niewygodny z dwóch powodów:

  • bardzo proste środowisko działa tylko pod Androidem (chociaż program do tworzenia aplikacji z kodu w basic-u jest przygotowany pod Windows), a na tablecie nie daje się efektywnie pisać kodu;
  • oprogramowanie ma wirusową licencję GPL i każda aplikacja (zawiera w sobie interpreter RFO-Basica) musi być otwarta dla użytkowników (o ile w przypadku demek to nie ma znaczenia, jednak komercyjne zastosowania są wykluczone).

Szukałem zatem dalej i dalej. W świecie PC jestem praktykiem programowania w Delphi. Mam jeszcze krążek z wersją 3.0. W takiej jednej instytucji, w której zdarzyło mi się ostatnio pracować, programujemy w Delphi 2007 (zaczęliśmy właśnie A.D. 2007)… Ale jest jeszcze Lazarus – open source’owe środowisko „delfiopodobne” dla kompilatora FreePascal (z którego nota bene firma CodeGear, obecny właściciel marki Delphi, korzysta przy kompilacji dla MacOS-a). Właśnie dla tego środowiska przygotowany został kompilator FPC (na razie wersja testowa) pozwalający kompilować aplikacje dla Androida w oparciu o NDK i jni (dla grafiki). Przeczytałem, ściągnąłem, skonfigurowałem, skompilowałem, przetestowałem i zapomniałem. Aplikacje nie są „produkowane” stabilnie – działają „czasem tak, czasem siak„. Tak, jak wspomniane wcześniej Android Studio – poczekam aż dojrzeje. Wtedy „egoistycznie” zerwę i spróbuję… Może wcześniej firma CodeGear opublikuje nowe Delphi z serii XE (obecnie jest czwórka na topie), dla którego zrealizowane będą obietnice (wygłaszane już od trzech lat) włączenia do środowiska RAD interfejsu do tworzenia aplikacji androidowych.

Żeby wyczerpać „do cna” temat basic-a, to miałem jeszcze epizod z trial-em Basic4Android. Zainstalowałem środowisko, coś tam popraktykowałem… Na pierwszy rzut oka wyglądało to na translator basic -> java. Struktura aplikacji w basic-u analogiczna jak w Eclipsie. Trial produkował projekt właśnie dla Eclipsa. Nie było automatycznego build-owania do formatu APK. Ponieważ dla mnie liczy się pierwsze wrażenie – więcej tego trial-a nie uruchomiłem. I w tym przypadku nie będę czekał – zapominam! Nie dam nawet linku, a co!

Zwiedziłem sporo stron internetowych wyszukanych pod kątem hasła „game engine„. Jak ktoś chce pójść moimi śladami, to uprzejmie informuję: jest strona na anglojęzycznej Wikipedii poświęcona temu hasłu i znajduje się na niej sporo wartościowych odnośników. Ze sporego zbioru wziętych pod uwagę i aktywnych „game engine’ów” szybko eliminowałem takie, które opierają się na HTML5 i tylko oferują „przepakowanie” kodu javascript-owego w opakowanie dla Androida lub iOS-a. Chwilę zatrzymałem się przy Blenderze i jego dwóch „growych silnikach„: Game Engine i Game Development Kit. Pierwszy jest publikowany na licencji GPL i wymaga udostępniania źródłowego kodu aplikacji (ponadto z opinii – jest dość wolny), a drugi engine jest jeszcze w fazie eksperymentalnej i nie udało mi się zbudować na jego podstawie nawet demonstracyjnej aplikacyjki.

Już, już byłem niebezpiecznie blisko kapitulacji. Tak sobie myślałem – może „przełamać się” i zagłębić w Javę – wszak już kiedyś popełniłem jakieś mniej lub bardziej rozbudowane applety w tym języku, które miały po kilka tysięcy linii kodu. A może zainwestować w Unity lub Unreal Development Kit? Jednak wersje tych silników oferowane „za free” nie zyskały w moich oczach uznania (np. takie zdanie ze strony producenta „Please also be aware that the feature set of the free version is not intended for the production of professional games and interactive content„). A cena komercyjnych „modeli” przekraczała moje możliwości. To może po prostu porzucić mobilne programowanie i zająć się znanymi, okienkowymi problemami?

Jednak upór zwyciężył i nie skapitulowałem. Przypomniałem sobie, a także trochę podpowiedziała mi moja Nieoceniona Córka, że istniej taki język co się nazywa Lua. Kiedyś natrafiłem na Luę, gdy próbowałem pisać oprogramowanie dla 3Com-owskich Palm-ów – zatem temat nie był mi obcy. Na rynku mamy sporo game engine’ów wykorzystujących ten język. Ponoć najpopularniejsza aplikacja świata (Angry Birds) została napisana właśnie w tym języku (silnik o nazwie Moscrif, o ile mnie pamięć nie myli). Znalazłem w sieci kilka silników do pisania w języku Lua, które mają swoje w pełni funkcjonalne darmowe wersje. Zacząłem od Gideros-a, ściągnąłem też i zainstalowałem SDK CoronaLabs ( w wersji starter), chwilę się zatrzymałem nad środowiskiem o wdzięcznej nazwie Marmalade, a także nad Moai. Trochę więcej czasu „badałem” w pełni open-source’owe (licencja zlib) Love. Wspomnianego wcześniej Moscrif-a też „spróbowałem” ale wersja free/trial była wyjątkowa – uniemożliwiała stworzenie funkcjonalnej aplikacji. Z tej wycieczki po game engine’ach dla programujących w języku Lua zwycięsko wyszły: Gideros i Corona.

W międzyczasie zwróciłem uwagę na innowacyjny projekt MIT AppInventor. Nawet trochę w nim zaprogramowałem (rysowanie palcem po śladzie, a także nową wersję układanki 4×4 tzw. 15-puzzle). Jednak wydajność kodu tworzonego przez AppInventor-a jest wysoce niezadowalająca. W mojej ocenie szybkość działania graficznych aplikacji jest porównywalna (a może i gorsza) niż podobnych aplikacji napisanych w HTML5. Ale AppInventor to, w mojej ocenie, całkiem przydatne narzędzie do tworzenia szkieletów aplikacji, które trzeba czasem pokazać w formie wczesnego prototypu. Łatwo się projektuje przejścia pomiędzy ekranami, łatwo się ustawia komponenty i definiuje logikę. Jeszcze będę się zastanawiał, jak wykorzystać to narzędzie. Może jako centrum do uruchamiania innych apk-ów? A może do aplikacji, w których nie trzeba stosować ruchomej grafiki? Zobaczymy…

Od kilku lat korzystam ze strony, na której autor zbiera multum informacji o darmowych narzędziach programistycznych. Na tej stronie znalazłem kiedyś odnośnik do środowiska zwanego Processing. Przypomniałem sobie o nim i zajrzałem niedawno ponownie pod ten adres. Okazuje się, że Processing posiada w pełni funkcjonalny interfejs dla Androida – tworzone są projekty przygotowane do „buildowana” pod Eclipse’m. W dodatku aplikacje graficzne tworzone w tym języku – właściwie nie jest to nowy język lecz Java opakowana super wygodnymi bibliotekami – są uniwersalne tzn. działają pod Windows, Mac OS-em, Linux-em (jako aplikacje Javy) oraz Androidem (też jako standardowe apk-i zbudowane przez Eclipse). Można też wyeksportować projekt jako aplikację javascript-ową – HTML5. Jak na razie sprawdziłem Androida i Windows (full screen i okienko). Działa.

Na Processing-u zakończyłem obecną fazę poszukiwań i rozpocząłem fazę produkcyjną. Najpierw przygotowałem pięć aplikacyjek realizujących tę samą funkcję – przesuwanie bitmapy palcem po ekranie. Mam tablet (właściwie „tablecik”) siedmiocalowy, kupiony w hipermarkecie za circa 270 PLN (i to już jakiś czas temu). Jego wydajność jest… Nie do końca zadowalająca – chyba jedną z najniższych wśród mobilnych urządzeń na rynku. I dlatego doskonale nadaje się do wszelakich testów – różnicuje wyśmienicie efektywność aplikacji. Ponadto mam Samsunga Galaxy Mini (S5570), który też do demonów szybkości nie należy (procesor 600 MHz, nie za dużo pamięci, ekranik o nietypowych wymiarach). Warsztat sprzętowy w sam raz do oceny „silników„.

Pod względem wydajności (przynajmniej graficznej 2D) „silniki” można podzielić na dwie rodziny:

  • wydajną (oparte na Lua, czyli Gideros i Corona, a także oparty na Javie – Processing);
  • niewydajną (HTML5 i AppInventor).

Różnice są wprost wyczuwalne „pod palcami” – raz obrazki przesuwają się płynnie, raz nie. Raz ruch bitmapy lepiej nadąża za ruchem palca, raz gorzej.

Porównajmy jeszcze wielkości zbudowanych plików apk (w przypadku HTML5 – strony internetowej). Największe apk-i tworzone są przez Coronę. Prosta aplikacja to ponad 4 MB. Coronie dorównuje Gideros – ta sama funkcjonalność i… prawie 3 MB. AppInventor zamyka się w 1,3 MB, a najoszczędniejszy plik apk powstaje dla „silnika” Processing – zaledwie 300 kB. Dla porównania – strona www (HTML5) to niecałe 30 kB, z czego przytłaczającą większość zajmuje grafika. Ale trzeba pamiętać, że taka sama strona „opakowana” w projekt Eclipse’a to już kilkaset kilobajtów.

Inne są też ścieżki prowadzące do instalacyjnych plików apk. Corona i AppInventor pracują w trybie kompilacji w „chmurze„. Użytkownik otrzymuje zbudowaną na zdalnym serwerze aplikację, po tym jak kod programu został wysłany „w świat„. Gideros i Processing przygotowują projekt do zbudowania w Eclipsie. Obydwa modele mają swoje wady i zalety. Kompilacja/budowanie w „chmurze” uwalnia programistę od utrzymywania środowiska – dbania o aktualizacje, konfigurowania, ściągania wielosetmegowych paczek etc. Własna kompilacja pozwala (przynajmniej w teorii) na modyfikowanie wszystkiego w aplikacji np. można w prosty sposób wymieniać ikonki, grafiki, zasoby, modyfikować plik manifestu. A ponadto – nie wysyła się kodu „w świat„.

Poniżej zamieszczam odnośniki do testowych „aplikacyjek” – należy pamiętać aby uaktywnić opcję instalowania z nieznanych źródeł.

  1. Aplikacja napisana w Gideros Mobile.
  2. Aplikacja napisana w Corona Labs.
  3. Aplikacja napisana w Processing.
  4. Aplikacja napisana w AppInventor.
  5. Aplikacja (stroniczka) w HTML5.

Aha! Na koniec warto wspomnieć, że darmowa wersja Gideros-a wyświetla przy starcie aplikacji ekran „Made with Gideros”. Aplikacja przygotowana w środowisku Corona ma problemy z uruchomieniem na smartfonie z Androidem 2.3. Na tablecie i smartfonie z Androidem 4 działa bez problemów.

2 odpowiedzi na “Czym pisać i w jakim języku?”

Co do artykułu „Czym pisać i w jakim języku?” proponuję spojrzeć na komercyjną wersję WINDEV Mobile firmy PCSOFT.
http://www.windev.com/windevmobile/index.html
Wieloplatformowe narzędzie do urządzeń mobilnych z ich własnym językiem WLanguage.
Jest wersja testowa v17 można sprawdzić że działa fajnie. Dodatkowo w Google Play są przykładowe apki od producenta i można sprawdzić naocznie.

Pozdrowienia

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *