Cloud Foundry: Design and Architecture
Derek Collison discusses the goals, the design premises and patterns employed in creating the architecture of Cloud Foundry, VMware’s open source PaaS, unveiling internal architectural details.
The content has been bookmarked!
There was an error bookmarking this content! Please retry.
Posted by Abel Avram on Jan 07, 2011
MonoDroid brings the whole Mono VM to Android, enabling .NET developers to write applications for Google’s mobile OS. Developers now can write applications targeting iOS, Android, and Windows Phone 7.
MonoDroid is a framework similar to MonoTouch enabling developers to write applications for the Android mobile operating system using the C# language and the Mono VM. The MonoDroid API contains the set of core libraries which are contained by Silverlight, except for the UI interface, and a set of bindings to the native Android Java API which are necessary in order to access device specific functionality such as various sensors, cameras, Bluetooth, etc.
In order to develop for Android on Windows, the Visual Studio Professional or better is needed along with a plug-in and an SDK. The SDK makes reference to the Android SDK which in turn uses the Java SDK. Development on Mac OS X is supported from Preview 10 with MonoDevelop, the cross platform IDE developed by Mono. Linux development is planned to be supported soon also via MonoDevelop.
MonoDroid opens the Android world to .NET developers. Using .NET and Mono, one could develop an application for Windows Phone 7, iPhone OS, and Android in the same time, but things are not as straightforward as developers might like. The UI APIs and specific device functionality is different from platform to platform, so one should not expect to write once and run everywhere the same code. The code needs to be clearly divided in business logic and UI-logic, the last part having to be rewritten for each mobile OS. Nonetheless, this is a step forward for .NET developers who want their applications to reach a market as wide as possible.
The roadmap for MonoDroid does not specify when version one will be available, but Miguel de Icaza mentioned they are “are working as fast and as hard as we can to complete Mono for Android.” MonoDroid 1.0 will use Mono 2.8, and will support C# 3.0, .NET 3.5, garbage collection, multi-threading, and other standard features such as LINQ. OpenGL will also be supported through OpenTK API, an object-oriented wrapper for OpenGL libraries. OpenTK is also included in MonoTouch, so OpenGL code can be shared between Android and iOS.
According to de Icaza, MonoDroid is used by the DeltaEngine, a cross-platform game development engine, to run games on iPhone, Android, Windows Phone 7, and XBox 360. Among other demoes, at CES 2011 NVidia presented a game, Soul Craft, running on LG Optimus 2X, an Android phone based on NVidia’a Tegra 2 dual-core chip. The game ran on MonoDroid.
MonoDroid is going to be a commercial product, the price not being available yet. As a reference point, the price for MonoTouch starts at $99 for the Student edition, goes to $399 for the Professional, and ends up at $3,999 for a 5-seats enterprise license.
Building HTML5 Apps in Hours, Not Days
Why NoSQL? A Primer on the Rise of NoSQL
Adopting Git for the Enterprise: Risks and Considerations
Visual Studio vNext: ALM features for Agile Planning, Team Collaboration
...you have have some code that is platform specific and it is not OpenSource or freeware. And with the extra overhead, it would seem, of .NET running, what Android devices will you be able to target? If you have the time and money and you really really only want to use VS.NET and .NET, then I can see buying and using it. But then if you only want to use Microsoft products, why are you targeting non-Microsoft platforms? Otherwise, why not use Java and Eclipse or Python?
That being said, I wonder if this will be even possible in reverse - "Java" running on Windows 7?
I see this as an opportunity for companies with large investments in .NET/C#/VB.NET, especially programming expertise, being able to more easily port their WP 7 apps to Android. Same goes with MonoTouch for iOS. It is easy to buy an IDE or another, but it is not easy to get skilled staff for whatever platform you have.
It's not .NET running, it's Mono. My understanding is that (at least on the IPhone) Mono and the program are Ahead of Time compiled into one big binary, thus getting around IPhone's runtime restrictions.
As far as why. Who knows. People want to program in C# instead of Java or Python. Monotouch might have cross-mobile APIs so that you almost target the IPhone and Android without much fuss.
I'm assuming it would be possible to run "java" on a Win7 mobile, since (unlike the JVM running C#), the CLR should be able to handle Java. Now whether anybody would have the inclination to build something like that is another story.
Since Android is a pretty open platform, I'd be curious to see what the breakdown of development languages/runtimes are for the big apps running on it.
It looks like Mono is carving itself out a nice little niche in the gaming industry.
Take a look at tirania.org/blog/archive/2011/Jan-06.html and mobilebits.de/Blog/post/2011/01/05/SoulCraft-Te...
Yeah, I know Mono is not .NET. I was using it "generically".
The JVM could run C# just as "easily" as Java on the CLR.
The problem is ... Android is an open platform will Win7 is not. That is why MonoDroid was possible.
Not sure, but I think everything must run in Dalvik. Java and Python are just the syntax [currently] used.
i.e. - dev.mainsoft.com/
The JVM can't run C# as easily as Java on the CLR because of things like pointers and value types.
Not everything runs in Dalvik on Android.
The problem is ... Android is an open platform will Win7 is not. That is why MonoDroid was possible.
It's not a problem and not why MonoDroid was possible. The Mono guys targeted the iphone first, which obviously isn't "open".
IMHO Abel Avram touches on a common misconception about skills transfer and easing into new technologies.
First, "programming expertise" is not the same thing as familiarity with a particular language or platform. "Programming expertise" is not language-specific or platform-specific.
Second, the approach of using some sort of wrapper or emulator as a way to ease an organization into a new technology has been tried many times before, and the results are usually not what people hope for. Differences between platforms tend to be deeper than a quick glance can reveal. Just look back to the days when VB6 programmers tried to move to .NET by writing VB.NET. The differences turned out to be significant, after all. The key "new" element to learn was the .NET environment; hiding the details behind a familiar source language didn't really help. Those who bit the bullet and learned C# were better off. IMHO if you need to support a "new" platform then just use the tools that are made for that platform.
When it comes to phones, the differences between devices are so significant that it may be foolish to hope for a single development environment for all platforms. The logistics of managing a codebase may well be more complicated if we develop a set of common code alongside several sets of platform-specific code than if we develop functionally-equivalent versions of an application for multiple target devices, using the tools appropriate to each target platform.
Hi Dave,
I would say it is clear from the context of my comment that "programming expertise" refers to ".NET programming expertise", i.e. knowing the platform, the language(s) and the tools, and not general programming skills.
Regarding the second remark you make, it is true that using a "native" tool for a platform is best from a developer's perspective, but a business decision depends on many factors. If one can use the entire business logic of a C# application, and just rewrite parts of the UI to make it work on Android, then a manager may decide that it is a sound decision to port that C# application to Android because it saves time and money.
Yes, points taken. I just wanted to point out that there is a difference between "because it saves time and money" and "because the manager believes it will save time and money." Shortcuts often turn out to be...not so short.
Derek Collison discusses the goals, the design premises and patterns employed in creating the architecture of Cloud Foundry, VMware’s open source PaaS, unveiling internal architectural details.
Andrew Watson talks about the work of the OMG, where CORBA is alive and well (hint: in your car), UML and UML Profiles vs. custom Modeling languages, DDS and other middleware, and much more.
Sohil Shah discusses creating iPhone and Android enterprise mobile applications based on cloud services using the open source platform OpenMobster.
Paul Sanford presents the transformations supported by data throughout its life cycle, and how that can be better done with Splunk, an engine for monitoring and analyzing machine-generated data.
A common “best practice” for unit tests is to only write a one assertion in each test. I intend to question this advice by showing that multiple assertions per test are both necessary and beneficial.
John Rauser presents the architectural and technological evolution of Amazon retail websites starting with 1994 and ending with adopting Amazon Web Services.
Michael Stal discusses system architecture quality, how to avoid architectural erosion, how to deal with refactoring, and design principles for architecture evolution.
Every developer has had to integrate with another system, API or component. Tis article provides strategies to handle the change and for he separating system boundaries.
11 comments
Watch Thread Reply