The man, the legend: a main developer of the BeOS. Did the App Server, Interface Kit, Application Kit. These days, Benoit Schillings does something else entirely: he’s currently the chief technology officer at Myriad, where he and his team is working on Alien Dalvik. Now that I know he’s the one leading this team, I know for sure we’ve got something special here.
Schillings is obviously somewhat of a legendary name around these parts. Some of the more recent additions to the OSAlert readership might not realise it, but we are, effectively, an illegitimate bastard child of BeNews, where Eugenia worked before breathing life into OSAlert. Fun fact: she found OSAlert simply by typing the URL into the address bar, without knowing if she’d actually end up somewhere. OSAlert was – if I recall correctly – pretty barren at that point, so she contacted its owner (hi David!), and rewrote the site from scratch to suit her needs.
Yes, I cherish our heritage. It does explain why OSAlert always had a sort of special association with the BeOS world, which was further strengthened by the fact that I, too, am a massive BeOS zealot. But, enough history.
We already reported on Alien Dalvik not too long ago, but apart from a nice demo, we didn’t really have anything to go by. Luckily for us, Engadget dropped by Myriad’s booth at Mobile World Congress, and Schillings himself demonstrated Alien Dalvik running on Maemo on the N900.
Let’s start with a bit of news that should make the boatloads of Qt fans around here very happy: it is coded using Qt (not s surprise considering Schillings worked at Trolltech), in an entirely portable fashion. While they’re focussing on Maemo on the N900 right now, you should eventually be able to run this on Symbian as well, and possibly wherever else Qt runs.
Intriguingly, he also stated that it should be able to run on devices that do not have Qt – so I’m guessing the necessary Qt bits are then embedded inside Alien Dalvik or something? Some experts out here that could help with this one?
As good as it already seems to work, this is very much pre-production code, so there are a number of limitations. For instance, Schillings mentions that Angry Birds is problematic because it requires native code execution. He states that they know how to solve that issue, but that they haven’t yet implemented it.
Us end users won’t be able to just buy Alien Dalvik once it’s ready; the idea is that device manufacturers and carriers will buy the technology and integrate it into their devices. Now that I know Schillings is involved, I’m actually quite excited about the prospects of this technology.
It’s unlikely that Qt plays a big role here, as the point of Dalvik is that it comes with its own GUI toolkit. Probably, Qt was just a suitable windowing system to target, because it makes the whole thing portable. So if you don’t have or want Qt, it’s probably quite doable to port it to a different graphics/windowing system.
qt probably *plays* a big role. qt targets different paint engines on different platforms (x11 on *nix, CoreGraphics on osx, opengl es for embedded or it’s own raster engine for any other situation). that’s *one* of the things which makes qt great for cross-platform development.
programming virtual machines can be done with idea to run it in hosting environment (e.g. javascript, lua and even python) or to run it independent from any hosting environment. dalvik vm is done to be the only virtual machine running on top of hardware (using linux kernel just for communication with hardware). java vm tries to run in parallel with the rest of the system. alien dalvik obviously like java vm is designed to run in parallel with other vms or on top of them.
making vm to be easy to integrate with many systems is quite hard. that’s why qt is/was great choice for alien dalvik. besides targeting different graphic’s systems qt provides unique api for many other subsystems: networking, multithreading, multimedia, interobject/process communication etc.
qt is not perfect. but besides mono (which is heavily leaning on .net) this is the *only* really cross-platform development atm. and it is lgpl.
qt (without nokia fucking it up with ms deal) could repeat the history of superior os/2 which could run native windows application even better then windows itself. providing that kind of solution you usually convince lazy devs to go just with native android or in the past windows applications.
Please note that I said “doesn’t play a big role *here*” (answering Thom’s question). Why else would Benoit say that Qt can be eliminated from the equation?
ok, sorry. i probably got it wrong. my point is that qt *is* very important for writing the vm and of course that after vm being finished/compiled you don’t need qt anymore to run it. still, there is a probably quite easier integration with systems which are based on qt (e.g. meego).
Hmm, no. Libraries used to develop a code are usually also needed at runtime; otherwise there’s no point in using them. The only exception I know of is unit test libraries, which are useless after the product is released. Unless Qt is used by the development tools and not by the product itself, Qt is needed at runtime. It may be linked in a static way but it’s definitely there.
Edited 2011-02-21 13:53 UTC
Please HP put this on webOS! Right now webOS is missing country/city-specific apps (for instance public transport planning) in most parts of the world. If Android apps could run on webOS, this would no longer be an issue, and nothing would stand in the way of a successful worldwide webOS launch!
I’m actually a bit sad that considering it was first developed on the N900 with Maemo 5, they are not considering releasing it to the end users of that platform. In a MWC video they say it’s a 20 MB install, and I’m pretty sure most N900 owners would be more than happy to pay for having this on their phone (as a long thread on a Maemo forum shows).
Indeed. I too am an N900-owner and would definitely want this thing. N900 is in the sad state of being completely discontinued, even the OS itself, and as such the only people interested in coding for it are those who do it on their free time at home and thus there simply ain’t many applications to choose from, if any. If we got Alien Dalvik on the other hand we could just tap into all the great Android apps and continue using our beloved N900s for years to come.
I really hope Myriad comes around and releases this for N900, too.
Huh? To me it appears there are tons of apps for N900 coming all the time, to extas-devel.
<quote>Huh? To me it appears there are tons of apps for N900 coming all the time, to extas-devel.</quote>
From the afore-mentioned people who code in their free time, not from any commercial entity and hardly “all the time.” And tbh, most of the stuff there is just poor-quality rehashes of what is already available.
+1. I’d pay some serious money for a nice Android emulator on my N900, even in “as is” condition – not because I’m unhappy with my N900 (what other phone runs Free42, Python and Firefox?), but just for the fun of exploring alien Android apps on my old friend.
Well, I can hope they’ll change their mind…
You can buy an mmc card and install Android (NITDroid) on it. This sets up a dual boot system where you can select either Maemo or Android at boot time.
There’s still plenty basic of functionality that doesn’t work. Last I tried it even basic phone calls didn’t work. Neither does camera. That already renders some of the most important functionality useless.
If on the other hand we had Alien Dalvik we would be able to benefit from those features and still sport our favorite Android apps.
What is so great about this?
I mean, what is so great about Java/Dalvik apps, that make them better than QT apps?
If he can embed needed QT code, why can^A't this be done with any app, making it completely portable?
I suppose this would have the advantage of UI compositing possibly being hardware accelerated unlike Android, but that^A's not really an advantage over something that keeps away from Dalvik entirely. I just don^A't like the whole idea that Dalvik has ^A'resurrected^A' Java somehow, when I thought it was dying for good reaons. Why not just put the same effort into building more meta-APIs, scripting JIT and tools to extend QT?
Edited 2011-02-19 02:17 UTC
It’s not about Dalvik versus Qt; it’s about making Dalvik applications available to people who can’t run them now.
If this isn’t open source and won’t be available even for buying – what’s the fuss?
OK, crap for all, then…
I mean, why not Win16 for all platforms?
Certainly more apps exist there than Dalvik.
I’m not sure what are you talking about. Given the popularity of Android – the number of quality Dalvik based apps will only increase.
Java never died.
Many people wish it did, but it is still the number one language to program for. And in the IT world, most new developments are Java/.Net based, regardless of the geek community might feel about it.
I do love my C++, and feel there is no native programming language that matches it for the time being, but many companies see it differently.
To be honest if it hasn’t for QT, you would be hard pressed to find a good C++ framework.
The main problem being that there are not many developers that know how to properly make use of C++.
Plus C++ is not a language that is easy to outsource,
hence the focus in easier languages.
Right, I don`t expect everybody to write every little app in C++.
(though Apple`s App Store seems to have plenty of developers who can write in ObjC…)
Fortunately, QT has it`s own JS-based QTScript and QML, and can link to other langauges like Ruby or Python. So language isn`t the issue for WRITING the apps, but only matters as far as the `standard platform language` determines the functionality of the API. Obviously, people still write C++ where it`s needed… And Google recognizes this, enabling native code execution was their first step away from Java mediocrity. Yet their entire API apps are expected to interact with general functions is still based on Java/Dalvik and it`s compositor isn`t even HW-accelerated (and they don`t seem to care).
Including QT sub-components for platforms that don`t already host them is a drag, but that`s what you have to do when platforms are closed and don`t allow users to install those libraries. Given network speeds, and the fact each app will not use the vast majority of QT, I don`t think it imposes an overly harsh burden for downloading of single apps.
Edited 2011-02-20 01:22 UTC
Ah, so it’s the new Cobol.
“And in the IT world, most new developments are Java/.Net based, regardless of the geek community might feel about it. ”
They can have all the java and C# they want as long as it stays behind the corporate firewall along with Visual Basic. Consumers want smooth 3D hardware acceleration and low latencies for audio apps and they won’t get it from java. That’s why Android had to spend so much time working and expanding the NDK/renderscript.
“I suppose this would have the advantage of UI compositing possibly being hardware accelerated unlike Android”
I think this has changed for Honeycomb:
http://android-developers.blogspot.com/2011/02/introducing-rendersc…
http://developer.android.com/sdk/android-3.0-highlights.html
“Android 3.0 offers a new hardware-accelerated OpenGL renderer that gives a performance boost to many common graphics operations for applications running in the Android framework. When the renderer is enabled, most operations in Canvas, Paint, Xfermode, ColorFilter, Shader, and Camera are accelerated. Developers can control how hardware-acceleration is applied at every level, from enabling it globally in an application to enabling it in specific Activities and Views inside the application.”
It is possible to embed parts of Qt in an app by recompiling Qt to be statically linked.
It does take a bit more work to accomplish, but it is perfectly doable.
Probably the reason why most developers don’t do this is that it substantially increases the application’s size, since it has to include whole or parts of Qt inside the app itself. It is also more practical to use Qt as an external library so it can be reused by other Qt apps, reducing code redundancy.
However, if the developer is targeting a system that doesn’t have a Qt installed (or is quite a hassle to install), embedding Qt might be a better option.
More info here: http://www.formortals.com/how-to-statically-link-qt-4/
Edited 2011-02-19 05:16 UTC
Right, no reason you couldn`t do this for iOS AFAIK.
Even under their former language restrictions, C/C++ qualified.
Since Lighthouse is still in development and not included in regular Qt licenses – all this can’t be normally used. But it’s possible, yes:
http://www.youtube.com/watch?v=MjYJdi48B8Q
Sorry in advance if I sound like that-same-troll-again, but can someone remind me again why MeeGo is now Nokia’s fifth wheel, while WP7 – for which Alien Dalvik is not ready, and would have to be allowed to use native code (not impossible, but not done yet) – is their main platform?
“MeeGo is too late and does not have any app”, right?
Seriously, between this and the lack of communication with Intel, Nokia really looks like a headless chicken.
(On an unrelated note, I just discovered the real story of Mike the headless chicken… :shock:)
Edited 2011-02-19 22:12 UTC
Because customers want a compelling experience. Shoehorning Android apps onto another platform wont solve that problem.
It doesn’t have to be shoehorning. I use old Windows, Amiga and other games all the time on my T61p with Fedora, they appear as icons in the game menu and when clicked start fullscreen, fully configured for my hardware, including gamepad. Somebody without technical knowledge would not know it isn’t native.
When implemented this way you have the second largest library of applications in the world right from the start.
Edited 2011-02-20 07:59 UTC
They maintain the Android look and feel, and throwing users who are accustomed to one experience, into another one, for the sake of application compatibility to me, is a waste. People don’t want a half assed implementation I don’t think, people want home grown applications optimized for the host platform.
The size of an application store does not matter as much as the quality of the most commonly used applications. 100,000 task managers don’t mean a thing to the end user.
This is why a lot of these open platforms don’t get anywhere. The opennes is overemphasized to the point where you sacrifice cohesion in the platform. There is a real balance that needs to be struct, and until people stop pretending that because you can do whatever you want with something, that you should, then things wont change.
Stop looking at things as numbers, or checkmarks in a feature list, and start looking at them as genuine, compelling end user experiences.
I’d much rather an application that performs and feels like it belongs on my phone, versus something that someone threw together. In fact, if we’re going to draw comparisons, this is akin to Palm using iTunes for its webOS devices. Sure, they could do it, but its a cop out and unprofessional.
Edited 2011-02-20 09:28 UTC
Oh My God, this is so disturbing! The big rounded boxes does not have the same color! Everybody is so lost!
Seriously, who gives a damn? You already can’t see the difference between a maemo and an android app (just look at the deezer app).
I know…every website has a completely different look and feel and yet that doesn’t stop people from using the internet.
Most websites have a lot of common interface elements …
e.g.
Call to action buttons,
Click on logo take you back to the home page,
BreadCrumbs
Header / Footer Areas.
etc. etc.
The way an end user expects to interact with an app is the way it’s been interacting with the system as a whole. If an experience is different (not just visually, you cant sit here and tell me that Android and Maemo/MeeGo/whatever will all share consistent behavior with Android’s look and feel) then the customer will be legitimately thrown off. This is UX 101. It’s the whole point behind standard controls.
But you know what, you can be dismissive and you can oversimplify it if you want. However you, and engineers who think like you, are the reasons why the platform will never be a viable third way and will always remain a science project. It’s like its amateur hour.
You people put principals above experience, to the point of absurdity, and you’re producing a genuine, free software, open, …. piece of shit.
There is nothing wrong with code sharing or code reuse across platforms. That’s fine, but the front end UI should be platform specific.
Edited 2011-02-20 16:56 UTC
You people put principals above experience, to the point of absurdity, and you’re producing a genuine, free software, open, …. piece of shit.
You know, more-or-less all modern platforms suffer from the fact that their applications have wildy differing looks and feel. Just take a sampling of Windows apps. Or OSX apps. Or even Android apps. And so on. Hell, even Microsoft themselves have trouble with keeping looks and feels consistent across their own software.
It still hasn’t stopped people from using those applications. In fact there’s applications that are extremely popular despite having looks and feels totally and wholly different from anything else!
The fact is that basic UI elements still work the same: tapping/clicking a button works the same on Android, OSX, Maemo and Windows, scrolling up or down works almost identically across all the platforms, and so on. Having slightly differing looks and feel is a hindrance, yes, but it’s almost never completely blocks one from using the application in question.
Besides, trying to insinuate that only open-source software has consistency-issues is not only ignorant, it’s downright stupidity.
Edited 2011-02-20 19:13 UTC
[qThis is UX 101. [/q]
Didn’t stop the iPhone. If you want an inconsistent mess, look no further than iOS.
Well said.
A lot of commenters on here put ideals over pragmatics to the point of obsurdity.
The general “polish” on a software product that makes the difference between something which is adequate to something that is fantastic.
For example on my HTC desire, the volume buttons is exactly where my thumb would be if I am talking on the phone, so I can adjust the volume accordingly.
I also have a nokia 1661 which I use as my backup phone … which I had to use this weekend since I left my android charger on my office desk … another nicely designed phone which is solid …
Double tapping “up” on the phone turns the small torch on, which is kinda intuitive since the the torch is above the screen. Tapping “down” on the phone brings up the phone book which is where the phone’s keypad is … this is a ^Alb20 phone, and nokia has made the effort to put this in … on one of their lowest end phones.
These “nice little touches” that make the difference between good and great and many devs and geeks have an attitude “of you don’t really need that” … Consumers notice these little differences over time and it can either tarnish a companies name or make it.
And experience proves that consistency is an over-hyped concept, usually championed by Apple and thrown by Apple fanboys at the ugly, unsuccessful Windows and Linux (as you are doing again – which is funny, as linux desktops are very consistent, at the expense of some other more important IMHO design details), who just happen to have turned their coats, by the way: http://www.osnews.com/story/24218/Consistency_in_UI_Design_Is_Now_B…
But maybe you’d rather read a report from a usability expert on this awesome iOS that crushes the competition thanks to the consistency of its interface (and not just hype):
http://www.useit.com/alertbox/ipad.html
Say what again?
Edited 2011-02-21 12:50 UTC
Is it open source?
Is that more important than the functionality or is it the natural curiosity in your tech side that speaks out?
See my comment above. If it’s not open source (read I can install / port it if possible wherever I want), and can’t even be purchased by individuals – this project is of little interest to me because of its very limited usability.
Edited 2011-02-21 15:08 UTC
This development seems to confirm what i had suspected, that the idea of os independent (subset of) programmable runtime isn’t as dead as it seemed to be. Having the bigger part of the mobilie app market being just variants of iphone experience and differing for sake of more political ( vertical platform controll ) than technical reasons just begs for such a simple solution. They only seemed to have taken the torch form now failed sun attempt. Most apps (esp. fat clents ) doesn’t dive deep into native platform caps anyway. It’s only sad that programmers have again been forced to re-learn the same paradigms expressed a little bit differently for no apparent benefit most of the time. Example? somebody seemed do resent the lack of good public communication guides in some app store. from what I see there’RE plenty of perfectly capable solutions for that in j2me space, including google’s own. And new ones are still emerging.
Edited 2011-02-20 14:42 UTC