Dlaczego nie lubię Androida ?

Pobierz artykuł jako plik PDF

Aktualnie po godzinach zajmuje się kilkoma rzeczami. Wszystkie one jednak wyraźnie skupiają się wokół technologii mobilnych i embeded. Ponieważ nie przepadam za Androidem, który bardzo topornie działa na niektórych sprzętach (nic dziwnego, że do komórek ładuje się procesory ponad 1GHz i to dwujądrowe – dlaczego ? żeby w głównym wątku aplikacji umieścić obsługę GUI wraz z efektami specjalnymi). Niezbyt podoba mi się też jego architektura, znacząco ograniczająca możliwości wykorzystania platformy (szczególnie że to jest linux). Dużo lepiej czuję się kiedy mam WinCE/WM5/WM6/WM6.1/WM6.5/Embeded Linux. Powyżej wersji Wm 6.5 Microsoft niestety zmienił strategię i w Windows Phone nie można programować natywnie – pozostaje tylko platforma .NET. Niestety nie ma już Windows Forms na tej platformie i pozostał nieszczęsny Silverlight (czytaj namiastka tego co Flash i Flash Light dały już światu przed „wiekami”). A tak nota bene Adobe wycofał się już z Flash’a na urządzenia przenośne (wersja light, w szczególności na Androida) i ponoć jest już pewne, że ten sam krok poczyni z maszynami stacjonarnymi.

Dodatkową ważną informacją zwrotną z rynku produkującego urządzenia mobilne klasy High-End jest to, że u nich nie słychać nawet o próbach wyjścia z platform WM, a co tu mówić dopiero o Android’zie. Nawet nie chętnie w kierunku Windows Phone 7, czego przyczyn można upatrywać w tym, że ten system operacyjny jest przeznaczony stanowczo na rynek powszechny, czyli gry, multimedia i community interraction. Prawdopodobnie był to krok Microsoftu poczyniony w celu zrobienia konkurencji Androidowi. Widać tutaj sporo podobieństw w polityce w zakresie rozwoju oprogramowania – tylko C#/Java, opcjonalnie C++.NET/C++ via NDK, tylko jeden spójny podsystem UI (Silverlight/AndroidUI).

A co tak naprawdę lubię ?

Krótko mówiąc to co jest najbardziej powerfull, czyli WinCE i Windows Mobile.

Dlaczego ?

To, że są to systemy czasu rzeczywistego, mocno dopracowane i przede wszystkim sprawdzone w wielu profesjonalnych rozwiązaniach. Dla programisty jest to nie mal raj, bo naprawdę można zrobić bardzo wiele, chodź wymaga to sporej wiedzy, bo nie wszystko jest opisane często wymaga pewnych eksperymentów (aczkolwiek MSDN to gigantyczna, ciągle poszerzana skarbnica wiedzy)

Ale, żeby nie było, nie jest aż tak różowo jak można byłoby sobie życzyć, chociażby dlatego, że na urządzenia mobilne po prostu programuje się koncepcyjnie troszkę inaczej (jest to system typu RTOS, no i posiada bardzo ograniczone zasoby,  no i zakładam że chcemy to robić profesjonalnie, a nasz soft ma być stabilny, bezpieczny i we właściwy sposób wykorzystywać zasoby – czyli to co nam w pewien ogólny sposób określają inżynieria oprogramowania wraz z etyką zawodową). Jeszcze inną kwestią jest API – w wielu miejscach jest inne niż API dla XP czy Win7. Wielu rzeczy po prostu w ogóle nie ma.

Czy są alternatywy ?

Oczywiście ! Jeśli nie lubisz WinCE/WM, a chcesz mieć potężne możliwości i pisać w prawie dowolnym języku na Linux, to możesz kupić sobie płytę ewaluacyjną, z EmdededLinux’em ze stertą wyjść IO, ETH, USB, wyświetlaczem (wszystko sam sobie możesz dobrać, sam podpinać inne urządzenia, wkompilować moduł jego obsługi do jądra ELinux’).

Są też rozwiązania troszkę mniej hardcore’owe, ale też potężne. Mówię tutaj o sterownikach do automatyki budynkowej/przemysłowej oparte o EmbededLinux’a, które są już gotowymi rozwiązaniami i nie mają tak dużych możliwości konfiguracji sprzętowych. Spora część tych rozwiązań, jest co najmniej zgodna z wymaganiami dla WinCE, a na niektóre można także skompilować i wgrać kernel Androida.

Podsumowanie

Pisanie na kilka platform jednocześnie jest sporą trudnością. Ale to jest już temat rzeka na inny artykuł, ja ze swojej strony mogę powiedzieć, że dla mnie najważniejsze wnioski z ostatnich lat pracy sa następujące:

• w tej dziedzinie trzeba nieustannie zgłębiać wiedzę (i teoretyczną i empiryczną)
• trzeba koniecznie mieć konkretny model urządzenia w ręce – co prawda można pisać ogólnie na wszystko i to będzie działało na danej platformie, ale tak czy siak kiedyś trzeba będzie zrobić ten test zanim oddamy to w ręce klienta, w szczególności gdy tworzymy system z zabezpieczeniami, używamy jawnie rejestru systemowego, korzystamy z dedykowanych API, robimy zautomatyzowany podsystem do deploy’a, etc
• dobrze zrobiony  przyszłościowy projekt to kawał naprawdę ciężkiej pracy zaczynającej się już od planowania i analiz (szczególnie gdy ma objąć swoim zasięgiem różnych platform builder’ów, różne platformy)
• zapewniam Cię, że nie prędko zaczniesz się nudzić, bo tutaj wyzwania stoją niemal „za każdymi drzwiami” (zarówno architektoniczne, jak i implementacyjne)

pozdrawiam