A "mobil OS X" piaci részesedése meghaladta a Windows Mobile-ét; az MS iPhone alkalmazást adott ki

Címkék

A Gartner elemző előzetes eredményei szerint 2008 harmadik negyedévében olyan jól ment az Apple iPhone telefonjának értékesítése, hogy (első alkalommal) sikerült az OS X-nek az okostelefonokra szabott operációs rendszerek közt maga mögé utasítania Windows Mobile-t. A Gartner szerint a legnagyobb számban értékesített smart phone operációs rendszer a Symbian. Ezt követi a második helyen a RIMM-féle BlackBerry OS, a dobogó harmadik helyén pedig az OS X áll. A Windows Mobile csak a negyedik, utána következik a Linux.

Seadragon Mobile Gyártókra lebontva ez így néz ki: első a Nokia, második a RIMM, harmadik az Apple, negyedik a HTC, az ötödik helyen pedig a Sharp áll.

Úgy tűnik, hogy a Microsoft-ot sem hagyja hidegen az iPhone sikere. A Microsoft Live Labs kiadta a Microsoft első iPhone alkalmazását, a Seadragon Mobile-t. A Seadragon a saját honlapja szerint egy olyan alkalmazás, amely következő generációs vizuális élményt nyújt függetlenül a megjelenítő eszköz méretétől, a megjelenítendő file méretétől és a rendelkezésre álló hálózati sebességtől.

Hogy mit tud a program, arról az is meggyőződhet akinek nincs iPhone-ja. A program honlapján elérhető egy Seadragon Ajax demó, amellyel tesztelhető a program.

A Seadragon Mobile ingyenes letölthető az Apple App Store-ból.

A Gartner elemzése itt olvasható.

Hozzászólások

azt észre vettétek, hogy a kozépső körös képen van egy csomó magyar előadó? :))

Hát tehetek én arról, hogy egy randomizált layout algoritmus pont Majka Papát tette középre? ;)
Hülyeséget félretéve, az a vizualizáció a Last.fm teljes adatbázisából készült (némi előszűrés után), így nincs különösebb oka annak, hogy magyar előadók (is) vannak benne.

egy kicsit csalóka a cím. windows mobile olvasásakor, pár olvasóban talán a microsoft windows piaci dominanciája ugrik be első asszociációként. pedig windows mobile csak névben hasonló, valójában egy más operációs rendszerről van szó. a mobil linux forráskód kompatibilis az asztali vagy notebook computeren használt linuxal. természetesen a mobilok szükösebb hw erőforrásait figyelembe kell venni. windows mobile esetében nincs szó forráskód alapú kompatibilitásról sem. legfeljebb .net platformon lehetne próbálkozni, de még ott sincs a portolásra élő gyakorlat.
továbbá a windows mobile a kisebb szereplők közé tartozik smartphone piacon, ahogy egyébként a linux is. az elmúlt 4 évben a windows mobile elvesztette a smartphone részesedésének az 50%át.
A wince platform utoljára PDAkon volt sikeres. ott átvette a vezető szerepet a PalmOStől, de mire elérte PDAn a vezető szerepet maga PDA piac purcant ki, pont a smartmobilok miatt.
a smartphone piacot toronymagasan a Symbian vezeti és ez sokáig nem fog változni. a mobil OSX sikere érthető. jelenleg a symbian mellett ez az a smartmobil os, ami signalling stackel rendelkezik. a RIM blackberryt nem ismerem, lehetséges abban is van signalling stack.

az utóbbi időben jelentősen bővült a hup olvasótábora, ezzel az általános tájékozottsági szint inkább csökkent, mint stagnált volna. nem kell ide dyslexia, elég a tájékozatlanság is. nemrég egy olvasó úgy gondolta, hogy a gnu/linuxban rendszeresen kell túrni a registryt, ami azért eléggé LOL:)

A Research In Motion (RIM) es a BlackBerry sikere mashol keresendo, konkretan abban, hogy a Nagy Viz tulpartjan rengeteg nagyvallalat mobil e-mail es szoveguzenet kommunikacioja epul az o rendszerukre, valamint hogy olyan kozponti management szoftvereket adnak a telefonjaik melle (BlackBerry Enterprise Server), amik potolhatatlan eszkozze teszik a tobbszaz, esetleg tobbezer telefont adminisztralo rendszergazdak koreben. Foleg, hogy az uzenetkuldes mellett tonnaszamra vannak egyeb, sok esedben egyedi fejlesztesu ceges szoftverek, aminek a kozponti upgrade-jet, stb-jet is a BES-en at lehet megoldani, 3 kattintassal. Kb. emiatt nepszeru a BlackBerry, mert maga a telefon OS, foleg a halozati resze, hat szoval finoman szolva is...

Egyebkent ha mar itt tartunk, a BlackBerry platform telefonoldali resze egy Java-ban programozhato valami, az alatta levo OS-rol eleg keveset tudhat a foldi halando, de nem lehet egy bonyolult allat, mert a telefon sajat felulete is nagyreszt Java-ban van irva... A business szoftvereket leszamitva pedig semmi mast ne akarjal ra csinalni, mert ha egy picit is tullepsz a megszokott dolgokon, eleg hamar hmmm... "korlatokba utkozol". A napjaim nagyreszet manapsag ugyis az teszi ki, hogy olyasmiket csinalok meg BlackBerry-ken, amiket a sajat developer supportjuk bevallasa szerint egyszeruen nem lehet... :)

-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-

igen, ez így van. az app level természetesen fontos, de amire utaltam, a signalling stack, az a kicsi software, amely a telefon gsm/umts/hsdpa stb kommunikációjáért felel. Symbianon ez kernel szinten van megvalósítva. kicsit gány megoldással imho, S40 instruction emulator fut kernel szinten, és azon a jól bevált S40 kód. ennek ellenére stabilan működik. azzal érvelnek, hogy célszerűbb és gazdaságosabb megoldás volt, mint írni egy natív Symbian signalling stacket. hát nem tudom...
mobil OSX forráskódjához nem volt szerencsém. az elmúlt időszak 3G hálózattal kapcsolatos hibáiból arra következtetek, hogy az OSXnek is van signalling stackje. valószínűleg ezért ajánlott az Apple firmware frissítést a probléma megoldására. az OSX microkerneles felépítése miatt tökéletesen alkalmas a feladatra.
linuxnak komoly hiányosságai vannak a téren. a monolitikus kernel itt meg fogja bosszulni magát. nem véletlen, hogy az Android telefonok is féltégla méretűek. windows mobileal ugyanez a helyzet. ezeknél a rendszereknél valójában két külön álló rendszerre van szükség. egy a pda szerű működéshez, egy másik a Gsm/3G kommunikációhoz. két processzor, két rendszer, nagyobb méret és fogyasztás. windows mobile buherálásánál annyira elkülöníthető ez a két alrendszer, hogy külön lehet frissíteni a WinCE/PocketPC utód Windows Mobilet és az gsm részt működtető Radio softwaret.
egy Blackberry telefon szétszerelésével jó eséllyel meg lehetne állapítani, hogy van e rendszer szintű signalling stackje, akkor is ha egyébként szeret titkolózni a cég:)
ami magasabb szinten van, java felület stb. az már egy külön téma. egyébként mennyire kompatibilis a blackberry java felülete? androiddal biztosan nem kompatibilis, de az a Google sara. valamiért fontos nekik az inkompatibilis dalvik java variáns támogatása.

Amit a signaling stackrol irsz, arra nem tudom a valaszt, de abbol, hogy pl. egy Java appletben is mit kell szopni azzal, hogy milyen modon jojjon letre egy halozati kapcsolat, nem lehet valami jo megoldas alatta. Szetszedni meg nem volt kedvem a fejlesztoi device-jainkat... ;)

A Java kompatibilitasa erdekes. A jelenlegi BlackBerry-k mar tudjak a sima J2ME applikaciokat, es .JAR-okat is futtatni, de alapvetoen az Androidhoz hasonloan sajat API-s rendszerrol van szo, amihez pl. sajat IDE (BlackBerry JDE) meg ilyesmi is jar. A nativ alkalmazasok pedig a szinten proprietary .COD formatumban leteznek... De szerintem Sun VM van alatta, mert a telefon About kepernyojen egy bazinagy Sun Java logo is diszeleg.

Mentsegukre legyen mondva, hogy amikor a sajat cuccukat elkezdtek csinalni, a J2ME olyan buta volt mint a fold, es meg most sem tudna mindent, ami kell, a J2SE meg total overkill egy mobil eszkozre. Valoszinuleg a Google is ezert ment el teljesen a sajat megoldas fele.

Egyebkent eleg ketarcu a BlackBerry API. Egyreszt, szeduletes szopassal jar tok alapveto dolgok tamogatasa is, masreszt viszont meg igy is urraketa egy alap J2ME telefonhoz kepest, harmadreszt viszont sok resze baromi jo, pl. az egyik legelegansabb es legkonnyebben programozhato GUI gadget kitet raktak ossze hozza, amit valaha lattam, ebbe a desktop platformokat is beleertve. Osszessegeben en szeretek vele dolgozni. Dolgoztam mar sokkal nagyobb rakas szar rendszerekkel is, ebben legalabb latszik, hogy probalkoztak.

Egy kicsit beledugtam az orrom az Androidba is, szerintem egyelore meg jobb a BlackBerry rendszere, Java szemszogbol, mert az Android meg tobb mint kiforratlan, de nagyon durvan jon fel... Es a RIM is dolgozik gozerovel, mert csak az alatt a kevesebb mint egy ev alatt, miota en dolgozok vele 4.3-rol 4.7-re ugrott az OS verzioszama, egy egy tonna uj dolgot vezettek be, es irtak at jobbra (vagy sajnos neha rosszabbra). Szoval erdekes lesz a jovo.

-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-

"a signalling stack, az a kicsi software"

Ez a Nokia telefonokban egy komplett oprendszer, nemes egyszerűséggel NOS-nak nevezik (Nokia Operating System) és nincs köze az S60-hoz. Feladata a telefon hardver vezérlése, mint pl. bázisálomásokkal kapcsolat tartás, térerősség mérés, kimenő teljesítmény szabályozás, hivás kezdeményezés és fogadás stb.

Régebben amíg a Nokia telefonok 2 processzorosak voltak, addig a NOS saját processzoron futott. Mostanában (a mobil processzorok fejlődésének köszönhetően) a Nokia telefonokban csak egy processzor van és ezen osztozik a NOS és a S60. Azt hiszem ez a legérdekesebb része a dolognak, hogy hogyan fut két OS egy processzoron. A megoldás, hogy a NOS fut a processzoron és "idle time slice"-ban futtatja az Symbian, úgy, hogy az semmit nem tud a dologról. A két OS egyébként shared memory-n keresztül beszélget egymással.

A Symbian-ban vannak egyébként telefon kezeléssel kapcsolatos API-k, de ezek csak a NOS felé továbbítják a kéréseket. A telefon hardver kezelését azért nem Symbian szinten oldják meg, mert ez a harver gyártók feladata (Nokia, SE, Samsung, stb.), és teljesen eszköz specifikus.

a NOS csak egy geek bloggerek és internetes újságírók által használt ad hoc név. a Nokián belül csak kódszámukkal hivatkoznak rá. ezért írtam, hogy S40 kód feljebb. természetesen ez sem pontos megfogalmazás, mert valójában az S40 user interface mögötti tényleges operációs rendszerről van szó. a célnak megfelelt ez a név is.
nem fut teljes S40 alatti OS, vagy ha úgy tetszik NOS a Symbian, mellett.
az EKA2 kernel óta a Symbian rendelkezik personality layerekkel, ami lehetővé teszi NOS kód futtatását. így a NOSból csak a signalling stack kód található meg egy Symbian rendszeren, az pedig a Symbian kernelének az EKA2nek egy emulációs rétegén fut.
a processzoroknak nem sok köze van ehhez. az symbian esetében egyébként már a kezdetektől mindig valamilyen ARM cpu volt. házon belül létezik port már architecturára is, de hivatalos termék sosem jelent meg velük. a signalling stack egy cpun való futtatásának a lehetősége a symbian új generációs kernelének volt köszönhető.

Amit én NOS-nak nevezek, az a programozók számára láthatatlan. Normál halandók általában nem hallottak róla, nem publikus, a különböző gyártóknál különböző. Amit te signaling stack-nak nevezel, az a Symbianban a kapcsolattartó réteg a NOS felé.
Egy kicsit elbeszélünk egymás mellett (lehet hogy én nem voltam elég világos), te a signaling stack-rők írsz itt, ami a Symbian-ban fut, és ami közös kód az S40-el, én meg a mögöttes oprendszerről ami igazából vezérli a telefont és virtuálisan futtatja a Symbian-t. Eltöltöttem néhány évet ott.

nincs köztünk értelmezési vita abban, mit nevezel NOSnak. az a Nokias belső használatú os, amely a nem Symbianos Nokia telefonok rendszeréül szolgál. az un feature telefonok OSe. két fő változata S40 és S30 userinterface variánsok, ma inkább s40nek van jelentősége. ez a rendszer nem fut párhuzamosan a symbian telefonokon amolyan másodlagos OSként, a mai Nokia smartphoneokon. korábban, amikor két külön processzor volt a symbianos Nokiákban valóban volt bennük egy NOSnak nevezhető os, az futott a másik processzoron és vezérelte a telefonos hw részt. user interface természetesen nem tartozott hozzá, és sok más összetevő hiányzott egy nornál S40es telefon NOS rendszeréhez képest. természetesen felesleges is lett volna. a felhasználó felé a symbian nyújtott user interfacet, sms, wap, címjegyzék stb szolgáltatásokat.
voltak kísérletek a két rendszer egy CPUra hackelésére, de ezekből soha nem lett megbízható közös rendszer.
a symbian új EKA2 kernele végül megoldotta a problémát. ennek része az a kernel szintű emulációs réteg, amelyen natív NOS kódokat lehet használni, és az itt használt NOSból származó kód vezérli a smarphone telefonos hardwarét. de ezt a signalling stach kódot, ami valóban a NOS része, semmiképp sem nevezném teljesértétű NOSnak, még csak nem is tekinthető operációs rendszernek. memóriakezeléssel egyáltalán nem foglalkozik, ahogy több feladat ütemezésével sem, mert ezt az EKA2 personality layere, ha úgy teteszik emulátora elvégzi helyette. a GSM/3G hardwaret valóban közvetlenül vezérlni, ez a feladata. ez így nálam nem fér bele az operációs rendszer fogalmába. a legelfajultabb változata lenne az OSeknek ez a kis NOS eredetű signalling stack kód, mivel önállóan az a kód működésképtelen lenne.