niedziela, 17 czerwca 2007

RIA w Java ME

Obserwuję rozwój aplikacji internetowych i zastanawiam się nad tym, czy kiedykolwiek nadejdzie moment, kiedy ludzie zaczną masowo korzystać z internetu przez komórkę. Obecnie sytuacja przypomina mi jak płacono za łączenie z internetem przez modem analogowy. Z drugiej strony zastanawiam się czemu rozwój oprogramowania na komórki kojarzy sie z grami czy zawartością taką jak muzyczki czy tapety. Możliwości komórek są coraz większe. Ze strony programistycznej niewiele sie zmieniło. Zazwyczaj robi się to w Java ME albo w Flash Lite. Uważam że w najbliższym czasie rozwój oprogramowania bardzo się zmieni na korzyść Java ME, bo ma dużo więcej możliwości do tworzenia midletów, które mogą wykorzystywać AJAX na równi z aplikacjami webowymi. Z drugiej strony Flash Lite też staje się interesującym rozwiązaniem dla aplikacji internetowych czego przykładem są projekty Shuriken zestaw komponentów UI dla FlashLite 2.0 oraz Flyer biblioteka w Pythonie pozwalająca na wykorzystanie przez Flash Lite Playera możliwości jakie są w Symbianie (np: komunikacje za pomocą Bluetootha).

Same urządzenia mobilne można podzielić na dwie grupy. Pierwsza, do której należy większość telefonów komórkowych, to urządzenia o mocniej ograniczonych zasobach pamięci i mocy procesora (przygotowano dla nich konfigurację CLDC - Connected Limited Device Configuration). Druga grupa to urządzenia lepiej wyposażone, posiadające więcej pamięci operacyjnej i szybsze jednostki obliczeniowe. Należą do niej na przykład palmtopy, handfieldy. Dla nich podstawą jest konfiguracja CDC - Connected Device Configuration. Na bazie tych dwóch konfiguracji przy pomocy zestawów dodatkowych specyfikacji można budować kompletne rozwiązania.

Wraz z pojawieniem się nowej wersji Sun Java Wireless Toolkit 2.5 for CLDC wprowadzona została specyfikacja JSR 248: Mobile Service Architecture definiująca podział środowisk mobilnych, a także określająca rekomendowane zestawy komponentów platformy Java ME. Jest ona rozszerzeniem wcześniej obowiązującej specyfikacji Java Technology for the Wireless Industry (JTWI).

Dodatkowo pojawiły się też nowe rozszerzenia platformy. Wśród ciekawszych wymienić można:

JSR 234: Advanced Multimedia Supplements, umożliwia między innymi kontrolowanie z poziomu aplikacji J2ME dodatkowych gadżetów coraz częściej obecnych w nowoczesnych telefonach komórkowych, takich jak aparaty fotograficzne, czy radioodbiorniki FM, a także pozwoli na zaawansowaną obsługę dźwięku.

JSR 179: Location API for J2ME, umożliwia pisanie aplikacji na urządzenia przenośne wyposażone w odbiorniki GPS, które dostarczą informacji o fizycznym położeniu geograficznym urządzenia.

JSR 229: Payment API umożliwia użytkownikom telefonów komórkowych dokonywanie płatności.

JSR 226: Scalable 2D Vector Graphics API for J2ME zapewnia obsługę obrazów wektorowych w formacie SVG.

Obecnie programiści Java ME mogą wybierać środowiska RAD: jakim są NetBeans Mobility Pack i jak rozwiązania bazujące na Eclipse (EclipseME czy Carbide.j). Wiele ciekawych rzeczy zostało powiedzianych na konferencji Java One 2007. Sun opublikował w ramach uwalniania kodu Javy na licencji GPLv2 rozwiązania Java ME pod nazwą phoneME Dla rozwiązań opartych na CLDC przyjęło nazwę phoneME Feature, a dla CDC przyjęło nazwę phoneME Advanced. Jest też ciekawy przykład tego jak wykorzystać phoneME w NetBeans Mobility Pack.

Rebranding nazwy z Java ME na phoneME chyba się nie przyjmie. Zawsze to będzie Java ME. Sun wprowadza już nowe projekty takie jak phoneME UI (User Interface) Labs który kładzie nacisk na zastosowanie SVG - JSR 226. Jest też zbiór kodów źródłowych do obsługi AJAX w Java ME pod nazwą Mobile Ajax for Java ME. Można także ściągnąć kody źródłowe pokazujące wykorzystanie wielu nowych możliwości jakie są w nowszych pakietach JSR w projekcie Developer Demo Box. Warto też zwrócić uwagę na projekty związane z Rich Internet Application - Project Orbit i JavaFX Mobile.

W przyszłości najbardziej można oczekiwać wprowadzenia w urządzeniach mobilnych w latach 2008-2011 następujących specyfikacji.

JSR 256 - Mobile Sensor API - wprowadza sposób komunikacji aplikacji J2ME z różnego rodzaju czujnikami/sensorami takimi jak: mikrofon, kamera, czujnik rytmu serca czy termometr.

JSR 257
- Contactless Communications API
ma być standardem bezstykowej komunikacji na niewielkie odległości (wykorzystywana np. przy odczycie kodów kreskowych, czy chipach RFID).

JSR 271: Mobile Information Device Profile 3 ten standard wprowadza sporo nowych rozwiązań takich jak: równoczesne uruchamianie wielu midletów, komunikację pomiędzy midletami. pozwala na tworzenie współdzielonych bibliotek wykorzystywanych przez wiele midletów, wprowadza obsługę standardu IPv6, wprowadza możliwość tworzenia bogatszego interfejsu graficznego.

JSR 280 - XML API for Java ME ma być standardem do obsługi programistycznej dokumentów XML bazując na DOM i SAX2

JSR 287
: Scalable 2D Vector Graphics API 2.0 for Java ME - następna wersja API do obsłygi standardu SVG Mobile 1.2 (z wykorzystaniem animacji i mediów dostarczanych w sposób strumieniowy)

JSR 290 - Java Language & XML User Interface Markup Integration - pozwala to na integrację w aplikacjach mobilnych kodu SVG czy XHTML w midletach,

JSR 293: Location API 2.0 - dalszy rozwój standardu odpowiedzialnego za obsługę lokalizacji użytkownika, nowością ma być wsparcie dla nawigacji GPS, geolokalizacji na mapach,


JSR 297: Mobile 3D Graphics API 2.0 - następna wersja standardu do programowania grafiki trójwymiarowej, wykorzystująca możliwości jakie daje implementacja sprzętowego wsparcia OpenGL ES 2.0

JSR 300: DRM API for Java ME - jest to propozycja programistycznego standardu dla wsparcia OMA DRM2.0

Z perspektywy czasu tempo rozwoju technologii wydaje sie bardzo szybkie - chociaż informacje o tym są znane tylko wąskiej grupie specjalistów pracujących nad implementacją tego w swoich produktach. Z drugiej strony czas przyswajania nowych technologii jest bardzo wolny, wiele czynników na to się składa. Najbardziej istotny to brak dobrej literatury wprowadzającej w możliwości Java ME. Po drugie też różnorodność urządzeń mobilnych wspierających tą platformę sprawia (pomimo bibliotek wspomagających takich jak J2ME Polish) , że trudno ogarnąć jak dana aplikacja może zachowywać się konkretnym modelu urządzenia. Kolejną cechą sprawiającą trudności w połapaniu są bardzo szybkie zmiany w rozwoju systemów (platform) operacyjnych na urządzenia mobilne. Aż 7 wersji Symbiana wypuszczono w ostatnich latach Symbian OS 6.0 (2001), Symbian OS 7.0 (2003), Symbian OS 8.0 (2004), Symbian OS 9.1 (2005), Symbian OS9.2 i Symbian OS 9.3 (2006), Symbian OS 9.5 (2007).

Nokia ma 4 platformy operacyjne (Series 40, Series 60, Series 80, Series 90)
SonyEricsson rozwija graficzne UI dla urządzeń mobilnych UIQ (są dostępne wersje 2.0 2.1 i 3.1) SonyEricsson wprowadziło też podział na 7 platform Javy

Czy w Polsce jest więcej programistów Java ME niż tych od Flash Lite?

2 komentarze:

rattkin pisze...

Moim zadaniem zupełnie nie tędy droga. Poniekąd Steve Jobs miał racje - Java nie sprawdziła się. Dni javy minęło. Java to teraz ciężki runtime, w którym zrobienie prostych rzeczy wymaga niesamowitych nakładów. Nieważne ile standardów JSR czy JavaME powstanie. Sun jest dobry w nadymaniu takich bezsensów.

Nie widzę też przyszłości dla FlashLite. W bardzo krótkim czasie komórki staną się minikomputerami o poważnych możliwościach - a na pewno takich, które pociągną zwykłą przeglądarkę z Flashem 9. W ten sposób RIA będzie RIA - wszędzie i tak samo. To by było naprawdę dobre rozwiązanie.

Osobiście pokładam olbrzymie nadzieje w iPhonie, choć Flash w Safari wciąż stoi pod znakiem zapytania, a być może nawet go tam nie ma - tylko ten jeden minus całkowicie zniechęci mnie do kupienia telefonu na który bardzo czekam.

Eloar pisze...

Java to dobre rozwiązanie cały czas. Nie można się spodziewać, aby nagle wszystkie telefony przyjęły jedną architekturę, albo jeden stał się niezwykle popularny na całym świecie, aby opłacało się pisać aplikacje niskopoziomowo na komórki. Tak długo, póki java oferuje przenośność dla dowolnej platformy, nikt z niej nie zrezygnuje.