Flex 2

Ukrycie Symbiana

2010-10-26T01:37:00.003+02:00

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

2010-08-03T16:09:00.000+02:00

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

2010-08-01T14:16:00.000+02:00

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

2010-07-31T00:24:00.000+02:00

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

2010-07-25T16:36:00.001+02:00

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

2010-07-08T13:34:00.000+02:00

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

2010-07-02T02:22:00.006+02:00

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.

2010-04-20T19:30:00.006+02:00

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

2010-04-08T22:17:00.005+02:00

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

2010-04-05T23:15:00.007+02:00

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.

Programowanie ActionScript 3 na Symbiana

2010-04-04T10:54:00.003+02:00

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

Ewolucja WebRuntime i FlashLite

2010-03-22T12:36:00.004+01:00

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:

Zobacz więcej prezentacji z konferencji Forum Nokia Developer Conference 2010.

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.

Symbian Silverlight beta

2010-03-17T19:07:00.004+01:00

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 5^th 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ę

APIBridge i Nokia Platform Service 2.0

2010-03-16T12:49:00.005+01:00

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.

Wild Duck - otwarty telefon Symbiana

2010-02-10T14:56:00.006+01:00

Otwarcie kodu źródłowego Symbiana pozwala iść dalej w stronę rozwoju sprzętu dla kogoś kto chciałby mieć własny telefon, czy jakieś urządzenia oparte na tym systemie operacyjnym. Jeszcze nie wypuszczono Start Kita niskobudżetowego tak żeby można było sobie zrobić "własny" inteligentny telefon, który pozwoliłby uruchomić Symbiana i nauczyć się tworzenia oprogramowania wykorzystującego możliwości sprzętowe nowych urządzeń.

Obecnie do prac rozwojowych nad Symbianem^4 używa się układów Zoom OMAP34x-II MDP (Mobile Development Platform) To cudo jest bardzo drogie $1150 - z powodów, że to jest limitowana seria, która pozwala też uruchomić inne systemy operacyjne w tym Androida czy eLinuxa.

Zawsze szuka się tańszych rozwiązań. Wybór padł na BeagleBoards.org, gdzie zakup prostego układu scalonego kosztuje $149.

Warto obejrzeć filmik przedstawiający przygotowanie do pracy z Symbianem

Warto poczytać o tym jak przygotować Symbiana do pracy z tym układem.
Z okazji otwarcia kodu Symbiana^3 okazało się, że potrzebny będzie bardziej zaawansowany układ. Tak powstała koncepcja zrobienia nowego Starter Kitu pod nazwą kodową "Wild Duck" dla kogoś kto by chciał zobaczyć Symbiana^3 w działaniu i rozwijać w stronę Symbiana^4.

Wystarczy zainwestować w:
- płytkę Beagle Board - $146
- rozszerzenie Ethernet i portem dla kart MMC/SD dla płytki Beagle Boards - $79
- UC864-G Modem and S3 Starter Kit to modem UMTS/GMS z GPS i układ scalony który można podłączyć do płytki. Koszt modemu to 146 Euro (około $200) a sam starter kit kosztuje 409 Euro (około $576) chociaż jest tańsza wersja starter kita S3 za 329 Euro, ale nie wiem którą wybrano do tworzenia Wild Ducka
- Flyswatter JTAG do debugowania a kosztuje to $50
- zasilacz za $7
- przełączniki do Beagle Board za $19
- mikrofon i słuchawki do modemu
- monitor DVI łączący się za pomocą HDMI

Wyszło mi że koszt dla "Wild Duck" bez Starter Kita dla modemu to kosztuje prawie $500 a z Starter Kitem dla modemu kosztuje $1068. A do tego trzeba jeszcze dołączyć koszt przesyłki i podatki. To jest jeszcze trochę za drogie dla hobbystów.

Symbian S60. Programowanie urządzeń mobilnych

2009-12-29T19:38:00.012+01:00

Kupiłem książkę Pawła Gali o Symbianie wydaną przez wydawnictwo Helion. Z dużym zapałem zacząłem ją czytać. Podczas czytania zauważyłem, że styl pisania zaczynał być bardzo akademicki, co zmuszało mnie do przerywania lektury, żeby zastanowić się o co chodziło autorowi. Z wielkim trudem dobrnąłem do końca książki. I mam duże wątpliwości, co do tego kto ją powinien kupować i czytać. Pierwsze skojarzenie to studenci, którzy będą uczyć się programować na Symbiana. Oni są na dobrej drodze żeby kupić tą książkę i razem z wykładowcą na ćwiczeniach przerabiać wiedzę z tej książki. Druga grupa czytelników to ci, którzy już programują na Symbiana. Im bardzo polecam tą książkę ze względu żeby mogli uporządkować sobie wiedzę na temat programowania na Symbiana. Natomiast odradzam kupowanie tej książki ludziom, którzy wcześniej nie programowali na Symbiana, ponieważ w tej książce jest zawarta wiedza teoretyczna, bez praktycznie działających przykładów (czyli przygotowanych projektów z kodem do skompilowania). Są natomiast listingi, które tak naprawdę służą do pokazania jakiejś teoretycznej podstawy w kodzie. To już zmusza czytelnika do dużego wysiłku intelektualnego, żeby sprawdzić tą teorię w praktyce.

Z pierwszego rozdziału czytelnik dowie się o systemie operacyjnym Symbian i o jego budowie i zrozumie dlaczego jest to jeden z najbardziej restrykcyjnych systemów operacyjnych i jednocześnie bardzo trudnym w zrozumieniu. Istotne jest zrozumienie architektury EKA2. Z drugiego rozdziału można dowiedzieć się że jak trzeba przegotować warsztat programisty. Autor poleca żeby użytkownik instalował SDK S60 3rd FP2 i Carbide.C++. Właściwie to już trochę nie trafiony wybór, bo ja bym zaproponował instalowanie ADT ze stron Fundacji Symbian. Zmartwiło mnie, że to tylko wspomniał o Designerze UI twierdząc, że nie poleca używania tego kreatora bez znajomości teorii o programowaniu. Dzisiaj większość ludzi zaczyna naukę programowania właśnie od takich kreatorów. Zrozumiale jest to, że bez teorii nie ma sensu uczyć programowania, ale przecież można było krok po kroku pokazać gdzie wstawiać odpowiednie fragmentów kodów z listingów. Autor od razu przedstawia w rozdziale 3 architekturę GUI czyli framework AVKON. Podczas tej lektury zauważyłem że celem autora przedstawienie wiedzy niż pomóc czytelnikowi w zrozumieniu jej. Potem spróbowałem wykorzystać listingi do zbudowania sobie aplikacji. Nie udało się, bo listingi nie zawierały wszystkiego co było potrzebne do zbudowania tej aplikacji. Następnie wygenerowałem sobie projekt z Carbide, oraz zacząłem badać jakie są różnice z tym kodem autora, a tym z kreatora. Sęk w tym, że raz autor pisze o standardowym kodzie tj takim który nie uwzględnia wersji językowych, a potem nagle pisze o tworzeniu wersji językowych. Można było się pogubić w lekturze, pomimo że merytorycznie treść jest w porządku. Skończyło się na tym, że zrobiłem 2 wersje raz tylko z wersją angielską a raz z wersją polską. Tylko, że wersja polska nie poprawnie wyświetlała znaki polskie. Poszukałem na Forum Nokia rozwiązania problemu. Wymagało to podania makra CHARACTER_SET UTF8 w pliku lokalizacyjnym. Zadowolony, że uporałem się z problematycznym rozdziałem zacząłem czytać rozdział 4 o platformie bezpieczeństwa. Rozdział ten dość dokładnie omawia o uprawnieniach aplikacji i podpisywaniu aplikacji na Symbiana. Także bardzo dobrze omówił procedurę certyfikacji i sposób uzyskiwania identyfikatorów dla aplikacji w Symbian Signed. Według mnie to najlepiej napisany rozdział w całej książce. Tak zadowolony przeszedłem do czytania 5 rozdziału o emulatorze Symbiana. Jakoś nie darzę szczególną estymą ten emulator z tego powodu, że jest bardzo powolny i trzeba mieć dużo cierpliwości do niego. To co mnie zainteresowało to wykorzystanie narzędzi do diagnostyki czyli zainstalowania ecmtagent_cpp.sis i monitorowanie aktywności aplikacji w komórce z poziomu panelu diagnostycznego Carbide. Wcześniej w tym celu korzystałem tylko z AppTRK. Zawsze można coś dla siebie odkryć ciekawego. Od rozdziału 6 rozpoczyna się wykład o niuansach programowania w Symbianie. Jedyne co mogę uznać za plus to, że autor ustala terminologię w języku polskim dla programistów Symbiana. Rozdział 6 dotyczy konwencji nazewniczych. Tutaj miałem problem z szybkim załapaniem co powoduje ze dana klasa jest na stercie lub na stosie. Czy jest jakiś wyznacznik w kodzie co pozwala na rozróżnienie tego czy daną klasę należy nazwać z przyrostkiem C albo T? Jakoś to rozumiem, ale jeszcze brakuje mi wprawy w tym. Rudział 7 dotyczy obsługi wyjątków w Symbianie. Po prostu podczas tworzenia Symbiana trzeba było wymyślić jakiś sposób obsługi różnych problematycznych sytuacji. W tej sytuacji wymyślono cały unikalny mechanizm oparty na wyjściach, podwójnym konstruktorze, panikach, oraz stosu czyszczącego. Najcenniejszą informację dla mnie była informacja o pliku ErrRd, dzięki któremu programista czy użytkownik może dowiedzieć się o tym jaka panika wystąpiła. Rozdział 8 dotyczy używania deskryptorów. Deskryptory są po to żeby umieć zarządzać danymi w Symbianie. Zarówno tymi tekstowymi i jak binarnym. Szczerze mówiąc zawsze miałem problemy ze zrozumieniem dobrze deskryptorów. Po przeczytaniu tego rozdziału mam jeszcze większy mętlik w głowie - głownie dlatego, że trzeba będzie do każdego listingu zrobić wersję programu który pokazywałby to w działaniu. A tego jest bardzo dużo do przyswojenia i nie da się tego od razu zrozumieć. Czytając te listingi przyszła mi myśl, że skoro takich rzeczy w nauce C++ wystarczy zwykła aplikacja konsolowa to w tym przypadku też można byłoby sobie napisać aplikacje konsolowe i sprawdzać to w trybie debugowania na komórce. Myślę że bardzo to ułatwiłoby naukę. Zrobiłem przerwę w lekturze, czasami polecam przerwanie lektury książki jak okaże się za trudna i wrócić do niej po jakimś czasie. Rozdział 9 traktuje o tablicach dynamicznych. Ten rozdział koncentruje się na klasach typu CArray, o tym że niektóre klasy mają zdolność do wyszukiwania elementów, sortowania. To co mnie zainteresowało to mechanizmy zarządzania pamięcią. Będę musiał przemyśleć jeszcze raz ten rozdział przerabiając do każdego przypadku klasy odpowiedni przykład. to co wyróżnia Symbian od innych systemów operacyjnych to koncepcja aktywnych obiektów. To można potraktować jako pewnego rodzaju AJAX w aplikacji. Kod w aplikacji może zostać wykonany synchronicznie czy w wg odpowiedniej kolejności a także asynchronicznie czyli równolegle. Asynchroniczność zakłada istnienie stanów aplikacji co za tym idzie określanie informacjo o zdarzeniach. Każda klasę która ma być wykonywana w sposób asynchroniczny musi dziedziczyć od klasy CActive i być uruchamiana przez obiekt klasy CActiveScheduler, którzy często jest zwany Zarządcą Aktywności. Ma to sens bo sporo aplikacji na Symbiana, może działać w tle, co tez sprzyja pisaniu aplikacji, które mogą działać długi czas. To jednak trzeba kilka razy czytać ten rozdział. Pomyślałem, że warto by przeczytać cała książkę jeszcze raz pod katem panik różnego rodzaju oraz specjalne napisać takie kody źródłowe które by pokazywały wywołanie określonej paniki a to tak żeby wiedzieć czego unikać. Każdy system operacyjny który ma być wielozadaniowy ma w sobie wątki i procesy o czym omawia rozdział 11 W Symbianie można powiedzieć w dużym uproszczeniu, że proces to załadowana biblioteka bądź uruchomiona aplikacja w której działają różne wątki które wykonują różne zadania. To jak zostaną zadania wykonane zależy też od ustawionych priorytetów. Przynajmniej dzięki tej lekturze lepiej zrozumiałem mechanizmy synchronizacji od strony teoretycznej o semaforach, muteksach i sekcjach krytycznych oraz o klasie Rendezvous. Ponieważ nie miałem okazji do zastanawiania się nad takimi subtelnościami, to w większości ten temat będzie wymagał ode mnie kilkakrotnej lektury. Zauważyłem, że bardzo przyda się zastosowanie klasy RUndertaker w celach diagnostycznych do śledzenia działania wątków w aplikacji. Jak czytam od kilku dni tą książkę to tym coraz bardziej czuję bardzo skomplikowane mechanizmy, których nie da się zrozumieć bez eksperymentowania na listingach i czytania dokumentacji o samym systemie Symbian. Z taką raczej obawą, że nie zrozumiem wszystkiego do końca postanowiłem zrobić przerwę w lekturze. Gdy wróciłem do lektury to uświadomiłem sobie, że autor musiał zrobić pewnego rodzaju kompromis pomiędzy tym żeby w sposób treściwie przedstawić materiał a tym co jest dydaktyką. Kierując z lekturą w stronę bardzo świadomego i samodzielnego czytelnika aspirującego do poziomu wiedzy autora powoduje bardzo zawężenie grupy ludzi, którym ta książka może się przydać. Ja jako czytelnik zacząłem czytać o architekturze klient-serwer i odkryłem fakt, że prawie wszystko w systemie Symbian działa w architekturze klient - serwer. Prawie całą komunikacja w tym systemie od środka polega na tworzeniu sesji i podsesji. Bardzo trafna analogia, że sesja z podsesjami to taki kabel wielożyłowy. Podstawowa klasą odpowiedzialną za tworzenie sesji jest klasa RSessionBase, a za obsługę podsesji odpowiada klasa RSubSessionBase, natomiast serwer i jak klient tworzą instancje obiektów klasy CSession2 aby przesyłać wzajemnie komunikaty, które są obiektami klas TIpcArgs (po stronie klienta) lub RMessage2 (po stronie serwera). Tworząc serwer bazujemy na klasie CServer2. Zauważyłem, że te mechanizmy związane z uprawnianiami i z polityką bezpieczeństwa w tej architekturze mają kluczowa rolę. Po dość długim wprowadzeniu autor zaprezentował to na teoretycznym przykładzie serwera usług kryptograficznych. Znowu autor liczy na samodzielność czytelnika, że sam sprawdzi kod z listingów i przerobi to w kod projektu, a potem sam zaimplementuje klienta. Pomyślałem, że raczej lepiej to zaimplementować w postaci biblioteki dll niż uruchamianego serwera EXE. Ponieważ tworzenie bibliotek dll jest omówione na końcu książki to do tego przykładu warto powracać. Najbardziej zagadkowy okazał się rozdział o właściwościach i repozytoriach. Można przeczytać w nim jak Symbian przechowuje dane globalne o stanach różnych funkcji w komórce. Zaletą właściwości jest to że aplikacja która je zaimplementuje może je rozgłaszać ale już inny program w dowolnym momencie może odebrać tą informację. W architekturze serwer klient obydwie strony wiedzą o sobie nawzajem. Natomiast program który wykorzystuje klasę RProperty nie musi nic wiedzieć o tych klasach które wykorzystują te dane. Repozytoria to już taka specjalna biblioteka która stale przechowuje informacje nawet po restarcie komórki. Dostęp jest możliwy za pomocą obiektów klasy CRepository. W praktyce możliwy jest dostęp do repozytoriów systemowych takie jak stan sieci, profile użytkownika (czyli dostęp do ustawień użytkownika). Tak naprawdę lekturę książki rozpocząłem od rozdziału 14, w którym analizowałem kod z listingów jak tworzyć aplikację wielookienkową. Trochę to różni się od tego co potrafi zrobić kod za pomocą Designera UI z Carbide C++. Jak zwykle autor wymaga od użytkownika zaangażowania, żeby przerobił i uzupełnił kod z listingów w projekt do kompilacji. Czytając na przykład stronę 418 o klasach widoków mam wrażenie, że można pogubić się w tym jak napisać kod brakującej w listingach klasy. Zresztą za pierwszym razem mi nie wyszło. To co mnie zainteresowało też bardzo to aplikacje bez interfejsu użytkownika. I znowu skupiłem swoja uwagę na aplikacji konsolowej. Ten przykład co podał autor jest asynchroniczny co mnie zaskoczyło, że nie mogłem zamknąć tej konsoli w odróżnieniu od aplikacji konsolowej generowanej przez Carbide C++. Największe zdziwienie wywołał u mnie skrypt instalacyjny dla komórki z wyłączoną platformą bezpieczeństwa tak żeby mieć dostęp do plików w folderze !:sys/bin w celu uruchomienia. Potem częściowo to wyjaśniło się jak zacząłem czytać o tworzeniu plików zasobów dla aplikacji, która ma sama się uruchomić. Wyszło na to że aplikacja ma uruchomić się podczas startu systemu. Stosowanie globalnych okien dialogowych nie wymaga przygotowywania specjalnie plików zasobów w interfejsie UI S60 co sprawia że łatwo jest nimi zarządzać z poziomu kodu. Kod z listingów należy przerobić tak żeby działało w aplikacji HelloWorld z trzeciego rozdziału książki albo samodzielnie wstawić do kodu aplikacji GUI wygenerowanej przez Carbide. Autor omawia 5 klas okien dialogowych. Klasa CAknGlobalConfirmationQuery służy do wyświetlania okna dialogowego wyboru logicznego. Klasa CAknGlobalListQuery służy do wyświetlania listy wyboru. Klasa CAknGlobalMsgQuery może wyświetlić długi komunikat bo zawiera pasek przewijania. Klasa CAknGlobalNote wyświetla krótkie komunikaty z odpowiednią kategorią ikon, Natomiast klasa CAknGlobalProgressDialog pokazuje pasek postępu. Aczkolwiek trudno wymyślić sensowną aplikację bazującą na tym to jednak bardzo mogą się przydać przy wyświetlaniu komunikatów wysyłanych przez biblioteki dll, bądź przez aplikacje działające w tle. Najbardziej praktyczny rozdział z tej książki to rozdział o tworzeniu bibliotek dll. Tak naprawdę tworzenie bibliotek dll jest podstawą programowania na Symbianie, do takiego wniosku doszedłem podczas lektury tej całej książki. Są 2 rodzaje bibliotek ładowane statycznie i ładowane dynamicznie. W większości przypadków ładowanie statycznie jest najlepszym rozwiązaniem, ponieważ działa razem z aplikacją. Brak biblioteki powoduje, że aplikacja nie uruchomi się. Przykładem biblioteki statycznej jest Qt. Natomiast gdy istotna jest szybkość i wydajność to warto pomyśleć nad ładowaniem biblioteki polimorficznej do pamięci RAM. Bardzo ciekawie autor pokazał na listingach sposoby tworzenia takich bibliotek i kompilowania tego z linii poleceń. W listingach można zauważyć, że tak naprawdę programowanie na Symbiana w C++ wymaga znajomości wielu makr które w pewien sposób tworzą jakby nakładkę na język C++. Ostatni rozdział opisuje stosowanie podstawowych makr. Właściwie odebrałem wrażenie, że Ci którzy znają się na programowaniu w C++ mogliby rozpocząć od lektury tego rozdziału. Makra _DEBUG wskazują kompilatorowi że ten fragment kodu ma zostać skompilowany dla wersji debugującej. Makro EKA2 ma sens jak tworzy się wersje dla starszych wersji Symbiana. Bardzo użyteczne są __FUNCTION__ czy G_STRLOC makra które służą informowaniu o działaniu programu. Inne użyteczne makra to makra zapobiegające wyciekom pamięci, do których należy grupa makr rozpoczynających się od __UHEAP. Dobrze napisany kod na Symbiana to kod z makrami asercji. Makra które rozpoczynają się od __ASSERT pozawalają już na poziomie kodu sprawdzać wykonanie pewnych założeń i w razie czego wywołać panikę. Obecnie tą rolę zaczynają spełniać testy jednostkowe, które nie są częścią API Symbiana.

QML i Declarative UI

2009-12-22T12:07:00.002+01:00

Tworzenie interesów użytkownika to bardzo trudne zadanie, szczególnie jak tworzy się tak jak strony internetowe. Zazwyczaj tworzy się jakiś framework UI i kompiluje się do jakiejś postaci binarnej. Na przykład piszesz kod w ActionScript 3, ale do opisu UI używasz składni MXML a skompiluje się to do postaci binarnego SWF . Piszesz kod interfejsu w XAML ale i tak efektem końcowym kompilacji jest plik wykonywalny.
Tworzenie interfejsu strony internetowej polega na pisaniu odpowiednich skryptów JavaScript i kodów CSS oraz HTML. Zaletą takiego podejścia jest to że można dynamicznie zmieniać zawartość interfejsu. Czy przeniesienie takiego mechanizmu do tworzenia aplikacji komputerowych i na komórki pozwoli na szybsze tworzenie efektywnego interfejsu użytkownika?

Jak można zauważyć duża popularność języków opisów deklaratywnego pozwoliło na oddzielenie prac nad wyglądem aplikacji od jej logiki. XAML czy MXML są językami deklaratywnymi które są potem przekształcane w odpowiedni kod do kompilacji. Natomiast próbą przeniesienia mechanizmu obsługi interfejsu aplikacji tak jak działa strona internetowa czy poprzez parsowanie i kompilację kodu skryptowego dzięki mechanizmowi JIT. Od dłuższego czasu Qt Nokia pracuje nad Qt Declarative UI. Jest to biblioteka która pozwala przy pomocy języka deklarytywnego QML bazującego na CSS3 i skryptów JavaScript budować layout aplikacji.

Ściągamy ftp://ftp.trolltech.com/qml/qt-4.6.0-declarative.zip
Wypakowujemy to w e:\qt-4.6.0-declarative
Otwieraramy QtCreatora 4.6 i importujemy plik declarative.pro następnie go otwieramy i na koncu kodu dodajemy

*-g++*: CONFIG += create_prl

Potem otwieram camand prompt który ustawia MinGW
wchodzę na e:\qt-4.6.0-declarative\src\declarative
i generuję pliki makefile

qmake

następnie generuje binaria dla wersji release i debug

mingw32-make all

pozostaje potem jeszcze przegranie plików

mingw32-make install kopiuje tylko wersję debug

E:\qt-4.6.0-declarative\src\declarative\.obj\QtDeclaratived4.dll
do E:\qt-everywhere-opensource-src-4.6.0\bin\QtDeclaratived4.dll
E:\qt-4.6.0-declarative\src\declarative\.obj\libQtDeclaratived4.a
do E:\qt-everywhere-opensource-src-4.6.0\lib\libQtDeclaratived.a

a także sami skopiujemy wersję release
E:\qt-4.6.0-declarative\src\declarative\.obj\QtDeclarative4.dll
do E:\qt-everywhere-opensource-src-4.6.0\bin\QtDeclarative4.dll
E:\qt-4.6.0-declarative\src\declarative\.obj\libQtDeclarative4.a
do E:\qt-everywhere-opensource-src-4.6.0\lib\libQtDeclarative.a
E:\qt-4.6.0-declarative\src\declarative\.obj\QtDeclarative.prl
do E:\qt-everywhere-opensource-src-4.6.0\lib\QtDeclarative.prl
E:\qt-4.6.0-declarative\src\declarative\.obj\QtDeclaratived.prl
do E:\qt-everywhere-opensource-src-4.6.0\lib\QtDeclaratived.prl

Na koniec potrzebne jest przekazanie plików nagłówkowych. Zaznaczamy poniższy kod i wklejamy do w oknie konsoli.

xcopy /E /Y ..\..\include\QtDeclarative %QTDIR%\include\QtDeclarative

Następnym krokiem będzie skompilowanie narzędzia interpertacji kodu QML czyli pliku qmlviewer.exe

W okno konsoli wpisujemy

cd ..\..\tools\qmlviewer

następnie

qmake

a potem w celu wygenerowania pliku qmlviewer.exe wpisujemy

mingw32-make release

Następnie kopiujemy plik E:\qt-4.6.0-declarative\bin\qmlviewer.exe tam gdzie mamy plik QtDeclarative4.dll czyli do E:\qt-everywhere-opensource-src-4.6.0\bin\qmlviewer.exe

Potem możemy otworzyć nowy projekt QML w QtCreatorze kliknąc w zakładkę Projekt oraz wskazać ścieżkę dla qmlviewer.exe czyli E:\qt-everywhere-opensource-src-4.6.0\bin\qmlviewer.exe

Mając już przygotowane Declarative zainstalowane API
warto przejrzeć przykłady z
E:\qt-4.6.0-declarative\examples\declarative

Jedyne wprowadzenie do Declarative UI to strona
oraz dokumentacja
Wygląda na to że w przyszłości będziemy tworzyć aplikacje QML na komórki z Symbianem
co widać na przykładzie kodów New Qt APIs Technology Preview 2 - Mobility Project
(instrukcja do tego jak to zainstalować jest na wiki i na forum)

Kiedy Ci ludzie odpoczną? Ciekawy jestem czy uda mi się skompilować qmlviewer w XM 5800.

Polskie środowisko programistów Symbiana

2009-12-10T14:07:00.023+01:00

Rola Symbiana jako platformy programistycznej w Polsce została zauważona już dość dawno. Niektóre polskie firmy współpracują z Symbianem od samego początku.

Programowanie w systemie operacyjnym Symbian często jest traktowane jako coś bardzo elitarnego, co powodowało że lepiej było zrobić otoczkę tajemniczości ze względu na liczne umowy NDA czy zakazu pracy w konkurencji. Pośrednio powoduje to, że dotarcie do osób zajmujących się programowaniem na Symbiana nie jest takie łatwe. Odtąd kiedy pojawiły się portale społecznościowe to część programistów pozakładała sobie profile zawodowe. Pozwoliło prześledzić kariery tych ludzi. Najciekawsze będzie to w jakich firmach pracują. Daje to dość interesujący obraz tego jak szybko rozwija się społeczność Symbiana w Polsce.

Comarch w Krakowie i w Łodzi ma dział zajmujący się rozwijaniem technologi mobilnych na Symbiana. Bardzo aktywnie włącza się w prace rozwojowe badawcze nad rozwojem Symbiana. Silne inwestuje w edukację uniwersytecką czego przykładem jest inwestowanie w pracowników i w studentów. Warto zobaczyć kod źródłowy projektu 2 gier autorstwa Jerzy Chałupskiego i Pawła Piotrowicza. Bardzo często realizują odpowiednie zadania z zakresu programowania na Symbiana dla Nokii w metodyce Scrum. Pracownicy Comarchu, którzy mają dobre doświadczenie z programowaniem na Symbiana: Krzysztof Sołtysik (ASD), Krystian Jasiński (ASD), Maciej Sufa (ASD), Michał Czerwiec (ASD), Dominik Frankowski, Piotr Mądry, Grzegorz Gustof (ASD), Adrian Cichoń, Łukasz Sromek, Przemyslaw Jacak , Marcin Szymański, Grzegorz Wąchocki (ASD), Jerzy Suzanowicz

Psiloc to firma, która specjalizuje się od bardzo długiego czasu w tworzeniu oprogramowania na Symbiana. Program który jest wizytówką tej firmy to WorldTraveler. Programiści w tej firmie programują na Symbiana od samego początku tej platformy: Maciej Gawroński, Sławomir Baranowski, Jarosław Pelczar, Tomasz Polański, Maciej Kujałowicz.

Mobica to brytyjska firma, która ma 2 oddziały w Polsce: w Warszawie i w Łodzi. Wyspecjalizowała się w konsultacjach dla rynku telekomunikacyjnego na różne platformy programistyczne z preferencją programowania na Symbiana. Ludzie, którzy znają się na programowaniu na Symbiana to: Rafał Jańczyk, Grzegorz Kapusta Joanna Zolopa, Paweł Jankowski.

eLeader to lubelska firma wyspecjalizowana w tworzeniu oprogramowania biznesowego na Symbiana. Głównym ich priorytetem jest tworzenie oprogramowania dla bankowości mobilnej. Osoby które znają się na programowaniu na Symbiana to: Tomasz Włodzimierz Smutek i Karol Pawlik.

Fancyfon kolejna brytyjska firma która ma centrum rozwojowe badawcze w Otominie pod Gdańskiem. Mają też kilka produktów na Symbiana. Według mnie najciekawszy jest produkt MoDo czyli system pozwalający na pracę dziennikarzy w terenie za pomocą komórki. Jednak osobą odpowiedzialną za rozwój produktów opartych na Symbianie jest Bartosz Leoszewski.

Tieto międzynarodowy koncern IT działający głównie w technologiach programistycznych na urządzenia mobilne. Intensywnie rozwijają outsourcing na rzecz wielu firm. W Polsce mają swoje siedziby w Szczecinie i we Wrocławiu. Główni programiści od Symbiana w tej firmie to Piotr Staniszewski (ASD), Dariusz Rosołek (ASD), Piotr Orzechowski (ASD), Piotr Żabiński

BLStream ma siedzibę w Szczecinie i studio w Bydgoszczy oraz placówki we Wrocławiu i w Warszawie. Firma bardziej wyspecjalizowała się w tworzeniu prototypów na Symbiana i na inne platformy mobilne. Najbardziej znany opensourcowy projekt tej firmy to Open Video Hub Za kod źródłowy tego projektu odpowiada Sebastian Jędruszkiewicz Pracownicy którzy znają się na programowaniu na Symbiana to: Tomasz Dubik, Piotr Szmyt, Konrad Słowiński (ASD), Magdalena Mostek , Paweł Gala (ASD), Rafał Kocisz.

Teleca - szwedzka firma mająca oddział w Polsce w Łodzi. Głownie specjalizują się w pisaniu niskopoziomowych rozwiązań dla Symbiana, czyli głównie tutaj chodzi o przeprogramowanie systemu Symbian pod kątem określonych mikroprocesorów i układów scalonych. Większość programistów prowadzi też badania na poziomie akademickim: Piotr Gawroński, Bartłomiej Świercz (ASD), Oskar Kamiński (ASD), Maurycy Mikos.

Opera we Wrocławiu i w Warszawie tworzy wersję mobilną Opera Mobile. W Polsce z programistów Symbiana biorą przy tym udział m.in. Maciej Kasprzyk, Michał Zajączkowski, Łukasz Lipski, Damian Trelka

Programiści Symbiana są też potrzebni w centrach badawczo rozwojowych przy wdrażaniu nowych zastosowań telekomunikacyjnych u producentów urządzeń. W warszawskim Samsung Electronics Polska Sp. z o.o. pracuje m.in Michał Lipiński (ASD). Dla Motorola Polska Electronics Sp. z o. o. pracuje Piotr Dziewoński. Natomiast w Nokia Siemens Networks programowaniem na Symbiana znają się Justyna Żmuda i Bartłomiej Prędki .

Cybercom to firma, która ma oddziały w Warszawie i w Łodzi specjalizuje się w realizowaniu zadań dla firm telekomunikacyjnych dostarczając im rozwiązania z zakresu wykorzystania infrastruktury internetowej dla komórek z Symbianem. Pracownicy, którzy programują pod Symbianem to: Marek Bartosik (ASD), Konrad Marek Zapalowicz (ASD), Tomasz Kuczera, Robert Kowalski (ASD), Sławomir Firlej.

SMT Software to wrocławska firma która ma w swojej ofercie tworzenie oprogramowania mobilnego dla zarządzania flotą transportową i oprogramowaniem logistycznym. W tej firmie głównymi specjalistami od Symbiana są Jacek Munko, Roman Ludwicki Radosław Puścian, Tomasz Hołodniak.

Polidea to mała warszawska firma z duzym potencjałem rozwojowym dla technologii mobilnych, aktywnie intensywnie rozwijają cross-platform technologii mobilnych. Twórcy tej firmy mieli okazję programować na Symbiana: Jakub Lipiński i Piotr Wach. Przykładem ich współpracy jest kod źródłowy biblioteki s60-json-library.

W GG Network S.A. gdzie za rozwój mobilnej wersji Gadu-Gadu na Symbiana odpowiada Alexey Shabalovskiy

Od całkiem niedawna na studiach w Polsce na niektórych uczelniach można już poważnie postudiować programowanie na Symbiana duża zasługa tutaj Comarchu, który inwestuje w program edukacyjny na AGH od 2007 roku. Przykładowy plan zajęć z 2008 roku.Obecnie zajęcia prowadzi Jacek Danda. Natomiast za praktyki studenckie dla programistów Symbiana w Comarchu odpowiada Grzegorz Wąchocki. W 2009 roku rozpoczęły się intensywne prace nad stworzeniem platformy edukacyjnej MoTeCo do edukacji nad programowaniem Symbiana w ramach europejskiego programu Leonardo da Vinci.

Teleca też współpracuje z politechniką Łódzką tworząc projekt edukacyjny od 2008 roku zwany Akademią Symbiana. Jest to program studiów podyplomowych na których też przygotowuje się do egzaminów ASD. Warto zatrzymać się na tym programie prowadzonym przez Bartłomieja Świercza.

W Warszawie powstała raczej oddolną inicjatywa zwana Akademią Inżyniera "Szlif" ponieważ ma być coraz większe zainteresowanie tworzeniem aplikacji na urządzenia mobilne nie tylko na Symbiana ale i też na inne platformy programistyczne dla urządzeń mobilnych.

W Szczecinie firma BLStream podpisała umowę z Zachodniopomorskim Uniwersytetem Technologicznym o współpracy. Pozwoli to na lepsze kształcenie studentów w programowaniu na Symbiana.

Warto też zwrócić uwagę na inicjatywę Rafała Kocisza, który na łamach czasopisma Software Developer`s Journal napisał cykl artykułów o programowaniu na Symbiana pod tytułem "Programowanie gier dla Symbian OS" (Szkielet aplikacji w 09/08, Budujemy grę w 11/08, Rozwijamy grę w 12/08, Efekty specjalne w 1/09) Problem w tym, że nie można dostać się do listingów powiązanych z tymi artykułami.

16 grudnia 2009 wydawnictwo Helion wydało pozycję Symbian S60. Programowanie urządzeń mobilnych autorstwa Pawła Gali. Książka też ma kod źródłowy.

Debugowanie aplikacji Symbiana w komórce.

2009-12-07T23:09:00.005+01:00

Bardzo ważną cechą w pracy programisty jest umiejętność używania debugera, tak żeby można było na bieżąco sprawdzać działanie programu. W środowisku Carbide.C++ można sprawdzać działanie programu na 2 sposoby: w emulatorze i na komórce. Najbardziej polecam sprawdzanie działanie programu bezpośrednio w komórce podczas gdy Carbide.C++ będzie informować o procesie debugowania.

Najpierw trzeba w swojej komórce zainstalować program App TRK którzy będzie przesyłał informacje do Carbide.C++ . Trzeba zwrócić uwagę na to, żeby pobrać wersję która będzie zgodna z komórką którą będziemy debugować aplikację. Na przykład dla 5800 XM pobieramy s60_5_0_app_trk_3_1_2.sisx.

Instalujemy App TRK w komórce (najczęściej za pomocą Nokia PC Suite). Komórka ma być połaczona kablem USB. Uruchamiamy App TRK w komórce. Wybieramy lewym softem menu Opcje -> Setting. Pojawi się wybór Connect to ustawiamy na USB. Komórka jest podłączona kablem USB to z Opcje wybieramy Connect. Pojawi się na wyświetlaczu komunikat Status Connected Connection:USB.

Uruchamiamy Carbide C++. Importujemy projekt E:\S60\devices\S60_5th_Edition_SDK_v1.0\S60CppExamples\helloworldbasic
Podczas wyboru SDK wybieramy Phone Debug (GCCE) [S60_5th_Edition_SDK_v1.0]. Po zaiportowaniu widzimy że mamy aktywny projekt Z menu Carbide.C++ wybieramy Project -> Properties. Pojawi się okno Properties for helloworldbasic. Z węzła Carbide.C++ wybieramy Build Configurations. Widzimy aktywną konfigurację na Phone Debug (GCCE) [S60_5th_Edition_SDK_v1.0]. W zakładce "SIS Builder" klikamy w Add. Pojawi się okno SIS Propories Z PKG File wybieramy sis\helloworldbasic_gcce.pkg. Upewniamy się że mamy zaznaczone Self sign sis file Klikamy w OK. Potem w przycisk Apply a następnie w OK. Więc już projekt mamy przygotowany do kompilacji.
Zanim weźmiemy się do kompilacji trzeba będzie zmienić w pliku sis\helloworldbasic_gcce.pkg
..\..\..\epoc32\release\gcce\urel\HelloWorldBasic.exe na ..\..\..\epoc32\release\gcce\udeb\HelloWorldBasic.exe
Zresztą pliki z SDK i tak muszą wymagać odpowiedniego przygotowania skryptów do instalacji. Po prostu trzeba wskazać gdzie kompilator umieścił wersję debugowaną.

Kompilację wykonuje się prosto. Z menu Carbide wybieram Project -> Build Project. Obserwujemy w oknie konsoli (Window -> Show View -> Console) komunikaty podczas kompilacji.

Następnie otwieramy plik src/helloworldbasicappui.cpp i przy linii 140 dla kodu
case EHelloWorldBasicCommand1:
stawiamy czujkę

Następnie z menu Run -> Debug As -> Debug Symbian OS Application. Może sie pojawić okno
"Application TRK Launch Configuration" > "Next" wybieramy połączenie USB Klikamy w Next to wstedy pojawi się USB Setting. Sprawdzamy czy Serial Port jest w liście rozwijanej nazwa komórki, w moim przypadku jest to COM7 Nokia 5800 XpressMusic USB Z listy rozwijanej Service OS wybieramy S60 5.0.0 Klikamy w Initiate Service testing i sprawdzamy czy doszło do połączenia. Pojawi się komunikat że mamy poprawna wersje zainstalowaną.

Z menu Run -> Debug powoduje otwarcie obszaru roboczego poświęconego debugowaniem. Carbide .C++ dokonuje kompilacji, pakowania w plik instalacyjny oraz instaluje w komórce i uruchamia w komórce. Gdy w uruchomionym programie w komórce uruchomię w menu to program zatrzyma się a w debugerze pokaże to że program zatrzymał się tam gdzie była postawiona czujka.
W obszarze roboczym debugowania w zakładce Debug warto używać przycisku StepOver (F6) pozwala to na prześledzenie krok po kroku działania programu. Natomiast w zakładce Variables śledzimy jak zachowują się zmienne. A dla odważnych polecam zakładkę Dissasembly, żeby nauczyć się asemblera ARM.

QtCreator 1.3 też ma możliwość pracy z App TRK. Upewniamy się że App TRK jest w komórce uruchomiony na USB. Uruchamiamy QtCreatora. w menu Narzędzia -> Opcje... uruchomi się okno Opcje. Wchodzimy w węzeł SDK S60 i sprawdzamy jakie mamy zainstalowane SDKi i czy są przypisane do odpowiedniego SDK Qt4.6

A więcej to można obejrzeć na tym filmie z Youtube

Hinduska impreza #fndc09

2009-12-07T11:23:00.003+01:00

Nokia zorganizowała dla Hindusów imprezę programistyczną Forum Nokia Developer Conference - mogę na bieżąco śledzić informacje dzięki Twiterowi pierwszy raz mam wrażenie że to narzędzie staje się tak silnym narzędziem marketingu wirusowego którego jeszcze nie widziałem w ciągu minuty dostawałem kilkanaście wpisów z tej konferencji, tak jak bym był tam na żywo. Gdybym jeszcze na żywo ogladał przekaz multimedialny to byłby hit. Drugi aspekt że prezentacje muszą być profesjonalnie przygotowane z efektami interaktywną prezentacją - w przeciwnym razie trzeba liczyć sie z porażką i dezaprobatą wobec technologii.

Bardzo ciekawe są moje spostrzeżenia.
Silna promocja technologii widgetów wraz z ograniczeniami: nie można pobierać plików i jak nie można uruchamiać midletów. Bardzo dobrze przyjęto bibliotekę Qt pomimo braków czyli dostępu do API niskopoziomowego ( z powodu security) oraz instalatora poprzez OTA. Podstawą budowania aplikacji na Symbiana ma być OpenC/C++ a warto tworzyć aplikacje już w Qt. Tworzenie aplikacji na Symbiana ma opierać się na IDE takich jak Carbide.C++, Aptana oraz QtCreator. "Rezygnacja" z rozwoju midletów Java Mobile - nikt nie chce o tym pisać ani inwestować co powoduje niezadowolenie cześci programistów którzy postawili na tworzenie na masowo aplikacji na S40 i braku rozwoju usług SMSowych. Ponad przeciętne zainteresowanie programowaniem na Maemo. Wątpliwości programistów czy poznawać Sybmian C++ skoro maja uczyć się Qt który ma 12 modułów i ponad 700 klas API. W mniemaniu niektórych programistów wyszedł show marketingowy a myśleli, że czegoś się nauczą. Też był konkurs na który wysłano ponad 110 aplikacji.

BlueHome, rozwijany przez Binu i Irene z Excel Technologies oparty jest na Pythonie dla Symbiana, głównie użytkownikami mają być niepełnosprawni i niewidzący i używa układu scalonego który jest kontrolerem.
Srinivasan V z firmy Indiagames Ltd skoncentrował się na możliwościach grafiki 3D w komórach Nokii w prezentacji o możliwościach OpenGL ES 2.0. Maemo w N900 używa układu scalonego PowerVR SGX W tej firmie stworzono silnik ICE3D i pokazali to na przykładzie gry do baseballa na N900 w Maemo. Ponieważ N900 ma czujniki ruchu to sprawia że otwierają się nowe możliwosci w programowaniu gier. Ta gra miała 15 fps on 800x480 . Problem jest taki że jest nie wiele jest komórek z wsparciem ze strony procesorów grafiki. Są też problemy z poszczególnymi wersjami pomiędzy OpenGL ES, Open GL ES 1.1 a tą najnowszą OpenGL ES 2,0 ze wsparciem shaderów.
Prezentacja "Innovation in Mobile Applications" była prowadzona przez by Ankur Srivastav MobiMonster. Ta firma koncentruje się na tworzeniu middleware czyli niskopoziomowych silników dla aplikacji mobilnych na styku z częścią sprzętową czyli tworzą mechanizmy silników dla sms/mms, stosy telekomunikacyjne: GPS/GPRS, szyfrowanie rozmów. Jego główną ideą jest to innowacja w muzyce gdzie użytkownicy mogliby też tworzyć muzykę w komórkach i dzielić się nią. Sukces polega na tym, że potrafisz dzięki programowaniu coś stworzyć dla innych z pasją
Mr. Vijay z Interchange Solutions pracuje nad aplikacjami bazującymi na lokalizacji i zaprezentował Trackut Aplikacji dzięki której użytkownicy otrzymują informację o tym gdzie są.Opiera się to na oprogramowaniu GPSWatch i mapach OVI. Mają już 1.7 mln uzytkowników i dziennie rejestruje się ponad 300 użytkowników.
Amit z BIZense technologies zrobił prezentację o programiku w FlashLite Justdial dla FlashLite 2 i Flashlite 3, Flash Player 10 dla urządzeń mobilnych pojawi się w przyszłym roku. Justdial będzie zawierał integrację z OviMaps.
Fajnie że można spotkać sporo hinduskich programistów i geeków na Twiterze, którzy na żywo informowali o przebiegu konferencji: @uma_kanth @subbu16 @s0h4m @dhempe @ashwinbhatks, @tsuvik, @slakshmikanth, @jain_rajesh, @Deepaksegaran, @im2amit, @phoenicks, @vkvraju, @mynokiaworld, @pramodxyle.

Przygotowanie do programowania Qt 4.6 na Symbiana

2009-12-03T12:29:00.009+01:00

Ostatni post zawierał informacje o tym jak powstawała biblioteka Qt na Symbiana. Teraz warto przygotować swój komputer do pracy do programowania biblioteki Qt. Zakładam że jest zainstalowane poprawnie SDK z Nokii (albo ADT z stron Fundacji Symbiana). Istotny jest wybór SDK-ów. Trzeba zainstalować S60 3rd FP1 SDK,S60 3rd FP2 SDK, S60 5th Edition v1.0 SDK, N97 SDK, albo Application Developer Toolkit i dodatki od Samsunga (DevPack v1.1 for Samsung i8910 HD oraz S60 3rd FP2) oraz SonyEricsson (Satio) . Następnie trzeba do do odpowiedniego SDK w którym chcemy pracować wgrać SDK dla OpenC/C++ 1.6. Dla każdego kto ma zamiar w Carbide C++ programować pod Qt 4.6 to musi pobrać patha x86Tools_3.2.5_Symbian_b482_qt.zip dla Windows XP / Vista / Seven. Trzeba to wypakować tam gdzie ma się zainstalowanego Carbide C++ w folderze \x86Build. Ci którzy używają Vista /Seven powinni zapoznać się z tą sekcją. Ja zainstalowałem najpierw Qt SDK for Windows* (283 MB) który zawiera kompilator MinGW, biblioteki pod Windows oraz QtCreator 1.3. Zazwyczaj zainstalujemy tym celu żeby nauczyć się programowania Qt. Trzeba wiedzieć, że później trzeba będzie odpowiednio przygotować pod pracę z Qt 4.6 SDK dla Symbiana.

Następnie pobieramy Qt 4.6 SDK dla Symbiana Instalujemy to na tym samym dysku co mamy zainstalowane SDKi Symbiana. Podczas instalacji pojawi się okno pytające się do którego SDKa Symbiana ma dodać pliki binarne biblioteki Qt dla emulatorów.

Użytkownicy XP / Visty / Seven muszą ręcznie dodać zmienne środowiskowe PATH na C:\Qt\4.6.0\bin; i restartować komputer (oraz ustawić uruchamianie pliku epoc.exe w trybie zgodności z XP). Następnym krokiem będzie aktualizacja Carbide C++ (istotne jest żeby zaktualizować kompilatora C:\Symbian\Tools\ADT_1.0\Carbide.c++\x86Build\Symbian_Tools\Command_Line_Tools\mwccsym2.exe do wersji większej niż 3.2.5, build 482). Programiści programujący na S60 3rd Edition, FP1 SDK muszą reinstalować bibliotekę RPipe z \Symbian\9.2\S60_3rd_FP1_3\RPipe_3.1.zip i wypakować to do folderu \Symbian\9.2\S60_3rd_FP1_3\Epoc32\ I no trzeba zamienić plik getexports.exe \Symbian\9.2\S60_3rd_FP1_3\Epoc32\tools\getexports.exe.

Najpierw zawsze preferuję sprawdzenie czy Qt będzie działać z linii poleceń. Po zainstalowaniu Qt 4.6 SDK dla Symbiana trzeba skonfigurować Qt z linii poleceń. Następnie trzeba skonfigurować Qt 4.6.0 żeby rozumiało polecenia dla kompilacji dla Symbiana. W folderze E:\Qt\4.6.0\ robimy plik wsadowy z poleceniem:

configure -platform win32-g++ -xplatform symbian-abld

Pojawi się monit pytający się jaką wersje chcemy używać wpisujemy 'o' jeżeli chcemy używać wersji Open Source Edition. Potem pojawi się następny monit z informacjami o licencjach, akceptujemy licencję LGPL wpisując 'y'. Trochę czasu potrwa Running syncqt.....

Kolejnym krokiem ma być dodanie ustawień dla systemu Windows w zmiennych środowiskowych. W większości przypadków wystarczy użyć Start ->Programy -> Symbian Foundation ADT v1.0 -> Carbide.c++ -> Configure environment for WINSCW command line (albo jak mamy tylko Carbide.c++ to trzeba użyć Start ->Programy -> Carbide.c++2.0 -> Configure environment for WINSCW command line, a potem Start -> Programy -> Qt for Symbian by Nokia v4.6.0 -> Qt for Symbian Command Prompt.

Z nieznanych mi powodów to nie zadziało więc postanowiłem ręcznie zmienić zmienną środowiskowej QMAKESPEC z 'win32-g++' na 'symbian-abld'. Gdy nam zechce się programować Qt pod Windows będzie trzeba z powrotem zmienić zmienną środowiskową QMAKESPEC.

Następnie wchodzę w jakiś projekt na przykład E:\qt\4.6.0\examples\widgets\analogclock i tworzę plik wsadowy z poleceniem cmd, który uruchamiam go. W oknie z linii poleceń wpisuję dla folderu E:\qt\4.6.0\examples\widgets\analogclock polecenie

qmake -v

to pojawi się

Qmake vesion 2.0.1a
Using Qt version 4.6.0 in E:\Qt\4.6.0\lib

Oznacza to tyle że mamy to już zainstalowane poprawnie i wystarczy wygenerować pliki konfiguracyjne dla projektu.

qmake -spec symbian-abld -r

Zostanie wygenerowanych sporo plików w tym folderze zawierające m. in. najważniejsze: Bld.inf i *.mmp oraz *.pkg. Jeżeli tych plików nie ma to oznacza że nie dodaliśmy do zmiennej środowiskowej PATH C:\Qt\4.6.0\bin; może być zamiast tego ścieżka dla Qt 4.6 SDK dla Windowsa czyli może być najpierw w PATH ścieżka C:\Qt\2009.05\qt\bin;. W tej sytuacji trzeba zmienić ścieżkę na C:\Qt\4.6.0\bin; tak żeby występowała najpierw. Następnie trzeba wpisać polecenie:

make

które z tych plików zrobi wersję binarną dla emulatora. Trochę to potrwa. Jeżeli w kodzie nie było błędów to można potem uruchomić emulator wpisując

make run

Jak chcemy już zrobić wersję na komórki wpisujemy

make release-gcce

Powstaną pliki binarne na komórkę, które potem trzeba przekształcić w paczkę. Wystarczy wpisać

make sis

Powyższe polecenia udają się pod warunkiem że mamy poprawnie skonfigurowane SDKi pod Symbiana. Podsumowując polecenie make które ma następujące argumenty:

debug-winscw - domyślne ustawienie które tworzy wersję binarną dla emulatora
debug-gcce - tworzy wersję binarną z informacjami do debugowania na komórkę przy pomocy kompilatora GCCE.
release-gcce - tworzy wersję binarną dla komórki przy pomocy kompilatora GCCE
run - uruchamia wersję binarną w emulatorze z projektu w danym folderze
sis - tworzy podpisaną paczkę do zainstalowania w komórce

Mamy 3 sposoby na tworzenie aplikacji: z poziomu Carbide C++, z poziomu QCreatora 1.3 i oczywiście z linii poleceń.

Zakładając że używaliśmy wcześniej Carbide.C++ (zarówno w wersji ze stron Nokii czy ADT ze stron Symbiana) to wystarczy wcześniej odpowiednio skonfigurować to IDE. W menu Carbide.C++ wybieramy Window ->Preferences -> (z listy) Qt. Klikamy w przycisk Add.. Pojawia się okno Add new Qt version gdzie trzeba podać ścieżki dla tej wersji co mamy zainstalowaną czyli u mnie to jest E:\Qt\4.6.0\bin oraz E:\Qt\4.6.0\include.
Klikam w Apply a potem w OK

Następnie trzeba stworzyć projekt Qt w Carbide.C++ używając z menu File -> New -> Qt Project. Zostanie uruchomiony kreator projektu Qt. Otwiera się okno New Qt Project Wizard. Z tego wybieramy z listy rozwijanej Qt GUI Main Window i klikamy w Next. Kolejne okno to New Qt Symbian OS C++ Project gdzie podajemy nazwę projektu. Nazwa projektu nie może zawierać spacji. Lokalizacja projektu musi być na tym samym dysku co zainstalowany Qt, SDK oraz CarbideC++ (u mnie to jest dysk E) i też nie może być spacji w nazwach folderów w ścieżce do projektu. Następne okno kreatora to Build Targets gdzie wybieramy sposób kompilacji dla projektu przy użyciu zainstalowanych SDKów. Do wyboru mamy:
Emulator Debug (WINSCW) tworzy wersję binarną dla emulatora Symbian w Windows.
Phone Debug | Release (GCCE) tworzą wersje binarne dla telefonu przy pomocy darmowego kompilatora GCCE, który zazwyczaj jest instalowany z odpowiednim SDK
Phone Debug | Release (ARMV5) tworzą wersje binarne dla telefonów przy pomocy kompilatora ARM RealView Compiler (RVCT). Ponieważ przeważnie nie mamy dostępu do tego kompilatora to pozostawiamy odznaczone. Kolejne okno kreatora to Qt Modules gdzie wybieramy moduły Qt które mają zostać użyte. Przeważnie do prostej aplikacji w celu przetestowania wystarczy to co jest. Ostatne okno kreatora to BasicSettings, gdzie podajemy nazwę głównej klasy, która zresztą jest nazwą projektu a także wygenrowany identyfikator UID3 i klikamy Finish

Możemy zauważyć jak wygląda dokument projektu

TEMPLATE = app
TARGET = QtWitaj
QT += core \
gui
HEADERS += QtWitaj.loc \
QtWitaj.h
SOURCES += QtWitaj.rss \
QtWitaj_reg.rss \
main.cpp \
QtWitaj.cpp
FORMS += QtWitaj.ui
RESOURCES +=
symbian:TARGET.UID3 = 0xE34838B0

Mamy już okno do pracy z kreatorem GUI jak wybierzemy prace z plikiem *.ui

Następnie z menu Window -> Show View -> Other... pojawi się okienko dialogowe i wybieramy z węzła Qt -> Qt C++ Property Editor i zmieniamy nazwę okna w Property WindowTitle na Witaj Świecie.

Można zmienić kod w pliku main.cpp na ten:

int main(int argc, char *argv[])
{
QApplication a(argc, argv);
QtWitaj w;
w.showMaximized();
w.show();
return a.exec();
}

i zapisujemy zmiany z menu wybieramy Run -> Run As... -> Run As Symbian OS Application i pojawia się okno New Launch Configuration Wizard i klikamy Finish i kompilujemy dla emulatora. Możemy sobie podziwiać w emulatorze.

Teraz pozostaje przygotowanie do uruchomienia w komórce Nokia XM 5800. Z menu Project -> Build Configuration -> Manage... i pojawia się okno dialogowe Add/Remove Carbide Build Configuration i z węzła S60_5th_Edition_SDK_v1.0 wybieram Phone Release (GCCE) i klikamy OK Następnie z menu Project -> Build Configuration -> Set Active -> Phone Release (GCCE) [S60_5th_Edition_SDK_v1.0].

Następnym krokiem będzie przygotowanie do robienia paczki instalacyjnej z menu wybieramy Project -> Properties i pojawi się okno dialogowe Properties for QtWitaj. Z węzła CarbideC++ wybieramy Build Configuration . Wybieramy zakładkę Add i z kolejnego okna dialogowego SIS Properties przy liście rozwijanej PKG File wybieramy QtWitaj_template.pkg i klikamy OK waracamy do poprzedniego okna dialogowego gdzie wciskamy Apply a potem OK.
Pozostaje już skompilowanie i zbudowanie paczki instalacyjnej wybieramy z menu Project -> Build Project. Trwa kompilacja i tworzenie paczki instalacyjnej QtWitaj_template.sisx

W komórce odinstaluję poprzednie wersje Qt 4.6 z poprzednich instalacji i uruchamiam E:\qt\4.6.0\qt_demos.sis w swojej Nokii XM 5800 . Po zainstalowaniu sprawdzam czy dema Qt zainstalowane działają.

W Project Explorator CarbideC++ klikamy 2 razy w QtWitaj_template.sisx i rozpoczynamy instalację poprzez Nokia PC Suite. W komórce uruchamiamy w Menu -> Aplikacje -> QtWitaj

Podczas tworzenia tej instrukcji oparłem się na materiałach z wiki dla programistów Symbiana dodałem w tym swoje spostrzeżenia jakie miałem z problemami podczas przerabiania tej instrukcji. Dla programistów preferujących Qt Creatora 1.3 polecam zapoznanie z filmami na blogu dla programistów Qt.

Qt 4.6 na Symbiana

2009-12-02T10:46:00.002+01:00

Do przetestowania Qt4.6 w komórce to wystarczy wejść z komórką z Symbianem S60 3rd FP1, Symbianem S60 3rd FP2, Symbianem S60 5th (Symbianem^1) pod adres qt.nokia.com/phonedemos Instalator to paczka zawierająca biblioteki OpenC/OpenC++ 1.6, biblioteki Qt 4.6 i aplikacje (dema) pokazującym możliwości Qt. Aby zaprogramować swoją aplikację warto pobrać instalator SDK pod Windowsem. Trzeba znać ograniczenia jakie są w tym wydaniu biblioteki na Symbiana
Interesująca może być śledzenie listy bugów. Lista większych problemów z którym trzeba się liczyć i może zostaną poprawione.

Qt 4.6 w wersji dla Symbiana rozwijało się od marca 2008 roku. Główna zasługa Espena Riskedala (@snowpong na Twitterze) szefa zespołu który rozwijał kod na Symbiana.Na początek ludzie z Qt rozpoczęli współpracę z firmą Digia . Początkowo tym projektem było związanych 10 programistów. Pierwszą wersją dla publiczności wypuszczono w październiku 2008 "Pyramid" i bazujaca na Qt 4.4 i posiadała moduły QtCore, QtNetwork, QtGUI. W grudniu 2008 wypuszczono już wersję "Tower" już bazująca na Qt 4.5 z następującymi modułami QtSVG, QtDesktopServices. Następnie rozpoczęła się współpraca z firmami Nokia Sosco, Fundacją Symbian, które udziały wsparcia przy tworzeniu kolejnych wersji. W marcu 2009 wypuszczono wersję "Garden". Wtedy rozpoczęto prace nad stworzeniem modułu QtWebkit na Symbiana. W czerwcu wypuszczono wersję "Tower" Następnie doszły do współpracy firmy Accenture i Tieto. We wrześniu doszło generowanie wersji binarnych na bieżąco. W październiku zaktualizowano nową wersję silnika Webkit oraz wprowadzano wersję "Colossus". Postępy prac nad Qt dla Symbiana były pokazywane w Qt DevDays i jak na SEE09 W listopadzie było wydanie Qt4.6 RC1. 1 grudnia 2009 wypuszczono już wersję finalną Qt4.6.

Następnym krokiem ma być rozwój bibliotek rozszerzających możliwości Qt4.6 o możliwości charakterystyczne dla urządzeń mobilnych Qt Mobility Project. Potrzebne jest zrobienie lepszego instalatora bibliotek Qt a także prace nad obsługą OpenGL ES. W przyszłości będzie można się spodziewać środowiska Qt Creator online z mowhi.com i jak wsparcia przy tworzeniu aplikacji za pomocą QML.

Pozostało jeszcze czekać na wydanie 2 książek "The Definitive Guide to Mobile Qt: Symbian Development Platform" autorstwa Ray Rischpater i Dan Zucker wydawnictwa Apress oraz "Qt for Symbian" autorów Frank H. P. Fitzek, Tommi Mikkonen, Tony Torp wydawnictwa John Wiley & Sons.

Widgety - nowe technologie programistyczne

2009-11-21T10:54:00.011+01:00

Tempo rozwoju technologii programistycznych do tworzenia widgetów jest zawrotne. Mam wrażenie, że każdy producent technologii na widgety chce promocji swojej technologii.

Wymusza to nową definicję widgeta jako aplikacji na inteligentną komórkę która jest napisana w języku skryptowym i może korzystać z interfejsu użytkownika danego urządzenia mobilnego. Cechą widgetów jest to, że korzystają z możliwości danego urządzenia (robienie zdjęć aparatem fotograficznym, korzystanie z informacji o położeniu urządzenia). Jest też warunek opcjonalny uznania za widget: umożliwia korzystanie z informacji w internecie oraz wykorzystanie HTML, JavaScript, oraz CSS. Technologia FlashLite też mieści się pod warunkiem, że możliwości urządzenia pozwalają na uruchomienie plików SWF wewnątrz widgetów, albo pobierania i uruchamiania plików SWF przez widgety.

Obserwując pojawianie się nowych technologii na widgety spowodowane jest zrozumieniem pewnej istotnej rzeczy - trzeba ułatwić ludziom tworzenie programów na inteligentne komórki. Nokia w 2007 roku wypuściła technologię Web Runtime (WRT), ale dopiero połączenie z Platform Services 1.0 w S60 5th sprawiło, że widgety i aplikacje Flash na Symbiana S60 5th zaczęły mieć dostęp do możliwości inteligentnej komórki.

29 czerwca 2009 opublikowano Nokia Platform Services 2.0 nowością jest dostęp API do robienia zdjęć dla widgetów. Natomiast 4 listopada 2009 wypuszczono WebRuntime Bridge API zestaw API które pozwalał na tworzenie widgetów dla Facebooka czy MySpace w widgetach WRT.

Firma Nitobi przez cały rok rozwijała framework JavaScript Phonegap dla widgetów bazujących na iPhone, Androida. Ostatnio we wrześniu 2009 rozpoczęły się prace nad przeniesieniem możliwości tej biblioteki do widgetów WRT Webruntime. Efektem tej współpracy było wypuszczenie przez 18 listopada 2009 Sony Ericsson WebSDK dla tworzenia widgetów na Symbiana i jak na Androida.

17 listopada wypuszczono Qt 4.6.0 Release Candidate 1 zawierające też biblioteki dla Symbiana. Sprawiło to, że Nitobi rozpoczęło prace nad nowym silnikiem dla widgetów dla Symbiana wykorzystującego Mobile Extensions for Qt for Symbian i dla Maemo.

Opera od dawna intensywnie rozwija technologie widgetów. Najpierw to były widgety w przeglądarce internetowej. Obecnie wraz z współpracą z operatorami telekomunikacyjnymi (Vodafone i T-mobile) rozwija silnik Opera Mobile dla Symbiana i dla Windows Mobile. 3 listopada Nokia ogłosiła wypuszczenie Opera Mobile 10 beta na komórki z Symbianem a 18 listopada wypuściła wersję na Windows Mobile. Więcej informacji można poczytać w tym artykule. Opera dla twórców widgetów przygotowała odpowiednie wersje Opera Widgets SDK Natomiast Vodafone 19 listopada w współpracy z Operą opublikował na Betavine swoje Widget SDK version 2.

Rywalizacja też dotyczy w sferze technologii widgetów na komputerach użytkowników. Opera wypuszcza 15 października 2009 specjalną wersję Opery 10.10 beta zamieniająca widgety Opery na aplikacje komputerowe. Adobe 17 listopada 2009 ogłosiło upublicznienie beta Adobe AIR 2.0 bazującego na najnowszym silniku Webkita (bazującego na Safari 4.0.3) A Microsoft 18 listopada 2009 ogłasza udostępnienie SDK dla Silverlighta 4.

Adobe chce w 2010 roku wypuścić wersję Adobe AIR dla nowych wersji urządzeń mobilnych. Kwestia w tym że do rywalizacji z Adobe AIR w tworzeniu aplikacji widgetów dla urządzeń mobilnych wkroczył Appcelarator Titanium (dla aplikacji Androida i iPhone)

Dużą niewiadomą jest rozwój widgetów na Windows Mobile 6.5. Na tej platformie operuje się na zmodyfikowanym silniku IE6. Po bliższym zapoznaniu się z dokumentacją i prostym przykładem mam wrażenie że możliwości są takie jak opisano w standardzie dla widgetów. Okazuje się że istnieje możliwość rozszerzania funkcjonalności widgetów poprzez napisanie własnych kontrolek ActiveX

27 września 2009 opublikowano JIL SDK wersion 1.1 beta 2 - jest to technologia tworzenia widgetów na komórki z LiMo i jest to preferowane przez Samsunga i Vodafone. Jeszcze nie ma urządzeń które by wspierały tą technologię.

Faktem jest to, że Symbian, PalmOS, Android czy iPhone a także Windows Mobile 6.5 pozwalają na tworzenie aplikacji składającej się głównie z skryptów JavaScript to w praktyce z racji różnych wersji wydań silnika Webkit oraz integracji z interfejsem użytkownika i możliwościami urządzenia a także mechanizmów wdrożenia, powoduje pewną problematyczność w tworzeniu aplikacji na urządzenia mobilne. Fragmentaryzacja i dość szybkie zmiany w rozwoju sprawiają że trzeba solidnie napracować się nad kodem tak żeby działał zgodnie wg możliwości różnych UI i jak możliwości urządzenia.

Aby jakaś mobilna aplikacja reklamowa trafiła do jak największego grona użytkowników różnych urządzeń mobilnych trzeba solidnie popracować nad wersjami JavaMobile, FlashLite, i oczywiście jako widgety dla najnowszych modeli urządzeń mobilnych (z równoczesnym tworzeniem wersji mobilnej strony WWW). A użytkownikowi inteligentnej komórki pozostawić wybór.

Na podstawie tych zbiegu okoliczności w premierach różnych technologii pozostaje pytanie o to jak będzie rozwijać się dalej tworzenie widgetów. Pierwszą rzeczą jaką można zauważyć to że w sferze technologii mobilnych zaczyna dominować silnik Webkit co paradoksalnie przy obecnym tempie implementacji ich powoduje że w najbliższych latach komórki będą bardziej "nowocześniejsze" niż ich odpowiedniki na komputerach. Następną rzeczą będzie to co nazywam udostępnieniem API urządzenia aplikacjom internetowym. Obecnie można by uznać że dostęp do danych o kontaktach, kalendarza, o pozycji komórki, pobraniu informacji o geolokalizacji, wykorzystanie sensorów - położenia, zbliżenia, obrotu, położenia kierunku świata, a także dostęp do multimediów: robienie zdjęć czy filmików będzie wymagało ustalenia jakiegoś standardowego API które by pozwalało na pisanie ujednoliconego kodu .JavaScript. Firma Nitobi już to zrobiła. Natomiast wielką niewiadomą są frameworki UI - właściwie każda technologia widgetów może mieć swoje preferencje Dla Symbiana są to WRTKit i jak Guarana UI, dla iPhone bazuje na jQTouch iUI powstają też różne próby tworzenia frameworków mobilnych z jQuery UI, mochaUI, YUI.

Podsumowując tworzenie widgetów na urządzenia mobilne szybko przekształci się w odrębną specjalizację która będzie wymagać od twórców dość specyficznej wiedzy z JavaScriptu i możliwości programistycznych jakie oferują poszczególne technologie w konkretnych systemach operacyjnych. Wraz z tym będzie coraz większa presja na szybszy rozwój silnika WebKit tak żeby przynajmniej pod Symbianem potrafił mieć takie same możliwości jak aplikacje pisane w JavaScript dla Androida czy dla iPhone.

Jednym z wartościowych źródeł które należy śledzić w tym temacie to Mobile Web Initiative. oraz ich blog W tym temacie istotne jest to, że już napisano szkic roboczy 15 października 2009, który opisuje jakie API ma być dostępne w Java Scripcie dla mobilnych widgetów

No to faktycznie, żyjemy w ciekawych czasach dla programistów i developerów.

Widgety na Symbiana i ich programowanie

2009-11-08T14:41:00.003+01:00

Ponieważ możliwości inteligentnych komórek są często poza możliwościami przeciętnych programistów. Sukces Symbiana może opierać się na tym że daje duże możliwości tym co już umieją. Większość programistów w jakiś sposób zetknęło się z programowaniem w Java Script czy stylami kaskadowymi. Więc umożliwienie wykorzystania do programowania w tych technologiach na komórce daje o wiele większy potencjał popularności niż w przypadku tworzenia w natywnych technologiach typu Symbian C++ czy Java Mobile. Sukces iPhone czy Androida (a po części też WebOS Palma) polegał na tym że pozwalał programistom wykorzystać potencjał technologii internetowych w inteligentnych komórkach.

Na platformie Symbian można było już od dawna tworzyć aplikacje wykorzystujące potencjał wbudowanej przeglądarki internetowej a także z możliwości programowania w FlashLite osadzając je w aplikacji pisanej Symbian S60 w C++. Więcej informacji można znaleźć w dokumencie Flash Viewer Framework API łącznie z przykładem How to write a Flash Stub application to protect your SWF file?, natomiast w przypadku tworzenia aplikacji Symbian C++ wykorzystujących silnik przeglądarki internetowej warto zapoznać się z S60 Platform: Browser Control API Developer's Guide v2.0. Jedyny przykład jest zawarty w SDK i jak można też ściągnąć ze strony TSS001012 - Browser Control API: Cloning the connection for Download Manager. Ciekawostką jest to, że te technologia już istnieje sobie od 2004 roku ale jak wiadomo mało kogo to interesowało, albo jak kto to poznał to obowiązywało go przestrzeganie tajemnicy how-know.

W tej sytuacji powstawała idea widgetów na komórki. Więcej szczegółów można przeczytać w pracy doktorskiej Marcosa Caceresa z 2007 roku Ta praca to interesująca historia tego jak powstawała idea widgetów. Nokia w sierpniu 2007 roku wypuściła betę WRT Web Runtime S60 dla SDK S60 3rd Feature Pack 2. Możliwości tej platformy właściwie ograniczały się do wykorzystania potencjału samej przeglądarki S60 Web Browser. Potem wraz z pojawieniem się S60 5th wypuszczono wersję z WRT1.1 które zawierało programistyczny dostęp do danych z komórki. Jest to S60 Platform Services 1.0. Równocześnie Nokia opracowała pluginy do popularnych edytorów developerskich które pozwalały na tworzenie zawartości dla widgetów (dla Aptany, Dreamweawera, oraz VisualStudio). Aby ułatwić szybkie tworzenie zaawansowanych widgetów Nokia opracowała framework WRTKit. Jest zestaw bibliotek JavaScript dedykowany widgetom na Symbiana. Gdy Nokia wypuściła SDK dla N97 w kwietniu 2009 roku to do widgetów dodano nową funkcjonalność - homescreen, co pozwalało widgetom wyświetlać informacje na "pulpicie" komórki. Widgety WRT 1.1 w odróżnieniu od aplikacji na Symbiana miały dość ograniczone możliwości (nie pozwalały na dostęp do plików lokalnie). Idąc naprzeciw oczekiwaniom programistów Nokia wprowadziła nowe Platform Services 2.0 (tylko dla XM 5800 i dla N97) a także Web Runtime Bridge API które ma być dostępne dla wszystkich komórek obsługujących widgety. Na wiki jest dokumentacja tego co można się spodziewać po tej technologii.

Po bliższym spojrzeniu na to rozwiązanie okazuje się że do każdego widgetu będzie można dołączyć paczkę instalacyjną z serwerem HTTP który będzie komunikował się z widgetem lokalnie. Do tego serwera HTTP będzie można robić pluginy ECOM udostępniające funkcjonalności Symbianowego API. Idea całkiem ciekawa biorąc pod uwagę że już napisano takie rozwiązania wykorzystując Pythona S60.

Dla widgetów WRT była już próba napisania takiego serwera HTTP który udostępniałby widgetom API z Pythona takich jak dostęp do bazy danych, wykorzystanie Bluetootha, do wykorzystanie syntezatora mowy. Cały koncept polega na tym żeby zainstalować sobie Mobile Web Serwer z Pythonem albo PAMP z PHP i napisać sobie widget WRT, który byłby w stanie komunikować się z lokalnym serwerem co opisano w artykule How to utilize device resources from a WRT widget. Również można wykorzystać własny miniserwer napisany w Pythonie dla Symbiana co jest opisane w artykule How to access S60 resources in WRT or Flash Lite, using PyS60

Można powiedzieć że same aplikacje w Pythonie dla Symbiana też mogą pełnić funkcje widgetów czyli małych aplikacji rozrywkowych. Przykładem takiego rozwiązania jest framework Flyer współpracujący z FlashLite. Półżartem półserio można zrobić coś jak Adobe AIR na Symbiana czytają poniższe artykuły How to package Flash content in a Widget i How-to communicate with Flash Lite from Javascript in widget (WRT)

Jak tworzyć widgety?

Zainstalować edytor Aptana i plugin do tworzenia widgetów WRT.
Warto na początek wziąć udział w szkoleniu eLearningowym Nokii o widgetach Widgets for the S60 Platform E-learning Następnie ściągnąć sobie aktualna dokumentację Web Developer's Library. Trzeba dowiedzieć się jak importuje się widgety WRT i zacząć naukę na przykładach. Szczególnie polecam dla zaawansowanych RouteWidget Example AccuWidget Example Hue Widget Example a także przykłady aplikacji z fundacji Symbian SEE 2009 Widget OSCON 2009 Schedule Example Widget. Warto też postudiować wiki Forum Nokii i jak Fundacji Symbian

Kompilator ARM RVCT 4.0 for Symbian Foundation

2009-10-21T20:00:00.005+02:00

W SDK przeważnie mamy pliki dla 2 kompilatorów GCCE i dla ARM RVCT 4.0 Ponieważ są pewne ograniczenia kompilatora GCCE do większych projektów warto używać kompilatora ARM RVCT. Od pewnego czasu jest coraz więcej dużych projektów OpenSource które są przenoszone na platformę Symbiana. Klasycznym przykładem jest projekt Qt 4.6 for Symbian, ale co z tego że zawiera kod źródłowy w repozytorium Git to jednak do kompilacji binarnej na komórkę jest potrzebny kompilator ARM RVCT który kompiluje wydajniej pod architekturę EKA2.

Ze względu na to że fundacja Symbian staje się być bardziej przyjazną programistom to postanowiono udostępnić kompilator ARM RVCT sporej rzeczy programistów OpenSource.

Instrukcja instalacji kompilatora
1. Wchodzimy na tą stronę https://silver.arm.com/login/
2. Rejestrujemy się
3. Gdy otrzymamy maila z potwierdzeniem rejestracji - logujemy się
4. Klikamy w link - "RVCT 4.0 for Symbian" download
5. Akceptujemy warunki licencji - wersja ta jest ograniczona tylko dla pojedynczych programistów pracujących w małych firmach zatrudniających do 20 osób
6. Pozostaje podanie numeru telefonu i podanie numeru karty Ethernet ( dla nie wtajemniczonych w wystarczy z linii poleceń wpisać "ipconfig /all" i szukamy adresu fizycznego "Karty Ethernet połączenia lokalne" i wpisujemy 12 znaków bez '-')
7. Pojawi się tekst pliku licencji i zapisujemy go na Pulpicie (albo tam gdzie go możecie potem znaleźć)
8. Rozpoczyna się ściąganie pliku zip 76MB
9. Wypakowujemy to w tymczasowym miejscu i uruchamiamy plik Setup.exe
10. Ustawiamy instalację na !:\Symbian\ARM (gdzie ! oznacza literę dysku w moim przypadku to było E:\Symbian\ARM
11. Pod koniec instalacji pojawi się ARM License Wizard i klikamy w Install Licence
12. Uruchomi się okno w którym klikamy Add i dodajemy plik licence.dat
13. Zamykamy instalatora

Okazało się że kompilator zainstalował się w E:\Program Files\ARM, ale okazało się że to nie działa tak jak bym oczekiwał. I raczej nie zanosi się z powodu zmian w architekturze.

Larry Knibb napisał

Apologies for the confusion. SBSv1 (abld) is __not__ being updated for RVCT4.
The reason is that this functionality is already available in SBSv2 (Raptor).
Abld is due for deprecation soon so we are not adding major functionality to
it. Raptor replaces abld as the build system for Symbian OS, so new
functionality will appear in Raptor only.

Coś mi się zastanawia że kolejne SDK i wersje Symbiana już nie będą zgodne z poprzednikami na poziomie binarnym (pomimo architektury EKA2), ale prawdopodobnie kod pozostanie ten sam pod kątem wykorzystania API Symbiana.

W razie czego też można by postarać się o nowszą wersję kompilatora GCCE zamiast czekać na SDK dla modeli z Symbian^2 i Symbian^3 Natomiast Symbian^4 to już zupełnie inna architektura sprzętowa i jak API tutaj trzeba już programować w Qt