Android byl portován do C#

Nechtějí dál rozvíjet? To je skutečně škoda .. možná by to konečně donutilo některé firmy zamyslet se nad naprostou nevhodností Dalivka pro telefony

hmm preco to len ten google nenavrhol v c++.

java musi byt totalna sracka ak toto preportovanie sposobilo narast vykonu

Problém není v samotné Javě, jako spíš v nedoladěném Dalviku. Tak o tom alespoň mluví lidi z Xamarinu. Dalvik je prostě moc nový a má řadu much.

A proč to Google udělal je jasné - aby byla stejná aplikace spustitelná na architektuře ARM, x86 a jakékoliv další. Myšlenka to není v principu špatná.

Ono to i celkem dává smysl. Ve formátech bytecode není až takový rozdíl. Aspoň ne IMHO takový, aby z toho vyšel .NET lépe. Spíš je to otázka implementace. Doufám, že se Google poučí.

aha ... pán nezažil WinCE ...

jedna aplikace pro 3 různé CPU
* knihovna 3. strany pro 3 různé CPU
* MS implementace WinCE pro 3 různé CPU
= nekonečno problémlů

lepší je

jedna aplikace
* knihovna 3. strany
* davlik pro 3 různé CPU
= mnohem méně problémlů

Zjevně je lepším nápadem jedna aplikace, knihovna třetí strany, a .NET pro 3 různé CPU :)

no VM je pro tyhle účely vždy dobré řešení ...

a až bude .Net fungovat na víc než jednom CPU tak by taky šlo použít

O čem konkrétně mluvíte? O podpoře SMP, nebo o podpoře více architektur? .NET Framework samozřejmě podporuje SMP, a je multiplatformní (například WinCE s .NETem jsou k dispozici pro x86, ARM a SuperH).
Navíc se domnívám, že zákazníkům čím dál méně záleží na technických parametrech zařízení. Kdo si kupuje telefon podle počtu jader CPU nebo velikosti ROM? Zákazníky daleko víc zajímá, k čemu mohou telefon použít. Například Windows Phone (kde dosud není v prodeji zařízení s dual core CPU) mají daleko plynulejší a rychlejší interface, než dual CPU zařízení s Androidem.

Na x86 je .NET Framework, ale na ostatních je jen .NET Compact Framework a to je sakra rozdíl ...

O plynulosti .Net/Java/Davlik se můžeme bavit hodiny ... vždy jde jen o dojmologii.

Pokud jde o nahrazování Davliku něčím lepším, nepotřebujete plný .NET Framework. Bohatě stačí Common Language Infrastructure. Další možností je Bartok compiler.

O (ne)plynulosti GUI Androidu mluvil i Andrew Munn z Googlu.
http://www.androidmarket.cz/ruzne/proc-je-ios-plynulejsi-nez-android/

Možný důvod bude v tom, že je to docela rozdíl, když ta aplikace má 120 MB místo 40, aby podporovala obě hlavní ARM architektury a ještě x86.

hmm preco je ten Davlik tak uspesny a Mono nie a nie

ze by boli vsetci sialeni

Protože Dalvik byl vytvořen podle potřeb z praxe, zatímco Mono je projekt, který se rozhodl řešit neexistující problém?

Tak s tím narustem vykonu to neni as tak horke. V clanku se sronavaji jen struktury a generiky na daviku a na .net virtual masine a tam je nameren zminonany narust.

Něco podobného jsem čekal. To mi připomíná jeden blog post, kde autor psal o přechodu z CPythonu na PyPy. Dosáhl za určitých okolností zvýšení propustnosti aplikace cca o 20%, ale za cenu toho, že mu paměťová náročnost vzrostla o stovky procent, musel obětovat jeden handler, aby se mu aplikace vůbec do paměti vešla (což se mohlo projevit za specifických okolností) a hlavně: zrychlení se projevilo až poté, co se JIT pořádně nasosal; po restartu aplikace byly odezvy podstatně horší než s CPythonem. Jinými slovy - s nadšením opatrně.

Já také věřím, že nárůst výkonu je dost diskutabilní. Vypíchnout vlastnosti běhového prostředí, oproti jinému je velmi levné. Otázka je, jak to vypadá v reálně psaných aplikacích. Já osobně se strukturám poměrně rád vyhýbám.
A co se týče generik, hádám, že rozdíl tam byl způsoben tím, že byly použity Value typy proti primitivním typům v Javě, kde - pokud se nepletu - v javě dojde k Boxingu a Unboxingu. Pokud by se jednalo o reference, pak by měl být výsledek spíše stejný.

Jinak v odkazovaném článku se hovoří o "výhodném" klíčovém slovu virtual. Já osobně bych za tohle klíčové slovo nějraději někomu napráskal.. stejně tak za možnost "Hide". Správně napsaná virtuální mašina by měla mít nižší výkon pouze ve chvíli nahrávání nových tříd, kdy je potřeba překopat kód volání virtuální metody. Jinak je to jen další věc co obtěžuje programátora

statistikam, ktore si sam nesfalsujem. Inak musim povedat, ze mono je celkom slabota, mozno na nejake prezentacne ucely ale dat ho do nejakej serioznej aplikacie, tak to by som neodporucal.