Ukrycie Symbiana

Zmiana Prezesa Nokii odejście sporej starej kadry Nokii. Zmiany w Fundacji Symbian, zwolnienie 1200 ludzi zajmujących się Symbianem w Nokii. To tylko pokazuje, że zmieniają się ludzie a kod pozostaje i ktoś musi nim się opiekować.

Organizacyjnie zmiana szefa powoduje, że większość kadry zarządzającej zmienia się. Kierownicy pojawiają się i odchodzą, natomiast ludzie z średniego szczebla nadal robią to co robią. Fundacja Symbian nie potrzebuje wielu ludzi do zarządzania rozwojem Symbiana. Odejście Samsunga czy SonyEricsona z rozwijania Symbiana jest wyrazem braku wykwalifikowanej kadry z ich strony, która miałaby pomagać rozwijać Symbiana. W praktyce przedstawiciele tych firm okazjonalnie pojawiali się na telekonferencjach czy spotkaniach face-to face. Czarny public relations wokół Nokii i Symbiana wystraszył ich skutecznie. Te firmy tak naprawdę dostawały technologię, produkowały sprzęt do niego i nie zawracały sobie głową rozwojem. Natomiast inne podejście mają Japończycy. Dla nich Symbian jest "ukryty" i "zamknięty" co oznacza tylko tyle że firmy Fujitsu, Sharp i DOCOMO ściśle ze sobą współpracują i wypuszczają nowe modele komórek z Symbianem dla nich samych. Jest inny problem dla użytkowników takich japońskich komórek. Użytkownicy japońskich komórek z Symbianem raczej nie potrzebują instalowania aplikacji, bo większość aplikacji działa na zasadzie korzystania z internetu i uruchamiania w przeglądarce internetowej midletów i-mode czy aplikacji FlashLite 1.0 Silne ograniczenia bardzo korzystnie wpłynęły na rozwój tamtejszych aplikacji. Konieczność przebywania w trybie online w internecie z komórkami z Symbianem sprawiło, że Japończycy byli już "przygotowani" na nadejście inteligetnych komórek z iOS czy Androidem.

Ludzie z Fundacji Symbian doszli do wniosku, że skoro ludziom nie podoba się interfejs uzytkownika Symbiana to poinformowali o tym że zmienią go. Problem okazał się bardziej prozaiczny, nie można zmienić interfejsu użytkownika bez napisania na nowo systemu. Pierwsza koncepcja Symbiana^4 polegała na tym, że trzeba by napisać kod interfejsu uzytkownika od nowa co powodowałoby konflikt z istniejącymi aplikacjami. Takie podejście zostało bardzo źle przyjęte przez społeczność użytkowników Symbiana, którzy pamiętają czasy przejścia z S60 2nd na S60 3rd. Programistom Symbiana nie uśmiechało się porzucanie AVKONa. bo przypominało to losy UIQ. Szybki rozwój zespołu odpowiedzialnego za Qt na Symbianie sprawił, że ciężar rozwoju Qt na Symbiana przeniósł się do zewnętrznych firm ściśle współpracujących z Nokią na zasadach kontraktowych (Digia, Tieto, Comarch,  Cybercom). W maju 2010 roku w Nokii nastąpiła pewna zmiana polityki wobec dalszego rozwoju Symbiana. CTO Nokii został Rich Green któremu rewolucyjne zmiany w interfejsie użytkownika nie były mu na rękę, więc zatrzymał tempo rozwoju nad UIEMO przez Orbit Team (Daniel Zucker i Ray Rischpater). Okazało się  że konserwatyzm programistów był tak silny że zmieniono podejście.  Odejście szefa fundacji Lee Williamsa to konflikt nad wizją rozwoju interfejsu użytkownika. Szef fundacji widział potrzebę zmiany w interfejsie użytkownika, to po zmianie szefa Nokii na Stephana Elopa już nie był taki pewny że to zrealizuje. Nie wiem co Scott Weiss zrobi sam bez wsparcia  Elizabeth Dykstra-Erickson i Sara Berg.

Nowe podejście do Symbiana wyszło z założenia, że skoro tyle lat interfejs użytkownika dobrze spełniał swoje zadania (szczególnie na komórkach z klawiszami). Programiści wolą nadal korzystać z AVKONA i jak ostatnio z Qt wybrano strategię ukrywania Symbiana, a w przyszłości ponowne jego zamknięcie do spółki z Japończykami. Rolą fundacji Symbiana będzie tylko informowanie świata o rozwoju Symbiana ale tak naprawdę dalszy rozwój fundacji będzie przypominał rozwój fundacji Eclipse czy fundacji Mozilla.

A jaki był problem prac nad interfejsem użytkownika? Sympatycy Fundacji Symbian mają poważny problem w rozwijaniu różnych projektów na przykład przeniesienia Homescreena z Symbiana^3 do wersji z S60 5th Edition. Te zmagania można było poczytać na  forum dyskusyjnym. Ten wątek jest pasjonujący. Głównym problemem były się zmiany w API jądra Symbiana^3 co uniemożliwiło backportowanie (warto zwrócić uwagę na ten watek i wpisy w bugtraqu) . W tej sytuacji społeczność zainteresowała się tworzeniem nakładki na bazie Qt czyli Orbitem i Homescreenem Symbiana^4. Nie było to interesujące rozwiązaniem jeżeli chodzi o UI i UX. W Nokii zastały dalsze zmiany bo w zespole MeeGo zatrudniono Petera Skillmana jako szefa od UX. Sporo zmian spowodowało "zamrożenie" prac zanim nowi ludzie w Nokii odnajdą się.

Istotne jest też że proces prac nad Qt 4.7 do Symbiana w Nokii N8 dopiero się rozpoczął. Do tej pory Orbit i jak Direct UI opierały się na tym co maiło do zaoferowania Qt.4.6.3 Teraz dzięki nowym możliwościom QtQuick  i jak QtWebKit 2.0 specjaliści od UX mogą na nowo zdefiniować UI. Powoduje to pewien problem zależność UI od aktualnego stanu rozwoju Qt. Jedynym rozwiązaniem jest "ukrycie Symbiana" polega to na tym, że można zostawić AVKONa bez zmian, co pozwoli to na uruchamianie starszych aplikacji. Natomiast użytkownik będzie widział nową nakładkę użytkownika bądź w razie czego ją zmieniał tak jak zmienia się motywy na Symbiana.  Gdyby API HomeScreen było bardzo rozbudowane na poziomie interfejsu API a programiści mogliby mieć dowolność w tworzeniu wyglądu. W praktyce oznacza tylko tyle że załadowaniem plików zasobów sterujących interfejsem użytkownika będzie odpowiadać inny silnik dziedziczący od  API AVKONa. Jest to trudne, ale konieczne i możliwe do zrealizowania co pokazały takie firmy jak TAT (silnik Kastor) czy SPB (nakładka Mobile Shell), bądz Acrodea (silnik Vivid)

Można też zauważyć coś dziwnego: absencję Nokii w pracach nad stworzeniem nowego API który miały stać się API dla nakładek. Japońska firma Acrodea forsuje rozwiązanie zwane Common UI Framework
(więcej na tym wątku forum). Faktyczne przyjęcie propozycji Japończyków w Fundacji Symbian wywołało pewne zaniepokojenie w Nokii (w sumie Nokia wstrzymała się w głosowaniu) Japoński framework Vivid UI miał być obok Qt i TAT Kastora jako podstawa do budowy nakładek na Symbiana.

Ciekawostką jest przejęcie przez firmę HTC francuskiej firmy Abaxia dla której w Mińsku w Białorusi w firmie BRLSoft pracują tacy inżynierowie od UI Symbiana: Organ Modeniz, Alexander Zolotarev Vadim Abrossimov. Bardzo możliwe, że HTC zainteresuje się Symbianem.

Szablon aplikacji Qt Quick na Symbiana

Tak jak wcześniej zauwazyłem, nie można uruchamiać aplikacji Qt Quick w sposób skryptowy. Co oznacza że dla Symbiana trzeba napisać szablon dzięki któremu będzie można testować działanie kodu Qt Quick w QML.

Tworzymy folder Szablon ( u mnie to jest na wirtualnym Windows XP w Windows 7 pod c:\Projekty\Szablon). Tworzymy plik projektu main.pro

# jakich bibliotek Qt chce się uzyć
QT       += core gui declarative
# nazwa aplikacji 
TARGET = Szablon
# informujemy że tworzymy aplikację Qt na Symbiana
TEMPLATE = app
# pliki żródlowe 
SOURCES += main.cpp
# pliki nagłowkowe
HEADERS  +=
# pliki designera Qt
FORMS    +=
# inne pliki używane w Qt (szczególnie pliki QML)
OTHER_FILES = main.qml
# plik zasobów zawierajacy pliki QML
RESOURCES = main.qrc 
# informacje które są potrzebne dla kompilatora dla Symbiana
symbian {
# plik ikonki programu 
ICON = icon.svg
# biblioteki potrzebne do zablokowania położenia aplikacji w orientacji poziomej
LIBS += -lcone -leikcore -lavkon
}

Tworzymy plik zasobów main.qrc

<RCC>
<qresource prefix="/">
<file>main.qml</file>
</qresource>
</RCC>

Zrobimy plik main.qml z kodem QML

import Qt 4.7
 
Rectangle {
    anchors.fill: parent; color: "black"
 
    Rectangle {
        anchors.centerIn: parent
        width: 100; height: 40; radius: 5; color: "lightgray"
 
        Text { anchors.centerIn: parent; text: "Koniec"; color: "black" }
 
        MouseArea {
            anchors.fill: parent
            onClicked: Qt.quit()
        }
    }
} 

Na koniec pozostał kod wykonywalny z main.cpp

#include <QtGui/QApplication>
#include <QDeclarativeView>
#include <QDeclarativeContext>
#include <QDeclarativeEngine>
#include <QGraphicsObject>

// biblioteki potrzebne do zablokowania zmiany orientacji
#ifdef Q_WS_S60
    #include <eikenv.h>
    #include <eikappui.h>
    #include <aknenv.h>
    #include <aknappui.h>
#endif

// funkcja main uruchamiająca aplikację
int main(int argc, char *argv[])
{
    QApplication app(argc, argv);
   // kod AVKON blokujący orientację 
#ifdef Q_WS_S60
 CAknAppUi* appUi = dynamic_cast<CAknAppUi*> (CEikonEnv::Static()->AppUi());
    TRAP_IGNORE(
        if(appUi) {
               appUi->SetOrientationL(CAknAppUi::EAppUiOrientationLandscape);
        }
    );
#endif
    QDeclarativeView view;
// będzie nam to potrzebne jak zechcemy uzywać innych bibliotek importowanych takich jak
// moduły WebView czy Particles
   view.engine()->addImportPath("./imports");          
// pobieramy plik z zasobów
     view.setSource(QUrl("qrc:/main.qml"));
// ustawiamy tryb zmiany rozmiaru
    view.setResizeMode(QDeclarativeView::SizeRootObjectToView);

#if defined(Q_WS_S60)
// ustawiamy na sztywno obszar gdzie będzie rysowane 
    view.setGeometry(QRect(0,0,640,360));
// wykonujemy pełne wyświetlenie
    view.showFullScreen();
#endif
// aplikacja ma zostać uruchomiona
    return app.exec();
}

Do plików w tym folderze trzeba dodać jakaś ikonkę SVG 44x44 z programu inkspace i nazwać ją icon.svg

Pozostało więc popracować nad kompilacją Uruchomiłem Start -> Programy-> Qt for Symbian by Nokia v4.7.0-beta2 (S60) -> Qt for Symbian Command Prompt i wpisałem

cd c:\Projekty\Szablon

następnie zrobiłem pliki potrzebne do komplikacji wpisując

gmake

następnie robię kompilację pod emulatora

make debug-winscw

uruchamiam emulatora

make run

zamykam emulatora i sprzątam po emulatorze poleceniem

abld reallyclean winscw udeb

następnie ustawiam pod kompilację na komórkę

make release-gcce

po skompilowaniu trzeba zrobić paczkę

make sis QT_SIS_OPTIONS=-u

zrobiłem nie podpisaną paczkę i trzeba ją podpisać

signsis -s szablon.sis szablon.sisx c:\key\imobile.cer c:\key\imobile.key

Instalujemy to na komórce i na koniec pozostaje posprzątanie po kompilacji

abld reallyclean gcce urel

a może jednak lepiej będzie używać polecenia do czyszczenia wszystkiego (łącznie z paczkami)

make distclean

Na zakończenie przyszła mi myśl, że prawdziwego programistę można poznać po tym jak sprząta po sobie.

Qt Quick na Symbianie

Za jedną z najciekawszych technologii uważam QtQuick. Jest to nowy język opisu interfejsu graficznego wzorowany na CSS 3. Składa się z biblioteki Declarative i z języka QML. Ale mnie najbardziej zastanawiało jak będzie można programować w tym pod Symbianem. Przeczuwałem że mogą być problemy z tego powodu że Qt Quick tak naprawdę nie potrzebuje kompilacji kodów, więc przypominało mi to sytuację z programowaniem na Pythona czy m-shell. Wystarczy skompilować program qmlviewer i prawie wszystkie programy Qt Quick uruchamiać przez niego. Ale pomyślałem że takie rozwiązanie to przeczy zasadom bezpieczeństwa w Symbiaznie. Zaintrygowany  postanowiłem sprawdzić jak to rozwiązano.

Ściągnąłem Qt 4.7 beta 2 na Symbiana i zainstalowałem to na wirtualnym Windows XP.pod taką ścieżką C:\Qt\4.7.0.b2. Postanowiłem sprawdzić jak pójdzie mi kompilacja z linii poleceń.
Jest w menu Start -> Programy-> Qt for Symbian by Nokia v4.7.0-beta2 (S60) -> Qt for Symbian Command Prompt. Uruchomiłem to ale zaciekawiony byłem co to za skrót i okazało się że wykonuje on takie działanie: C:\WINDOWS\system32\cmd.exe /K C:\Qt\4.7.0.b2\bin\qtenv.bat Pojawiło mi się czarne okno do  wpisywania z linii poleceń. Napisałem tak

cd C:\Qt\4.7.0.b2\tools\qml

byłem już w folderze programu qml wpisałem

qmake

Wygenrowało mi pliki abld.bat, makefile i jak *.mmp. Postanowiłem najpierw zobaczyć jak dziala w emulatorze i wpisałem

make debug-winscw

zrobiło mi binarną wersję na emulatora i pozostało mi uruchomić. Wpisałem

make run

po jakimś czasie emulator uruchomił się z tym programem. Ale zreflektowałem się że w emulatorze nie mam plików z QtQuick. Zamknąłem emulator i przegrałem zawartość z folderu C:\Qt\4.7.0.b2\examples\declarative\animation do folderu C:\S60\devices\S60_5th_Edition_SDK_v1.0\epoc32\winscw\c\animation i uruchomiłem jeszcze raz emulator poleceniem

make run

i uruchomił mi sie program co sprawiło że mogłem wybrać ścieżkę do uruchomienia c:/animation/basic/color-animation.qml i zadziałało. No to teraz skompiluję qml na moją komórkę XM5800
Najpierw doinstalowywałem na kartę pamięci komórki następujące biblioteki w tej kolejności
C:\Qt\4.7.0.b2\qt_installer.sis
C:\Qt\4.7.0.b2\qt.sis
C:\Qt\4.7.0.b2\qtwebkit.sis
C:\Qt\4.7.0.b2\qt_demos.sis
C:\Qt\4.7.0.b2\fluidlauncher.sis

Po zainstalowaniu pomdlałem że znajdę jakieś programy typu oparte na QML. i zalazłem w folderze QtDemos takie jak qmlcalculator, qmlclocks, qmldialcontrol, qmleasing, qmlflickr, qmlphotoviewer, qmltwitter. Gdy uruchomiłem  qmldialcontrol to zauważyłem że zmiana położenia komórki blokuje program. doszedłem do wniosku że te programy wykorzystujące QML są jakby osadzone. To spróbuję skompilować na komórkę QML. Wróciłem do okna linii poleceń i wpisałem

make  release-gcce

i skompilowało się. Pozostało zrobić paczkę i wpisałem, żeby zrobiło mi paczkę bez podpisu

set QT_SIS_OPTIONS=-u

a potem

make sis

i pojawił się taki komunikat:


Auto-patching capabilities for self signed package.

Patching package file and relevant binaries...

Executing elftran -vid 0x0 -capability "NetworkServices ReadUserData" /S60/devic
es/S60_5th_Edition_SDK_v1.0/epoc32/release/gcce/urel/qmlviewer_patched_caps.exe

NOTE: A patched package should not be used for distribution!

Processing qmlviewer_release-gcce.pkg...
Created  qmlviewer_unsigned.sis.


Wygląda na to że nie można używać programu qmlviewer w dystrybucji.
Podpisałem swoim certyfikatem

signsis -s qmlviewer_unsigned.sis qmlviewer.sisx c:\key\imobile.cer c:\key\imobile.key 

Po zainstalowaniu tego okazało się że nie działa tak jak bym się spodziewał. Uruchamia się ale nie można wybrać żadnego pliku QML a nagłówek tytułowy wskazuje na plik zasobów content/Browser.qml, który nie mógł zostać uruchomiony z powodu restrykcji z dostępem do plików w Symbianie. Zrozumiałem że po zaprogramowaniu plików QML trzeba będzie pakować je w pliki zasobów oraz osadzać je jakby wewnątrz programu. Ale jak? Pewną wskazówkę dawały mi przykłady

C:\Qt\4.7.0.b2\demos\embedded\qmlcalculator
C:\Qt\4.7.0.b2\demos\embedded\qmlphotoviewer
C:\Qt\4.7.0.b2\demos\embedded\qmltwitter

Testowałem tworzenie takich paczek z powyższymi przykładami. Wyglądało to obiecująco ale nie do końca.
Nie wiem jak będę tworzył pliki QML z kodowaniem unicode (utf-8), bo przykłady dotyczą kodowania Latin1. Zauważyłem też że przestają przykłady działać jak zmieni się orientację W sumie to można już myśleć o pisaniu kolejnego artykułu o tym jak zaprogramować własną aplikację Qt Quick, pomimo że to jest jeszcze wersja beta 2 i będziemy jeszcze czekać na wersję Qt 4.7 RC

Programowanie Symbiana pod Windows 7

Zainstalowałem całe środowisko programistyczne na Symbiana, ale okazało się że nie działa tak jakbym się spodziewał. Szczególnie kompilacja z poziomu Carbide.C++ nie kompilowała kodu. Emulator epoc.exe wywalał się. Polecenie devices wymagałoby zmieniania ręcznego pliku konfiguracyjnego. W tej sytuacji zrozumiałem że potrzebna mi będzie maszyna wirtualna z Windows XP.

Użytkownicy wersji Windows 7 Proffesional, Ultimate i Enterprise mogą zainstalować tak zwany tryb XP. Ten tryb opiera się na zainstalowaniu oprogramowania Windows Virtual PC i jak uaktualnienia do trybu XP. Więc w takim przypadku pod Windows 7 Home Premium sam zainstalowałem Windowsa XP na Windows Virtual PC Po zainstalowaniu Windowsa XP musiałem ściągać ponad 90 poprawek Następnym krokiem było skonfigurowanie wirtualnej maszyny o dodatek RemoteApp

Poszukałem w internecie ActivePerl-5.6.1.635-MSWin32-x86.msi i ściągnąłem. Po zainstalowaniu sprawdziłem czy mam zainstalowane co wystarczyło mi zrobić z linii poleceń wpisać polecenie

perl.exe -version

This is perl, v5.6.1 built for MSWin32-x86-multi-thread...

Kolejny krok to instalacja na wirtualnym XP środowiska wykonawczego Javy czyli JRE ze strony Oracle i po zainstalowaniu wpisałem z linii poleceń

java.exe -version

i otrzymałem coś takiego

java version "1.6.0_21"
Java(TM) SE Runtime Environment (build 1.6.0_21-b07)...

Następnie zasinstalowałem SDK S60 5th Edition SDK for Symbian OS
(zakładając ze jesteśmy zarejestrowani w Forum Nokia). Instalując SDK trzeba się upewnić że wirtualny Windows XP obsługuje na dysku partycje NTFS i jest uruchomiony jako 32-bitowy. Podczas instalacji jesteśmy proszeni o zainstalowanie CSL Arm Toolchain.

Po zainstalowaniu SDK zacząłem sprawdzać czy wszystko jest we właściwym miejscu w zmiennych środowiskowych. Wpisałem z linii poleceń

devices

pojawiło sie

S60_5th_Edition_SDK_v1.0:com.nokia.s60 - default

Następnie wpisacełem z linii poleceń epoc.exe U mnie to uruchamiało się i znikało. Pomyślałem że to problem ze nie mogę jeszcze uruchamiać emulatora bo nie mam zainstalowanego Carbide.C++

Więc ściągnąłem Carbide.C++ a następnie zainstalowałem. Po instalacji potrzebowałem poprawne skonfigurować Carbide.C++ Pierwszą rzeczą to było aktualizacja do wersji 2.6 z menu i wybrałem Help -> Check for updates. Po zainstalowaniu aktualizacji trzeba było zrobić restart Carbide.C++. Następną rzeczą było uruchomienie ustawień konfiguracyjnych
C:\Symbian\Tools\ADT_1.4\Carbide.c++\x86Build\env_switch\env_update.exe
i jak zainstalowanie kompilatora Nokii dla emulatora.

Uruchamiając IDE trzeba pozmieniać pewne domyślne ustawienia. Z menu wybierałem Windows -> Preferences. Pojawiło się okno Preferences, gdzie po lewej stronie miałem takie drzewko i wybierałem stamtąd węzeł Carbide.c++ i podwęzeł Platform Filtering Preferences.
Przy EKA2 Platforms pozostawiłem tylko Emulation (WinSCW) i GCCE (wszystko co ma w nazwie ARM odznaczyłem). Następnie sprawdziłem czy Carbide.C++ wykryło odpowiednią wersję S60 SDK to wybierałem węzeł SDK Preferences i tam zobaczyłem że Carbide dobrze wykrył S60 5th Edition SDK for Symbian OS. Zamknąłem i uruchomiłem z menu Carbide File -> New -> Symbian OS C++ Project i pojawiło się okno z którego wybrałem węzeł S60 -> GUI Application i przeszedłem krok po kroku wszystkie okna kreatora. Jak kreator zrobił całą strukturę folderów to w menu wybrałem Project -> Build Configuration -> Manage... i pojawiło się okno Add/Remowe Carbide Build Configuration i zaznaczyłem tylko Emulator Debug i Phone Release.
Zanim zacząłem kompilację to ustawiłem zakładkę Console na aktywną i wybrałem z menu Projekt Build All Configurations. Wtedy Carbide.c++ skompilował kod na wersję na komórkę oraz zrobi paczki w folderze sis a także zrobił wersję binarną dla emulatora. Komunikaty podczas kompilacji obserwowałem w zakładce Console. Uruchomiłem emulator przez wybranie z menu Run ->Run. Po kilku minutach uruchomił mi się emulator ale nale przestał działać. Trzeba liczyć się z tym że przy każdym uruchamianiu emulatora pojawiał się komunikat Alertu zabezpieczeń systemu Windows o pozwolenie na uruchamianie aplikacji w emulatorze. Więc wyłączyłem firewall wirtualnego Windowsa XP. Po przeszuakniu Forum Nokia przyczyny tego problemu doszedłem do wniosku że trzeba będzie sprawdzić komunikaty jakie zapisuje emulatror w pliku epocwnd.out Wszedłem w menu Start -> Uruchom i wpisałem %temp% Po znalezieniu pliku epocwnd.out przeanalizowałem go i wysłałem zapytanie na Forum Nokia to dostałem uwagę żebym wyłączył sterownik karty dźwiękowej.
Wszedłem w ustawienia Virtual PC dla wirtualnego Windowsa XP i przy ustawieniach intergacji odfajkowałem udostępnienia Audio. Zrobiłem restart wirtualnego PC i po tych zmianach wpisałem znowu z linii poleceń epoc.exe to tym razem uruchomił się bez problemu. Dokonałem rejestracji emulatora. Uruchomiłem Carbide.C++ i emulator zadziałał.
Denerwowało mnie że przy starcie Carbide.C++ informował mnie że nie może połączyć się z komórką. W tej sytuacji zainstalowałem Nokia PC Suite w wirtualnym Windowsie XP. Gdy podłączyłem Nokię XM 5800 to z menu wirtualnego Windowsa XP trzeba było wybrać USB ->Nokia 5800 Dołącz. W tej sytuacji komórka była już przygotowana do debugowania.

Zaciekawiło mnie jak będzie wyglądała kompilacja z linii poleceń. Uruchomiłem z linii polecen:

cd C:\S60\devices\S60_5th_Edition_SDK_v1.0\S60CppExamples\Note\group

potem wpisałem

bldmake bldfiles

i zrobił się plik abld.bat

Następnie wpisałem

abld build gcce urel

co powinno było mi zrobić kompilacje binarną na komórkę. Jak wszystko poszło w porządku to wpisuję

cd C:\S60\devices\S60_5th_Edition_SDK_v1.0\S60CppExamples\Note\sis

a potem

makesis note_gcce.pkg

zrobił się plik note_gcce.SIS

Następnie zrobiłem folder c:\key gdzie trzymam certyfikaty developerskie od chińczyków

wróciłem do okna i z linii poleceń napisałem

signsis -s note_gcce.sis note_gcce.sisx c:\key\imobile.cer c:\key\imobile.key

otrzymałem plik note_gcce.sisx do zainstalowania w komórce.

Na koniec pozostało wyczyszczenie tego co wygenerowałem podczas kompilacji

cd C:\S60\devices\S60_5th_Edition_SDK_v1.0\S60CppExamples\Note\group\

i wpisałem

abld reallyclean gcce urel

Pozostało sprawdzenie czy działa kompilacja pod emulator i wpisałem

abld build winscw udeb

następnie wpisałem

epoc.exe

i uruchomił mi się emulator

poszukałem programu Note i odpaliłem i zadowolony zamknąłem emulator

i pozostało posprzątanie więc wpisałem

abld reallyclean winscw udeb

tym poleceniem wyinstalowałem z emulatora program.
Mając już dobrze zainstalowane SDK i skonfigurowane środowisko programistyczne to mogłem już myśleć o programowaniu na Symbiana. Zamknąłem wirtualnego Windowsa XP w poczuciu dobrze zrobionej roboty.

Ludzie Nokii

Nokia ogłosiła 22 lipca dane o sprzedaży w drugim kwartale 2010. Podsumowując wyprodukowała 24 mln inteligentnych komórek co przyniosło jej 3429 mln Euro przychodów przy założeniu, że średnia cena inteligentnej komórki to 143 Euro. Wnioski? Pierwszy raz przychody z sprzedaży inteligentnych komórek były większe niż ze zwykłych. Co najważniejsze Nokia utrzymała swój poziom udziałów na rynku inteligentnych komórek, pomimo złej passy medialnej wokół Symbiana i coraz silniejszej konkurencji (Android, RIM) oraz coraz mniejszej sprzedaży w Ameryce Północnej.

Natomiast przez internet przeszły plotka puszczona przez amerykańską prasę o szukaniu nowego szefa Nokii przez radę zarządzająca. Okazało się że ta plotka miała swoje podstawy w wydanej niedawno po fińsku książce Uusi Nokia. Autorem tej książki jest Johani Risku. Ten człowiek w Nokii był szefem zespołu który tworzył interfejs S60 dla Symbiana w latach 2001-2002. W Nokii pracował do sierpnia 2009. Obecnie prowadzi własną firmę. Ta książka jest bardzo cenna i pokazuje aktualny stan w jakiej się znalazła Nokia. Autor nawet założył bloga dla tej książki (po fińsku). Najciekawszy artykuł o tej książce napisał Andrew Orlowski z brytyjskiego The Register.

W firmie Nokia widać na dłoni cechy które są charakterystyczne dla koorporacji. Przerost biurokracji. Czy ktoś zna tych ludzi z Nokii? Takich jak: Marko Ahtisaari (odpowiada ze design i UX), Petteri Alinikula (szef laboratorium w Helsinkach), Timo Ali-Vehmas (odpowiada za współpracę w branży), Mark Durrant (odpowiada za PR), James Harper (odpowiada za marketing technologii), Sari Ståhlberg (odpowiada za UX z Accessibility), Jo Harlow (odpowiada za marketing inteligentnych komórek w US), Dilip Kenchammana (odpowiada za Qt w Nokii), Kari Tuutti (koordynuje kampaniami reklamowymi), Henry Tirri (szef badaczy w Nokii), Juha-Pekka Sipponen (odpowiada za produkcję zwykłych komórek), Mark Ollila (odpowiada za App Wizard Ovi), Axel Meyer (odpowiada za projekty inteligentnych komórek z serii N), John Loughney (odpowiada za rozwój Maemo OS), Ukko Lappalainen (odpowiada za rozwój biznesowych telefonów), Alex Lambeek (odpowiada za marketing zwykłych komórek), Janne Jakobsen (szefowa działu multimedialnych inteligetnych komórek), Quinn Jacobson (lider badaczy od GPS), Ari Jaaksi (odpowiada za rozwój MeeGo), Michael Halbherr (odpowiada za Ovi Map razem z Gil Teissier), John Clarke (szef działu IT), Péter Boda (naukowiec odpowiedzialny za interfejs użytkownika za pomocą gestów), Nikki Barton (odpowiedzialna za interfejs użytkownika w cyfrowych mediach), Rebecca Allen (artystka, szefowa centrum badawczego-multimedialnego Nokii w Hollywood), Purnima Kochikar (szefowa Forum Nokia).

Wygląda na to że Ci menadżerowie odpowiadają w pewien sposób za to gdzie teraz jest Nokia? Tak ci którzy teraz są na szczycie kariery w Nokii, staja się bardzo zachowawczy, Nokia ma największy potencjał badawczo rozwojowy, setki patentów. Wystarczy spojrzeć na listę naukowców czym się zajmują się. Pomimo tego sporo wynalazków czy idei nie zostało zaimplementowanych. (na przykład elementy 3D w interfejsie użytkownika czy interfejs NFC w smartfonach). Im większa biurokracja i skomplikowana budowa inteligentnych komórek powoduje problemy z komunikacją

Sam Risku przytacza anegdotkę w której poprosił o to żeby okno dialogowe było mniejsze o 5 mm. to dostał odpowiedz, że nie mogą znaleźć kodu który by pozwalał na zmniejszenie okna dialogowego bo to wymaga przeszukania 2 milionów linii kodu. Dzisiaj to wywołuje uśmieszek politowania wśród programistów Symbiana takich jak Jan Ole Suhr a nawet Chris Redpath znalazł kod który za to odpowiada w ciągu 5 min co wywołało podziw.

Innym przykładem było to że tworząc serwisy internetowe Ovi menadżerowie do końca nie wiedzieli jak to rozwijać, gdy kierownictwo Nokii nie potrafiło korzystać z mobilnego internetu. Co tłumaczy taką długą stagnację w rozwijaniu przeglądarki internetowej w komórkach Nokii

Cechą biurokracji jest zbieranie wszelkich danych i analizowanie je. Często serwisy internetowe Nokii są tak zaprojektowane że użytkownicy muszą przechodzić testy A/B witryny internetowej, użytkownicy mają do wypełniania jakieś skomplikowane formularze.

Jeden z problemów w Nokii jest "narzucenie" projektantom designu filozofii Contextual Design wg Karen Holtzblatt, która zakładała dogodzenie użytkownikowi podczas projektowania. To ma sens w wzornictwie przemysłowym, ale nie ma zastosowania do innowacji. Bo jak produkt innowacyjny może zostać przetestowany przez użytkowników jak jego nie znają? Podobnie zauważył że lepszy efekt daje zawężenie portfolio i dostarczenie do sprzedaży wyspecjalizowanych produktów, co już Nokia prawie zrealizowała. Natomiast nadal pozostaje problem wypuszczania do sprzedaży podobnych do siebie modeli co sprawia że potencjalni klienci mają problem z wyborem właściwego modelu dla siebie. W świecie technologii klienci nie lubią mieć wyboru. Wolą jak ktoś im to poleci czy zarekomenduje.

Bardzo duże niebezpieczeństwo dla Nokii wynika z inercji. Brakuje przyspieszania. Często wewnętrzne projekty są anulowane bo nie nadążają z czasem, a do nowych projektów menadżerowie nie są przekonani. Skutkuje to sytuacją w której nie wykorzystuje się potencjału pracowników.

Od 2006 roku za działania marketingowe Nokii przejmowały firmy, które z marketingiem wysokich technologii nie miały do czynienia. Spowodowało co że masowa reklama Nokii bardziej przypominała reklamę produktów spożywczych. Często też brakowało spójnej koncepcji jak mają wyglądać serwisy internetowe, gdzie jak wspomniałem ciągle eksperymentowano.

Risku zasugerował stworzenie nowego stanowiska Chief Innovation/Creative/Design Officer który byłby równy rangą CEO. Problem w zarządzaniu Nokią wynika też w tym ze w latach 2003-2008 amerykańscy udziałowcy Nokii próbowali za bardzo wpływać na styl pracy w Nokii. Silnie postuluje żeby na tym stanowisku został ktoś kto jest Finem i zna od środka Nokię. Ale wskazuje też na istnienie Zasady Petera która mówi, że w organizacji hierarchicznej każdy awansuje aż do osiągnięcia własnego progu niekompetencji.

Sporo dostało się kadrze zarządzającej Nokii. Mary McDowell była szefową działu strategii programistycznej, ale sama nic na tym nie znała się. Trzeba było przejąć firmę Symbian i Trolltech. I zapewnić im dużą niezależność. Tero Ojanperä który jest na stanowisku CTO to jednak Nokia nie wprowadziła żadnych innowacyjnych technologicznie produktów od 2008, najgorsze jest to że nie ma wiarygodności w branży multimedialnej. Właściwie największym przykładem niekompetencji wg Risku jest Marko Ahtisaar. Wystarczy przejrzeć jego wpisy na Twiterze pod nickiem @moia Właściwie to on odpowiada za to ze nic nie dzieje w interfejsie użytkownika. Olli-Pekka Kallasvuo jest uważany za dobrego menadżera, ale czuć jego niekompetencję gdyby miał zarządzać inżynierami. Najbardziej medialną osobą Nokii jest Anssi Vanjoki, (raczej to też ma związek z jego aktywnością charytatywną wśród osób z niedosłuchem). Jedyne co można mieć zastrzeżenie do niego to czy jest w stanie być elastyczny i szybko dostosowywać się do szybko zmieniających się wymagań rynku.

Ponieważ media amerykanskie są nieprzychylne Nokii to w tej sytuacji były pracownik Nokii Tomi T Ahonen na swoim blogu napisał artykuł Obituary for OPK: Wall Street is a Cruel Mistress - Nokia searching for CEO. W tym artykule wspomniał 6 czynników które mają wpływ na negatywny wymiar spojrzenia na Nokię ze strony amerykańskich mediów.
Sytuacja Nokii w 2006 była taka miała inna konkurencję: Motorolę z jej telefonem Rokr i SonyEricssona z serią Walkman. Inteligentne komórki wtedy miały zastosowanie główne biznesowe.
Nokia postanowiła wejść na rynek amerykański z Symbianem. Symbian był wtedy tworzony na zasadzie partnerstwa pomiędzy udziałowcami. Innym słowem wtedy Nokia nie miała wpływu na to jaki jest Symbian. Idea Finów była taka żeby współpracować przy Symbianie, na efekty współpracy nie trzeba było długo czekać. W 2006 roku Nokia miała 48% udziałów w produkcji inteligentnych komórek i cały rynek miał wtedy wyprodukować 80 mln inteligentnych komórek. W 2007 roku Apple rozpoczęło masową marketingowe działania związane ze sprzedażą iPhone. Nokia wtedy sprzedawała z powodzeniem N95. Stało się coś dziwnego. Marketing Apple zrobił swoje, ludzie na giełdzie amerykańskiej przestali interesować się Nokią. Wtedy amerykańskie media często pisały o końcu rozwoju RIM Blackberry (co nie było prawdą). Okazało się że mało kto liczył się z faktami. Okazało się ze nagle potrzebny byłby ktoś kto byłby dla Nokii showanamen. CEO Nokii nie nadawał się do tej roli. Styl zarządzania Finów to współpraca i działanie w ciszy i spokoju z dala od mediów.

Dzisiejszy sukces dużo zależy od działań w sferze Public Relations. Nokia potrafiła sprzedawać dużo tanich komórek po 25 dolarów w biednej Afryce czy najtańsze modele inteligentnych komórek po 200 dolarów i jeszcze mieć zyski Nokia wprowadziła ekologiczne procesy produkcji komórek co jakoś to medialnie nie trafia do analityków. Analitycy często zapominali że porównując Apple z Nokią to porównywali rynek dóbr luksusowych z rynkiem dóbr pierwszej potrzeby. Wywołuje to silną presję na dostarczenie przez Nokię inteligentnych komórek o jeszcze lepszych parametrach. Nawet gdy technologicznie Nokia była lepsza od iPhone to media często brały argument z tego ile ludzi korzysta z internetu do przeglądania stron internetowych i na podstawie tego argumentu formułowano osądy że Nokia straci pozycję lidera. W Nokii mało kto przywiązywał wagę do przeglądania internetu w inteligentnej komórce.

Kolejny problem analityków to przekonanie że produkcja inteligentnych komórek jest bardzo dochodowa. Owszem początkowo Nokia miała wysoką marże (21% w 2007 a w 1Q 2010 zaledwie 4%). Ale trzeba pamiętać że Nokia to nie odniosła strat w produkcji zwykłych komórkach (i Samsung też) Motorola i jak SonyEricsson globalnie poniosły straty i jak spadek udziałów. Lata 2008-1009 to lata kryzysu Nokia właściwie przetrwała te czasy za cenę mniejszych zysków. HTC, Motorola, SonyEricsson, Palm miały duże straty. W sumie największe straty podczas kryzysu miały działy tworzące rozwiązania dla operatorów telekomunikacyjnych (NokiaSiemens Networks miała duże straty, ale Nokia postanowiła jeszcze przejąc analogiczny dział od Motoroli. Tak więc w tej branży liczącym się konkurentem Nokii pozostał Ericsson. To oznacza że Nokia w czasach kryzysu zamiast zajmować się wprowadzaniem programów oszczędnościowych czy redukcją załogi tylko dlatego żeby mieć lepsze zyski Nokia poprzez przejmowanie firm takich jak Symbian, czy Trolltech inwestuje w ludzi i w technologie. To jest główna różnica w stylu zarządzania Finów od Amerykanów.

Media i analitycy (szczególnie amerykańscy) wręcz nienawidzą Symbiana. Skoro Microsoft, RIM, Apple, Google, Palm mają własny system operacyjny to dlaczego Nokia dalej popiera Symbiana? Odpowiedz jest prosta bo ten system operacyjny nie wymaga mocnych procesorów i sprawia że produkcja inteligentnych komórek jest tańsza, a co za tym idzie dłuższe działanie baterii. Reakcją Finów na iPhone było rozpoczęcie prac nad Symbianem S60 5th edition, który na rynek wszedł w 4Q 2008. Cały rok 2009 to czas na przygotowanie do udostępnienia kodu źródłowego Symbiana^3. Nokia wprowadzając otwarty model zarządzania nad kodem źródłowym pośrednio pozbywa się potencjalnych zysków. Nokii zależy na współpracy niż na rywalizacji. Przykładem jest przejęcie działu od biznesowych rozwiązań Symbiana przez Accenture od Nokii. Samsungowi taka rola do końca nie odpowiada i postanowił zainwestować w włąsny system operacyjny. Udostępnienie kodu źródłowego jest strategią długoterminowa, głownie mającą na celu rozbrojenie przeciwników którym nie podoba się Symbian. Jeżeli nie podoba się komuś w tym systemie to może włączyć się do społeczności i razem z nimi poprawić to co nie podoba się. W dłuższej perspektywie dojdzie do powstania firm tworżących wyspecjalizowane dystrybucje Symbiana (np: komercyjne wsparcie dla architektury Atom na x86). To co różni Symbiana od Androida jest to że zarządzanie kodem źródłowym jest jawne, dotyczy to głownie tego że programiści wiedzą czego mogą się spodziewać w następnych wersjach Symbiana. Dlaczego Symbian jest taki dobry to prawie nikt o tym nie pisze?

W tym dochodzimy do sedna problemu. Mało ludzi chce pisać o Symbianie, gdy wszyscy krytykują go. Trzeba rzeczywiście dobrze poznać ten system operacyjny zanim zacznie o nim pisać. A co dopiero pisać o programowaniu na nim. Wychodzę z założenia, że należy dobrze poznać to co się ma, niż iść za modą i wymieniać modele komórek na nowsze. Ponieważ Symbian jest mało znany w Ameryce Północnej,powoduje to że blogosferze amerykańskiej powstaje sporo mitów o tym systemie operacyjnym. Brak instytucjonalnego wsparcia ze strony Nokii powoduje frustrację wielu sympatyków OS Symbian i ich zniechęcenie. W takiej sytuacji Nokia skoncentrowała się na rozwijaniu Forum Nokia społeczności dla programistów. Szybko doszło do sytuacji w której setki ludzi którzy cheliby zacząć programowanie na Symbiana natrafiali na barierę krzywej uczenia się.
Brak wsparcia w samodzielnym uczeniu się Symbiana i fakt że dokumentacja Symbiana jest raczej dla tych którzy znają Symbiana, a książki do nauki Symbiana są napisane takim stylem akademickim co nie sprzyja dobrej opinii dla Symbiana. To co powinno nastawienie do Symbiana dużo zależy od blogerów i nieformalnych działań w środowisku programistów Symbiana. Polecam czytanie takich blogów jak Nokia Developers, czy blogi pisane przez Vishala Dharankara, czy Hendy Irawana. Bardzo dużym zainteresowaniem cieszy się inicjatywa Symbian Developer Cooperative, która chce skupiać ludzi profesjonalistów zajmujących się Symbianem. Są to jednak strony znane tylko w wąskim gronie ludzi, głównie programistów a nie wśród ludzi zajmujących się analizą rynku inteligentnych komórek. Ci analitycy i dziennikarze powinni czytać takie blogi jak Mobile Phone Development pisany przez Simona Judge, czy Communities Dominate Brands pisany przez Tomi T Ahonena bądź blog VisionMobile

Zazwyczaj problemy z amerykańskimi operatorami sprawiają że Nokia przez długie lata miała słabą pozycję w Ameryce Północnej. Trzeba pamiętać że o sukcesie inteligentnych komórek bardzo duży wpływ mają operatorzy i to oni często decydują o tym co mają wybierać ich klienci. OPK powinien często podróżować do Stanów Zjednoczonych dużo spotykać się z kadrą zarządzającą od amerykańskich operatorów telekomunikacyjnych i udzielać dużo wywiadów mediom amerykańskim. Stworzyć w Stanach Zjednoczonych centrum marketingowe w którym każdy kto chciałby na przykład nauczyć się programowania na Symbiana miałby tam darmowe lekcje i spotkania. Bardzo dobrą koncepcję byłoby organizowanie "Tour Nokia" cyklicznych objazdów z wykładami o tym czym jest Symbian. Owszem jest to kosztowne logistycznie. Myślę że warto zrobić "big comeback" Nokii w Stanach Zjednoczonych i skoncentrować się na wartości merytorycznej (a nie tylko części artystycznej).

Porażką Nokii był model N97. Nokia nie chciała dać wyłączność operatorom tylko sprzedawać bezpośrednio klientom. Tą samą drogą poszedł Google z Nexusem One i też poniósł klęskę w dystrybucji. Jest bardzo mało ludzi którzy chcieliby sami od razu kupić nowy model komórki. Trzeba pamiętać że że większość ludzi preferuje płacić raty za inteligentną komórkę w abonamencie. Inny problem polegał na tym że N97 sprzedawano pod hasłem marketingowym "zabójca iPhona". Zresztą to okazało się że to nie miało pokrycia z rzeczywistością. Użytkownicy iPhona często korzystali z przeglądarki internetowej która była często aktualizowana. Natomiast użytkownicy N97 nie mieli takiego komfortu. Wymusiło to na Nokii wprowadzenie planu aktualizacji przeglądarki internetowej OSS Browser. I zaproponowanie programistom tworzenie aplikacji internetowej na bazie QtWebKit. Ale niesmak pozostał.

Randall Arnold autor bloga Tabula Crypticum w swoim artykule How Nokia can retake the US Market… and more wskazuje na czynniki które mogą przyczynić się do powrotu Nokii na rynek amerykański. Obecność pasjonatów i ich wspieranie. Częste organizowanie spotkań dla programistów i firm w których pracują. Aktywizacja medialna w postaci masowej reklamy filmów dla profesjonalistów. Niechaj masowo inwestują w markę Qt czy Nokia bądź Symbian w świadomości amerykańskich firm i przedsiębiorców. Nokia ma uczyć ludzi korzystania z ich komórek a nie tylko pokazywać co mogliby zrobić z ich komórkami. Produkty na rynek amerykański powinny mieć nazwy zwyczajowe a nie tylko skróty. Zrobić nowy branding tak jak z modelami Vertu. W przypadku słabego zainteresowania na rynku amerykańskim dobrym rozwiązaniem jest subsydiowanie "klona" E71 i N900. Wsparcie ze strony Intela powinno pomóc Amerykanom wybierać ich swoje produkty i wypromować Intela jako "ojca" MeeGo, a Nokię potraktować jakby tylko producenta. Aktywniej prowadzić komunikację medialną w sytuacjach kryzysowych. (np: dlaczego nikt z rady zarządzającej Nokii nie potwierdził czy zaprzeczył plotce o tym że akcjonariusze chcą zmiany CEO). Zmniejszyć skutki działania biurokracji w zarządzaniu firmą ba często kadra zarządzająca nie ma do końca dobrego obrazu tego czym zajmuje się firma.

Najważniejsza rada od Randalla Arnolda to zaprzestanie prowadzenie polemik z niezadowolonymi klientami i reagowanie szybko na zaistniałe problemy. Często jest tak że ludzie nie umieją korzystać z komórek. Dlaczego ludzie mają tyle problemów z centrami naprawy komórek? Sensownym rozwiązaniem jest wprowadzenie programu wymiany komórek w centrach naprawy komórek, niż naprawianie samych komórek. Można sobie wyobrazić jak ktoś uszkodzi komórkę to oddaje komórkę a z serwisu naprawy czy od operatora dostanie nową komórkę. Nokia musi nauczyć się i operatorów też zarządzać skutecznie recyclingiem i komórkami z serwisów i ze zwrotów od klientów. Dużym plusem takiego programu jest to ludzie będą mieli motywację do pozbywania się starych komórek Nokii, a one same po "naprawie" mogą dalej trafić do dalszej oficjalnej sprzedaży. Skuteczny sposób na zadowolonych klientów.

Niestety tak to już jest że łatwo krytykować i wskazywać słabe strony. Rzadko ktoś zada wysiłek przemyślenia i opisze przyczyny oraz poda rozwiązanie. Dlatego uwagi ludzi którzy byli w Nokii (ale już teraz nie są) są bardzo cenne.

Symbian^3 to potęga programistyczna do sześcianu

Prawie wszystkie informacje o Symbianie ^3 tak naprawdę dotyczą tylko tego kiedy Nokia wypuści swój model  inteligentnej komórki z tym systeme operacyjnym. Prawie nikt nie pisze o tym co nowego dla programistów wprowadzono w Symbianie^3. Obecnie mamy 3 główne źródła informacji dla programistów Symbiana ^3: Nokia Qt SDK, Nokia Symbian^3 SDK oraz Symbian Foundation Symbian^3 PDK.
Nokia Qt SDK zawiera w sobie Qt Mobility 1.0 co pozwala programistom już teraz programować możliwości Symbiana^3 w Qt. Myślę, że najciekawsze będzie jak programiści wypuszczą Qt Quick pod Symbiana i nowszą wersję QtWebkit 2.0 (z pełną obsługa HTML5 i CSS3 jako Webkit 528) w wydaniu Qt 4.7 Dodatkowo jeszcze będzie można będzie zdalnie kompilować kod na różne platformy i w tym na Symbiana^3. Głównym źródłem dokumentacji dla programistów jest Qt Reference Documentation. Qt dla Symbiana zawiera tylko cześć tego co jest możliwe do wykorzystania przez programistów Symbiana C++

Nokia Symbian^3 SDK to właściwa dokumentacja API wszystkich technologii które wchodzą w skład Symbian^3. W tym artykule skupię się na tym co nowego jest w Symbian^3

FreeWay to pozwala programistom na stworzenie aplikacji typu firewal czy hotspot. One-Click Connectivity to wbudowana funkcjonalność pozwalająca na szybkie łączenie się i przełączania się pomiędzy punktami dostępu. USB On-The-Go (OTG): pozwala na podpinanie masowych pamięci przez port USB inteligentnej komórki. AVRCP (Audio/Video Remote Control Profile) v1.4 pozwala na zdalne sterowanie urządzeniami Bluetooth w tym przypadku ma się dostęp do playlisty urządzenia. Obsługuje już obecnie pełny zestaw poleceń AT to co często było kiedyś używane w telekomunikacji do zdalnego sterowania urządzeniami. Ciekawsze możliwości są w zakresie obsługi geolokalizacyjnych API: Management Object (MO) for A-GPS, Application Processor Engine (APE) Centric Location Architecture. Location Based Services (LBS) SUPL Positioning Module (PSY) pozwala na bazie CelID okręslić położenie i przesłać dane SUPL v2.0. Wsparcie dla chipsetów GPSCost5.0D i GPSCost4.0D GPS pozwoliło stworzyć nowe A-GPS Nokia Positioning Engine (NPE) a także LBS SUPL Radio Resource LCS Protocol (RRLP) jako nowy sposób określania położenia wg stacji bazowych nowej generacji Aplikacje geolokalizacyjne bedą mogły wykorzystywać dane wg standardu Secure User Plane Location v 2.0.

W zakresie multimediów sprzętowo dodano API dla : Mobile TV DVB-H Receiver HAI, który pozwala na dostęp do telewizji mobilnej w sposób programistyczny. Jest też Fusion Player Application który jest główną aplikacją multimedialną w Symbianie. Niskopoziomowy dostęp do dźwięku jest możliwy dzięki API OpenMAX IL, który stanowi podstawę programistyczną do Multimedia Device Framework (MDF) do obsługi wyższego API: Thin Adaptation of A3F DevSound, który jest wysokopoziomową biblioteką do obsługi dźwięków. Kolejną nowością jest Image Processor library, który jest wysokopoziomowym API do obsługi obróbki obrazu głównie zdjęć. Camera API Extensions: zawiera wysokopoziomowe API do obsługi aparatu fotograficznego dzięki czemu będzie można tworzyć programy dla aparatu fotograficznego na przykład tworzące dopowiednio zdjęcia do dalszej obróbki HDR Symbian^3 posiada też zapis video wg kodeka H264, a także umożliwia zapis do dużych rozmiarów plików 3GP, 3G2 i MP4. Można też programistyczne dzięki Video Subtitle CRP ustawiać napisy w filmach video. Jest też wsparcie dla Dolby Digital Audio 5.1 co w praktyce oznacza możliwość podłączenia komórki do zestawu Hi-Fi poprzez port HDMI. Podobnie można poprzez ten port podłączyć się do telewizora i oglądać filmy czy prezentację z plików graficznych. Nie jest dla mnie pewne jak inne aplikacje mogłyby być wyświetlane przez HDMI na telewizorze. Istotne dla multimediów jest to że istnieje API Metadata Utility Library, dzięki któremu umożliwia odczyt czy edycję metadanych w pikach multimedialnych.

Z interfejsu użytkownika stworzono 6 ekranów na podgląd widgetów HomeScreen. Ponieważ za grafikę w pełni odpowiada procesor graficzny to do obsługi UI dodano nowe efekty i przejścia Nie wiadomo czy będzie można je zaprogramować we własnej aplikacji. Dodano takie możliwość powiększania 2 palcami, kinetyczne scrolowanie. Rozbudowano nowy interfejs do tworzenia motywów. Dzięki odtwarzaczowi telewizji mobilnej można oglądać telewizję nadawaną DVB-H (720pp przy 12 Mbps 30 kl/s). Przeglądarka plików graficznych oparta jest na Extended ICL JPEG API. Można też programistyczne odtwarzać i transmisję Radio FM. Dużą ciekawostką jest współdzielenie transmisji wideo w normalny sposób dla dzwoniącego, nie trzeba używać protokołu videokonferencji bo za całe zadanie odpowiada Multimedia Comms Engine API, które jeszcze nie jest udokumentowane podobnie jak Video Telephone API.

Wprowadzono istotne zmiany w podstawach działania systemu Symbian. Writable Data Paging (WDP) pozwala na dynamiczne zapisywanie pamięci RAM na dysku C co powoduje szybsze działanie wielu aplikacji w trybie wielowątkowym. W praktyce to oznacza że ilość pamięci RAM będzie tylko używana do aktywnej aplikacji Pozostałe aplikacje w tle dynamicznie będą zapisywane na dysku. Przypomina to działanie pliku stronicowania w Windows XP. Przepisano kod Symbiana tak żeby można było wykorzystać wielordzeniową architekturę taką jak ARM Cortex A9 zawierające rozwiązanie typu Symmetric multiprocessor (SMP). Serwer obsługujący system plikowy stał się 64-bitowy co pozwala na obsługę plików większych niż 2 GB.

Dodano nowy silnik Browser Application v7.2 (znany jako WebRuntime 7.2 bazujący na Webkit 528), który zawiera następujące cechy: silnik przeglądarki, możliwość dopasowywania funkcjonalności przeglądarki, możliwość programowania wtyczek, nawigacja dotykiem, dostęp do lokalnej zawartości, dopasowywanie strony WWW do rozmiarów wyświetlacza, Optical Finger Navigation (OFN), obsługa zawartości FlashLite 3.1, integracja z wyszukiwarkami, lepsze komunikaty z zakresu bezpieczeństwa, aktualizacja Platform Service API, wsparcie do wizualnego trybu przełączania się (prawdopodobnie chodzi o to że przełączanie się pomiędzy oknami przeglądarki), lepsza wydajność dzięki JIT i sprzętowej obsłudze grafiki i renderingu strony WWW.

Przystosowano Java Runtime do pracy w Symbianie^3. Oficjalne teraz to nazywa się Mobile Runtime for Java Application. Jest dokument omawiający zmiany jakie zaszły w Java Runtime 2.1 for Symbian (JRT2.1) Główne zmiany to: uruchamianie innych aplikacji i midletów, zaimplementowanie w LCDUI pojedynczego dotknięcia, wsparcie sprzętowe przy wyświetlaniu grafiki, robienie zrzutów ekranu, obsługa schowka, dodanie własnej grafiki wyświetlanej podczas uruchomienia midletu.

Natomiast trochę dziwnie postępują z Pythonem for Symbian. Ustalono, że użytkownik komórki sam zadecyduje o tym czy zechce aktualizować do swojej komórki runtime Pythona. Na razie przeniesiono kod źródłowy do repozytorium fundacji Symbian. Natomiast całe centrum rozwojowe nad Pythonem znajduje się na Garage Maemo. Dopóki nie zrobią PySide pod Symbianem

Dla programistów rozbudowano API o nowe możliwości. Programowanie w Symbianie wymagałobiegłej znajomości makr czy deksyptorów pojawiła się nowa biblioteka której zadaniem jest ułatwienie programistom lepsze zarżadzanie pamięcią - EUser High Level (EUserHL) Library API. Programiści mogą programować w C++ a szczególnie w bibliotekach IOStream i STL (Standard Template Library) oraz Boost co zostało opisane w Standard C++ Library (STLport v5). Do obróbki dokumentów XML programiści maja nowe 2 API: XML DOM Engine and XPath API i jak Libxm2 Library API

W Symbianie^3 domyślnym API do zarządzania trwałością danych w aplikacjach staje się biblioteka SQLite  która pozwala to na tworzenie bardziej wyrafinowanych klientów różnych aplikacji biznesowych dzięki wbudowanej obsłudze języka SQL

Standardy grupy Khronos mają coraz większe znaczenie. Dzięki temu że podsystem grafiki zawsze wymaga wsparcia mobilnych procesorów grafiki GPU to stało się możliwe w pełni zaimplementowanie API jak OpenGl ES 2.0 dla grafiki trójwymiarowej i jak OpenVG dla sprzętowej obsługi grafiki wektorowej a także zaimplementowano interfejs EGL, którego zadaniem jest przejecie od niskopoziomowego API Symbiana programowania sposobu wyświetlania. Na bazie tych standardów stworzono nowy silnik renderujący OpenWF co stanowi wysokopoziomową API dla OpenGL ES, OpenVG i jak EGL. Właściwie dopiero teraz programiści Symbiana dostali jawne API na którym mogą tworzyć własny GUI dla swojej aplikacji a w przyszłości przejść z AVKON na jakiś własny system interfejsu użytkownika. W S60 to też jest możliwe stworzenie nakładki na ten GUI i aplikacje Symbiana mogą inaczej wyglądać, przykładem jest silnik Kastor firmy TAT.

W Symbianie^3 zmienił się wygląd pulpitu użytkownika tzw HomeScreen Rozbudowano nowe API do obsługi interfejsu HomeScreen o: E-mail Widget API (pozwala obsługiwać pocztę z poziomu pulpitu) Extended Content Publisher API (pozwala na publikację zawartości na pulpicie), Home Screen Widget Publisher API (pozwala na zarządzanie widgetami na pulpicie) Location Centre Utility API (pozwala na uruchamianie aplikacji i zarządzanie nimi z poziomu pulpitu).

Pozostawienie frameworka AVKON (S60 GUI) jest podyktowane tym, żeby uruchamiać wszystkie programy, które były pisane pod S60 3rd i S60 5th a programiści mieli jak najmniej pracy z przeniesieniem funkcjonalności "jednego dotyku" w Symbianie^3. Więcej o przystosowaniu kodu ze Symbiana^1 do Symbiana^3 można przeczytać w artykule Modifying applications to support single-tap

To co sprawia że Symbian^3 wyprzedza konkurencję o lata świetlne to obsługa nowych protokołów komunikujących się pomiędzy urządzeniami. Do tej pory efektywny sposób programowania komunikacji pomiędzy urządzeniami w sposób bezprzewodowy opierał się na Bluetooth. Nowe rozwiązania w tym temacie to wykorzystanie NFC i WiFi Direct a do obsługi urządzeń komunikujących się między sobą w Symbianie^3 Zaimplementowano UPnP i Zeroconf. Najciekawsze możliwości maja programiści którzy chcieliby wykorzystać NFC. Zawiera to takie interfejsy programistyczne jak: NFC Discovery API (służy do subskrypcji tagów i wiadomości NDEF), NFC Tag Extension API (dostarcza implementację do obsługi rożnych rodzajów tagów NFC), NDEF API (obsługa wiadomości NDEF w tagach), NFC Peer-to-Peer API (dostarcza obsługę protokołu LLCP do komunikowania się pomiędzy urządzeniami NFC), NFC Content Handler API (komponent ECOM obsługujący wiadomości NDEF).

To co sprawia że programowanie na Symbiana stanie się przyjemniejsze to jest wsparcie do biblioteki Qt. Jest szansa że spora cześć programów pisanych pod Linuxem KDE może zostać przepisana na Symbiana i MeGoo. Właściwie taka "symbioza" pomiędzy tymi systemami operacyjnymi jest bardzo korzystna dla ekosystemu programistów Symbiana. Lekki edytor QtCreator 2.1 prawdopodobnie stanie się najpopularniejszym edytorem C++ wśród programistów Symbiana. Natomiast Carbide.C++ 3.0 bardziej będzie nadawało się do programowania kodu na wszystkie wersje i wykorzystaniem prac nad tworzeniem interfejsu użytkownika w Designerze UI. natomiast kolorystykę i styl aplikacji będzie można przygotować w Carbide UI

Symbian Foundation Symbian^3 PDK to jest wersja Symbiana^3 z kodem źródłowym i z kompletnym wsparciem narzędziowym Największą zmianą jest wdrożenie środowiska do emulacji Symbiana na bazie QEMU tzw: Syborg co pozwala że programy skompilowane pod platformę ARM mogą zostać uruchomione pod platformą Windows.

Całkiem niedawno ukazał się raport Mobile Developer Economics 2010 Jest tam na stronie 12 tabelka w której podano na jakiej platformie programiści preferowali: Symbian preferowało 45% programistów Jave Mobile (J2ME) 50% programistów Mobile Web (i widgety) 40% programistów a FlashLite to 20% programistów W sumie programistów na Symbiana można znaleźć w Azji i w Europie w dużych firmach. Najciekawsze w tym badaniu wyszło że programowanie na Symbiana nie jest takie trudne w porównaniu z innymi platformami.(na stronach 53-54 raportu)

Statystyki Nokii

Ostatnio brałem udział w polemicznych dyskusjach na temat Nokii i Symbiana. Często bardzo dziwiłem się że ludzie nie potrafią dobrze czytać raportów i wyciągają z nich niewłaściwe wnioski. Ponieważ to co się liczy to są fakty dotyczące sprzedaży ilości inteligentnych komórek. Dodatkową informacja może być informacja o lokalizacji sprzedaży.

Spróbujemy popatrzeć na rynek w latach 2007- 2010 wtedy właściwie nas interesuje ilość sprzedanych komórek z Symbianem. Pomimo że tego w raportach nie ma wprost. To da się wyciągnąć dość ciekawe wnioski. Tutaj opublikowałem swoje podsumowanie tych danych

Sytuacja medialna Nokii jest nie do pozazdroszczenia. Potwierdza się informacja o tym że fundusze inwestycyjne Sorosa grają spekulacyjne na akcjach Nokii, Pierwsze informacje o tym że przychody Nokii są poniżej spodziewanych z powodu słabego euro było zamieszczone informacji, że przychody działu Devices Sevices są niższe niż 6,7 mld euro. Szkoda, że nikt nie zrobił analizy jak wygląda sytuacja w poprzednich latach w raportach.  Skoro przychody w ciągu 2009 roku z tego działu były powyżej 6 mld euro to zejście na poziome 5 mld euro w 2Q 2010 zł to naprawdę oznacza tylko, że firma będzie miała mniejsze zyski. Nawet jak okaże się że znowu Nokia sprzedała 20 mln smartfonów w drugim kwartale 2010. To nic nie ma wspólnego z tym że Apple sprzedało w ciągu 3 dni 1,7 mln iPhonów 4. W Ameryce miliony ludzi chce przejść ze zwykłych komórek na inteligentne. Tam łatwiej im kupić komórki z Androidem czy iOS. Popatrzmy jeszcze inaczej. Z moich szacunków wynika w 2 kwartale 2010 że: RIM sprzedał 10 mln, Android miał  15 mln aktywacji a Apple sprzedało 3 mln iPadów i 12 mln iPhonów. Po sprzedaniu takiej dużej ilości to okaże się, że znowu globalnie Nokia najwięcej sprzedaje komórek z Symbianem. Ponieważ komórki z Symbianem stają się coraz tańsze, a co za tym idzie bardziej dostępne niż cała reszta smarfonów za cenę mniejszych zysków.

Trzeba powiedzieć wyraźnie Nokia jest liderem w sprzedaży inteligentnych komórek.
Nokia w ciągu 3 lat sprzedała 200 milionów komórek z Symbianem. W ramach serii N sprzedano 92 miliony egzemplarzy, natomiast w ramach serii E sprzedano 35 miliony egzemplarzy.  Od 2007 roku Nokia wyprodukowała  1444 milionów komórek pod własną marką.

Nawet jak przychody będą nieco mniejsze, a spekulanci grali na akcjach Nokii, a szefowie Apple czy Google mogą chwalić się wielkością sprzedaży, to jednak jest coś dziwnego,

Zauważyłem medialne zjawisko propagandowe, które nazwałbym "wojną o śmierć Symbiana". Jest to objaw reakcji amerykańskich analityków i badaczy rynku którzy z perspektywy amerykańskiego rynku widząc coraz mniejsze udziały w rynku amerykańskim komórek Nokii zaczynają pisać teksty nieprzychylne Nokii i pod adresem systemu operacyjnego Symbian. Bardzo doskonale w to udało się zaangażować emocje milionów ludzi. Spowodowało to że w dyskusjach o komórkach Nokii zaczęły brać pejoratywne emocje. W tej sytuacji gdy rosną oczekiwania użytkowników pojawia się frustracja. W większości przypadków frustracja ta była spowodowana niewiedzą, bądź nie pogodzeniem się z ograniczeniami tych urządzeń. Zauważyłem bardzo częstą sytuację, że bezkrytycznie powiela się pewne schematy myślowe byleby pasowało do tezy, że Symbian i Nokia już nie rozwijają się tak jak ich konkurencja. W takiej sytuacji gdy w obiegu jest pełno nieprawdziwych, bądź niedopowiedzeń powoduje to, że ludzie w takie informacje zaczynają wierzyć a niewiedza robi swoje. Amerykańcy blogerzy w poczuciu bezradności z cała sytuacją medialną zaczynają coraz mocnej krytykować Nokię. Przykładowe teksty z ostatniego miesiąca:
The Mass Exodus of Symbian Bloggers..
Symbian-Guru.com Is Over
An Open Letter to Nokia for 2010
7 Ways Nokia Can Win Again
Nokia, Please Kill Symbian
Nokia N8 to be final Symbian N Series device, all MeeGo from here on out
Nokia and the new age of mobile development
Where is Nokia’s Steve Jobs? Not available, just yet
Nokia Loses Battle for Apps as IPhone, Android Snare Developers
Symbian-Guru is dead, are there any Nokia advocates left?

 W Polsce na blogu pasjonatów technologii SpiderWeb sporo pojawiło się artykułów inspirowanych medialną atmosferą. Ponieważ powielały one poglądy z angielskojęzycznych artykułów zupełnie nie pasujące do specyfiki w Polsce. Często pokazywałem w komentarzach uwagi wskazujące na tendencyjność autorów artykułów. Zapraszam do przeczytania moich komentarzy pod tymi artykułami.

Nokia musi pozbyć się przeszłości
Ovi Store Nokii – czy ktoś to jeszcze pamięta?
Dlaczego Nokia traci programistów?
Alternatywny świat złudzeń Nokii
Adobe wydał Flash Player 10.1 dla komórek, ale zapomnij, że go użyjesz
Szkolne błędy Nokii 
Koniec ery Symbiana. Nokia oddaje rynek smartfonów konkurencji

Stan faktyczny Nokii jest taki, że jako firma ma dochody i jak sprzedaje dużo więcej inteligentnych komórek niż poprzednich latach. Kiedy Apple wyprodukuje 200 mln iPhonów? Kiedy Google osiągnie 200 mln aktywacji Androida? Nokia wyprodukowała przez ostatnie 3 lata 200 mln inteligentnych komórek. Wartość na giełdzie to w dzisiejszych czasach bardziej zależy od dobrego PR i obecności na rynku amerykańskim jeżeli firma jest notowana na giełdzie nowojorskiej.

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.

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).

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.