V minulΘm Chipu jste se mohli seznßmit se zßkladnφmi rysy operaΦnφho systΘmu Epoc, pou₧φvanΘho pro mobilnφ za°φzenφ. Dnes Φlßnek dokonΦφme popisem mo₧nostφ v²voje aplikacφ pro tento systΘm.
Epoc svΘ programßtory nijak neh²Φkß; pro u₧ivatele ÜpiΦkovΘho API, jak²m je OpenStep nebo Apple Cocoa, je jeho API velmi strohΘ. V∞tÜina programßtor∙ vÜak mß zkuÜenosti jen s nesrovnateln∞ horÜφmi posixov²mi nebo windowsov²mi prost°edφmi û z jejich pohledu bude programovßnφ pro Epoc pom∞rn∞ pohodlnΘ.
SouΦßstφ v²vojovΘho prost°edφ Epocu je pom∞rn∞ Üirokß podpora standard∙. Zßkladnφ programovacφ jazyky jsou C/C++ a Java, k dispozici je i (ne zcela kompletnφ) API Posix. Co je to vÜak vÜechno platnΘ, kdy₧ "stolnφ" aplikace v naprostΘ v∞tÜin∞ p°φpad∙ z p°φΦin rozebran²ch v prvnφ Φßsti Φlßnku na mobilnφ systΘmy portovat nelze.
Patrn∞ ideßlnφ by bylo standardnφ API rozÜφ°enΘ o specifickΘ slu₧by, odpovφdajφcφ mobilnφmu prost°edφ. Epoc je vφcemΘn∞ objektov² operaΦnφ systΘm; jedinΘ dnes standardizovanΘ objektovΘ API je OpenStep, ten vÜak bohu₧el v Psionu asi neznajφ. Proto navrhli proprietßrnφ API, zalo₧enΘ na C++, tedy vφcemΘn∞ neobjektovΘ, proto₧e podpora objekt∙ v C++ je dost tristnφ.
I p°es tuto nev²hodu platφ pro API Epocu zhruba totΘ₧ co pro cel² operaΦnφ systΘm: nenφ ani zdaleka dokonalΘ, je ale lepÜφ ne₧ API systΘm∙ jako PalmOS nebo Windows CE. I p°es omezenφ, danß jazykem C++, dodr₧uje API Epocu alespo≥ zßsadnφ objektovou strukturu a i jeho slu₧by jsou na dost vysokΘ ·rovni.
Firma X.soft sice pracuje na otev°enΘm SDK pro Epoc, zalo₧enΘm na GNUStepu, to je vÜak dlouhodob² projekt, tak₧e v souΦasnosti i v st°edn∞dob²ch v²hledech po°ßd z∙stßvß s p°ehledem nejlepÜφm "mobilnφm" API standardnφ API Epocu.
Programovacφ jazyky
Zßkladnφm programovacφm jazykem Epocu je C++, v n∞m₧ je sßm Epoc napsßn. Podobn∞ jako nap°φklad u BeOS to p°inßÜφ °adu nep°φjemn²ch omezenφ, pro "mobilnφ" Epoc to vÜak nese i n∞kterΘ v²hody.
C++ je patrn∞ nejhorÜφ z dnes b∞₧n∞ u₧φvan²ch jazyk∙ û uve∩me jen orientaΦn∞ n∞kolik jeho hlavnφch nev²hod:
* s jeho nep°ehlednostφ snad m∙₧e sout∞₧it jen PL-1 neblahΘ pam∞ti; proto vy₧aduje relativn∞ dlouhou dobu na nauΦenφ;
* nepodporuje korektn∞ prßci s objekty (nap°. t°φda je pro n∞j jen typ, nelze ji ulo₧it do prom∞nnΘ nebo p°edat jako argument; metody jsou volßny staticky; v∙bec nemß protokoly...);
* nemß prakticky ₧ßdnou b∞hovou ochranu (nap°. volßnφ metody nesprßvnΘho nebo neexistujφcφho objektu vede k pßdu programu bez informace o p°φΦin∞ chyby);
* vφcenßsobnß d∞diΦnost, overloading operßtor∙ a templates p°esnadno vedou k dokonale neΦiteln²m program∙m û tedy obtφ₧n∞ laditeln²m a s extrΘmn∞ drahou ·dr₧bou.
Na druhou stranu mß C++ i n∞kterΘ v²hody. P°edevÜφm, z nepochopiteln²ch p°φΦin (kv∙li jeho kvalitßm to rozhodn∞ nenφ), je velmi rozÜφ°en: aΦkoli dobr²ch programßtor∙ v C++ je velmi mßlo, jeho zßklady znß tΘm∞° ka₧d² a skoro ka₧d² v n∞m dokß₧e "n∞co nasmolit". Prßv∞ dφky jeho nejv∞tÜφ nev²hod∞ û statickΘmu p°φstupu k objekt∙m û je p°elo₧en² k≤d relativn∞ velmi efektivnφ (statickΘ volßnφ metody v C++ je v pr∙m∞ru 1,5krßt a₧ 2krßt rychlejÜφ ne₧ p°edßnφ dynamickΘ zprßvy v Objective C): u mobilnφch systΘm∙ s jejich nφzk²m v²poΦetnφm v²konem to mß smysl. Tv∙rci Epocu se alespo≥ t∞m nejhorÜφm vlastnostem C++ dokßzali vyhnout: overloading operßtor∙ se prakticky nevyu₧φvß, vφcenßsobnß d∞diΦnost slou₧φ jen pro simulaci protokol∙, templates se vyu₧φvajφ pouze pro vylepÜenφ typovΘ kontroly.
V urΦitΘm smyslu srovnatelnß s unixov²mi operaΦnφmi systΘmy je Java. Je to velmi sluÜn² objektov² programovacφ jazyk, odstra≥ujφcφ v∞tÜinu chyb jazyka C++ a trpφcφ trochu jen neÜ¥astnou "teΦkovou" syntaxφ; to ale vyjma snφ₧enφ Φitelnosti zdrojovΘho k≤du nenφ zßsadnφ nev²hoda. Zßsadnφ nev²hodou pro mobilnφ systΘmy je vÜak jejφ nßroΦnost na v²poΦetnφ v²kon. Jakkoli interpreter Javy v Epocu pat°φ mezi nejlepÜφ, pro implementaci nßroΦn∞jÜφch algoritm∙ je Java nepou₧itelnß. DalÜφ omezenφ jsou dßna tφm, ₧e sßm Epoc je bohu₧el implementovßn v C++ a ₧e z toho, Φemu se tam °φkß t°φda Φi objekt, ud∞lat plnohodnotnou javovskou t°φdu nebo objekt prost∞ nejde. Proto je z Javy trochu komplikovan² p°φstup k systΘmov²m slu₧bßm. P°esto lze p°edpoklßdat, ₧e Java urΦit∞ znamenß budoucnost programovßnφ v Epocu û vyjma jednoduch²ch a nenßroΦn²ch aplikacφ, na kterΘ staΦφ dneÜnφ v²kon, vÜak budoucnost pom∞rn∞ vzdßlenou. Prozatφm je pro plnohodnotnΘ aplikace bohu₧el nutnΘ z∙stat u C++.
T°etφm a poslednφm jazykem, kter² Epoc API standardn∞ podporuje, je OPL, co₧ je proprietßrnφ varianta strukturovanΘho Basicu. OPL je interpretovan² jazyk a jako jedin² umo₧≥uje v²voj p°φmo v Epocu (pro v²voj v Jav∞ nebo v C++ musφme vyu₧φvat k°φ₧ovΘ SDK na stolnφm poΦφtaΦi). OPL mß n∞kolik v²hod, kterΘ jej p°edurΦujφ pro rychlou tvorbu jednoduch²ch aplikacφ: sßm jazyk je prostink² a dß se jej nauΦit za pßr dnφ (zkuÜen∞jÜφ programßtor se jej nauΦφ za pßr hodin). Jeho interpreter je velmi rychl² û aplikace psanΘ v OPL jsou o poznßnφ rychlejÜφ ne₧ aplikace psanΘ v Jav∞, i kdy₧ nemohou sout∞₧it s aplikacemi psan²mi v kompilovanΘm C++.
Nakonec bych se rßd velmi struΦn∞ zmφnil o Objective C: struΦn∞ proto, ₧e v souΦasnosti podporovanΘ nenφ. Je to vÜak nesmφrnß Ükoda, proto₧e jde o ideßlnφ kompromis: jazyk s mo₧nostmi a elegancφ Javy (v °ad∞ detail∙ dokonce lepÜφ a s efektivitou blφ₧φcφ se C++. Otev°enΘ SDK, na n∞m₧ pracuje X.soft, bude Objective C samoz°ejm∞ podporovat. Bude takΘ podporovat tvorbu projekt∙ vyu₧φvajφcφch pro r∙znΘ Φßsti r∙zn²ch jazyk∙; i to je nynφ dost problematickΘ.
C++ SDK
Vzhledem k uvedenΘmu se dßle zam∞°φm jen na SDK C++, jeho₧ zßkladnφ koncepci navrhli v Psionu bohu₧el dost neÜ¥astn∞. P°edpoklßdß se toti₧, ₧e aplikace bude nejprve odlad∞na v tzv. "emulßtoru" Epocu. Tato myÜlenka mß dv∞ zßsadnφ nev²hody: p°edn∞, emulßtor je k dispozici jen pro Windows, tak₧e u₧ivatelΘ jinΘho prost°edφ majφ sm∙lu. Co h∙°, v∙bec nejde o emulßtor; je to jen port Epocu, hostujφcφ uvnit° Windows a vyu₧φvajφcφ jejich zdroje. Vzhledem k tomu b∞₧φ cel² emulßtor nad "cizφ" architekturou; proto odliÜnΘ jsou takΘ formßty jeho spustiteln²ch soubor∙, jin² je strojov² k≤d uvnit° nich, a dokonce se liÜφ i p°ekladaΦ, kter² se pro jejich tvorbu pou₧φvß! Zatφmco pro tvorbu cφlov²ch aplikacφ slou₧φ vcelku rozumnΘ GNU C++, aplikace pro "emulßtor" se vytvß°ejφ v MS Visual C++.
Epoc SDK proto dokß₧e vytvß°et aplikace t°φ typ∙: tzv. WINS, WINC a MARM. WINS jsou prßv∞ aplikace pro zmφn∞n² emulßtor; WINC jsou "epocovskΘ" aplikace, kterΘ lze spouÜt∞t p°φmo pod Windows. Na rozdφl od emulßtoru vÜak vyu₧φvajφ GUI Windows û ne Epocu û a majφ neomezen² p°φstup k windowsovsk²m zdroj∙m. Hlavnφm ·Φelem tΘto slu₧by je podpora konverzφ, na kterou se podrobn∞ podφvßme nφ₧e. KoneΦn∞ MARM jsou aplikace urΦenΘ pro prßci na cφlovΘ architektu°e (v souΦasnosti poΦφtaΦe s Epocem vyu₧φvajφ procesory ARM, odtud MARM).
Paradoxnφ je, ₧e tv∙rci tΘto "potvornosti" uvßd∞jφ, ₧e cht∞li "umo₧nit vyu₧itφ skv∞lΘho debuggeru" z MSVC. P°itom kter²koli u₧ivatel gdb, kter² musel pracovat v MSVC, jist∞ za₧il Üok: sice je vÜe v barevn²ch okΘnkßch, ale v∙bec nic to neumφ û dokonce nelze ani do okΘnka pro zobrazenφ hodnoty zapsat libovoln² v²raz!
V praxi je proto nejrozumn∞jÜφ vytvß°et aplikace p°φmo pro cφlovou platformu. K tomu slou₧φ GNU C++; standardn∞ bohu₧el op∞t v jakΘsi windowsovskΘ mutaci, je₧ obΦas p°inßÜφ podivnΘ problΘmy (nap°. nelze p°eklßdat zdrojovΘ k≤dy rozlo₧enΘ na vφce disk∙!). I p°esto je to tΘm∞° optimßlnφ û staΦφ vyu₧φt standardnφ distribuci GNU C++, a skoro bychom mohli pro Epoc vyvφjet kdekoli. Skoro proto, ₧e SDK Epocu vyu₧φvß n∞kolik proprietßrnφch konverznφch program∙, je₧ je zapot°ebφ nejprve upravit pro platformu, na nφ₧ chceme mobilnφ aplikace vyvφjet.
Tato "neportabilita" v²vojovΘho prost°edφ je jen doΦasnß. HorÜφ problΘm je bohu₧el s lad∞nφm: zatφmco samotnß tvorba epocovsk²ch aplikacφ v rßmci libovolnΘ architektury je otßzkou pom∞rn∞ krßtkΘho Φasu, je v souΦasnosti naprosto nejasnΘ, jak takovΘ aplikace ladit. Epoc nabφzφ pro lad∞nφ "emulßtor", ten je ale pou₧iteln² jen pod Windows a nenφ p°enositeln² (byl by, pokud bychom m∞li jeho zdrojovΘ texty; ty ovÜem k dispozici nejsou a t∞₧ko kdy budou).
Bude tedy zapot°ebφ nejspφÜe p°ipravit dopln∞k Epocu, umo₧≥ujφcφ remote lad∞nφ s vyu₧itφm gdb a sΘriovΘho kabelu, nebo napsat skuteΦn² emulßtor. Ani jedno bohu₧el nenφ jednoduchΘ; tvorba emulßtoru navφc narß₧φ na nedostateΦn∞ dokumentovan² hardware nejr∙zn∞jÜφch p°φstroj∙ pracujφcφch pod Epocem. Zdß se tedy, ₧e po n∞jakou dobu bude nutnΘ se p°i lad∞nφ spokojit s klasick²mi asserty a kontrolnφmi v²pisy.
Krom∞ GNU C++, dokumentace a °ady p°φklad∙ u₧ toho standardnφ v²vojovΘ prost°edφ moc nenabφzφ: nalezneme v n∞m jen n∞kolik perlov²ch script∙ a windowsov²ch "batch∙", kterΘ zajiÜ¥ujφ tvorbu a zpracovßnφ projekt∙. Tento systΘm je dost nepohodln² a mß °adu um∞l²ch omezenφ (nap°. slo₧ku, ve kterΘ projekt le₧φ, nelze p°ejmenovat, ani₧ bychom zßrove≥ zm∞nili projekt); proto ani nemß smysl uva₧ovat o jeho portu. Namφsto toho X.soft p°ipravuje SDK, vyu₧φvajφcφ standardnφch makefiles a GUI prost°edk∙ vΦetn∞ vizußlnφho programovßnφ (o kterΘm se Epocu v souΦasnosti bohu₧el ani nezdß). P°edb∞₧nΘ informace o novΘm SDK lze nalΘzt na www.ocs.cz/text/XSdk.
P°ehled slu₧eb Epocu
VÜechny slu₧by jsou k dispozici prost°ednictvφm t°φd C++ z dynamicky zavßd∞n²ch knihoven û toto °eÜenφ mß v²hody i nev²hody. Nev²hody jsou op∞t dßny omezenφmi jazyka C++. Jeliko₧ jde o statick² jazyk, nejsou zde k dispozici ani kategorie, o mo₧nosti dynamicky nahradit jednu t°φdu jinou u₧ v∙bec nemluv∞. Proto je problΘm s dopl≥ky a ·pravami systΘmu.
Na druhou stranu je to nejkorektn∞jÜφ mo₧nΘ °eÜenφ a patrn∞ nejpohodln∞jÜφ i z hlediska programßtora. Vzhledem k tomu, ₧e standardnφ knihovny jsou v pam∞ti ROM (dφky kvalitnφ sprßv∞ pam∞ti Epocu nenφ t°eba je zavßd∞t, ale jsou pln∞ a kdykoli k dispozici p°φmo na sv²ch "romkov²ch" adresßch), je spouÜt∞nφ aplikacφ velmi rychlΘ. Proto si Epoc m∙₧e snadno dovolit objektovou aplikaΦnφ architekturu (viz dßle).
Base
Skupina t°φd, sdru₧enß pod pojmem Base, nabφzφ zßkladnφ slu₧by pro "engine" aplikacφ: nalezneme zde kontejnerovΘ objekty, slu₧by pro prßci s buffery a textov²mi °et∞zci (API podporuje i UNICODE, avÜak implementace dosud nenφ tak daleko), pom∞rn∞ luxusnφ a efektivnφ systΘm odchycenφ a zpracovßnφ chybov²ch stav∙ a dalÜφ slu₧by.
File server
Zßkladnφ slu₧by pro prßci se soubory a₧ na mφrn∞ odliÜnΘ API velmi p°esn∞ odpovφdajφ klasick²m posixov²m soubor∙m. Epoc vÜak nabφzφ mnohem luxusn∞jÜφ slu₧by ne₧ naprostß v∞tÜina ostatnφch prost°edφ pro prßci s obecn²mi streamy. Architektura tzv. "stream stores" toti₧ podporuje rekurzivnφ vno°ovßnφ stream∙ nebo uklßdßnφ vφce stream∙ do spoleΦnΘho kontejneru. To je samoz°ejm∞ ideßlnφ pro vklßdßnφ dokument∙ (typu "obrßzek vlo₧en² v tabulce vlo₧enΘ v textovΘm dokumentu") a nabφzφ to velmi luxusnφ mo₧nosti i pro zapouzd°enφ dat. P°edstavte si textov² editor; je velmi p°irozenΘ û a z hlediska programßtora i velmi pohodlnΘ û ulo₧it Φist² text do jednoho streamu, formßtovacφ informace do druhΘho, do t°etφho nap°φklad jmΘno autora a do ΦtvrtΘho nastavenφ u₧ivatelskΘho rozhranφ (nap°. zoom)... Streamy se mohou sklßdat i "do sΘrie" û je nap°φklad velmi snadnΘ pracovat se streamem k≤dovan²m pomocφ hesla: prost∞ "nad" streamem se skuteΦn²mi daty otev°eme stream, kter² se starß o Üifrovßnφ, a k dat∙m p°istupujeme jeho prost°ednictvφm.
Databßze
Epoc standardn∞ obsahuje velmi luxusnφ databßzovΘ API a trochu mΘn∞ luxusnφ implementaci databßzov²ch slu₧eb. API nabφzφ skv∞lΘ slu₧by pro relaΦnφ databßzi vΦetn∞ p°φstupu s vyu₧itφm standardnφch SQL p°φkaz∙. KonkrΘtnφ implementace nabφzφ trochu omezen² subset SQL a je realizovßna jako sada slu₧eb na stran∞ klienta pro p°φstup k databßzov²m soubor∙m. Zatφm tedy nenφ k dispozici plnohodnotn² server se sdφlen²m p°φstupem k dat∙m. I tak jsou ale databßzovΘ slu₧by Epocu prakticky srovnatelnΘ nap°φklad s OpenBase Lite a mnohonßsobn∞ p°evyÜujφ slu₧by databßzφ z wintelu (nap°. FoxPro).
AplikaΦnφ architektura
Architektura aplikacφ Epocu je pom∞rn∞ d∙slednou implementacφ pln∞ objektovΘho pohledu, kdy vlastn∞ aplikace jako takovΘ neexistujφ, ale systΘm obsahuje slu₧by pro zpracovßnφ r∙zn²ch druh∙ dokument∙. To samoz°ejm∞ p°inßÜφ urΦitΘ problΘmy (nap°. s otevφrßnφm jednoho dokumentu v r∙zn²ch aplikacφch), ale v²znamn∞ to usnad≥uje ₧ivot laickΘmu u₧ivateli, kter² se o v²poΦetnφ techniku nezajφmß a studovat ji nechce û chce prost∞ jen pou₧φvat ten Φi onen p°φstroj. To dnes ji₧ platφ dokonce i o v∞tÜin∞ u₧ivatel∙ poΦφtaΦ∙; docela jist∞ to platφ o drtivΘ v∞tÜin∞ u₧ivatel∙ mobilnφch p°φstroj∙, od telefon∙ a₧ po organizΘry.
U₧ivatel tedy v∞tÜinou nepracuje s "aplikacemi", ale namφsto toho jen zavφrß a otevφrß "dokumenty". Pojem "aplikace" û a n∞kterΘ na n∞j vßzanΘ prvky u₧ivatelskΘho rozhranφ û z∙staly zachovßny p°edevÜφm kv∙li aplikacφm, je₧ s dokumenty nepracujφ (nap°. hry). Dokumentem aplikace je v₧dy stream store; v tomto p°φpad∞ navφc obsahuje sΘriovΘ Φφslo, je₧ jednoznaΦn∞ identifikuje aplikaci, kterΘ dokument pat°φ. Podobn∞ jako u Macintoshe tedy neexistuje ₧ßdn² problΘm s p°φponami, proto₧e typ dokument∙ se podle nich neurΦuje. Epoc navφc obsahuje podporu i pro p°i°azenφ "obyΦejn²ch soubor∙" s danou p°φponou nebo s definovan²m obsahem konkrΘtnφ aplikaci, tak₧e je mo₧nΘ je "importovat" prost²m otev°enφm, stejn∞ jako otevφrßme-li dokument.
Cone a Eikon
VyÜÜφ vrstvy aplikaΦnφ podpory jsou v Epocu rozd∞leny na dv∞ ·rovn∞. Ni₧Üφ z nich, Cone, obsahuje abstraktnφ slu₧by u₧ivatelskΘho rozhranφ a grafick²ch prvk∙ bez vazby na jejich konkrΘtnφ implementaci. Teprve jasn∞ odd∞lenß vyÜÜφ vrstva, Eikon, p°idßvß t∞mto prvk∙m konkrΘtnφ vzhled a chovßnφ. Toto rozd∞lenφ dßvß Epocu neobvyklou flexibilitu u₧ivatelskΘho rozhranφ: dφky spoleΦnΘmu API Cone jsou aplikace û nebo alespo≥ drtivß v∞tÜina jejich k≤du û p°enositelnΘ mezi r∙zn²mi implementacemi, nabφzejφcφmi prost°ednictvφm r∙zn²ch Eikon∙ r∙znß u₧ivatelskß rozhranφ.
TΘto mo₧nosti samoz°ejm∞ vyu₧φvajφ malß specializovanß za°φzenφ: zatφmco kapesnφ poΦφtaΦ Ericsson MC218 mß "obyΦejn²" Eikon, inteligentnφ mobil Ericsson R380 nabφzφ odliÜnΘ u₧ivatelskΘ rozhranφ dφky p°epracovanΘmu Eikonu. P°itom zachovßvß se vÜemi ostatnφmi implementacemi Epocu zßkladnφ kompatibilitu. Jin²m p°φkladem vyu₧itφ tΘto slu₧by je ji₧ zmφn∞nß (oficißln∞ dosud nepotvrzenß) aktivita firmy Nokia, je₧ p°ipravuje Eikon s u₧ivatelsk²m rozhranφm odpovφdajφcφm oblφbenΘmu PalmOS.
Konverze formßt∙
Pro konverze nabφzφ Epoc nov², netradiΦnφ p°φstup, kter² bohu₧el, podobn∞ jako SDK s "emulßtorem" pod Windows, p°inßÜφ vφce problΘm∙ ne₧ v²hod. Epoc toti₧ nepublikuje formßty sv²ch dokument∙ a mφsto toho nabφzφ "engine" ka₧dΘ standardnφ aplikace jako dynamicky zaveditelnou knihovnu. P°evodnφk "z Epocu ven" tedy nepot°ebuje znßt formßt, proto₧e data naΦte prost°ednictvφm slu₧eb samotnΘ aplikace, je₧ je vytvo°ila; dalÜφ standardnφ slu₧by vyu₧ije pro p°φstup k t∞mto dat∙m a na jejich zßklad∞ generuje v²stupnφ formßt. Obdobn∞ je tomu u p°evodnφku "do Epocu": ten pomocφ standardnφch slu₧eb aplikace vytvo°φ prßzdn² dokument a zaplnφ jej daty, je₧ vytvo°φ na zßklad∞ "importovanΘho" souboru.
Prßv∞ pro tyto konverznφ programy slou₧φ "architektura" WINC, podporovanß SDK. Epoc toti₧ pova₧uje za samoz°ejmΘ, ₧e takovΘto konverze budou pracovat na stolnφm poΦφtaΦi. Tato ·vaha je vÜak hluboce chybnß, a to ze dvou p°φΦin:
- WINC podporuje jen Windows; podobn∞ "engines" aplikacφ existujφ jen jako dynamicky zavßd∞nΘ knihovny pro Windows (jen jedin² "engine" textovΘho editoru je k dispozici i ve zdrojovΘm tvaru; to je ovÜem mßlo platnΘ, proto₧e vyu₧φvß API Epocu, a je proto p°elo₧iteln² zase jen pro WINC);
- dokonce ani pro u₧ivatele Windows to ale nestaΦφ: konverze formßt∙ jsou zapot°ebφ Φasto i ve chvφli, kdy ₧ßdn² desktop nenφ k dispozici û nap°φklad dostaneme-li e-mail s attachmentem prost°ednictvφm GSM modemu.
Proto X.soft p°ipravuje univerzßlnφ konverznφ architekturu XConversion, je₧ pracuje p°φmo v Epocu a zajiÜ¥uje oboustrannΘ konverze datov²ch formßt∙ podle pot°eby. Na rozdφl od kompletnφho portabilnφho SDK, je₧ bude k dispozici v dlouhodobΘm v²hledu, je systΘm XConversion t∞sn∞ p°ed dokonΦenφm. P°edb∞₧nΘ informace o tΘto technologii lze nalΘzt na www.ocs.cz/text/XSdk/WhatsXConversion.html a www.ocs.cz/text/XSdk/XConversion.html.
Ostatnφ
Epoc obsahuje dlouhou °adu dalÜφch knihoven a slu₧eb: luxusnφ knihovnu pro °φzenφ a spoluprßci s GSM telefony, kompletnφ TCP/IP a IrDA stack i slu₧by pro sdφlen² p°φstup k databßzi kontakt∙ a k ·daj∙m v elektronickΘm diß°i vΦetn∞ standardnφch prost°edk∙ pro jejich export a import (vCard). O °ad∞ dalÜφch slu₧eb se pro omezen² prostor ani nezmi≥uji.
N∞kterΘ dalÜφ slu₧by, je₧ Epoc sßm o sob∞ nenabφzφ, budou i souΦßstφ SDK, na kterΘm pracuje X.soft. Ji₧ nynφ jsou v rßmci velmi omezenΘ podpory XConversion p°ipraveny nap°φklad obecnΘ beztypovΘ kontejnery, poloautomatick² garbage collector, hash tabulky nebo luxusnφ t°φda pro prßci s textov²mi °et∞zci, podporujφcφ °adu standardnφch osmibitov²ch k≤dovßnφ (vΦetn∞ vÜech t∞ch, kterß se pou₧φvajφ pro ΦeÜtinu) i Unicode.
Shrnutφ
Epoc je velmi kvalitnφ modernφ operaΦnφ systΘm, kter² nabφzφ vÜechny odpovφdajφcφ slu₧by (jako je ochrana pam∞ti nebo preemptivnφ multitasking). Jeho zajφmavost spoΦφvß i ve ÜpiΦkovΘ podpo°e specifick²ch vlastnostφ mobilnφch za°φzenφ, ve vysoce flexibilnφm u₧ivatelskΘm rozhranφ a v ÜirokΘ podpo°e od velk²ch firem (Nokia, Ericsson, Motorola, Panasonic, Sony...). Korektn∞ podporuje nejd∙le₧it∞jÜφ standardy (TCP/IP, IrDA, v budoucnosti BlueTooth...).
Stßvajφcφ standardnφ SDK sice nabφzφ velmi solidnφ paletu knihoven s pom∞rn∞ luxusnφmi slu₧bami, je vÜak omezeno jazykem C++ a p°edevÜφm striktnφ orientacφ na MS Windows. Alespo≥ potencißln∞ vÜak umo₧≥uje vyÜÜφ portabilitu ne₧ jinß °eÜenφ, a to dφky tomu, ₧e jeho zßkladem je pln∞ p°enositeln² p°ekladaΦ GNU C++. Ji₧ nynφ X.soft rozbφhß projekt, jeho₧ cφlem je pln∞ portabilnφ SDK, podporujφcφ i daleko lepÜφ Objective C, ale i t°eba Fortran Φi kompilovanou (a proto rychlou) Javu.
Ze vÜech t∞chto d∙vod∙ je Epoc p°inejmenÜφm pro n∞kolik nejbli₧Üφch let patrn∞ softwarovou budoucnostφ mobilnφch systΘm∙.