<br><br><div class="gmail_quote">2009/10/23 Göran Krampe <span dir="ltr"><<a href="mailto:goran@krampe.se">goran@krampe.se</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
Hi all!<br>
<br>
Some interesting points:<br>
<br>
On Android you can install an app just by clicking on it in the web browser and bam, it will install. AND it can contain native libraries in C or whatever BUT AFAICT it needs to "be" a Dalvik Java app around it.<br>
<br>
For example, someone just published Quake wrapped in a very thin Java/Dalvik layer around Quake as a C lib working using OpenGL ES.<br>
<br>
THUS... Android is MUCH more fun for Squeak. There is no central bottleneck like the App store.<br>
<br>
Secondly, there are TONS of Android phones coming out the next few months. The one that most waits for is "The Droid" from Motorola (Motorola is going "all in" on Android):<br>
<br>
<a href="http://droiddoes.com" target="_blank">http://droiddoes.com</a><br>
<br>
They take iPhone head on :)<br>
<br>
Note also that the Mono folks are all over Android now, the mono JIT seems to run fine, see below.<br>
<br>
Finally, some links:<br>
<br>
<a href="http://www.koushikdutta.com/2009/01/dalvik-vs-mono.html" target="_blank">http://www.koushikdutta.com/2009/01/dalvik-vs-mono.html</a></blockquote><div><br></div><div>Goran, thanks for this link. In particular this is a neat idea:</div>
<div><br></div><div><span class="Apple-style-span" style="font-family: 'Lucida Grande', Verdana, Arial, sans-serif; font-size: 12px; "><dt class="comment-author" id="comment-2227105061610620173">Anonymous said...</dt>
<dd class="comment-body"><p>I believe you didn't understand Dan's presentation after all.<br><br>The Android security model imposes that each application runs<br>in its own isolated process, which forces you to implement<br>
one-whole-VM per process runtime model. In case you don't<br>realize this, this is different from AppDomain because it<br>allows, among other things, your application to run arbitrary<br>native code without risking compromising the system's security.<br>
<br>Dalvik is thus designed to share as much code *and* data as<br>possible between processes. That's why there is an initial<br>"zygote" process that loads a very large number of system classes<br>at boot time (where loading each class requires running code<br>
and allocating objects in the heap), which is later forked with<br>copy-on-write semantics when a new application needs to start.<br>Consequently, this speeds up the startup of new applications<br>significantly.<br><br>I don't think Mono supports any of that.<br>
<br>Finally, Dalvik design doesn't preclude a JIT, it's just that<br>this is not necessary for a large number of applications and<br>that having a really good interpreter was more important to<br>ship a 1.0 device.</p>
</dd><dd class="comment-footer"><span class="comment-timestamp"><a href="http://www.koushikdutta.com/2009/01/dalvik-vs-mono.html#comment-2227105061610620173" title="comment permalink" style="color: rgb(238, 0, 136); text-decoration: none; ">January 6, 2009 2:15 AM</a></span></dd>
</span></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Note that Dan Bernstein (designer of Dalvik?) comments it below.<br>
<br>
regards, Göran<br>
<br>
</blockquote></div><br>