Vyvíjíme pro Android – úvod

16. 3. 2011 | Tomáš Kypta | Programování | 55255×

Operační systém Android se na trhu mobilních telefonů objevil teprve nedávno. Od té doby zaznamenal raketový růst a dnes je jedním z nejpoužívanějších operačních systémů pohánějících chytré telefony. Spolu s rozšířením systému roste také poptávka po zajímavých aplikacích. V krátkém seriálu si ukážeme základy programování aplikací pro Android.

V tomto dílu si nejprve krátce povíme něco o samotném systému, představíme si vývojové nástroje a řekneme si něco o principech, na jakých OS Android funguje.

Obsah

• Co je to Android a trocha historie
• Vnitřnosti Androidu
• Vývoj a dostupné nástroje
• Obsah SDK
• SDK komponenty
• Další zdroje
• Aplikační principy
  • Activity
  • Service
  • Broadcast receiver
  • Content provider
  • Android manifest
  • Volání komponent a běh aplikace
  • Task
• Závěr

Co je to Android a trocha historie

Android je open source platforma pro mobilní zařízení, která je založená na pozměněném linuxovém jádře. Systém byl původně vyvíjen firmou Android Inc., kterou v roce 2005 koupil Google. V roce 2007 pak byla založena Open Handset Alliance skládající se z několika desítek firem – kromě Googlu jsou to převážně výrobci mobilních telefonů, polovodičových součástek a také mobilní operátoři. OHA zastřešuje vývoj otevřených standardů pro mobilní zařízení a má za úkol kooperovat vývoj operačního systému Android.

Vnitřnosti Androidu

Platforma se kromě linuxového jádra skládá z řady C/C++ knihoven – např. systémová libc, knihovny pro práci s médii, knihovny enginu webového prohlížeče, knihovny grafického enginu, SQLite knihovny a mnoho dalších.

Systém dále obsahuje Dalvik Virtual Machine, který slouží pro vykonávání bytecodu, na kterém jsou postaveny vyšší vrstvy systému. Dalvik Virtual Machine ale není Java Virtual Machine a používaný bytecode není Java bytecode. Přesto, jak mnozí vědí, se pro Android programuje primárně v Javě. Jak to? Android SDK (které rozebírám dále) obsahuje nástroj dx pro převod Javovských .class souborů do Dalvikovských .dex souborů. Při převodu se mimo jiné konvertuje Java bytecode do Dalvik bytecode. Měl bych ještě zdůraznit, že převod není stoprocentní, ne vše z Javy lze použít na Androidu, aplikace se tedy neprogramují v plnohodnotné Javě.

Systémové aplikační rozhraní, které aplikacím zprostředkovává nejrůznější API, je pak už stavěno nad virtuálním strojem. Součástí platformy je také řada už hotových aplikací – např. správce kontaktů, prohlížeč nebo samotná aplikace pro telefonování.

Vývoj a dostupné nástroje

Na oficiální vývojářské stránce na developer.android.com je pro vývoj dostupná řada nástrojů, dokumentace a další zdroje. Nejdůležitější je zde SDK, bez kterého nic nevytvoříte. Díky vřelému vztahu Googlu k Linuxu je dostupné pro všechny hlavní platformy – Linux, Mac i Windows. SDK v základu obsahuje pouze některé vývojové nástroje, další části se doinstalovávají jako komponenty. Jednotlivé komponenty a další nástroje obsažené v SDK si rozebereme dále.

Pro vývoj aplikací, jejichž odezva je kriticky důležitá (především pro hry), lze využít Android NDK, což je balík pro vývoj Android aplikací v C/C++. Vývoj aplikací využívajících NDK je pokročilejší téma a nebudeme se jím zde zabývat.

Kromě SDK a NDK si lze stáhnout oficiální ADT plugin pro Eclipse, který značně usnadňuje vývoj a ladění aplikací. Protože je Eclipse díky svému pluginu primárním IDE, ve kterém se pro Android vyvíjí, budu ho dále v průběhu seriálu používat při tvorbě kódu a některé popisy a screenshoty se k němu budou vztahovat.

Pokud ovšem nejste fanouškem tohoto IDE, jsou tu i jiná řešení. Pro NetBeans existuje plugin pro vývoj Android aplikací, více o něm naleznete na kenai.com. V Intellij IDEA je od verze 10 také možné vyvíjet aplikace pro Android, více informací naleznete na jetbrains.com.

Obsah SDK

Holé SDK obsahuje pouze několik programů v adresáři tools. Asi nejdůležitější položkou je program android, kterým se spouští Android SDK and AVD Manager. Přes něj se stahují jednotlivé komponenty SDK – různé verze platformy Android a další rozšíření.

Android SDK mimo jiné obsahuje emulátor androidích zařízení. Emulátor je samostatná desktopová aplikace umožňující testování aplikací bez mobilního zařízení. Pomocí Android SDK a AVD Manageru lze vytvářet a spouštět Android Virtual Devices – nakonfigurované instance emulátoru. Lze si tak velice přesně vymodelovat vlastnosti konkrétního zařízení. Pokud je to pro ladění potřeba, lze spouštět více instancí emulátoru zároveň, jednotlivá AVD ovšem nelze spustit vícekrát současně. Pro spouštění instancí emulátoru lze také použít příkaz emulator, který má širokou škálu parametrů sloužících k další úpravě konfigurace AVD.

Dalším důležitým programem v SDK je ddms, jenž spouští Dalvik Debug Monitor – nástroj, s jehož pomocí lze ladit aplikace. Program umí komunikovat jednak s běžícími instancemi emulátoru, ale také s připojenými telefony. Pro ladění aplikací přímo v telefonu je nutné v nastavení telefonu povolit ladění přes USB (přepínač naleznete v sekci Aplikace -> Vývoj). Dále je ještě nutné nastavit počítač, aby zařízení rozpoznal – konkrétně v Ubuntu je třeba:

• jako root vytvořit soubor /etc/udev/rules.d/51-android.rules
• do tohoto souboru přidat řádky ve tvaru: SUBSYSTEM=="usb", SYSFS{idVendor}=="18d1", MODE="0666"
  
  • místo „18d1“ uveďte příslušné id výrobce telefonu - to zjistíte na počítači po připojení zařízení např. pomocí příkazu lsusb (hodnota „18d1“ je pro Google Nexus One)
• přidat souboru práva pro čtení: chmod a+r /etc/udev/rules.d/51-android.rules

Ještě pro úplnost dodám, že aby bylo možné aplikaci ladit, je v ní třeba provést malou úpravu v manifestu, o kterém se zmíním později.

Dalvik Debug Monitor umí mimo jiné zobrazovat logy přicházející z celého systému, simulovat různé akce emulátoru nebo zobrazovat různé ladící informace z virtuálního stroje. Aplikaci lze také využít pro získání screenshotů obrazovky – pro nerootované telefony je to prakticky jediný způsob, jak je vytvořit.

SDK komponenty

Nejdůležitějšími komponentami v SDK jsou platformy Androidu. Ty odpovídají produkčním platformám běžícím na skutečných zařízeních. Momentálně jsou dostupné verze 1.5, 1.6, 2.1, 2.2, 2.3.1, 2.3.3 a nově také verze 3.0. Každá platforma obsahuje systémové knihovny, systémový obraz, skiny emulátoru, ukázky kódu a jiné zdroje specifické pro platformu.

Android SDK Platform-tools je balík obsahující další vývojové nástroje, důležitý je zde především program adb – Android Debug Bridge. S ním lze např. na zařízení nahrávat soubory nebo aplikace. Program aapt slouží k vytváření a modifikaci aplikačních balíků.

Dalšími komponentami jsou balíky Google API, jenž jsou dostupné pro každou verzi platformy a obsahují knihovny Google map, které jinak nejsou základní součástí platformy. Pokud chcete vyvinout aplikaci využívající interně Google Mapy, budete tyto balíky potřebovat.

Market Licensing package obsahuje License Verification Library – knihovnu umožňující ověřování licence aplikace. Knihovna umí kontrolovat, zda byla běžící aplikace zakoupena a nejedná se o černou kopii. V SDK je též k dispozici komponenta GALAXY Tab Addon – emulátor Samsung Galaxy Tabu.

Další zdroje

Kromě oficiální stránky developer.android.com lze na webu najít spoustu dalších zdrojů. Nejnovější inoformace ohledně Androidu naleznete na oficiálním blogu android-developers.blogspot.com. A protože je Android open source, můžete si stáhnout i zdrojové soubory k celému systému na stránkách source.android.com.

Aplikační principy

Android aplikace jsou zkompilované zdrojové soubory, které jsou společně s dalšími resourcy zabalené do ZIP balíku s koncovkou .apk – takzvaného Android package. Ten slouží k distribuci aplikací a jejich instalaci na zařízení.

Jak už bylo zmíněno, Androidí aplikace se programují v „Javě“ a běží nad virtuálním strojem, který běží na linuxovém jádře. Každá spuštěná aplikace má svůj vlastní virtuální stroj.

Základní vlastností Androidu je možnost využít části jiných aplikací ve své aplikaci. Důvod k tomuto řešení byl prostý – zamezit opakovanému vytváření stejné funkcionality a usnadnit tak vývojářům práci. K tomuto účelu byly aplikace navrženy jako balíky několika komponent, které lze samostatně instanciovat. Existují čtyři typy komponent: activity, service, broadcast receiver a content provider, přičemž každá z těchto komponent slouží k jinému účelu. Postupně si je nyní projdeme.

Activity

Aktivita je základní vizuální komponenta – každá aktivita specifikuje jednu obrazovku aplikace. Představme si třeba e-mailového klienta, kde jedna aktivita zobrazuje seznam přijatých e-mailů, jiná aktivita zobrazuje obsah jednotlivých e-mailů a třetí slouží k jejich psaní. Samozřejmě by takovou aplikaci šlo také napsat jednou aktivitou s tím, že by se vždy kompletně změnil obsah. Takovou architekturu ale nelze doporučit, je to špatná a mnohem pracnější cesta. V čem je tedy kromě snazšího vývoje výhodná popisovaná struktura několika aktivit? Právě v možnosti jednotlivé kompenenty samostatně volat i z jiných aplikací. Například narazíme-li v prohlížeči na link odkazující nás na e-mailovou adresu, lze po kliku přejít do naší aktivity určené pro psaní e-mailů. K tomuto účelu stačí jen aktivitě předat požadovanou e-mailovou adresu.

Protože je aktivita vizuální komponentou, má okno, do kterého je možné kreslit. Okno aktivity typicky zaplňuje celou obrazovku, ale může být také menší – být jen plovoucím dialogem. Obsah okna je specifikován pomocí views. View je vizuální prvek, na obrazovce mu odpovídá obdélníkový prostor. View se řadí do hierarchické struktury – rodičovské prvky, nazývané layouty, organizují rozložení vnitřních prvků. Typ layoutu určuje, jakým způsobem budou jeho podřízené view rozloženy v dostupném prostoru. Příklad základních view je třeba tlačítko nebo obrázek.

Service

Jiným typem komponenty je service (služba), která není uživatelsky viditelná a běží na pozadí. Příkladem je třeba komponenta určená k síťové komunikaci. V příkladu e-mailového klienta bychom mohli použít službu pro stahování a odesílání e-mailů na pozadí.

Broadcast receiver

Tato komponenta slouží k „poslouchání“ broadcastových oznámení a k reakci na ně. Broadcast receivery nejsou, stejně jako služby, uživatelsky viditelné. Jako reakci na příchozí oznámení mohou například spustit jiné komponenty. Broadcasty mohou být jak systémové, tak uživatelské – aplikace si mohou vytvářet své vlastní broadcasty.

Jednoduchým příkladem může být receiver reagující na systémový broadcast oznamující nízký stav baterie. Reakcí naší aplikace může být například uložení aktualního stavu a ukončení aplikace. Dalšími příklady mohou být receivery reagující na odpojení nebo připojení sd karty. Jiným příkladem může být receiver reagující na příchozí textovou zprávu tím, že spustí další aktivitu, která danou zprávu zobrazí.

Content provider

Poslední komponentou je content provider, který slouží ke zpřístupnění dat jiným aplikacím. Ty k datům přistupují pomocí instancí třídy ContentResolver. Data lze zpřístupnit ke čtení i k zápisu. Rozlišení toho, kdo může jen číst a kdo může i zapisovat, se provádí podle práv, jež aplikace mají a jež jsou vyžadována. Pomocí content resolveru lze přistupovat například k záznamům v adresáři telefonu, fotkám v galerii telefonu nebo záznamům o příchozích a odchozích hovorech.

Android manifest

Toto byly čtyři druhy stavebních kamenů aplikací určených pro operační systém Android. Aby mohlo vše fungovat jak má, je třeba nějak operačnímu systému sdělit, jaké komponenty jsou k dispozici. K tomu slouží Android manifest. Je to xml dokument, který specifikuje parametry aplikace – jednotlivé komponenty, požadovaná systémová práva a jiné požadavky na běh.

Volání komponent a běh aplikace

Jak už bylo zmíněno, jednotlivé komponenty aplikace mohou spouštět jiné komponenty, dokonce mohou spouštět i komponenty cizích aplikací. Všechny komponenty, mimo content providerů, se aktivují pomocí asynchronních zpráv tzv. intentů. Používání intentů je jednoduché, v příští části seriálu si ukážeme konkrétní příklady.

Task

Nyní bych měl zmínit ještě jeden důležitý a možná trochu matoucí pojem, a to je task. Task je zásobník instancí aktivit, které byly postupně spuštěny. V momentě, kdy jedna aktivita spustí nějakou jinou aktivitu (může to být i aktivita z jiné aplikace), je tato nová aktivita instanciována a vložena na zásobník. Uživatel komunikuje s instancí na vrcholu zásobníku aktivního tasku.

Například pokud chceme ze své aplikace odeslat e-mail, můžeme pomocí intentu spustit aktivitu e-mailového klienta. Tato aktivita se tedy instanciuje a vloží na vrchol zásobníku. Ačkoli přecházíme mezi aktivitami různých aplikací, z uživatelského hlediska se zdá, že jsme stále v jedné aplikaci. Uživatel nyní může odeslat e-mail, po odeslání lze očekávat ukončení aktivity. Na vrchol zásobníku se tak dostává zpět aktivita, která předtím aktivitu e-mailového klienta spustila.

Pro pohyb na zásobníku také slouží tlačítko zpět. Pomocí něj je možné smazat vrchol zásobníku a přejít na předchozí aktivitu.

Tasků může být v systému samozřejmě více – nový task vzniká např. spuštěním aplikace z menu operačního systému. Task lze opustit, a pokud nebyly instance v něm ukončeny, tak se do něj lze také vrátit. Z uživatelského hlediska je tedy task aplikací.

Závěr

V tomto díle jsme si řekli něco o tom, co je to Android, popsali si vývojové nástroje a zmínili základní principy a stavbu Androidích aplikací. Příště si ukážeme konkrétní ukázky kódu na jednodušší aplikaci.

Chceš se naplno pustit do vývoje skvělých aplikací pro Android? Pošli nám CV na chci.job@inmite.eu – v Inmite právě hledáme posily do našeho androidího týmu! Pokud nás chceš napřed poznat a nezávazně pokecat, určite se ukaž na Android Devcampu, na jehož organizaci se podílíme. Inmite je už od samého začátku českou jedničkou ve vývoji pro Android a s tvou pomocí bychom si pozici rádi upevnili :)

       

Komentáře

[David Watzke]

Těším se na další díly, hlavně o GUI.

[Zilogat0r]

Zresetoval jsem v mozku vse, co vim o Jave a o tom, jak funguji pocitace, a jal se tu skvelou vec vyzkouset.

1) download - nechapu, proc 150MB iso rozdeluji na 2 casti po 90 a 82 MB, a uz vubec ne, proc nejakym proprietarnim HJ Splitem. Ale dobra, stahl jsem oboje, a spojil cat p1 p2 >p.iso

2) nabootoval jsem to qemu -cdrom p.iso. nabeh standardni 2.6.x kernel, nicmene inicializace graf. rezimu skoncila zatuhem v rozsypanem caji neinicializovane VRAM na 2 minuty, nacez se pak na pristich 10 minut objevilo cukave updatovane nasvecovane logo android a kde nic tu nic. rebootuji s 256MiB RAM, totez. Konecne jsem se dockal.

3) nesmyslne nabehlo varovani o 15% battery remaining, ac jde o emulaci sitoveho klasickeho PC bez ACPI. Po odkliknuti v rekordne kratkem case 30s system zareagoval a hlaska zmizela. Mysi pointer se updatuje cca s 2fps, coz je ostuda i na atari 2600. browser nabehl za 1 minutu. Nacteni idnes.cz pak 55 sekund.

Zaver: proc vyvijet pro pseudoplatformu, co degraduje pocetni vykon HW o nekolik radu niz, pricemz se nestydi prezentovat jako platforma pro mobilni zarizeni, kde jde o usporu energie v prvni rade? Zahodit do propadliste dejin, jako cokoli, co ma neco spolecneho se zrudnym omylem jmenem Java.

[bubak]

souhlas!

nelibi se mi pridavani nepruhlednych vrstev (android) nad linuxove jadro.

[Filip Jirsák]

To by mne tedy zajímalo, co jste vlastně vyváděl. Android v telefonu i v jeho emulátoru na PC funguje svižně. Proč pro tu platformu vyvíjet? Protože je to třetí nejrozšířenější platforma v mobilních telefonech, a počet uživatelů se neustále zvyšuje.

[Zilogat0r]

Vzdyt to pisu, co jsem presne vyvadel, a ma zkusenost je tedy snadno reprodukovatelna. Jeste Vam to ulehcim - zacal jsem zde: http://code.google.com/p/live-android/downloads/list

Mozna se lisi nase nazory na to, co je to "efektivne" a "svizne". Pro mne to ovsem 10 minut nabihajici zbytecna, zpomalujici mezivrstva transformovane Javy, neni.

[Filip Jirsák]

Android aplikace se spouští buď nativně v telefonech, nebo v emulátoru Androidu, který si spustíte v PC a je součástí SDK. Ke stažení je na vývojářských stránkách k Androidu. Vy jste si stáhnul nějaký pokus o port Androidu přímo na platformu x86. To je jako byste hodnotil Linux podle toho, že si spustíte Cygwin ve Wine.

[Zilogat0r]

No moment - chcete rict, ze jakymsi divnym omylem system bezi tuze spatne na 3GHz x86 core2 nekolikajadru, a mavnutim kouzelneho proutku pobezi svizne na 400MHz ARMu? A to k vasi spokojenosti delim merene casy sedmi, coz je zhruba koeficient zpomaleni jitovaneho qemuovskeho kodu.

To nedava dobry smysl, ze. Prirovnani k cygwinu ve Wine je take nesmyslne, zde se nepokousim nic emulovat, jen jsem si vybral pouhy port onoho skveleho systemu, pro jednu z nejsilnejsich a prostredky nejnadupanejsich platforem. A ostatne, k tomuto snad Android preci je, ne - aby se aplikace psala jednou, a bezela na vsemoznych jeho inkarnacich, bez ohledu na platformu. Nebo opet chybka? WORE again? :)

Zaver: pomale, nepouzitelne, overhyped. Co byl Oak pro Sun, zrejme bude Android pro Google. Takova mala vstupenka pro budouci akvizici :).

[Filip Jirsák]

Chci tím říct, že vy jste si stáhnul bůhvíco, ne Android. Usuzovat z toho na rychlost Androidu je stejně dobré, jako věštit to z kávové sedliny.

[Jindřich Makovička]

400MHz nevim, ale v kapse mam 600MHz a chova se to celkem svizne :)

Co se tyce toho Live Androidu, hned na vrchu te stranky je napsano, ze ten projekt je mrtvy, takze nema moc smysl se o nem bavit.

[Zilogat0r]

Dobre, ptam se tedy, kde sezenu port onoho skveleho systemu na nejrozsirenejsi platformu, tedy x86? Jiste v 20 ruznych modifikacich na 100 mistech, ze. Takze mate sanci mi nejaky port vybrat, a presvedcit mne, ze to funguje. Ma zkusenost je zatim presne opacna.

A pokud tvrdite, ze na x86 neexistuje pouzitelny port, pak se ptam PROC - nebylo nahodou zamerem teto platformy portabilitu mezi zarizenimi zajistit? Je snad x86 tak zoufale nevykonna, ze toi nelze? :)

Nekde neco smrdi.

[Filip Jirsák]

Záměrem bylo vytvořit platformu pro chytré mobily. Kolik že to mobilů má v sobě x86?

[Rivon]

Přesně tak... Android je dělaný pro ARM, ne pro x86. O žádném x86 portu nevím.

[Zilogat0r]

Tak ty dva linky, co se jen v tomto flamu objevily, berte jako fata morganu, a nevzrusujte se jimi prilis. :))

[JeChW]

Port Androidu na x86 není hotový, vše, co existuje, jsou různé vývojové verze v různých fázích dokončení a funkčnosti.

Jelikož je Android určený pro mobily (a pouze velmi krátkou dobu i pro méně výkonné tablety), není x86 zatím oficiálně podporováno.

Nicméně Intel na letošek ohlásil několik zařízení s Atomem Zxx a Androidem. Takže Android pro x86 letos bude, ale protože se jedná o mobilní OS, je každý build dělaný na míru konkrétnímu zařízení. Neobsahuje ovladače jiných zařízení atd. Nedá se tedy čekat, že to rozběháš na desktopu, k tomu Android není určený.

Pokud bych chtěl vidět, jak svižný je Android na x86, podívej se na tohle video: http://www.youtube.com/watch?v=8DNjK5GKngU

Ještě je třeba dodat, že to vše funguje bez akcelerované grafiky, protože chybí použitelný linuxový ovladač pro GMA500. Na tomhle počítači jsou Windows 7 líné jako prase.

[Ladicek]

Začal jste špatně a to, co jste dostal, nemá s vývojem pro Android nic společného. Což pochopitelně víte a já tady ze sebe jenom dělám vola.

Takže abych přidal něco hodnotného: Upravovat manifest kvůli ladění (android:debuggable) už AFAIK není potřeba.

[Zilogat0r]

Ma smysl bavit se o vyvoji, pokud zde snadno dokazuji, ze sama platforma je za hranici proste pouzitelnosti, a to na nejsilnejsi dostupne platforme? :)

[kyytaM]

Co je najsilnejsia dostupna platforma?

[Zilogat0r]

Hadejte - 600MHz ARM, nebo nekolikajadrove iBuhvikolik na 3+ GHz? :)

[Jindřich Makovička]

ARM je siroky pojem. Pokud ma integrovane nejake pekne FPGA nebo DSP, pro nektere ulohy muze mit urcite navrch :)

[Zilogat0r]

Nebo nejakou hezkou extenzi, jako napriklad Jazelle, ze :). Typicky priklad dalsi javisticke katastrofy :).

[kyytaM]

x86 je na tom lepsie ako Power7? :)

[Zilogat0r]

Neni, a predpokladam, ze vam tato masinka truni doma na stole. A ze ten skvely vykon pouzivate k tomu, abyste... pod AIXem emuloval androidni mobilni siditka, a radoval se z teto skvele platformy naplno :P.

[Bedňa]

Mne ide Android vo virtuále aj v telefóne úplne hladko, niekde robíš chybu.

[kralyk z abclinuxu]

Hadejte - 600MHz ARM, nebo nekolikajadrove iBuhvikolik na 3+ GHz? :)

To první v mobilním segmentu, to druhé v desktopovém.
A Android je systém pro který segment?..... Áha

[Ladicek]

Android oficiálně pro x86 NENÍ, takže nedokazujete vůbec nic (možná krom svých … atd.). Viděl jsem v sdk.git nějaké commity ohledně podpory více platforem (arm/x86/jiné) v SDKčku, takže se možná blýská na lepší časy. Do té doby – happy trolling.

[w4rr10r]

Intel ho portoval, ne?

[Ladicek]

Jo, myslím, že ten commit v SDKčku byl od nějakého člověka z Intelu. Jaký je přesně stav nevím, ale když teď koukám, tak před několika dny syncované AOSP už mi v lunch menu nabízí x86 build. Takže jsem možná kecal, večer to vyzkouším.

[Zilogat0r]

Tak snad nepromarnite historickou sanci ukazat svetu prvni pouzitelny x86 androidi build - smele do toho. :)))

[Ladicek]

Takže takhle. Je tu (32bitový) toolchain pro android-x86. vbox_x86-eng se nezkompiluje, full_x86-eng ano. Chybí prebuilt jádro. generic_x86 a make installer_vdi dokonce vytvoří obraz disku pro VirtualBox, ale nedá se dostat přes GRUB. Předpokládám, že kdyby někdo chtěl, asi by to do bootovatelného stavu dostal, já k tomu nemám důvod.

Zajímalo by mne, jak se do AOSP dostávají věci. Honeycomb (Android 3.0) v AOSP pořád chybí (takže je efektivně closed-source), i když už se prodává v zařízeních (no, v jednom zařízení) a je k disposici SDKčko. Naopak x86 port už v AOSP je, ale podpora se do SDK Tools teprve začíná dostávat a na trhu to ještě není.

Dobrou noc.

[Jindřich Makovička]

BTW, ty ISO files Live Androidu jsou rozdeleny z prozaickeho duvodu - na Google Code soubor delsi nez 100MB nejde uploadnout.

[Senior Database Programmer]

Veď existuje aj milión linuxových mobilov, všelijaké tie Maemá, meega, openmoká, QtMoko, freerunnery,...stačí si vybrať (asi som zmiečal mobily s distribúciamy ale nemám v tom prehlaď, linuxové telefóny sú šmejdy, mám rád svoj Android mobil).

[Zilogat0r]

Btw. tech x86 portu je vic. Jeden by rekl, ze jde pouze o trivialni ukon vyroby linuxoveho live-cd, a dodani Dalviku coby aplikace nad to.

A ono ne - vsechny tyto porty == stejna hruza. Obavam se, ze toto neni nahoda. Ale - proc mne to jen u na Jave zalozene architektury systemu prekvapuje, ze. Jak se rika lidove - z hovna dort neudelas.

[Filip Jirsák]

Až do teď to vypadalo, že jste se prostě spletl a omylem stáhl něco jiného. Ale vy jste jen obyčejný troll.

[Zilogat0r]

A co jsem mel tedy stahnout? Jsa pouhy majitel slaboucke x86... :)

Troll tak trosku jsem, ale hlavne assemblerista, telem i dusi, a nektere veci mne tuze rozesmutnuji.

[mrzout]

Hlavně jste troll, navíc hloupej. Stáhněte si http://www.android-x86.org/download a nainstalujte to na pc, ne do emulátoru.

A jestli to nezvládnete, prostě si kupte nějaký x86 hw s předinstalovaným Androidem: http://www.android-x86.org/hardware-list

Já být debil lopaťák a chtít řídit jaderná elektrárna. Stačí ukázat zelená a červená čudlík! Blbá elektrárna, udělat BUM! Špatně postavená! Přece já odborník!

[Zilogat0r]

Ale ale... zajimave, ze pro jakykoli jiny system, vcetne bloatu typu SuSE nebo Windows Vista, je JITovane prostredi Qemu se svym _pouze_ sedminasobnym zpomalenim naprosto dostacujici...

Vami zminovany portal jsem navstivil pred casem, a verzi 1.6r2 zkousel. Mohu Vas ubezpecit, ze nabiha sice o 2 minuty rychleji, ale po pulhodine prace s browserem se cely system pravidelne zasekaval, takze jste mne neuspokojil - nabidnete neco, co alespon FUNGUJE, kdyz uz ne dobre a efektivne. :)

Jinak ja ne zadna odbornik, kdyztak se Vam pak predstavit :P.

[Filip Jirsák]

Stáhněte si buď SDK, kde máte emulátor, nebo si zajděte do nějaké prodejny s mobily a tam si to vyzkoušejte naživo.

Pokud byste byl assemblerista, věděl byste, že udělat kvalitní port na jinou architekturu není otázka deseti minut – a že jste tedy nejspíš zkoušel nějaké pokusy, které asi měly za cíl Android na x86 vůbec spustit, ale k případnému produkčnímu nasazení mají ještě hodně daleko. Taky byste věděl, že se od sebe různé architektury liší, a program optimalizovaný pro jednu platformu může běžet mnohem rychleji, než stejný program spuštěný na jiné zdánlivě výkonnější platformě.

[Zilogat0r]

Nechci emulator mobilniho zarizeni - chci dany system provozovat nativne. Nehodlate snad tvrdit, ze emulace je v pripade x86 efektivnejsi, nez nativni beh, a ze nastroje, pouzite pri portu pro x86, jsou tak nizke kvality, ze tento nesmyslny paradox zpusobuji :).

Kvalitni port na jinou architekturu by melo zajistovat pouhe pouziti HLL (heh), a predpokladam, ze architektura x86 neni tak minoritni, nerozsirena a neznama, aby dostupne kompilatory nedovedly generovat alespon pseudooptimalni kod :))).

Summary: hajite neobhajitelne :>.

[Pindal]

Muhehe. Android je celosvětově tak úspěšný, že není potřeba to před kýmkoliv jakoliv obhajovat. Na tvém názoru prd záleží a prd proti tomu taky můžeš dělat )

[Filip Jirsák]

Nechci emulator mobilniho zarizeni - chci dany system provozovat nativne.

Pořád jste psal o x86. Pokud chcete Android nativně, poohlédněte se po nějakém mobilním telefonu.

Nehodlate snad tvrdit, ze emulace je v pripade x86 efektivnejsi, nez nativni beh

Emulace může být snadno efektivnější, než nativní běh. Zkuste si emulovat DOSové prostředí nebo třeba Amigu nebo Commodore.

ze nastroje, pouzite pri portu pro x86, jsou tak nizke kvality, ze tento nesmyslny paradox zpusobuji

Nástroje použité při portu (lidé) nemusí být nízké kvality, prostě jenom třeba zatím neměli dost času nebo chuť kvalitní port udělat.

Kvalitni port na jinou architekturu by melo zajistovat pouhe pouziti HLL (heh), a predpokladam, ze architektura x86 neni tak minoritni, nerozsirena a neznama, aby dostupne kompilatory nedovedly generovat alespon pseudooptimalni

Tipoval bych, že na rychlosti odezvy GUI bude mít kvalita kompilátoru minimální vliv. Daleko podstatnější je třeba forma multitaskingu a jeho podpora v hardware, zpracování událostí apod. A to vám žádný automat nevyřeší, to taky může znamenat třeba úplně změnit architekturu nějaké části systému. Vzpomeňte si třeba na problémy s vícejádrovými procesory, které občas mohou způsobit zpomalení proti témuž systému s jedním jádrem. S takovými problémy nebo jejich variantami se potýká i Linux – a kompilátor to nezachrání.

[Zilogat0r]

To snad nemyslite vazne.

Chci system nativne provozovat na nejrozsirenejsi hardwarove platforme - chci tak mnoho?

Emulace je vzdy maximalne STEJNE tak efektivni, jako nativni beh cehokoli, protoze je temi nativnimi instrukcemi v nejlepsim pripade 1:1 vykonavana (emulace plat. P na sobe same), jinak je VZDY pomalejsi vuci nativnimu vykonu host-platformy. Mrzi mne velmi, ze Vam toto musim vysvetlovat, a relevanci vasich argumentu to citelne snizuje.

Rychlost odezvy GUI uzce souvisi s portovanim, protoze predpokladam, ze zrovna rendering jeho prvku by mel byt resen i v necem tak hruznem, jako javisticko-dalvisticky android, nativnim volanim. Pokud tak reseno neni, TIM HURE.

Koneckoncu, Dalvik je POUHA aplikace, jako jakakoli jina virtualni masina, a tedy nevidim duvod, proc by melo byt jeji portovani zrovna na x86 obtizne :). Jina vec je ovsem ta, ze jde opet jen o dalsi formu JITu javovskeho, byt transformovaneho, classfile, takze puvodce neefektivity muze nevidet jen clovek, co zil poslednich 15 let v jinem, paralelnim vesmiru...

[kralyk z abclinuxu]

Chci system nativne provozovat na nejrozsirenejsi hardwarove platforme - chci tak mnoho?

To je jak do dubu... Android je OS pro mobilní zařízení. Na mobilních zařízeních má x86 minimální zastoupení. Takže ano, chceš toho celkem moc.

Emulace je vzdy maximalne STEJNE tak efektivni, jako nativni beh cehokoli, protoze je temi nativnimi instrukcemi v nejlepsim pripade 1:1 vykonavana (emulace plat. P na sobe same), jinak je VZDY pomalejsi vuci nativnimu vykonu host-platformy. Mrzi mne velmi, ze Vam toto musim vysvetlovat, a relevanci vasich argumentu to citelne snizuje.

Zapomínáš na jednu důležitou věc - daná aplikace může být pro platformu výrazně hůře optimalizovaná, a tak se emulace může stát efektivnější.
Předpokládám, že nikdo se zatím nechtěl/nemohl namáhat optimalizovat Dalvik pro x86.

Můžeš už se přes to konečně přenést?

[multi]

android je psan s optimalizacemi pro arm, takze na x86 se bez uprav nespusti, dokonce bez uprav nejel ani na starsich armech, porty sice existuji, ale jak to tu nekdo zminil tak neoficilani, ktere jsou vetsinou motivovane snahou to zkusit a ne to komercne nabizet zakaznikum

ten dalvik je sice virtualni masina, ale samotna masina bezi nativne

[Filip Jirsák]

Chci system nativne provozovat na nejrozsirenejsi hardwarove platforme - chci tak mnoho?

A já na nejrozšířenější hardwarové platformě chci provozovat Watsona nebo sekačku na trávu.

Emulace je vzdy maximalne STEJNE tak efektivni, jako nativni beh cehokoli, protoze je temi nativnimi instrukcemi v nejlepsim pripade 1:1 vykonavana (emulace plat. P na sobe same), jinak je VZDY pomalejsi vuci nativnimu vykonu host-platformy. Mrzi mne velmi, ze Vam toto musim vysvetlovat, a relevanci vasich argumentu to citelne snizuje.

Zmínka o DOSu, Amize a Commodoru vás mohla varovat, abyste se takhle neztrapňoval. Pokud nativní platformě trvá zpracování jedné instrukce 1 s, a spustíte aplikaci na emulátoru, který k emulaci 1 emulované instrukce potřebuje 10 svých instrukcí, ale emulátor poběží na platformě, která zpracuje 1000 instrukcí za sekundu, poběží pod emulátorem program (co se týče počtu zpracovaných instrukcí) 100krát rychleji, než nativně.

Rychlost odezvy GUI uzce souvisi s portovanim, protoze predpokladam, ze zrovna rendering jeho prvku by mel byt resen i v necem tak hruznem, jako javisticko-dalvisticky android, nativnim volanim. Pokud tak reseno neni, TIM HURE.

Vykreslování prvků tvoří jen menší část toho, co vnímáme jako odezvu GUI. Jinak zrovna to vykreslování může být něco, v čem samotný procesor x86 pokulhává za nativní platformou pro Android – protože v tom mobilu může být snadno schovaný nějaký čip na zpracování OpenGL, jehož práci musí v Qemu pracně suplovat procesor. Neříkám, že zrovna tohle a s těmito technologiemi je případ Androidu, pouze to uvádím jako možnost, jak může pomalejší specializovaná platforma zvítězit výkonem nad obecnou rychlou.

Koneckoncu, Dalvik je POUHA aplikace, jako jakakoli jina virtualni masina, a tedy nevidim duvod, proc by melo byt jeji portovani zrovna na x86 obtizne :)

Já ten důvod také nevidím, a právě proto nechápu, proč se tak tvrdošíjně bráníte vyzkoušet Dalvik a nějakou omáčku okolo (emulátor z SDK), a místo toho neustále trváte na testování portovaného jádra, knihoven a celého systému (port celého systému Android). Neboli místo spuštění Dalviku nad Linuxem pořád spouštíte Dalvik nad portem Linuxu na mobilní procesory portovaným znova zpět na x86.

Jina vec je ovsem ta, ze jde opet jen o dalsi formu JITu javovskeho, byt transformovaneho, classfile, takze puvodce neefektivity muze nevidet jen clovek, co zil poslednich 15 let v jinem, paralelnim vesmiru...

S rychlostí toho JIT nikdo problém nemá. Problém máte jen vy, když spouštíte ten JIT na jakémsi pochybném portu portu Linuxu. Nepřikloním se k vašemu způsobu uvažování a nebudu tvrdit, že je to chyba Linuxu, naopak mi z toho celkem jasně vychází, že je to chyba toho portu.

[Zilogat0r]

Ne, ne a zase ne. S dovolenim Vasi diskuzi ukazi zitra studentum, jako ukazku toho, kterak se katastrofalne ztraci jakekoli povedomi o strojove urovni fungovani HW. Je mi z toho jen hrozne smutno, a ano, mate pravdu - mnoho s tim delat nemohu :(. Valku se sebespokojenou neznalosti a diletantismem, hlavnimi smery vyvoje soucaneho IT, masivne krytymi stale-jeste-jakztakz exponencialnim narustem vykonu, nelze asi vyhrat.

predstavovat se radsi ani nebudu.

[Filip Jirsák]

Třeba vám studenti vysvětlí, že vykonání 1 instrukce za sekundu je pomalejší zpracování, než vykonání té samé instrukce za setinu sekundy. Nebo si to můžete prakticky vyzkoušet. Naprogramujte si emulátor kuličkového počitadla, a schválně, kdo bude rychlejší – jestli emulátor nebo výpočet na fyzickém kuličkovém počítadle (nativní hardware).

[Zilogat0r]

Pokud mate pocit, ze fakt, ze dnesni PC zvladaji emulovat 68k staricke A500 na vyssi rychlosti, nez fungovala originalni masinka na 7MHz, dokazuje, ze "emulace muze byt rychlejsi nez nativni kod", pak mi Vas ani nebude lito.

[Filip Jirsák]

Samozřejmě, že to dokazuje. Porovnávání rychlosti nativního běhu na nějaké platformě a emulovaného běhu na zcela jiné platformě jste sem zavedl vy. Samozřejmě se lze omezit na porovnávání nativního kódu na nějaké platformě s emulací kódu na téže platformě, pak samozřejmě optimálně napsaný program bude alespoň stejně rychlý při nativním běhu, jako při emulaci – přinejhorším se emulátor prohlásí za součást programu. To ale není vámi popisovaný případ – vy se pokoušíte systém pro platformu mobilních telefonů emulovat na x86. Což je přesně to samé, jako emulovat na x86 Amigu.

Mimochodem, vaše převedení tématu od platformy k procesoru ukazuje na jednu z příčin toho, proč se mýlíte – díváte se jen na hlavní procesor dané platformy a vše ostatní ignorujete. Jenže celkový výkon prostředí a aplikace na hlavním procesoru záleží čím dál méně – takže třeba sestava nějakého pro vás podřadného procesoru s dobrou GPU může v určitých aplikacích natrhnout triko vámi opěvovanému 3GHz x86 core2 několikajádru.

[Bedňa]

Nechaj ho píše úplne z cesty, je mi ľúto len tých študentov. Bol by som rád, keby to niekto z nich natočil a hodil sem, pokiaľ vie o koho ide.

[Zilogat0r]

Muzete prijit na me prednasky, jsou ze zakona verejne (takze vas vyhodit nemohu, ani kdybych chtel - jako ze nechci). :). Ct 7:30 katedra pocitacu, Karlovo namesti, budova E, mistnost 126. Predmet se zove "strojove orientovane jazyky" a zabyva se vyhradne assemblerem, predevsim rodiny x86, a jeho efektivitou jeho nasazeni :). Aktualne je sice na poradu dne rychla exkurze do pristupu k periferiim z realneho modu, coz je sice zajimave, ale pro flame ohledne managed-code "pseudosystemu" zde nebude moc mista.

Studentu Vam lito byt snad ani nemusi, jsou obvykle spokojeni: http://felguide.monty.cz/main.php?predmet=76&ucitel=244 V ankete CVUT si najdete, jak hodnotilo 60 absolventu predmetu uroven mych znalosti - nechce se mi sem tak trapne cislo ani uvadet :>. O Amize mi vypravet take nemusite, mam jich doma asi 6, s ruznymi vlastnimi HW modifikacemi. O hardwaru tez ne, opravuji jej (a trosku i vyvijim), a o DOSovych casech uz vubec ne - public.avast.com/~cimbal/x36soj :P.

takze zdravim javisty, byt dx-ovane, a preji trosku low-level rozumu do pristich let, jinak pujdete do stareho zeleza jako prvni: http://developers.slashdot.org/story/08/01/08/0348239/Professors-Slam-Java-As-Damaging-To-Students

pac a pusu. snad se mi konecne splni sen a nekdo ze zastancu platformy Java mi osobne vysvetli, v cem tkvi jeji prinos :).

[Filip Jirsák]

snad se mi konecne splni sen a nekdo ze zastancu platformy Java mi osobne vysvetli, v cem tkvi jeji prinos

Pro vás v ničem.

[Zilogat0r]

V tom s Vami celkem souhlasim. Pro alespon trosku schopneho kuchare polevka v sacku take nepredstavuje zadne terno - ale prijit klidne muzete. :>

[zzz]

Jsem zastáncem Javy.

Zkuste napsat web aplikaci pro přístup k elektronické poště čistě v assembleru a za použití Java + Struts + Tomcat (Jetty či jiný server). Jistě rychle vyhodnotíte přínosy a slabiny obou přístupů.

...docela by mě zajímal výsledek takového pokusu.

[Zilogat0r]

telnet pop3.blablabla 110 nepouzivate? obvykle mam tak maily prectene driv, nez by vubec nabehl browser :). proc mate pocit, ze aplikace ma sidlit kdesi na vzdalenem serveru, a odsuzovat vas vykonem nadupany pocitac do role terminalu? nevracime se do 60. let, ironii dejin s 1e6x vykonnejsim HW, resit tytez ukony? :)

[zzz]

To je právě Váš problém. Stále jen výkon, výkon, výkon....ale třeba že přijdu ke kamarádovi, do kavárny, do práce... a prostě se přihlásím na mail - nic neinstaluji, nic nenastavuji proste přijdu, přihlásím se a mail funguje, vypadá a ovládá se stejně ať je to Windows, linux, iOS nebo cokoli jiného.

Spíš naopak Vy jste uvízl v době minulé - nebo snad chcete tvrdit, že všichni kdo používají od web aplikací, přes virtuální servery po cloud jsou hloupí??

Třeba mail - bez připojení k internetu si stejně žádný mail nepřečtete/neodešlete. Podle Vás musím mít 6 jádrové core i9 s POP3/SMTP klientem a nahoře s rukojetí abych ho měl vždy sebou až si budu chtít přečíst mail?? (trochu to hrotím, ale já s tím nezačal)

A kdo říká, že běžný člověk pro svoji práci potřebuje 6 jader core i7 a 16GB RAM? Stále častěji pozoruji, že je daleko lepší mít tablet na prohlížení webu a mail (třeba na androidu), protože je připravený za 2s, network media player, protože žere málo a přehraje téměř cokoli, a konzoli na hraní her, než mít jeden nadupaný počítač se spotřebou 0.5kWh který sice zvládne to samé ale za nepřiměřeně jiné náklady na pořízení i provoz.

[Zilogat0r]

Nejsem sam, komu je idea cloudu proti mysli:

http://techcrunch.com/2010/12/14/stallman-cloud-computing-careless-computing/

degradovani pocitace na terminal k cizi sluzbe je dle meho chybny smer vyvoje, a dost omezujici co se tyce kompetenci uzivatele.

co se tyce efektivity (prenosu dat, generovani UI), tak je webovy prohlizec na spicce teto neefektivity (ajax, js - versus dedikovane protokoly a prime api). v pripade flashovych aplikaci je to jeste horsi, a v pripade flashovych aplikaci v macosovskem safari je to vylozena transformace notebooku v domaci vytapeni.

[Filip Jirsák]

Pro kuchaře, který neumí nic jiného, než jeden slepičí vývar, není žádné terno ani francouzský sýr, prvotřídní čerstvá zelenina nebo cokoli jiného, co nedává do té své jediné polévky. Bohužel, když půjde o přípravu chlebíčků na recepci, svatebního dortu nebo i jen obyčejného druhého chodu, zvládne to takřka kdokoli lépe, než onen kuchař – ten připraví zase jen ten svůj slepičí vývar. Ale co se týče slepičích vývarů, může to být skutečně machr, do restaurace se bude chodit jen na jeho polévku. Otázka pak je, zda si onen kuchař umí připustit, že existují i jiná jídla, než slepičí vývar.

[kralyk z abclinuxu]

Já taky moc Javu nemusim, ale 1)občas v ní je napsanej pěknej soft 2)s rostoucí popularitou .NETu si říkám zlatá Java, ta aspoň měla slušnou verzi pro linux.

[milovník nakousnutého jablka]

snad se mi konecne splni sen a nekdo ze zastancu platformy Java mi osobne vysvetli, v cem tkvi jeji prinos :)

Její přínos je například v tom, že díky ní (a na ní navázané nepřeberné množství "nju technolodži" bullshitu) najde i takový exemplář "programátora", který sedí o kancelář vedle práci a nemusíš ho živit ze svejch daní...

[Bedňa]

Ja sa Javy nezastávam a na x86 platforme si na ňu dávam majzla Na telefónoch to chodí super, tam už sa ale neprekladá Java, ale beží bajtkód na virtuálnej mašine. Celá tá zbitočná hádka vznikla len o malicherné doťahovanie sa o rýchlosť a zabila diskusiu k článku. Čo asi vysvetluje pohľad od asembleristu V asmeblery+C som pred veľa rokmi spravil prehrávač wav súborov, výkon vtedajších strojov ani nedovoloval iné riešenie. Java je multiplaformná, asembler nie. Poďalšie ako som písal, mne to androidie SDK ide výborne, v telefóne mi aplikácie makajú super, vo virtuále mi ide Android tiež výborne, tak úplne to na prd nemôže byť. Pre rýchly vývoj treba moderné jazyky, neviem si predstaviť vyvíjať programy pre mobilné telefóny v Asemblery. Osobne by som ale bor radšej keby to makalo pod C++ a QT, kvôli tomu ešte plánujem kúpu N900 na hranie

[Papouch]

Možná místo tlachání a dokazování Vaší pravdy , by jste mohl udělat něco produktivního , když jste odborník , o čemž jste nás už informoval . Věcí které jsou na*ovno (čímž netvrdím že java či android je) je kolem nás spousta , ale poučováním o tom v diskuzích lokálního významu (myšleno náš pidi-stát) nemá valný žádný smysl , krom tedy uspokojení vlastního ega . Věnujte ten čas radši dětem nebo přátelům , bude to mít alespoň nějaký význam ...

Papouch

[Zilogat0r]

Ale ja jsem par veci udelal, treba divide.cz mi dela docela radost, zrovnatak mam radost, kdyz nekdo pochopi, jak se da efektivne kodovat a zacne ho to bavit - a treba tohle je take moje, krom jineho http://www.abclinuxu.cz/clanky/hardware/cfide-compact-flash-pres-ide ...

... ale casem zjistuji, ze "pozitivni priklad" nemuze buldozeristickemu marketingu moc konkurovat. Predpokladam, ze nadseny zacinajici vyvojar pro Androida na tuto diskuzi narazi, a povazuji za dobre, aby tu krom nadseneho hykani, podporujiciho uz tak znacnou hype, byl i protinazor.

Dot.com silenstvi a pokladani rovnitka mezi internet a javu pred deseti lety nikdo nebrzdil, a dopadlo to blede. IT je asi jediny obor, jehoz zmerovani urcuje vyhradne neznaly zakaznik/neznaly management. Ze tenhle pristup jeste nezkolaboval je jen diky stale jeste pokracujicimu exponencialnimu narustu dostupnych prostredku.

[jehovista]

A k cemu mu ten protinazor bude? Ze ma vyvijet na symbian, nebo iOS? A to nejsou pro takoveho assembleristickeho guru pomale shity? Nebo nema radsi delat nic a opakovat mantry typu "word nabiha uz dvacet let porad stejne dlouho", nebo "za osmibitu bylo nejlip a programatori byli opravdovi muzi?" a na kolene bastlit z tranzistoru nasobicku?

[Zilogat0r]

Nikoli. Ja se bavim o pouzivani androidu (na x86, protoze tuto platformu povazuji za majoritni), vy se bavite o vyvoji (predpokladam, ze tez na x86, a k vyvoji Vase mobilni zarizeni nepouzivate).

Pokud je ve vyvojovem emulatoru Dalvik x86-nativni, a bezi uspokojive, pak se ptam, jak je mozne, ze tentyz x86-nativni Dalvik v x86 portu bezi takto katastrofalne neuspokojive.

Pokud je ve vyvojovem prostredi emulovana armovska binarka, a bezi uspokojive, pak se ptam TIM SPIS.

Vase argumentace je tedy bud spatne, nebo uplne spatne. Neprekvapuje mne, jake nesmysly zde zaznivaji, ani jaci lide tuto platformu obhajuji - jeji "kvality" s timto pozorovanim nejsou v rozporu, ba naopak.

[Filip Jirsák]

Ja se bavim o pouzivani androidu (na x86, protoze tuto platformu povazuji za majoritni)

Android pro x86 v současné době v produkční verzi neexistuje. Mimochodem, v mobilních telefonech x86 majoritní není ani náhodou.

Pokud je ve vyvojovem emulatoru Dalvik x86-nativni, a bezi uspokojive, pak se ptam, jak je mozne, ze tentyz x86-nativni Dalvik v x86 portu bezi takto katastrofalne neuspokojive.

Jak jste přišel na to, že jste spouštěl tentýž x86-nativni Dalvik? Podle toho, co jste tady psal, jste spouštěl bůhvíco na bůhvíčem v Qemu. S Androidem to asi mnoho společného nemělo – například androidí zařízení nepoužívají myš, tudíž nemají ukazatel myši. Vy jste ale psal o pomalém překreslování kurzoru myši – takže bůhví, co jste měl spuštěné.

Vase argumentace je tedy bud spatne, nebo uplne spatne

Moje argumenty jsou možná nepřesné, ale ty vaše jsou totálně mimo – pokoušíte se argumentovat nějakou subjektivní rychlostí či pomalostí, přitom jste Android ještě ani jednou nespustil.

[Zilogat0r]

Reknui vam to takto - handheldy maji radove vyssi pomer vykonu k grafickemu rozliseni, nez desktopova PC - a proto tak trosku maskuji neefektivitu systemu. Navic, na dany handheld vetsinou neexistuje dostatecne mnozstvi konkurencnich systemu, pro objektivni porovnani uspesnosti implementace.

A ja se ptam, jak je mozne, ze vsechny pokusy o port na x86 dopadaji tak tragicky, kdyz jedina vec, co se skutecne portuje (rozumej, jeji ceckovy source po nezbytnych upravach prejede jinak targetovanym cross-gcc) , je POUHA VM. A obratem se ptam, proc ma tentyz problem na teze architekture zalozena javovska VM.

Jednomu by uz skoro doslo, ze spolecny jemnovatel problemu je efektivni vykonavani javovskeho bytecode. Kteremu, zda se, ani dalvikovska transformace z nesmyslne zasobnikove architektury do registrove prilis nepomohla.

Kdy uz konecne zmizi Java v propadlisti dejin? Jak dlouho jeste bude moderni vyhazovat vykon (dnes celkem solidni) HW panubohu do oken? A z jakeho duvodu, proc vubec?

[kralyk z abclinuxu]

Když všichni stvrdíme vlastní krví, že Java je nejvíc nejhorší hrůzostrašnost a Dílo Ďáblovo™, přestaneš trolovat?

[Zilogat0r]

To uz stvrdil komercni uspech spolecnosti Sun. Mne by jen stacilo, kdyby programatori meli trosku vic soudnosti a ucty k pametove a operacni efektivite implementace. Jinymi slovy, Jave se vyhybali, pokud nebudou mit pistoli u hlavy (a pokud budou, podali na takoveho vedouciho projektu trestni oznameni).

Budou spokojenejsi jak oni, tak zakaznik.

[Filip Jirsák]

Budou spokojenejsi jak oni, tak zakaznik.

Pokud je zákazník zaopatřovací ústav pro x86 assembleristy, pak ano. Pokud chce získat určitý výsledek za co nejnižší cenu, pak spokojen nebude – je mu k ničemu, že za milion Kč mu aplikace poběží o 1 % rychleji, když větší zrychlení může získat nákupem paměti za dva tisíce.

[Filip Jirsák]

A ja se ptam, jak je mozne, ze vsechny pokusy o port na x86 dopadaji tak tragicky

Z vašeho jednoho pokusu je myslím trochu brzo dělat závěr o všech. Každopádně to, jak dopadají nějaké pokusy o port, nevypovídá o platformě nic. Když nešikovný soused při pokusu o opravu totálně zničí Porsche, asi taky hned nebudete tvrdit, že Porsche jsou hrozná auta.

kdyz jedina vec, co se skutecne portuje (rozumej, jeji ceckovy source po nezbytnych upravach prejede jinak targetovanym cross-gcc) , je POUHA VM.

A celý ten systém okolo se portuje sám od sebe, jako že odejdete na oběd, a když se vrátíte, najdete to naportované, nebo jak si to představujete?

Jednomu by uz skoro doslo, ze spolecny jemnovatel problemu je efektivni vykonavani javovskeho bytecode.

Společný jmenovatel problému je, že jste ještě nezjistil, co znamená platforma Android, a nejspíš jste ještě žádnou Dalvik VM neměl spuštěnu.

Jak dlouho jeste bude moderni vyhazovat vykon (dnes celkem solidni) HW panubohu do oken? A z jakeho duvodu, proc vubec?

Už navždy. Protože se většina zadavatelů chová ekonomicky, a když můžou něco vyřešit zaměstnáním dalších drahých programátorů a prodloužením projektu na straně jedné, nebo nákupem levného HW na straně druhé, zvolí si výhodnější druhou variantu. Paradoxně to pak může vést i k menší „spotřebě“ výkonu – přebytek HW výkonu umožňuje používat virtualizaci (z té se vám taky musí zvedat žaludek, takové plýtvání výkonem), která pak umožní seskládat na jeden hardware různou zátěž s odlišnými špičkami, takže pak nepotřebujete rezervu na špičkový výkon pro každou aplikaci zvlášť, ale můžete tu rezervu sdílet pro více aplikací.

[Zilogat0r]

Ty dalvikovske supportujici classfajlove vrstvy se snad jen prejedou DXem, ne? Od toho preci v jave snad jsou, ne?

No a ten Linux pod tim je vyvijen pro x86 primarne, tj. zadny port netreba. Stale nevidim ten zdroj obtizi.

[Filip Jirsák]

No a ten Linux pod tim je vyvijen pro x86 primarne, tj. zadny port netreba.

Jenže tam právě není vanilkové jádro, ale upravené a portované jádro a spousta dalších programů. Podívejte se na architekturu Androidu. Vy pořád píšete jenom o tom žlutém obdélníčku, ale portovat se musí celý červený, zelený a žlutý rámeček + něco z aplikačního frameworku. Přičemž třeba správa napájení je v Androidu řešena úplně jinak, než ve vanilkovém jádru. Kdyby nic jiného, je toho docela dost, takže portace bude nějakou dobu trvat. A hlavně je k tomu potřeba mít nějaký důvod – a zatím jediný důvod byl „schválně, jestli půjde Android spustit i na x86 PC“. Snad uznáte, že to moc silný důvod není, takže se té portaci asi nikdo moc nevěnoval. Teď s nástupem tablet PC se situace změnila, pokud někdo chce dělat tablety s Androidem na x86, bude ten port muset udělat. Teprve teď k tomu někdo má dobrý důvod. A i tak je otázka, zda takový port půjde spustit na běžném PC, nebo zda bude svázán s omezenou množinou HW, která se bude v tablet PC používat.

[Zilogat0r]

No prave. Jadro s ovladaci pro bezne PC predpokladam mame, zrovnatak x86 binarky danych podpurnych nativnich knihoven.

Naopak, vse nad Dalvikem zustava (a melo by zustavat) platformove nezavisle, jinak to cele nema smysl. Tedy to, co se potemncialne teprve portovat na x86 musi, je - jen onen zluty ctverecek, je mi lito.

Pokud jde o port, tak "spodek" nabiha svizne, problem nastane jakmile nastartuje dalvik. Pak se uspokojivy dojem z normalniho, jednoho z mnoha, live-linuxu, zmeni v hororovy zazitek z pomale... javy. Proc mne to jen neprekvapuje.

[Filip Jirsák]

Pokud jde o port, tak "spodek" nabiha svizne, problem nastane jakmile nastartuje dalvik.

Nevěřte všemu, co vám někdo vyprávěl. Opravdu je velmi jednoduché si to vyzkoušet, v obchodu s mobily určitě na nějaký s Androidem narazíte.

[Zilogat0r]

Sorry, ale kolik ze je rozliseni zminovanych handheldu dnes a barevna hloubka? rekneme ne vic nez 256x512 64k ... to mame 256k framebuffer. Mate pocit, ze k vykreslovani skutecne 500MHz arm, jeste pred par lety cpu snu, potrebuje podporu GPU?

Nebo jeste lepe, jaky vidite smysl v tom, aby byl procesor RADOVE (bohuzel, navzdory jitovani) co do vykonu degradovan, a zaroven byla tato ztrata vykonu kompenzovana pridanym HW?

A navic, je tento pristup legitimni na poli mobilnich zarizeni, kde ma jit o energetickou usporu predevsim? Cele je to jaksi protismyslne, ze.

[Ladicek]

kolik ze je rozliseni zminovanych handheldu dnes a barevna hloubka? rekneme ne vic nez 256x512 64k ...

800x480 a 16M? A to přišlo dotyčné zařízení na trh asi před rokem.

[Zilogat0r]

Dobra, 1.1MB - tedy "bezny" rozmer framebufferu v chipram Amigy, obsluhovanem m68k na 7MHz (pravda, presuny a filling podporovane blitterem a copperem) - takze chapu, ze ARM11 na 800MHz (pokud mate na mysli Apad7) zoufale nestiha :)))).

[Ladicek]

Ne, mám na mysli SGSko, tam je procesor na 1 GHz Jak moc je to špatně s dovolením přenechám ostatním diskutujícím, jen jsem v tomhle případě chtěl upřesnit současný stav věcí.

[pavlix]

S dovolenim Vasi diskuzi ukazi zitra studentum, jako ukazku toho, kterak se katastrofalne ztraci jakekoli povedomi o strojove urovni fungovani HW.

Na vašem místě bych ji studentům neukazoval, nebo ztratíte poslední zbytky autority, jestli ještě nějakou vůbec máte.

[jay]

Proč to vlastně chceš zkoušet, když je to podle tebe nepoužitelné?

[Zilogat0r]

Ze zvedavosti. Na prvni pouzitelne nasazeni Javy totiz cekam uz skoro 15 let. Stale slysim nadsene provolavani, jak je to skvele, ale skutecnost tomu neodpovida. Jsem sam, kdo vidi krale naheho?

[green hornet]

Chces akorat tak trolovat. Jinak by sis misto ventilovani sveho stresu davno stahnul SDK.

[Zilogat0r]

Ale ja nechci vyvijet pro platformu, ktera se stale jevi jako nefunkcni - kolik uz tech x86 portu bylo? 7? 8? fungoval uz konecne nejaky uspokojive?

A proc ne, kdyz jsou zalozeny na obycejnem live-cd s proverenou architekturou (2.6 linux), a jedine, v cem tedy tkvi ten prubirsky kamen, je rozchodit Dalvikovske vrstvy? Proc se to nedari? Nebude skutecne cela ta idea jitovane transformovane Javy opet (jako doposud vzdy v historii, zkrachovaly Sun muze vypravet) krokem vedle?

[kralyk z abclinuxu]

Proc se to nedari?

Třeba protože to nikoho moc nezajímá?

[Aminux]

"Ale ja nechci vyvijet pro platformu, ktera se stale jevi jako nefunkcni"

A proč s tim otravujete tady? Tohle je článek o SDK a vývoji pro tuto platformu.

[jehovista]

"Na prvni pouzitelne nasazeni Javy totiz cekam uz skoro 15 let." Tim se vse vysvetluje - 15 let jsi byl zavreny ve vypolstarovane cimre a ted te konecne pustili k tomu internetu, o kterem se bavili zrizenci. Java neni buhvijaky zazrak, ale bezi na ni dost velka cast infrastruktury nasi civilizace.

[JeChW]

A já chci na x86 provozovat nativně iOS, WM 6.5, WP7, Symbian a Badu. Akorát nikde nemůžu najít, kde to stáhnout....

[Vhailor@seznam.cz]

Checkpoint! :D

[Zilogat0r]

Jmenujete systemy, ktere jsou samostatne - narozdil od Androida, coz je jen spoustitko javovskych nesmyslu na mirne osekanem Linuxu. Tedy tak trosku nebe a dudy.

[Filip Jirsák]

Definujte, co je samostatný systém.

[Zilogat0r]

System, ktery se instaluje primo na dany hardware, tjh. interaguje primo s pametovymi misty a pripadne i/o prostorem dasne platformy. Nikoli ze jde jen o specialni aplikaci, spustenou v Linuxu, jako v pripade Androida. :)

[Filip Jirsák]

Aha, takže nezáleží na systému, ale na způsobu provozu. Linux provozovaný ve virtuálním počítači není samostatný systém, Java provozovaná na procesoru s podporou Java programů už samostatným systémem může být.

[kralyk z abclinuxu]

Jmenujete systemy, ktere jsou samostatne - narozdil od Androida, coz je jen spoustitko javovskych nesmyslu na mirne osekanem Linuxu. Tedy tak trosku nebe a dudy.

iOS má v základu Darwin. Je to afaik podobný vztah jako Android a Linux.

[Zilogat0r]

To je ten "multitaskujici" takysystem? :)

[kralyk z abclinuxu]

Nevim, ale jak to souvisí s mojí poznámkou?

[mkoubik]

Chci system nativne provozovat na nejrozsirenejsi hardwarove platforme - chci tak mnoho?

Průzkum jsem nedělal, ale myslím, že když sečtete všechny desktopy, servery, telefony, tablety, embedded zařízení, síťové prvky atd. Tak bude suveréně nejrozšířenější platformou právě ARM. To, že chcete mobilní OS provozovat na platformě, která je jakousi náhodou nejrozšířenější na desktopech a jinou náhodou je zoufale neefektivní - to už je váš problém.

[Zilogat0r]

Proc by kod, psany v Cecku, bezici na ARMu, nemel byt kompilovatelny alespon uspokojive pro x86? Register renaming + znacna expresivita x86 kodovani davno smazaly x86 deficit vuci RISC architekturam... priznejme si, ze tim problemem je managed bytecode Javy. No tak. Nebude to bolet. Vzdyt to davno vsichni vime.

Jinak nic proti ARMU, skvele navrzeny CPU, usporny, vykonny - ale proc ho za to trestame tim, ze musi lopotne jitovat transformovanou javu? na x86 takova rezerva vykonu neni, a Java je kvuli tomu znacne nepopularni.

[Filip Jirsák]

Kompilovatelnost kódu není žádný problém. Většina lidí ale chce, aby to šlo nejen přeložit, ale také spustit a aby to něco rozumného dělalo. Jenže to už je mimo vaše rozlišování. Bajtkód Javy problémem při portaci na jinou platformu opravdu není, protože na rozdíl od toho C jej ani nemusíte pro jinou platformu znova překládat.

Java je kvuli tomu znacne nepopularni.

Zejména mezi uživateli, kteří Javu nikdy nespustili, nebo ji používají a neví o tom.

Všechny ty vaše řeči o problémech s Dalvikem a s jeho výkonností poněkud kazí fakt, že jste v životě neběžel aplikaci běžící na Androidu. Z toho je bohužel evidentní, že jediný váš skutečný argument je „nemám rád Javu“. No tak nemějte, svět se kvůli tomu nezboří. Zůstaňte si u svého x86 assembleru, nemluvte do věcí, kterým nerozumíte, a všechno bude fajn.

[mkoubik]

ale proc ho za to trestame tim, ze musi lopotne jitovat transformovanou javu?

Protože kdyby Google vývojářům mobilních aplikací řekl ať je píší v Céčku nebo assembleru, tak by se android nikdy nerozšíril - o bezpečnosti ani nemluvě, nějaká abstraktní vrstva (bytecode v sandboxu) je prostě potřeba z praktických důvodů.

Navíc mi nešlo o konkrétní vlastnosti architektur, ale o to, že jestli chcete provozovat android na nejrozšířenější platformě tak stačí navštívit nejbližší obchod s telefony.

[eee]

Jak se rika, kdo to umi, ten to dela, kdo to neumi, ten o tom uci. Kdyby ses mel zivit vyvojem webovych aplikaci, nevydelal by sis svym pristupem ani na slanou vodu. Kdybys vedl it oddeleni nejake firmy, tato by zkrachovala. A to vsechno proto, ze nechapes ze efektivita kodu ma daleko mensi vyznam, nez efektivita programatora.

A me vskutku sere, ze takto hloupeho cloveka zivim ze svych dani. Tebe zivi javisti, ne ty je. Tak se veci maji. Tak mej uctu k jejich praci, i kdyz ji nerozumis.

P.S. Nejsem javista a nezivim se programovanim ani v oboru IT.

[Zilogat0r]

Napsat "muj nazor neni reelvantni" by bylo kratsi, ve vasem pripade :P.

[pavlix]

Napsat "muj nazor neni reelvantni" by bylo kratsi, ve vasem pripade :P.

Napsat "máte pravdu", by bylo kratší ve vašem :).

[hehe]

Ak tomu správne rozumiem, tak si stiahol neoficiálny x86 port Androidu, na ktorom robili štyria ľudia a už rok a pol sa nevyvýja. Potom ťa prekvapilo, že sa to celé rozpadáva a je to hrozne pomalé. Rozhodol si sa, že je to vinou Javy. Ďalej tvrdíš, že ak Android nebeží plynule na tvojom 3GHz x86 procesore, tak zákonite nemôže fungovať na 400MHz ARMe. Možno ťa to prekvapí, ale 400MHz telefóny s Androidom existujú a fungujú. Tiež emulátor z SDK na mojom päťročnom notebooku s 2GHz Pentium M beží v poriadku. Zjavne si stiahol hlúposť, alebo to nejako blbo virtualizuješ.

Potom si vyskúšal ďalšie amatérkse porty Androidu a znovu ťa zarazilo, že sú hrozné. Rozhodol si sa, že s portovaním Androidu na x86 sú problémy a že je to vinou Javy. Počas celej diskusie ignoruješ fakt, že Google žiadny port nevydal, že všetky porty sú neoficiálne, a že Android je OS pre mobilné zariadenia, kde x86 nemá zmysel. Oficiálny x86 port Androidu proste neexistuje preto, lebo nemá význam, nie preto, že by tomu bránila Java a Dalvik.

Ako si má človek po prečítaní tvojich príspevkov nemyslieť, že si idiot?

[Zilogat0r]

"mame na mobilnich platformach nejak moc velke rezervy vykonu. ze bychom tu javu, s prominutim, nasrali tedy aspon sem, kdyz uz vsude jinde jeji nasazeni dopadlo blede"? :P

[hehe]

V prvom rade je dôležité opýtať sa, či dochádza kvôli Jave k nejakému úbytku výkonu a či je ten úbytok dosť veľký na to, aby malo zmysel sa ním zaoberať.

Androidové telefóny rozhodne problém s výkonom nemajú a nepotrebujú výkonnejší HW oproti iOS alebo WP7 telefónom. Nechápem čo riešiš.

(A poznámkou o nasaditeľnosti jedného z najrozšírenejších jazykov zo seba len robíš o niečo väčšieho blbca než doteraz)

[Rivon]

Přesně tak. Android a aplikace na něm běží na tom stejném HW stejně rychle jako na WP7 nebo iOSu, ikdyž Android běží na Javě, iOS nativně a WP7 skoro nativně (imho).

[hvge]

To nie je pravda. Prepad vykonu na androide je viac nez viditelny. Pracujem ako iOS developer a sam pouzivam android telefon z horneho vykonoveho spektra a rozdiel vo sviznosti tychto platforiem ma ako zaryteho androidaka skutocne prekvapil. No hadam som este nevidel android aplikaciu, kde by sa nezasekaval napr. scroll, vsetko je to take nejake viac zdochnute. Pokial to clovek nedrzi v rukach pred sebou, tie same aplikacie, akurat portovane pre rozne systemy, tak proste neuveri. A to nemam ziadne iluzie o srackach, co vyprodukuje gcc z objective-c :)

[Luboš Doležel (Doli)]

To není moc pravda. Na Angry Birds to je hezky vidět. Na Androidu potřebujete lepší HW než na iOS. (To říkám jako někdo, kdo nemá iPhony moc rád)

[Bedňa]

HTC Tattoo, Android 2.3.3 Angry Birds idú úplne krásne ako hodinky. S Androidom 1.6 som ich ani nespustil. Rovnako som prekvapený ako pekne ide 3D Pool, čo je fakt náročná hra. Takže treba povedať o akej verzií Androidu hovoríme.

[Luboš Doležel (Doli)]

iPhone 2G (412 MHz ARM) dává Angry Birds s přehledem, na HTC Hero (528 MHz ARM11) s Androidem 2.1 jsem z toho měl slideshow.

[Ladicek]

No, já měl na SGSku s oficiálním Androidem 2.1 od Samsungu třívteřinový lag při prvním insertu do sqlite. S neoficiálním 2.2.1 naprosto v pohodě. Ony ty lagy na SGSku jsou docela pověstné, i když je to po hardwarové stránce nadupaný telefon. Čímž chci říct, že rychlost androidích telefonů se dá skvěle zprasit na úrovni "systémového" software. Chtělo by to nějaký rozumný benchmark.

[Bedňa]

2.1 ešte nemá JIT a to je fakt poznať, 2.3.3 ide ako rýchlik a nedá sa to z ničím porovnať. Ak sa mi bude chcieť spravím aj video ako mi to ide bez jediného šklbnutia. S Androidom 2.3.3 je z toho zrazu HI END mobil. To nehovorím o ďalších fjučúrach a docky panel na spodu viď môj screen http://img16.imageshack.us/img16/9807/snap20110321213144.png

[Filip Jirsák]

Můžu se zeptat, co je to ta aplikace Angry Birds zač a jak je naprogramovaná? Pro Android se programuje v Javě (pro Dalvik), pro iPhone jestli se nepletu v Objective-C. Tzn. podle mne by se mělo jednat o dva zcela odlišné kódy, které se snaží dělat to stejné. To přece ale na rozumné porovnání dvou platforem vůbec nestačí. K tomu by bylo potřeba ještě vědět, že je to pro obě platformy napsané optimálně, správně, způsobem, který je pro danou platformu doporučován.

[NdrU]

Je mi opravdu smutno, když vidím, že nejspíše velice inteligentní člověk (jakým předpokládám budete) může být tak arogantní a ukazovat naprosté nepochopení pro skutečný stav věci.

Věc je ta že nemůžou být všichni programátoři assembleristi, stejně tak jako nemůžou být všichni doktoři mozkový chirurgové (nebo jak se česky řekne brain surgeon). Operace mozku si jistě vyžádá silné zázemí, nákladné vybavení a spoustu času a přípravy. Když ale budu mít rýmu, je ale tohle všechno zbytečné, radši si zajdu k obvoďákovi, který nepotřebuje tak vysokou kvalifikaci, během pěti minut mi napíše léky a pošle domů. Nebo se rovnou zeptám na radu lékárníka. Stejně tak když si jako malý podnikatel budu chtít zřídit internetový obchod, najmu si nějaké phpčkaře.

Musím říct že se velice divím, že člověk z akademického prostředí není schopen pochopit, že hřebík se sice dá zatlouct sbíječkou, ale vzít na to kladivo je mnohem rozumnější...

[Mintaka]

Dobrý den

Zkoušel někdo programování Androidích aplikací v Pythonu nebo Jythonu? Tedy je to vůbec možné a reálně použitelné?

[NdrU]

Není. Teda existuje Android Scripting Layer, pod kterým spustíte i python (tuším to je přeložený klasický Cpython, ale nejsem si jistý), dá se přistupovat k některým částem android frameworku (dají se třeba vyvolávat jednodché dialogy, vibrovat, požívat tts a podobně), ale kompletní aplikaci včetně gui v tom nenapíšete.

[Tomáš Kypta]

Python (a několik dalších jazyků) lze částečně použít přes Android Scripting Environment (ASE) (http://google-opensource.blogspot.com/2009/06/introducing-android-scripting.html, http://code.google.com/p/android-scripting/). ASE je ale určeno jen ke skriptování, s tím, že Pythonu zprostědkovává přístup k podmnožině API.

Jython použít nelze. U JVM jazyků vzniká problém v případě, že daný jazyk generuje bytecode za běhu (to tuším právě Jython dělá). Java bytecode se do dalvikovského konvertuje při vývoji. Pro použití takového jazyka by tedy bylo nutné, aby generoval přímo Dalvik bytecode.

[Luboš Doležel (Doli)]

Jython generuje kód během kompilace. Aspoň tak mi to připadalo.

[Tomáš Kypta]

Jython zrovna není moje parketa, ale předpokládám, že Jython samozřejmě generuje bytecode během kompilace. Tuším ale, že ho (podobně jako jiné dynamické jazyky jako Groovy nebo JRuby) umí generovat i za běhu.

[vlk]

Používá se na to JSR 223 (Scripting for the Java Platform) a to v androidu nejspíš není. Do budoucna ještě přibude JSR 292 (Supporting Dynamically Typed Languages on the Java Platform).

[JeChW]

Dával jsem to jako jeden z návrhů pro GSoC u PySide. Jestli se toho někdo ujme, to netuším. Ale bylo by fajn, kdyby šlo psát programy pro Android v QML+Pythonu. Qt/QML už portovaný je.

[Mintaka]

Děkuji za odpovědi.

[jas]

A s novymi verziami vyzera byt vyvoj cim dalej tym zaujimavejsi. Napr. "you can now build an entire Android application without writing a single line of Java".

Mozno trocha zamrzi, ze podpora pre vyssie spominane je az od Androidu 2.3. Na druhu stranu pre starsie verzie sa da pouzit port sdl.

[Ravensun]

Moc pěkný článek, těším se na další díl.

Jen bych se chtěl zeptat autora nebo čtenářů, zda bude i seriál pro Maemo (od nějakého nadšence ;) ).

Děkuji

Přeji příjemný den.

[matiey]

Vím, že článek i poslední komentář je již cca 2 roky starý, nicméně po přečtení 20-40 komentářů založených hlavně na stěžování si mistra Zilogat0r, zřejmě předního odpůrce Androidu, javy apod., jsem nemohl nepřidat komentář.

Android je super platfoma PRO MOBILNÍ PŘÍSTROJE o tom už snad dnes nikdo nepochybuje, snad i pan Zilogat0r musí uznat drtivé NADPOLOVIČNÍ - tedy většinové vládnutí Androidu v mobilních zařízeních... a jeho dinamický rozvoj, open source, zkrátka vše hovoří dnes jasně. Pružnost nových verzí včetně stále širšího použití třeba na takových strojích jako Nexus7 apod. ... myslím, že rozčilování a hádání se o nesmyslech a osobních názorech V ŽÁDNÉM PŘÍPADĚ NEPATŘÍ POD TAKTO VÝJIMEČNÝ A SKVĚLÝ ČLÁNEK !!

MOC DĚKUJI, VELICE MI POMOHL POCHOPIT MNOHÉ, CO JE JINAK POUZE NA PRECIZNÍCH-PŘEDNÍCH SVĚTOVÝCH VÝVOJÁŘSKÝCH STRÁNKÁCH a to výhradně v anglickém jazyce

SKVĚLÝ ČLÁNEK, DÍKY!

přes veškerou fyzickou únavu jdu nadšeně nasávat další díl(y)... :)