wtorek, 20 kwietnia 2010

Perspektywa biznesowa programisty komórek.

Zauważyłem że często trafiają się pytania o to jak prowadzić biznes z programowania na urządzenia mobilne. Problem jest taki, że w dzisiejszych czasach przy tak szybkim tempie zmian technologicznym w urządzeniach mobilnych trzeba nastawić się na szybką edukację i dopasowywanie do rynku. Warto spojrzeć na perspektywę rozwoju poszczególnych platform mobilnych.

Komórki z Symbianem S60 3rd Feature Pack 2 będą dalej produkowane. Natomiast rozwijane będą wersje Symbiana z interfejsem dotykowym. Problem jest innej natury. Sama architektura Symbiana wymaga znajomości programowania cech charakterystycznych dla tego systemu operacyjnego. Pomimo, że programowanie programowanie na Symbiana jest odbierane jako coś trudnego to jednak Symbian posiada sporo technologii typu runtime: Java Mobile, Flash Lite, Python, czy Web Runtime. Symbian ^3 dalej będzie opierał się na frameworku UI AVKON a Symbian ^4 będzie opierał się na frameworku UIEMO bazujący na Qt, więc programowanie pod Symbiana czeka duży wybór technologii do programowania i jak frameworków. Zawsze będzie wybór przed programistami co do języka programowania do tworzenia aplikacji na Symbiana. Gdy wprowadzą na rynek urządzenia z Symbianem ^4 w 2012 to ludzie będą programowa w Qt 4.8. Więc pewnie do tego czasu w ciągu półtora roku można nauczyć się spokojnie Qt, Wtedy kod napisany w Qt będzie przenośny dla wielu aplikacji działających na wielu starych komórkach. Problem będzie jak zechcemy programować aplikacje SIP czy VoIP tutaj trzeba znać niskopoziomowe biblioteki i ich API pod konkretnymi modelami. Niektórych rzeczy raczej do końca nie przewidzi się jak będą są rozwijać. Mam na na myśli interfejsy OpenGL ES czy OpenCL ES. Dużo zależy też tego co chcemy programować. Programowanie gierek 3D będzie wymagało programowania w Symbian C++ czy OpenC++ ze względu na szybkość i wydajność. Proste aplikacje w szybkim czasie da się napisać w Pythonie czy w mshellu, Gdy trzeba uwzględnić to że aplikacja ma też chodzić na zwykłych komórkach to warto wybierać programowanie w Java Mobile (MIDP2.0). Inaczej patrzy się jak trzeba napisać kod crossplatformowy uwzględniający Symbiana - wybiera się wtedy frameworki typu Airplay, MoSync, Corona, PhoneGap czy OpenPlug Elips Studio 3 . Perspektywa pojawienia Symbiana^4 spowoduje to ze programiści mogą ograniczyć się do programowania na Qt Pomimo tego inwestowanie w poznanie Qt i Open C++ nie zwalniają programistów od znajomości architektury Symbiana i frameworku AVKON. Za rok czy dwa lata komórek z Symbianem S60 będzie na rynku tak dużo, że trzeba będzie dbać o tych którzy mają modele z Symbianem S60 3rd FP2. W takiej sytuacji programowanie pod Symbianem jeszcze ma przed sobą długie lata. Przypuszczam że jak Nokia będzie jeszcze na rynek dostarczać te komórki to jednak jest ryzyko że Nokia za 2 lata przestanie dostarczać na rynek nowe modele z S60 3rd FP2 i nastąpi masowa ucieczka programistów z programowania S60 na rzecz Symbiana^4. Bardzo może to przypominać czasy gdy wprowadzano S60 3rd w 2005 roku, a dopiero w latach 2007-2008 programiści przestali wspierać starsze wersje Symbiana. Dzisiaj dzieje się tak szybko, że programiści od razu przestają wpierać starsze modele. Tak było z Symbianem UIQ 3 (inwestowanego przez Motorolę i Sony Ericsson) skutkiem czego od 2009 roku już prawie nikt nie pisze oprogramowania pod te modele z tym Symbianem. Podobna reakcja jest w przypadku zaprzestania rozwoju platformy N-Gage w 2009 roku. A zostało wielu użytkowników tych modeli komórek którzy zostali pozbawieni wsparcia technologicznego. Pierwszych modeli z Symbianem^4 spodziewam się na 2 półrocze 2011. Myślę że po 2 latach dopiero wejdzie w etap "dojrzałości" w świadomości programistów i użytkowników jako Symbian^5 czyli na 2014 rok można by się spodziewać stabilnego rozwoju rynku programistycznego dla urządzeń z Symbianem ^4 i Symbianem^5 oraz koniec rozwoju oprogramowania dla Symbiana S60 3rd FP2. Natomiast dla komórek z Symbianem^3 raczej spodziewam się cyklu 4 letniego, co oznacza że programowanie we frameworku AVKON utrzyma się do 2015 roku, Jak widać dla frameworka AVKON pozostaje jeszcze kilka ładnych lat programowania.

Architektura Symbiana pozostanie ta sama (jądro,mechanizmy zarządzania pamięcią, system uprawnień) zmienią się kompilatory i jak nowsze modele procesorów ARM. Nie wiem czy będzie portowane na procesory Atom, ale to już zależy od programistów firmy Accenture. Na razie rozwijają oni Qemu. Ze względu na budowę systemu np: pisania sterowników to trzeba znać Symbiana C++. Mamy dostęp do kodu źródłowego Symbiana^3 i możemy poczytać sobie miliony linii kodu to jednak wymagana jest znajomość Symbian C++. W wielu przypadkach API Symbiana zostało jakby nie ruszane przez Qt (np: obsługa Bluetootha, IrDA, SIP, VoIP, syntezatory mowy, zaawansowane API do układów optycznych). Ponieważ Symbian ma budową modularną to ma abstrakcyjne klasy interfejsu użytkownika EIKON na którym mogą w Symbian^4 stworzyć nowy interfejs użytkownika. Pisząc kod w Open C++ czasami trzeba będzie zmagać się z kodem z Symbianem C++ (np w przypadku gier czy UI). Czasami może zdarzyć się trzeba będzie napisać jakiś kod silnika skryptowego i okaże sie że trzeba pisać rozszerzenia wykorzystujące mechanizmu plug-inów ECOM.

Na dzień dzisiejszy inwestowanie w programowanie w Symbiana jest kosztowne. Kosztuje nie tylko zainwestowanie w proces certyfikacji zakup certyfikatu na jeden rok czasu kosztuje 200$ a podpisanie jednej aplikacji 20$ oraz opcjonalne testy co mogą kosztować 200$. Jeszcze do tego dochodzi koszt dystrybucji przez Ovi Store (50 Euro/80$ opłaty rejestracyjnej). Warto też pomyśleć o zakupie komórek takiej jak N97 za 500$ czy E52 za $330.

Nie jest łatwo też programować pod Java Mobile ze względu na bardzo dużą fragmentaryzację technologii w szczególności, gdy mamy wiele różnych rozmiarów urządzeń i technologii wspieranych przez Javę Mobile. Szczególniej jak trzeba uwzględniać urządzenia z CLDC 1.0 czy a CLDC 1.1 a a interfejsem UI z MIDP 1.0 czy MIDP 2.o czy MIDP 2.1 bądź z eSWT. W pewnych sytuacjach trzeba też zainwestować w certyfikaty dla swoich aplikacji w Javie Koszt kupienia certyfikatu na jeden rok dla aplikacji Java Mobile to 240$ a koszt podpisania jednej aplikacji wynosi 20$. Pisząc aplikacje na zwykłe komórki i jak trzeba wziąć pod uwagę, że trzeba przygotować różne wersje aplikacji i każdą z nich podpisać.

Najtańszy koszt dystrybucji wychodzi w przypadku widgetów WRT, które też mogą zawierać pliki SWF z FlashLite. Tych plików wgz nie trzeba podpisywać.
Natomiast przygotowywanie plików SWF wymaga zainwestowania w zakup Flash Proffesional CS5 za 700$ i w zależności od modelu dystrybucji plików SWF trzeba przyjąć odpowiednie koszta. Można zawartość multimedialną FlashLite dystrybować jako pliki NPL, WGZ, jako część paczek JAR, SIS, czy CAB.

Natomiast poza Symbianem trzeba wziąć pod uwagę inne platformy. W przypadku Apple to trzeba będzie zainwestować w zakup Maca (MacBooka za $1000) i jak iPhone (iPhone3GS za $500) Do tego jeszcze dochodzi przystąpienie do programu dla programistów za $100 na rok, natomiast gdyby chcieć przeprowadzać dystrybucję na własną rękę trzeba zainwestować 300$ rocznie w program dla firm. Trzeba nauczyć się programowania w Objective-C.

Natomiast w przypadku Androida to wystarczy ściągnąć odpowiednie SDK i znajomość Javy Mobile pomoże przy programowaniu. na Androida. Natomiast przy dystrybucji trzeba wpłacić 25$ przy rejestracji do Market Android. Warto pomyśleć o zakupie urządzenia z Androidem, które mogłoby służyć przez 2 lata. Wybór padł na HTC Desire za 800$. Łatwość tworzenia aplikacji do Androida i niski koszt dystrybucji powoduje, że coraz więcej pojawia się aplikacji "śmieci" i jest presja na dostarczanie darmowych aplikacji do Market Android.

Właściwym rywalem o programistów Javy od zwykłych komórek, Symbiana i Androida jest platforma Blackberry kanadyjskiej firmy RIM. Ta platforma cieszy się opinią jednej z najbezpieczniejszych systemów dla inteligentnych komórek. Dostęp do SDK jest zazwyczaj darmowy i można sobie szybko nauczyć programować zarówno z poziomu aplikacji pisanych w Javie czy widgetów wykorzystujących HTML5 z WebKit. Natomiast gdyby chcieć zająć się programowaniem aplikacji dla BlackBerry to znowu warto zainwestować w najnowsze modele ze względu że czas dojrzewania na rynku modeli jest bardzo krótki ze względu że ludzie często wymieniają modele. Programiście dany model mu wystarczy na cały cykl rozwojowy produktu i danej platformy. W tym przypadku warto zainwestować w BlackBerry Storm 2, który kosztuje 500$. Aby instalować własne oprogramowanie do modeli BlackBerry to trzeba wykupić certyfikat do podpisywania plików JAR czy COD co kosztuje 20$. Natomiast dystrybucję oprogramowania na BlackBerry można prowadzić zwykle przez internet, przez strony internetowe bądź przez BleckBerry App World gdzie opłata administracyjna wynosi 200$ na umieszczonych tam 10 aplikacji. Na tej platformie warto programować różnego rodzaju widgety internetowe.

Microsoft wprowadzając nowy system operacyjny dla inteligetnych komórek Windows Phone 7 zerwał z wsteczną kompatybilnością co powoduje że programiści mają tylko jedno wyjście przeprogramować aplikacje do platformy Compact Framework.NET. Największy problem z platformą Windows CE na którym opierają się różne wersje urządzeń mobilnych jest jego zbyt duża różnorodność co programiści muszą solidnie programować aplikację prawie na każdy model inteligentnej komórki czy PDA Prawdopodobnie dzisiaj trzeba solidnie zastanowić się nad pisaniem oprogramowania na tą platformę ze wzgledów braku jasnych perspektyw co do dynamiki rozwoju tej plaformy. W teorii koszta na programowanie w Windows Mobile nia są tanie. Przede wszystkim trzeba zainwestować w Visual Studio 2010 Proffesional with MSDN Essential za $550 (a SDK do wersji Windows Mobile są za darmo). Następnie trzeba kupić inteligetną komórkę z Windowsem Mobile 6.5 na przykład HTC HD2 za 700$,. Potem jeszcze zainwestować w certyfikację czyli kupić certyfikat do podpisywania za 350$ na natomiast za identyfikator do podpisania jednej aplikacji kosztuje od 12$. Publikacja aplikacji w Windows Marketplace for Mobile kosztuje rocznie 99$ i można opublikować 5 aplikacji. W praktyce może być taniej jak założy się firmę i przystąpi się do programu BizSpark.

Warto też śledzić rozwój niszowych platform dla urządzeń mobilnych. Szczególną uwagę trzeba zwrócić na platformę Nokii Maemo (MeeGo ) i jak Palma WebOS. Pisanie oprogramowania pod te plaformy ma sens jak wykorzystujemy aplikacje pisane w C++ dla Linuxa i zależy nam na wykorzystania tych urządzeń mobilnych jako kontynuacja wykorzystania komputera. Wskazana jest znajomość programowania na Linuxa w C++ w celu pisania oprogramowania na te platformy. W programowaniu na te platformy bardzo przyda sie wykorzystanie biblioteki Qt. W przypadku pisania biznesowego oprogramowania warto zainwestować w zakup komercyjnej wersji biblioteki Qt (3000 Euro / 4000 $). Pisząc oprogramowanie w Qt w wersji komercyjnej właściwie ma sens jak chce napisać kod na urządzenia mobilne z Symbianem, Windows Mobile, z Maemo i z webOS (a także na niszowe urządzenie typu Kindle2 Amazona). Urządzenie z Maemo czyli N900 kosztuje 650$ a urządzenie z webOS czyli Palm Pre kosztuje 550$. Dystrybucja oprogramowania jest trochę zdecentralizowana. Trudno sprzedawać komercyjne wersje dla Maemo w Ovi Store a dla webOS w Palm App Catalog, co jest wynikiem przekonania że oprogramowanie tworzone na bazie Linuksa powinno być za darmo. Gdy chce się programować komercyjnie pod webOS należy zarejestrować się w webOS Developer Program z opłatą roczną za 99$ w tym za opublikowanie 20 aplikacji w Palm App Catalog. Charakterystyczną cechą webOS jest to, że prawie całe API jest dostępne z poziomu JavaScriptu dzięki bibliotece Mojo.

Podsumowując zestawienie kosztów wchodzenia w programowanie inteligentnych komórek i tempa rozwoju technologii mobilnych oznacza to dla przedsiębiorcy:

  • Inwestowanie w nowe modele komórek aby szybko dostarczyć oprogramowanie zanim dany model nie wejdzie w cykl dojrzałości co trwa rok czasu od momentu jego wprowadzenia na rynek oraz 2-3 letni cykl życia danego modelu. Potem ludzie inwestują w nowsze modele komórek przy wsparciu operatorów.
  • Trzeba znać bardzo dobrze technologie informatyczne używane w nowych modelach komórek i szybko uczyć się nowego API dla danego modelu. Trzeba też znać ograniczenia środowisk programistycznych oraz emulatorów.
  • Ciągle dokształcać się w programowaniu w C++, Java Mobile oraz w widgetach opartych na JavaScripcie
  • Pilnie śledzić rozwój bibliotek i frameworków cross -platformowych. Można się spodziewać trendu w którym programiści będą rozszerzać dostęp do API komórki z poziomu JavaScriptu i stąd coraz bardziej dynamiczny rozwój w tworzeniu widgetów. Także śledzić zmiany w usability interfejsu użytkownika poszczególnych platform.
  • Opracowywać różne modele dystrybucji oprogramowania w szczególności oparte na weryfikacji unikalnego identyfikatora urządzenia i jak na modelu subskrypcji. Bardzo przyda się tworzenie własnego systemu analitycznego do raportowania tego jak uzytkownicy korzystają z danego oprogramowania.
  • Koszt wejścia w tą branże jest nadal wysoki szczególnie pod kątem inwestycji kapitałowych i jak kosztów w ciągła edukację co powoduje że wytworzenie oprogramowania na urządzenia mobilne (szczególności VoIP SIP czy wykorzystanie rozpoznawania obrazu, bądź pisanie oprogramowania do nawigacji) jest bardzo trudne, bo jest niewielu ludzi którzy do tego doszli.
  • Trudno o rekrutację pracowników, bo mało ludzi na tym zna się. Trzeba tworzyć zespół ludzi, którzy tym zajmowali się od podstaw. Najtrudniejsze to będzie utrzymać taki zespół gdy osiągnie stopień profesjonalizmu wtedy korporacje mogą skutecznie podkupić zdolnych członków zespołu.

czwartek, 8 kwietnia 2010

Wybory do Rad Fundacji Symbian 2010

W skład Rad Fundacji Symbian to osoby które mają wpływ polityczny na to jak będzie rozwijał się Symbian. Procedura i wyłanianie tych rad to dość trudna lektura dokumentu Symbian Foundation Council Charters. Zasady wyborów opisano w tym dokumancie

W Fundacji Symbian są 4 rady:
Rada "Feature and Roadmap Council" - jej zadaniem przyjmowanie propozycji od innych donośnie rozwoju Symbiana i koordynowanie zadań odnośnie platformy Symbian i ustalanie mapy rozwojowej dla Symbiana w najbliższych latach. Członkowie rady spotykają sie na telekonferencjach albo na całodniowych konferencjach. O aktywności rady można poczytać na wiki
Rada "Architecture Council" - jej zadaniem jest ustalanie technicznych aspektów rozwoju Symbiana, podejmują decyzje o architekturze Symbiana i poddają ewalucji nowe rozwiązania dla Symbiana a także decyzje co do rozwijaniu narzędzi dla programistów. O aktywności rady można poczytać na wiki
Rada "User Interface Council" - jej zdaniem podejmowanie decyzji co do wyglądu interfejsu użytkownika i jak tworzenie wskazówek odnośnie doświadczeń użytkownika z korzystania z platformy Symbian. Poczynania rady można sledzić na tej stronie wiki
Rada "The Release Council" - koordynuje działania w zakresie tworzenia wersji Symbiana i ich pakietów oraz narzędzi. Efekty działań tej rady można śledzić na tej stronie wiki

Skład rady Feature and Roadmap Council to
Szefem jest: Ian Hutton, Symbian Foundation
AT&T - Greg Wong i Herman Chien
Fujitsu - Taisuke Inoue
Nokia - Jonas Hasselberg i Pia Vuorela
NTT DoCoMo - Masa Sumita i Motoya Miyauchi
Orange - Frederic Dufal i Mark Sage
QuIC - Mike Stefanick i Jim Callanan
Samsung - David Stacey i Stephen Storer
Sony Ericsson Mobile Communications - Eva Jönsson i Hironobu Arima
ST Ericsson - Enrica Filippi i Joel Bielle
Telefonica - Alfonso Fernandez i Daniel Coloma
Texas Instruments - Frederic Blesser i Sonia Ferrante
Vodafone - JC Theard i Stephen Packer

W wyborach 2010 startowali (4 pierwsze osoby przeszły)
Alfonso Fernández i Daniel Coloma (Telefónica)
Mark Sage i Rafel Uddin (Orange / France Telecom)
Kai Juusola i Leena Väänänen (Elektrobit)
Wolfgang Bau i Petr Smrž (Deutsche Telekom Ag)
Jani Turpeinen i Sandeep Chandak (Sasken Communication Technologies Ltd)
Zaiguo Zhu i Hongqi Dong (ShenZhen Temobi Science & Tech Development Co., Ltd.)
Rene Heuven i BTR Naidu (Inmote BV)
Mauro Monti i Emiliano Ceraldi (Telecom Italia S.p.A.)

Skład rady Architecture Council to:
Szef: Daniel Rubio, Symbian Foundation
ARM - Hobson Bullman i Richard Phelan
AT&T - Arne Schrider
Broadcom - James Chapman i Daniel Daum
Fujitsu - Taisuke Inoue i Mohamedsadiq Mandan
Nokia - Jukka Virnes i Andrew Harker
NTT DoCoMo - Yuuki Yamamoto i Kazuo Aoki
QuIC - PJ Bostley i Tony Newpower
Samsung - Kimmo Hoikka
Sony Ericsson Mobile Communications - Tobias Lindquist i Nakao Kenichi
ST Ericsson - Jouni Ylitalo i Hanta Albert
Texas Instruments - Frederic Blesser i Jonathan Bergsagel

W wyborach 2010 startowali (6 pierwszych osób przeszło)
Hobson Bullman i Richard Phelan (ARM)
Iain Campbell i John Roe (Accenture)
Yonghao Zhang i Haiyang Zhang (China Mobile Communications Corporation)
Jani Helin i Martti Piirainen (Tieto)
Nan Wang i Jin Shan Wang (Excellent Star Beijing)

W skład Rady Release Council wchodzą:
Szefem jest Mark Skrebels, Symbian Foundation
Digia - Petri Poikolainen i Harri Eronen
Elektrobit - Tero Savolainen i Kim Aitto-oja
Fujitsu - Yoshiiku Hanai i Chandra Narayanasamy
Nokia - Rauno Uusitalo i Riku Mettälä
NTT DoCoMo - Seishi Tsukada i Manabu Matsuura
QuIC - Rob Dunder i PJ Bostley
Sony Ericsson Mobile Communications - Anders Josefsson i QuakOnn Liew
ST Ericsson - Pierre-Henri Maitre i Philippe Gaudillat
Teleca - Ilkka Korhonen i Chandrashekar Challagonda
Texas Instruments - Moussa Belkhiter i Laurent Le Gal

W wyborach do rady 2010 startowali
(8 osób przeszło):
Peter Geen i David Hayward (Accenture)
Gero Schultz i Frank Burkhardt (Deutsche Telekom Ag)
Hanna Hulkko i Kim Aitto-Oja (Elektrobit)
Ilkka Korhonen i Jari Saarhelo (Teleca)
Shohei Yoshida i Tomonari Miyazaki (ISB Corporation)

W skład rady User Interface Council wchodzą:
Szef Scott Weiss, Symbian Foundation
Adobe - Chris Stott i Thomas Dahlblom
AT&T - Bryan Smoltz
Fujitsu - Kazuyuki Sato i Masashi Tanimura
Nokia - Elizabeth Dykstra-Erickson i Katja Smolander
NTT DoCoMo - Motoya Miyauchi i Yuurin Kogetsu
QuIC - Mike Stefanick i Tony Newpower
Sharp - Jinfeng Luo i Toshiyuki Matsubara
Sony Ericsson Mobile Communications - Klas Hermodsson i Katsunori Miura
T-Mobile - Martin Liboska i Stephan Keclik

W wyborach do rady 2010 było najwięcej chętnych i przeszło 10 pierwszych osób:
Liu Yan i Xiangang Qin (China Mobile Communications Corporation)
Andrew McGrath i Paul Moore (Orange / France Telecom)
Simon Hogg i Jinfeng Luo (Sharp)
Chris Stott i Thomas Dahlblom (Adobe Systems)
Biswarup Dasgupta i Henri Salminen (Sasken Communication Technologies Ltd)
Eeva Kangas i Riina Löija (Digia Plc)
Martin Liboska i Stephan Keclik (Deutsche Telekom)
Ilkka Syrjälä i Mikael Laine (Ixonos)
Terence Warmbier i Matias Impivaara (Immersion)
James Lee i Ryan Kim (Acrodea, Inc.)
Momoko Kin i Hiroyuki Seki (ISB Corporation)
Calum Lawler i Pim van Meurs (Nuance Communications, Inc.)

Z przeglądu kandydatur to mam wrażenie że to są osoby mało znane ludziom. Trudno często znaleźć informacje o tych osobach. Część z nich ma konta na Twiterze czy LinkedIn. Obecność Chińczyków i Japończyków w radzie Symbian może świadczyć o tym że będą dążyli do tworzenia własnych wersji "narodowych" Symbiana. Obecnie chyba najciekawsze będzie przed nami czyli śledzenie dyskusji o tym jak będzie wyglądać wdrażanie Symbiana^3 oraz dalszy ciąg deliberowania o tym jaki będzie Symbian^4. Zastanawia mnie wybór Chrisa Stotta z Adobe. Mam wrażenie że nie bierze aktywnego udziału w tym procesie ustalania UI. Z drugiej strony nie wiem jak to ma znaczenie z tworzeniem wersji FlashLite czy FlashPlayer 10.1 bądź Adobe AIR Mobile. Mam wrażenie, że obecność Adobe w tej radzie to tylko maszynka do głosowania. W pewnym sensie Adobe woli współpracować bezpośrednio z Nokią czy japońskimi producentami niż dyskutować nad tym co jest ładne i użyteczne dla użytkownika. Dużo ciekawsze są spotkania grupy odpowiedzialnej za architekturę Symbiana dowiedziałem się, że za prace nad FlashLite 4/ Flash Playerem 10.1 dla Symbiana odpowiada Sriram V. Zresztą on ostatnio awansował w Nokii więc myślę, że będzie miał większy wpływ na rozwój technologii runtime w Symbianie (WRT, FlashLite i Pythona).

poniedziałek, 5 kwietnia 2010

Aplikacje internetowe w Qt na Symbiana

Programowanie w Qt to inwestycja która pozwoli na tworzenie aplikacji internetowych dla programistów urządzeń mobilnych w C++ co przyniesie dobre rozwiązanie w sytuacji gdy potrzebujemy napisania aplikacji która ma być w przyszłości rozwijana. Programowanie internetowych aplikacji mobilnych które mają pełnić rolę wizytówek czy widgetów aktualizowanych w razie potrzeby i umożliwiających pracę w trybie offline to duża rzadkość z powodu nadmiaru różnych wersji urządzeń mobilnych. Napisanie aplikacji internetowej z użyciem silnika QtWebkit otwiera bardzo duże możliwości wykorzystania HTML5, JavaScriptu wraz z dostępem do API urządzenia w języku C++.

Większość ludzi woli uczyć się od obejrzenia jakiegoś wykładu. Polecam zapoznanie się z 48 minutowym filmem o QtWebKit zatytułowanego QtWebKit: Qt and Web 2.0
Filmik z 2008 roku pokazywał jak załadować stronę WWW, albo plik lokalny. Następnie pokazywał jak tworzyć pluginy na stronę wyświetlaną w QtWebKit, pokazał jak z poziomu kodu C++ sterować dzianiami HTTP na przykładzie Twiitera, Podobnie pokazał jak wykonywać kod JavaScriptu na stronie WWW z poziomu C++ na przykładzie załadowania Map Google.Można napisać kod JavaScriptu dzięki któremu można sterować możliwościami pluginów C++ na stronie WWW (na przykładzie QtScript Calculator)

Następny film jest zatytułowany - Developments in the Qt WebKit Integration Ten filmik jest raczej technologicznym opisem możliwości QtWebKita w wydaniu Qt 4.6. Do najwązniejszych należy dodanie klas QtWebElement, QtWebPluginDatabase, QtGraphicsWebView. Istotne jest to że można już robić aplikacje oparte na HTML5.

Warto też obejrzeć materiały szkoleniowe pt: Programming with Qt - WebKit prowadzone przez Stefana Hundhammera z basysKom i przez Katrinę Niolet z KDAB

Kolejnym krokiem byłoby zapoznanie z przykładami kodu w C++ dla Qt, które są na wiki Forum Nokia Aby zrozumieć jak wygląda współpraca pomiędzy kodem C++ a skryptami JavaScript należy przestudiować następujące kody: Exposing QObjects to Qt Webkit i na podstawie tego kodu Calling an exposed QObject slot from Qt WebKit with JavaScript oraz Connecting to a QObjects signal with JavaScript slot in Qt WebKit

Kolejnym krokiem byłoby zapoznanie z przykładami kodu w C++ dla Qt, które są na wiki Forum Nokia Aby zrozumieć jak wygląda współpraca pomiędzy kodem C++ a skryptami JavaScript należy przestudiować następujące kody: Exposing QObjects to Qt Webkit i na podstawie powyższego kodu Calling an exposed QObject slot from Qt WebKit with JavaScript oraz Connecting to a QObjects signal with JavaScript slot in Qt WebKit

Innym zagadnieniem jest wyświetlanie stron internetowych co pokazano na następujących fragmentach kodu: How to use QWebView in Qt for Symbian, Display local web page with Qt WebKit, , Gather data from web page with JavaScript, WebKit, and Qt, Add data to a web page with JavaScript, WebKit, and Qt. Warto zwrócić też uwagę na kod ze wskazówki Using QWebHistory to navigate through web pages

Gdy rozwijały się prace nad frameworkiem Qt 4.6 inżynierowie zrobili sporo przykładów w ramach projektu Graphics Dojo. W tym temacie interesujące są przykłady: fancybrowser, flightinfo, gsuggest, gweather, lightmaps, mapzoom, panwebview, prettybrowser, transparentweb, twitterview, videofeed, weatherinfo, webcapture, webgtalk, webmonster, webnightmode, websnap. Część z nich trafiło do oficjalnej dystrybucji Qt4.6 SDK jako demos embedded

Przykłady kodów jak mogą wyglądać dobrze zrobione aplikacje internetowe Qt pod kątem UI znajdziemy w Mobile Demos, które zostały napisane przez programistów INdT - Instituto Nokia de Tecnologia. Kiedyś był prowadzony blog Qt Effort który zawierał interesujący przykład jak wykorzystać Google Maps w QtWebkit

Natomiast na Forum Nokia są następujące przykłady aplikacji internetowych:
Qt: QWhoWhere Example
to przykład jak zrobić aplikację geolokalizacyjną, Qt for Symbian: qutIM Example to przykład jak zaprogramować własny komunikator,
QtWebKit: ListEm Example to przykład jak można zrobić aplikację bazodanową z interfejsem użytkownika w QtWebKit, QtWebKit: Beta Labs Example to przykład jak można zaprogramować widget przy pomocy QtWebkit

Z ciekawszych projektów z kodem źródłowym są to biblioteki wykorzystujące Qt. Była próba zrobienia portu Qt Symbian dla widgetów PhoneGap, które jest dość ciekawym rozwiązaniem - ale na razie wstrzymano się z jego rozwojem dopóki projekt Qt Mobility nie stanie się dojrzałym. Fundacja Symbian proponuje rozwijać własne rozwiązanie dla widgetów - cWRT na bazie Qt dla Symbiana ^3. Ciekawym rozwiązaniem może być biblioteka Qt do tworzenia klienta Twittera. Inna propozycja opiera się na wykorzystaniu biblioteki Qt do łączenia się z Facebookiem - co zostało opisane na wiki FN. Jednak najbardziej dynamiczniej rozwijanym projektem opensourcowym Qt dla Symbiana jest klient platformy blogowej WordPress

Podsumując z punktu widzenia programisty frontendu dla aplikacji internetowych biblioteka Qt z QtWebKit ma o wiele większe możliwości niż Adobe AIR a co za tym idzie perspektywa pisania aplikacji crossplatformowych na urządzenia mobilne w Adobe AIR nie wygląda interesująco w przyszłości. Zastanawiające jest to że wydanie FlashLite 4 na Symbiana bardzo opóźnia się. Polityka Adobe wobec platform mobilnych ostatnio zrobiła się taka nieciekawa, że mam wrażenie, że platforma Qt szybciej stanie się popularną technologią dla aplikacji mobilnych, niż Adobe AIR pomimo że więcej jest programistów ActionScript 3 niż C++, biorąc pod uwagę że prędzej Nokia wyda wersję Qt4.7 z QML i Qt Mobility na Symbiana niż Adobe z AdobeAIR z frameworkiem Flex 4 Mobile pod nazwa kodową Slider na Symbiana.

niedziela, 4 kwietnia 2010

Programowanie ActionScript 3 na Symbiana

Rozwój inteligentnych komórek jest coraz szybszy, a przez to stają się coraz bardziej dostępne. Konkurencja staje się coraz bardziej zażarta. A sytuacja producentów inteligentnych komórek coraz bardziej zaczyna przypominać rynek motoryzacyjny w którym bardziej rynek skłania się do tworzenia stref wpływu a także do specjalizacji pewnych zastosowań. Bardzo trudno jest być analitykiem urządzeń mobilnych dla internetu.

Ale spróbujemy spojrzeć na tą sytuację dzisiaj w kwietniu 2010 roku, dzisiaj coraz więcej urządzeń mobilnych korzysta z internetu, ale samych aktywnych użytkowników internetu wśród komórek inteligentnych nadal jest niewielu. Przeważnie są Ci którzy dobrze znają się na internecie i na komórkach.

Otóż większość raportów jaki ja widzę w internecie opiera się na tym jakie modele komórek są najczęściej używane w internecie albo po tym ile jest programów na stronach poszczególnych producentów. Ale z punktu analityka takie dane są pochodną ilości sprzedanych komórek i kultury użytkowników.

W takim bądź razie jak należy czytać dane statystyczne z punktu widzenia programisty. Przede wszystkim należałoby poczytać o tym ile komórek wyprodukował dany producent. Bardzo zła manierą jest opieranie się na procentach pisząc że Symbian ma 49% udziału we wszystkich inteligentnych komórkach na świecie. Paradoks jest innej natury: mało który analityk zada sobie pytanie jakich komórek inteligentnych z Symbianem jest najwięcej na świecie. Skoro teraz z Symbianem mamy 3 producentów (poza japońskimi) - Samsunga, Nokię i SonyEricsona. Czytając raporty o sprzedaży inteligentnych komórek należałoby też wziąć pod uwagę że w poprzednich latach produkcja komórek z Symbianem była na bardzo wysokim poziomie. W sumie nieformalnie w skali światowej dominuje Nokia z Symbianem

Duży wpływ ma też to w jakie sposób ludzie wchodzą w posiadanie inteligentnych komórek. Na tynkach rozwiniętych z dominacją internetu Ci którzy dobrze znają internet to chętnie przeniosą się w subsydiowane komórki z iPhone czy z Androidem. Natomiast wśród telefonów biznesowych rywalizacja dotyczy tego tego czy komórki maja klawiaturę QWERTY. Tutaj dominują RIM Blackberry i Nokia z E-Series. Te firmy bardzo chcą konkurować o przedsiębiorców na wschodzących rynkach. Używanie internetu w komórce wśród przedsiębiorców nie jest najważniejsze - liczy się bezpieczeństwo i szybki dostęp do poczty elektronicznej. Natomiast na rynku wchodzących typu Afryka czy Azja (Chiny i Indie oraz Rosja) liczy się przywiązanie do marki i model w którym kupujesz od razu cały model komórki bez subsydiowania. Tutaj Nokia wygrywa na rynkach bezwzględnie cenami. Używanie internetu jest w tych krajach okazjonalne, głównie przez Operę Mini

Dla programistów najważniejsi są użytkownicy biznesowi i tacy którzy okazjonalnie używają internetu ale nie w przeglądarkach internetowych. Jest duże zapotrzebowanie na aplikacje mobilne będące klientami różnych usług internetowych takich jak Twitter, Facebook, Amazon, Flickr, wszelkiego rodzaju komunikatory, czy dostęp do platform blogowych. Biznes potrzebuje aplikacji mobilnych pozwalających na dostęp do sklepów ecommerce, wydawcy o dostęp do treści przez aplikacje mobilne, marketingowcy o lepszą reklamę na inteligentne komórki.

Programistów na urządzenia mobilne można podzielić na tych którzy muszą się czegoś nauczyć nowego (Objective-C, C++, czy Java Mobile) i takich którzy chcieliby programować w tym co już znają (ActionScript, JavaScript, czy wykorzystać frameworki takie jak Qt).

Innym problemem jest różnorodność platform programistycznych, oraz przyzwyczajeń programistów Dla kogoś kto specjalizuje się w ActionScripcie pozostaje robić aplikacje na Flash Lite tego kto zna JavaScript to widgety WebRuntime i jak widgety Opery -sporo ludzi ma komórki z Java Mobile, ale ich programowanie zniechęca więc uciekają w programowanie na Androida. Podobna sytuacja jest po stronie Symbiana, mało kto chce programować w frameworku AVKON w C++ wolą już programować w czystym C++ przy pomocy różnych frameworków UI takich jak Qt, GTK. To co ratuje taka skomplikowaną sytuację to jest fakt, że prawie wszystkie inteligentne komórki chodzą na układach scalonych z procesorami ARM. Pojawiają się próby tworzenia bibliotek cross platformowych C++.

Qt Nokii to biblioteka C++ oficjalnie wspiera Windows Mobile(WinCE), Symbian, Maemo i systemy embbeded.
Ansca Corona to biblioteka z kompilatorem C++/Lua dla Androida i iPhone (Symbiana wspiera ale nieoficjalnie jeszcze)
Ideaworks AirPlay SDK to biblioteki C++ dla Symbiana, Windows Mobile, iPhone, Androida, Maemo, oraz Brew.Jest to najbardziej zaawansowany zestaw bibliotek w C++ dla Symbiana
MoSync SDK to biblioteki C++/JavaMobile dla Symbiana, Windows Mobile, Moblina a dojdzie wsparcie dla Androida, Maemo i iPhone.
OpenPlug z Elips Studio 3 to nakładka na Flex Buildera 3 pozwalająca napisać kod w ActionScript 3 którzy zostanie przekonwertowany na kod C++ i skompilowany pod odpowiednią platformę. Obsługuje Windows Mobile, Symbiana, Androida i iPhone.

Ponieważ mam już dostęp do wersji testowych Elips Studio 3 z OpenPlug to od samego początku to mam dziwne odczucia. Pierwsza beta nie działała dobrze pod Symbianem S60 5th, w następnej dodano obsługę Symbiana S60 3rd. Kolejne bety działały już coraz lepiej z kompilacją. Zastanawia mnie to że za każdym razem jak zainstaluję kolejną wersję ElipsStudio to muszę poprawiać plik wsadowy do uruchomienia. Po kilku próbach wyszło mi że muszę mieć tak napisany:

"E:\Program Files\OpenPlug\ELIPSStudio3.0\elips3.bat" E:\PROGRA~1\OpenPlug\ELIPSS~1.0 "E:\FlexBuilder3"

Początkowo myślałem że ma znaczenie jaka jest ścieżka do programu. ale okazało sie że działa to całkiem niezależnie od kompilatora CSL. Tylko kompiluje własnym z
E:\Program Files\OpenPlug\ELIPSStudio3.0\Tools\gcc\arm_elf\
i korzysta z własnego make.

W praktyce zauważyłem że w E:\OpenPlug\My Environments\ELIPS_3_0_1_235 jest sporo plików nagłówkowych i powiązanych z tym plików *.lib, kóre podczas kompilacji są łączone podczas kompilacji w jedną wielką bibliotekę.

Po ustawieniu środowiska Flex Buildera 3 że ma kompilować pod Nokię 5800 i gdy kliknę że ma skompilować pod środowisko dla Nokii zaczyna się długotrwały proces kompilacji. Najpierw generowane są pliki do E:\OpenPlug\My Systems\Flex_My Systems\ do 3 folderów (zakładając że zaimportowałem demo VideoApp):
E:\OpenPlug\My Systems\Flex_My Systems\VideoApp które zawiera kod przekowertowany z AS3 na C++ co ląduje do podfolderu elips_bin a następnie kompilator tworzy pliki dla assemblera ARM (*.o) które są w podfolderze ARM_Packages_Release W dalszym ciągu linkier łączy wszystkie biblioteki *.lib z istotniejszymi plikami *.o i kopiuje to wszystko do E:\OpenPlug\My Systems\Flex_My Systems\VideoApp_exe\ARM_Packages_Release gdzie efektem końcowym jest plik op (który często jest bardzo duży - 8MB). Ten plik to tak naprawdę jedna wielka biblioteka zawierająca w sobie wiele rożnych bibliotek. Dla Symbiana używa biblioteki gtk i bazującego na nim biblioteki C++ odwzorcowujące framework Flex, oraz biblioteki używających do stworzenia własnej biblioteki FlashPlayera w C++. Efektem końcowym jest stworzenie folderu E:\OpenPlug\My Systems\Flex_My Systems\VideoApp_cab\ARM_Packages_Release którzy tworzy plik uruchomieniowy dla pliku biblioteki op oraz tworzy paczkę SIS z tymi plikami.
Plik SIS osiąga bardzo duży rozmiar (powyżej 5MB) i zawsze instaluje się na dysku C.
Oczywiście, że można samemu przygotować własną wersję pliku *.pkg i wygenerować własny SIS.

To co jest plusem to szybkie tworzenie bardzo fajnych aplikacji z przyjaznym UI dla użytkownika. Jest możliwość wykorzystania szeregu bibliotek w czystym AS3.
To co wymagałoby inwestycji ze strony programisty to zaopatrzenie się w szybkie dyski SSD w celu dokonywania w nim kompilacji w rozsądnym czasie. Spowodowane jest to tym że w czasie kompilacji może wygenerować ponad 300 plików i potrzebować ponad 200 MB miejsca na dysku dla jednej kompilacji. W takim razie kompilacja trwa na słabych komputerach bardzo długo. Nadal to jest beta - więc najbardziej denerwuje brak obsługi znaków unicode w polach typu input. Uruchamianie aplikacji też nie wygląda na ciekawe doznanie - zachowuje się tak jakby komórka miała zaraz paść - wyświetlacz dziwnie migocze.
W takim bądź razie gdyby trzeba było szybko tworzyć prostą aplikację reklamową pisząc w ActionScript3 na Symbiana i Windows Mobile oraz iPhone oraz rozmiar aplikacji nie ma znaczenia to polecam do tego Elips Studio 3

poniedziałek, 22 marca 2010

Ewolucja WebRuntime i FlashLite

Nokia i Adobe planują wypuszczenie Flash Lite4 w ramach aktualizacji oprogramowania firmware. Ta aktualizacja jest podyktowana dalszym rozwojem silnika WebRuntime do lepszej współpracy z FlashLite. Okazało się że tworzenie aplikacji opartych na FlashLite wymaga właściwego mechanizmu dystrybucji. Obecnie żeby dystrybuować aplikację FlashLite trzeba przygotować plik SWF, albo załadować plik SWF ze strony internetowej, albo załadować plik SWF do paczki widgetu, albo w różny sposób robić instalki SIS. Biorąc pod uwagę istnienie mechanizmu pozwalającego ładowanie pliku SWF FlashLite do aplikacji Symbian w języku C++ to możliwości do wykorzystania. Obecnie zespół Qt pracuje nad integracją QtWebkit 2.0 z FlashLite 4 dla Symbiana^4. Silnik QtWebkit2.0 został tak skonstruowany, żeby prace nad nim nie wchodziły w kolizje z innymi projektami w Qt. Spowodowane to jest tez tym, że rozwój silnika Webkit staje się coraz szybszy co powoduje trochę inne cykle rozwojowe w przypadku zarządzania projektami IT.

Gary Chan przedstawił prezentację rozwoju silników WebRuntime:



Zdziwienie wywołało u mnie na slajdzie 11 informacja o dostępności w Platform Services 2.0 obsługi Audio. Owszem jest Media Management API ale z sterowaniem dźwięku chyba nie ma nic wspólnego. Na slajdzie 14 pisze że Ovi Maps API zapewni dostęp do danych map Nokii z poziomu komórki. Problem w tym że programiści nie mają dostępu jeszcze do internetowego interfejsu Nokia Maps z poziomu widgetów WRT. Natomiast juz są dema wigetów WRT czy aplikacji QtWebKit wykorzystujące API Google Maps czy OpenMaps API. Na slajdzie 15 pisze że wprowadzi się nowe API Show on Map. Nie wiem do końca na czym to ma polegać wychodzi na to że może takie aplikacje maja działać w ten sposób że zostają pokazane statystyki geolokalizacyjne dla tych którzy sprzedają aplikacje przez Ovi. Na slajdzie 16 wspomniano że obecnie należy programować w ActionScript2 dla FlashLite3 a także że Symbian^3 będzie zawierał Flashlite 4 a potem wprowadzi się wersję Flash Playera 10.1. Nie wiemy tylko czy Flash Lite 4 będzie dostępny dla starszych wersji Symbiana. Nowoscia w FlashLite 4 ma być możliwosć obsługi WebTV SDK z Adobe co pokazano na slajdzie 17. Przypuszczam że WebTV SDK to może operać się na Open Source Media Framework Natomiast w prezentacji nie wspomniano o projekcie Slider. Z punktu widzenia użytkownika lepiej zrobić interfejs aplikacji używając technologii FlashLite niż HTML/JS z WebRubtime, chociaż dzisiaj łatwiej o programistę JavaScript niż FlashLite.

środa, 17 marca 2010

Symbian Silverlight beta

Microsoft z współpracy z Nokią wypuścił wersję beta Silverlight 2 na Symbiana^1.. Betę opublikowano na stronach Nokia Beta Labs, To co mnie zainteresowało najbardziej to fakt, że wypuszczono wersję Silverlight w wersji tylko dla modeli dotykowych. Samo zainstalowanie wtyczki nic nie pomogło w sytuacji gdy nie ma linków do przykładów. W końcu ktoś podał linka do dema dla Binga
Po przeszukaniu informacji okazało się że to zespół z Indii stworzył tą aplikację. Tym zespołem kieruje Manav Gaur (@mgaur). Postanowiłem więc przyjrzeć się możliwościom tej wersji. Ściągnąłem więc wersję Silverlight for Symbian - Beta Developer Tools. Po zainstalowaniu zauważyłem że są przykłady: Digg, HelloWorld i SilverPlayer. Przegrałem je na kartę i spróbowałem uruchomić (nie udało się). Pomyślałęm że problem jest że te wersje nie są dobrze skompilowane. Postanowiłem zainstalować Visual Web Developer 2008 Express with SP1 (instalacja była trochę problematyczna) wraz z Microsoft® Silverlight™ 2 Tools for Visual Studio 2008 SP1 Po zainstalowaniu zrobiłem swoja wersję HelloWorld i wrzuciłem ją do komórki. Też nie dało się uruchomić w tej sytuacji zrozumiałem, że można tylko te pliki xap pobierać z internetu. Po pobieżnym zapoznaniu się z dokumentacją doszedłem do wniosku że na razie chyba sensowne rozwiązanie to używanie wersji na emulatorze dla S60 5th Edition SDK v1.0.. W tej sytuacji wszedłem do folderu Redist\Emulator zrobiłem plik c.bat z polecaniem cmd i uruchomiłem go, pojawiło się okno konsoli linii poleceń wiec wpisałem tam

InstS60Emu.cmd E:\S60\devices\S60_5th_Edition_SDK_v1.0

Po skopiowaniu 27 plików uruchomiłem emulator. W razie czego zmieniłem wybór emulatora poleceniem

devices -setdefault @S60_5th_Edition_SDK_v1.0:com.nokia.S60

a emulator uruchamiam poleceniem

epoc

Następnie uruchamiam w przeglądarce emulatora demo z Bingiem i zadziałało.
Pozostało sprawdzenie czy zadziałają przykłady z folderu Samples. Przypomniałem sobie nagle, że na lokalnym Apachu trzeba dodać MINE Types dla technologii Microsoftu wiec w pliku mine,types (albo można też w pliku httpd.conf) serwera Apache2.2 dodałem następujące wpisy:

application/manifest manifest
application/xaml+xml xaml
application/x-msdownload dll
application/x-ms-application application
application/x-ms-xbap xbap
application/octet-stream deploy
application/vnd.ms-xpsdocument xps
application/x-silverlight-app xap

Następnie zrestartowałem serwer Apache2.2. Przegrałem pliki przykładów do foldera htdocs/sl. Tak wiec miałem dostęp pod adresem http://127.0.0.1/sl/index.htm.
Uruchomiłem znowu emulator poleceniem epoc z linii poleceń. Długo się uruchamia sam emulator. Po otwarciu przykładu z SilverPlayer przgladarka w emulatorze zaiwszała się z błędem KERN-EXEC 3 Natomiast w przykładzie z Digga wyglądało na to że nie działa wpisywanie tekstu w pole tekstowe.

Czy Silverlight zagości w komórkach z Symbianem? Według mojego rozeznania nie za bardzo. Na poziomie użytkownika przypomina to konieczność ściągania i instalowania wtyczki (4 MB). Z punktu widzenia reklamodawców to technologia o bardzo małym zasięgu i dla niewielkiej liczby użytkowników. Z punktu widzenia zespołu programistycznego wymusza to fragmentaryzację i utrzymywanie wersji w Silverlight 2.0 (dla przeglądarek na Linuksie na Mono i dla urządzeń mobilnych) i Silverlight 3.0 (dla przeglądarek na Windowsie i Macu) i pracować nad migracją do Silverlight 4. W praktyce programiści i designerzy oraz developerzy prawdopodobnie zignorują wersję na urządzenia mobilne. Najgorzej wyjdzie jeszcze dla technologii Silverlight na Symbiana będzie rywalizacja z technologią Adobe czyli FlashLite czy Flash 10.1. Problem w tym że Ci którzy robią elementy Flash na stronach WWW nie biorą pod uwagę tego że trzeba dodać wersje Flash Lite dla użytkowników inteligentnych komórek. Jeżeli jest bardzo niskie zainteresowanie technologią FlashLite to jeszcze gorzej wypadnie dla Silverlighta. Następnym elementem, który wskazuje bardzo słabe zainteresowanie programistów .NET platformą Symbian jest upadek firmy RedFive a wcześniej AppForge. To co może dać szansę dla Silverlighta na Symbiana to:

  • dostarczenie wersji standalone do uruchamiania plików xap lokalnie
  • zrobienie wersji dla S60 3rd FP2
  • umożliwienie tworzenie paczek sis z aplikacjami Silverlight
  • umożliwienie uruchamianie aplikacji Silverlight (plików xap) z poziomu widgetów WebRuntime
  • dołączenie Silverlighta do aktualizacji FOTA (podobne do dystrybucji runtime Pythona 2.0)
  • dołączenie Platform Services 2.0 do runtime Silverlight
  • pokazać przykłady współpracy z QtWebkit
  • zrobienie frameworka UI dedykowanego dla Symbian i Windows Phone 7
  • i przede wszystkim dużo kursów i przykładów dla Symbiana oraz promowanie społeczności przez Microsoft i jak Nokię

wtorek, 16 marca 2010

APIBridge i Nokia Platform Service 2.0

Platform Services to API w Symbianie, dzięki któremu różnym technologiom na Symbiana (Web Runtime, FlashLite, Java Mobile i jak Python) zapewnia się identryczne API do pewnych funkcjonalności a w przyszłości rozszerzanie je.

Koncepcję API Platform Services powstała jak tworzono WebRuntime dla S60 3rd FP1 (bazując na Symbianie 9.2) Wtedy do obsługi aplikacji tworzonych jako widgety dodano API System Service Information pozwalające na zbieranie następujących informacji: stan baterii, stan połączenia z siecią, uruchamianie wibracji, stan wyświetlacza, stan pamięci RAM, oraz informacje o wersji językowej systemu. Pierwsze API nazwano WRT 1.0

API Platform Services 1.0 pojawiło się w 2008 wraz z wprowadzeniem S60 5th edition, jako rozszerzenie dla aplikacji internetowych dla WebRuntime i jak dla FlashLite. Celem było umożliwienie programistom szybkie wykorzystanie programowania w JavaScript czy ActionScriptu 2.0 do pewnych funkcjonalności komórki. Wtedy oficjalnie przyjęto że API dla WebRuntime w S60 5th nazwano WRT 1.1 Natomiast też wprowadzono API Platform Services 1.0 dla FlashLite 3 tylko dla S60 5th. One zawierały bardzo duży zestaw możliwości dla twórców aplikacji Symbiana w JavaScript czy ActionScript 2.0.
Oto zestaw API Platform Services 1.0 zawierał takie możliwości jak:
AppManager API pozwala na zebranie informacji jakie programy ma zainstalowane użytkownik i uruchamianie ich oraz plików powiązanych z aplikacjami
Calendar API- pozwala na dostęp i modyfikacje oraz zarządzanie danymi w kalendarzu.
Contacts API - można pobrać dane z kontaktów, modyfikować je i w razie czego eksportować do pliku vCard
Landmarks API - służy do zbierania informacji o punktach orientacyjnych i ich kategoriach a także tworzenie ich i czy eksportowanie w formacie XML
Location API - zbiera informacje o położeniu użytkownika z takich urządzeń GPS, AGPS czy z odbiorników Bluetooth GPS
Logging API - ma się dostęp do logów użytkownika kiedy i do kogo dzwonił
Media Management API - zapewnia dostęp do plików mediów w publicznych katalogach w komórce w tym do zdjęć użytkownika czy filmików użytkownika.
Messaging API - pozwala na wysłanie SMSa, MMSa czy emaila jako MMSa, pozwala też na przeczytanie treści w SMSach i MMSach, wyświetlenie monitu że otrzymało się wiadomość, zmianę statusu wiadomości a także kasowanie wiadomości programistyczne.
Sensors API - otrzymujesz dostęp do danych z czujników akceleracji, nacisku (tapping), orientacji, obrotu, kompasu (czujnik magnetyczny), przechylania (tilt)
System Information API dla WRT 1.1 ma sporo nowych opcji do odczytu: głównie informacje techniczne o komórce: firmware, nazwa, model, imei, identyfikator komórki, a także informacje związane z siecią: nazwę operatora, numer stacji bazowej, obszar gdzie użytkownik się znajduje.

Potencjalne możliwosci wykorzystania tego API są spore i wystarczające do tworzenia całkiem ciekawych funkcjonalności.

Potem Nokia aktualizowała w niektórych modelach silnik przeglądarki internetowej WebKit a także pojawiła się nowa wersja FlashLite 3.1 to dla niektórych modeli API WebRuntime zaczęło nazywać się WRT 7.0 i WRT 7.1.

Z jednej strony coraz większa presja na tworzenie aplikacji w HTML5, żeby dorównać możliwościom. Nokia wraz ze swoimi partnerami najpierw jako projekt wewnętrzny stworzono API do WebRuntime pozwalający na dodawanie nowych wtyczek i możliwości czyli APIBridge. Z tego co mi wiadomo najpierw wykorzystał Facebook do stworzenia aplikacji na N97. Ponieważ ta aplikacja stałą się popularna to Nokia postanowiła upublicznić komponent APIBridge. Najpierw w wersji alpha w listopadzie 2009, a potem już poprawione wersje w lutym 2010 dla APIBridge Web Runtime API i jak dla FlashLite czy J2ME

W praktyce okazało się że sporo jest komórek z S60 3rd które właściwie nie mają Platform Services, wiec wyszła potrzeba dostarczenia tym komórkom takiej samej funkcjonalności jakie mają te nowsze komórki. Wykorzystując możliwość tworzenia aplikacji serwerowej opartej na pluginach ECOM stworzono framework który pozwala na rozszerzanie możliwości dla WebRuntime, FlashLite czy nawet JaveMobile i Pythona. API tego frameworka API Bridge można wykorzystać zarówno każdej wersji WRT czy w FlashLite 2 czy FlashLite 3.
Możliwości APIBridge są takie: wysyłanie plików, nagrywanie filmów, robienie zdjęć, nagrywanie dźwięku, odczyt plików, skalowanie obrazków, tworzenie miniatur, dostęp do usług Logging API, dostęp do usług Location API, dostęp do plików multimedialnych i wysyłanie tonów DTMF podczas dzwonienia. To wszystko jest dostępne dla programistów ActionScriptu i jak JavaScriptu czy Javy

Równocześnie Nokia dokonała refaktoringu API Platform Service dostarczając możliwość obsługi kamery z poziomu JavaScriptu. API Platform Service 2.0 zostało wypuszczone jako wersja alpha do testowania w marcu 2009, natomiast rok potem w marcu 2010 zostało wysłane do aktualizacji w firmaware N97 i N97 Mini. Główna różnica pomiędzy API Platform Service 2.0 a API Platform Service 1.0 poza zmienionymi nazw metod polega na tym że większość kodu w API Platform Service 2.0 może wykonywać się w sposób asynchroniczny i usunięto ze względów bezpieczeństwa AppManager API.

Czy te możliwości przyjmą się wśród programistów na komórki? Trudno powiedzieć. Ludzie chcą bardziej bajerancki UI dla aplikacji, co jest możliwe do zrealizowania w FlashLite 3, a z drugiej strony spora fragmentaryzacja technologii wymusza dokonywanie pewnych kompromisów w zakresie projektowania i ingerencji w dane użytkownika. Ktoś złośliwy mógłby napisać gierkę a w tle dokonywałoby zbierania danych o użytkowniku, a potem AJAXem wysłałby dane o komórce użytkownika też wraz z danymi o położeniu użytkownika. W teorii można by wgrać listę wszystkich sklepów i ich dane kontaktowe do książki adresowej użytkownika a także wgrać listę punktów obserwacyjnych o tych sklepach do bazy w komórce. Takie aplikacje są dobre dla ludzi którzy potrzebują szybkiego kontaktu wewnątrz organizacji i na służbowych komórkach. Monitoring pracowników gdzie aplikacja w tle wysyła na serwer komunikaty o położeniu pracownika i jego aktywności jest wręcz konieczna w przypadku gdzie trzeba zarządzać ludźmi w czasie rzeczywistym. Pisząc o jego aktywności polega to na zbieraniu informacji o jego kontaktach. Wykorzystanie kamery w komórce pozwoli na robienie na szybko zdjęć i wysyłanie tego mailem czy MMS ma duże znaczenie w dostarczaniu komunikatów z imprez czy efektywności podejmowanych działań. Właściwie bardzo silna możliwość identyfikacji użytkownika komórki sprawia że łatwiej jest dokonać jego pomiaru aktywności poprzez wykorzystanie tej aplikacji jako widgetu w internecie niż w przypadku aplikacji internetowych z przeglądarki internetowej. Widgety Symbiana mogą stać się bardzo skutecznym w marketingu mobilnym - ale też przekleństwem dla użytkowników komórek.