Laicky řečeno: namíříte mobil do ulice a na displeji se Vám ukáže, v jakých místech je přístupový bod sítě WIA. Okamžitě pak víte, zda-li na onen konkrétní bod vidíte, či jak daleko přesně je (to je velice užitečné info). V neposlední řadě také vysílaná SSID a jiné informace.

Cíle tohoto projektu jsou poměrně jasné:

• zvýšení efektivity práce techniků montujících určité služby WIA spol. s r.o.
• pomoc běžným uživatelům s lokalizací přípojného bodu služby
• seznámení se s novou technologií a její implementací v praxi

Jak to funguje?

Jako platformu pro tento projekt, jsem zvolil ze dvou možných kandidátů tu s názvem Layar. Druhý byl Wikitude. Ten ale bohužel v době vytváření projektu neumožňoval registraci developerů a tak jsem skončil u Layaru.

Layar jako takový, je v podstatě pouze prostředníkem mezi telefonem a vytvořenou databází. Stará se o viditelnost jednotlivých POI, design a v neposlední řadě také o viditelnost v katalogu jednotlivých “layerů”.

Vše začíná v databázi postavené např. na MySQL (v mém případě). Dále je potřeba vytvořit PHP API skript, který bude převádět data z MySQL do JSON formátu (tomu rozumí Layar klient). Mezi tímto je ještě PHP rozhraní umožňující administrátorovi editovat, přidávat a konfigurovat jednotlivé položky v databázi.

Klient pro zobrazování layerů existuje na většinu předních platforem – Android, Symbian, iOS. Tedy je dostupný úplně všem s “chytrým” mobilním telefonem. Pro vetší přesnost doporučuji mít zařízení vybavené GPS modulem, zaměření přes bezdrátové sítě je velice nepřesné.

Jak jsme na tom?

V současné době plním databázi testovacími daty. Bohužel to jde pomalu, jelikož času nemám mnoho a své PHP rozhrání nemám zrovna “user friendly” i když na tom také pracuji. Layar s odpovídajícím názvem “Pokrytí WIA” je momentálně v developerské fázi a předpokládané publikování veřejnosti nastane v době, kdy budou doplněny minimálně všechny hotspoty v Chebu. Pak plánuji už doplňovat hotspoty za běhu.

V aktuální verzi je obsažený pouze jeden vyhledávací filtr – vzdálenost. Lze si tak nastavit maximální vzdálenost od Vaší pozice, do které se budou hotspoty zobrazovat.

Co se chystá?

• 3D vrstva s pokrytím služby WIA FIX
• filtr vyhledávání jen na vybrané služby
• modernizace ikonek mapy – HOTOVO
• zařazení všech hotspotů do databáze

Jak to tedy vypadá?

Předevčírem večer mě přepadla neskutečná nuda a lenost a při 23. flashi T-Mobile G1 už mne neskutečně štvalo vyťukávat stále “adb push nejakynazevrom.zip /sdcard“. Pustil jsem tedy Visual Studio a začal tvořit jaký-si front end pro tento program. Jde to poměrně od ruky i když narážím na problémy (například adb.exe neumí přesměrovat výstup do textového souboru což znamená, že zobrazit skrytý shell v mojí aplikaci bude velice obtížné). Těď už má ADB Suite pěknou řádku fcí. Od instalace APK souborl z počítače, přes wipe, restart do různých režimu až p ovytočení telefonního čísla.

Vždy aktuální changelog a odkaz ke stažení naleznete na Smartmania.cz v tomto vláknu fóra. Doufám, že bude program alespoň někomu k užitku

Ve firmě se používal do nynějška jeden email. Byl hostovaný u  Seznam.cz, což samozřejmě nevypadalo moc dobře. A jelikož jsme dostali T-Mobile G1 jako nové služební telefony, volba byla jasná. Odzkoušené Google Apps nasadit do firmy.

Požadavky nebyly nijak přehnané jelikož se jedná o small business prostředí:

• pro skupinu G1 jednotnou emailovou “hotline” schránku
• pro tu samou skupinu sdílený adresář včetně kategorizace tzn. třídění kontaktů, možnost volby synchronizace + adresář, který bude pro každou G1 unikátní (soukromá čísla)
• sdílený kalendář s možností organizace nejen vlastního kalendáře
• on-line textová komunikace pomocí Google Chat

Nic složitého. I přesto jsem při realizaci narazil na některá omezení ať už ze strany Google Apps nebo samotného T-mobile G1. Asi největším problémem, který se mi do teď nepodařilo vyřešit je kategorizace kontaktů. G1 sice podporuje skupiny a jejich synchronizaci, avšak jejich spravování už ne! Při vytváření nového kontaktu tak není možné ho zařadit např. do skupiny “zákazníci” nebo do jakékoli jiné. Snad se dočkáme této funkce v dalším cupcake systému pro G1. Díky tomu padá i možnost mít v telefonu vlastní neveřejnou skupinu kontaktů (soukromá čísla) která by se nikam nesynchronizovala. Ne že by to nebylo možné, telefon umí krásně vybrat skupiny které synchronizovat má, a které ne. K čemu to ale je, když každý nový kontakt je vytvořený v defaultní skupině (a nejdě to nijak změnit – pouze v PC s internetem)? U aplikace kontaktů jsem si ještě všiml, že i když ve webovém rozhraní emailu vytvoříte pro kontakt skupinu, synchronizuje se do G1 jen jako poznámka.

Nakonec jsem to vyřešil jedním uživatelem “servis@domain.tld” na kterého se přihlašují všechny G1ky ve firmě. Bohužel tím padá méně prioritní textová komunikace v rámci Google Chatu a samozřejmě soukromý adresář pro každého uživatele.

kalendář je naprosto bez problémů,když nepočítám, že nechtěl sesynchronizovat “podkalendáře”. Po nějakém čase tam jeden skočil, takže by do rána byli asi všechny. Pro naše účely postačí a výše zmiňované možnosti má.

Právě v možnostech kontaktů mě Google docela zklamal. Tiše doufám že vše napraví v dalším updatu, který ale bude bůhví kdy. Také doufám, že výrobci navigací se brzo umoudří a vydají nějakou off-line navigaci. Po dnešním testu jsem usoudil že GPS čip v T-Mobile G1 je zřejmě ten nejlepší, se kterým jsem měl tu čest se v mobilních zařízeních setkat. A GPS je fce která by rozhodně při hledání některých zákazníků hodně pomohla .

Když dorazila krabice, pomyslel jsem si “a hele, další strojek od HTC” a nebyl sem daleko od pravdy. G1ku pro T-Mobile opravdu vyrábí HTC, tedy přední výrobce komunikátorů s operačním systémem Windows Mobile.

Je to hezký stroj, který mě nadchnul, ale i v mnohém zklamal. Útěchou  je mi pouze to, že většinu nedostatků se aspoň daří pravidelně odstraňovat tzv. cupcakes tedy updaty systému. Ten poslední například obsahoval české prostředí, softwarovou klavesnici, podporu A2DP a jiné drobnosti.

Uvidíme po pár měsících pracovního nasazení, jestli poletí oknem, nebo vystřídá můj současný telefon HTC Diamond.

Moje mobilní historie obsahuje spoustu zařízení… od mého prvního telefonu Siemens C10, přes Sony Ericsson T300 až po právě odcházejicí iPaq 614c. Platformu Windows Mobile jsem si oblibil již před lety z důvodu její skvělé variability. To se o Symbianu (kterému jsem do té doby holdoval) říci nedalo.

Tady bych chtěl, hlavně pro nového majitele mého iPaqu shrnout krátce historii tohoto stroje v mých rukou.

iPaqa jsem předobjednávál v únoru loňského roku u ATC, byl to kus z první várky iPaqů do ČR (pokud si dobře vzpomínám, obchoďák ATC  tvrdil prvních 12 ks v ČR)  a po pár týdnech konečně dorazil.

Byl jsem nadšen, na svojí dobu uměl iPaq doslova všechno (snad jen krom rádia což mi v té době opravdu nevadilo). Následovalo nalepení fólie (která je na displeji dodnes a je opravdu kvalitní) a umístění do pouzdra od PDAir (ve kterém je také prakticky dodnes).

Zhruba po měsíci proběhl první flash zařízení, nejdříve originální HP ROM a zhruba o týden později ROM od Yevga, kterou po náležitých updatech používám dodnes. Dnešní podoba této ROM se podobá ROM pro HTC zařízení (TouchFlo atd.) což umožnilo začít iPaq používat opravdu na maximum a ovládat ho jednou rukou a pouze prsty.

Po nějaké době sem pro iPaq napsal freeware program který pomáhal řešit maličké drobnosti např. po hard resetu či flashi ROM – iPaq 614 Utils, který si od jeho uvedení stáhlo více jak 1000 uživatelů!

Pak následovalo už jen poklidné období zapisování poznámek, plánování jednání v kalendáři, výkazy pracovních hodin, posílání emailů, navigování a volání. Ano, sem tam se objevil nějaký problém jako např. samovolné vypínání bez upozornění… na to ale HP velice rychle vydalo záplatu a dodnes nové ROM od HP vycházejí.

Zařízení prošlo jedinou “reklamací” a to, že se poškodil zadní kryt baterie tak, že neudržel stylus vevnitř. Stačil krátký telefonát na HP a za tři dny jsem měl kryt doma nový.

Doufám, že novému majiteli přinese tolik užitku jako mě a že s ním bude spokojený.

Pokud i Vás potkal podobný problém, přečtěte si návod jak to napravit, který jsem zveřejnil na Smartmania.cz

O to víc mě to těší, protože diskuze u článku je víceméně pozitivní a za prvních 24 hodin jej shlédlo celých 1500 lidí. Mám radost z dobře napsaného textu a doufám že to není můj poslední .

Každý bod na obrazovce, tedy pixel, je reprezentován 16 bity. Těchto 16 bitů udává barvu pro onen pixel. Přesněji jde o 5 bitů červené, 6 bitů zelené a 5 bitů modré barvy. Toto složení se také nazývá jako RGB 565. Pokud bychom měli zařadit do škály barevných formátu i 18 bitovou hloubku (to znamená 262 tisíc barev), jednalo by se o 6 bitů na každou barvu. Tedy RGB 666.

Další věc, kterou je třeba pochopit je, jak proměnit bit na obrazovce v barvu. Představme si například klasické Pocket PC s rozlišením displeje 240×320 obrazových bodů (pixelů) s barevností 65536 barev. To znamená 320 řádků a 240 obrazových bodů, kde každý z nich má 16 bitů představujících barvu. Všechny tyto informace jsou uloženy v paměti známé jako frame buffer. Hardware obrazovky tedy vezme obsah tohoto frame bufferu a zkonvertuje ho přímo na obrazovku. Chcete změnit obraz, pak musíte změnit obsah frame bufferu.

Potřebujeme tedy 16 bitů pro každý pixel, a celkem máme u QVGA displeje 240×320 bodů. 16 bitů jsou 2 byty, což znamená celkový počet 153600 bytu, tedy zhruba 150kB z RAM použité pro vykreslení obrazovky. Jednoduchý vzorec pro výpočet velikosti frame bufferu tedy je (A x B) x C, kde A je osa X, B je osa Y a C je počet bytů v bitové hloubce (například v 16 bit jsou byty 2). Z přiloženého grafu jsou vidět rozdíly.

Z grafu je patrné, že rozdíl mezi jednotlivými hloubkami vůbec není malý, zvláště pak v případě 16 versus 32 bit, kdy hodnoty dosahují dvojnásobku hodnot původních. Obrovský rozdíl je také u QVGA a VGA displejů, kde je paměťová náročnost VGA zhruba čtyřnásobná.

Zajímavost: Tímto zároveň vyvracíme mýtus o tom, že VGA není o nic víc náročnější, než QVGA. Zatímco QVGA displej spotřebuje na jedno překreslení obrazovky 153,6 kB, tak VGA potřebuje 4× tolik, tedy 614,4 kB. Z toho vyplívá, že když si pustíte film při standardních 25 FPS, vaše Pocket PC s VGA displejem a 64 mB RAM bude muset začít přepisovat obsah framebufferu už po nějakých 9 vteřinách, tedy za předpokladu, že budete mít celých 64 mB volné RAM k dispozici. U QVGA displeje by se jednalo už o celých 16 vteřin, což dává procesoru dostatek času na další operace. Rychlost zařízení s VGA displejem tedy silně ovlivňuje procesor a rychlost vnitřní sběrnice společně s RAM. Proč tedy výrobci stále vyrábí zařízení s VGA displeji a 64 mB RAM? Jednoduše pro to, že zřejmě jsou jejich produkty určeny nenáročným uživatelům, kteří nekladou až takový důraz na multimédia, ale spíše na statické zobrazení obrazovky Dnes a sem tam nějaké to tapnutí, nebo že by doprodávali staré chipsetové zásoby?

Moderní procesory jsou schopné pracovat s 32 bity, což je optimální pro práci s 16 a 8 bitovou hloubkou barev. Proč tedy ne 262144 barev, respektive 18 bitů? Protože je pixel 16 bitový a procesor zvládá 32 bitů, stihne zapsat 2 pixely najednou během jednoho cyklu. Co by se ale stalo, pokud by byl pixel 18 bitový? První pixel by prošel bez problémů, druhý ale ne a čekal by až na další cyklus. Tím pádem 15 z každých 16 pixelů by bylo vykreslováno způsobem, který by byl naprosto neefektivní. 18 bitů si prostě s 32 bitovým systémem moc rozumět nebude. K pochopení vám jistě pomohou následující tabulky:

Každá barva znázorňuje 1 pixel. Je jasně patrné, že u 32 a 16 bitů nezůstává žádný nevyužitý bit. Z uvedeného také vyplívá, že použití 24 bitů je pouze o trochu nevýhodnější než při použití 16 bitů. Nevyužitých bitů je zde 8 a je to tedy stále podstatně výhodnější, něž použití 18 bitů, kde zůstane v jednom cyklu celých 14 nevyužitých bitů. Z tohoto důvodu prostě formát „RGB 666“ neexistuje. Není nativně podporován v žádném operačním systému (CE, XP, Mac, Unix, Palm či Symbian).

Ale počkat, teď vám to nesedí? Všude přece vídáme reklamy na mobilní telefony vybavené displeji s 262144 barvami. Jak je to tedy možné? Musí přece podporovat 18 bitovou barevnou hloubku, ale není tomu tak. Tato zařízení podporují 24 bitovou hloubku, ale zahodí 6 z 8 bitů navíc, což jsme si vysvětlili o odstavec výše. Existují dva způsoby, jak vytvořit 24 bitové barvy. V obou případech je k dispozici 8 bitů pro červenou, zelenou a modrou, tedy „RGB 888“, kde v případě prvním má každý pixel 24 bitů a případě druhém má bitů 32, zbylých 8 je pak pro transparentnost nebo jednoduše zůstanou nevyužity.

32 bitů je skvělá hodnota pro použití s procesorem. Znamená to jeden pixel na každých 32 bitů. 24 bitů už není tak dobré jako použití 32 bitů, ale je to podstatně lepší než použití 18 bitů. Při použití 24 bitů využijeme tedy pouze 18, čímž plýtváme pouze 6 bity z každých 24 oproti 14 bitů z každých 32 bitů. Je to zkrátka pořádná matematika.

Tento displej firmy SparkFun je typickým příkladem využití 18 bitové hloubky. Při parametrech QVGA (35×45mm) využívá 18 bitové rozhraní. Z výše uvedeno tedy vyplívá, že v 24 bit hloubce bude vše pomalejší než na 16 bitech. Windows CE zvládá obě formy (24 i 32 bitů). Pokud OEM výrobce tedy opravdu chce využít 18 bitů na displeji, má možnost. Otázkou ale zůstává, je opravdu potřeba tolik barev? Je vůbec k něčemu dobré investovat do takového vývoje, když lze stupínek přeskočit a pokračovat na lepší hodnoty?

Kdy tedy budeme mít na displejích našich komunikátorů více barev? Nejdříve potřebujeme obrazovky, které využijí plných 24 bitů. 24 bitů je funkčně stejně „rychlých“ jako 18 bitů, a 18 bitů je zase opravdu minimální rozdíl oproti 16 bitům. Nemá tedy smysl snažit se dosáhnout 18 bitové hloubky, ale mnohem výhodnější je dosažení 24 bitové. Pak také potřebujeme dostatečně výkonná zařízení, která dnes na trhu opravdu nejsou. Stále nás omezuje velikost operační paměti RAM a rychlost procesoru.

Nové displeje přitom jsou již dávno k dispozici. Otázkou tedy zůstává, proč je výrobci neimplementují? 24bitové displeje s přímou podporou tohoto rozhraní a také podporou mobilních CPU, tedy včetně různých ARM, vyrábí firma Sharp již poměrně dlouhou dobu. Na obrázku vidíte displej pro Sony PSP s 24 bitovou sběrnicí, který je možné doplnit o dotykovou vrstvu (opět od stejného výrobce).

Po softwarové stránce tedy není co řešit. Operační systémy již dovedou využívat celou škálu bitových hloubek; tedy 1, 2, 4, 8, 16, 24 i 32 bitovou podporu, a to včetně Windows CE. Zavést proto podporu do Windows Mobile by neměl být ze strany Microsoftu žádný problém. Jisté omezení by bylo ze začátku u autorů aplikací, kteří by museli svůj program naučit pracovat s novou barevnou hloubkou. Nezbývá tedy než doufat, že si této skutečnosti výrobci brzy uvědomí a například namísto nekvalitních a mnohdy i nevyužitelných fotoaparátů, začnou vybavovat své komunikátory lepšími displeji. Displej je přece jenom u komunikátorů, a zvláště těch s dotykovým rozhraním, jednou z nejdůležitějších částí.

Changelog ver. 5:

• přidaná česká xT9 s podporou HW klávesnice
• přidána česká SIP klávesnice (Resco)
• program jsem vrátil zpět do češtiny

Program stáhnete zde. NET CF 3.5 který je potřebný pro běh programu poté tady.

[donation]