
Android Ported to C# - pmjordan
http://blog.xamarin.com/2012/05/01/android-in-c-sharp/
======
untog
Fascinating, especially in the light of the Google Java issues right now- the
performance graphs are just the icing on the cake.

Mono has traditionally had a reputation as being a lot slower than .NET-
perhaps that isn't the case any more either? It would be great to see some
independent third party figures on this.

It's funny that the MS created C# is one of very few languages that lets you
make native apps in iOS, Android and WP.

~~~
acak
Forgive my ignorance. Which application lets you write native iOS apps in C#?
Thanks.

~~~
untog
The guys who made this blog post make some software called MonoTouch.

<http://xamarin.com/>

It costs $400 for a license, though. But boy I am tempted... I know, I know-
you need to go with the native languages for the best experience. But keeping
a huge chunk of my codebase between platforms is a very, very interesting idea
to me.

~~~
stouset
A very interesting idea to you, but one your users couldn't care less about.

Never forget about the users.

~~~
untog
It would be an interesting idea to them if they have an Android phone and I
wouldn't have the time to code for two platforms otherwise.

I get that there is a tradeoff involved, but the Mono-x products are in an
interesting space. They aren't webviews (like PhoneGap), they aren't a weird
JS hybrid (like Titanium)- they're full native experiences. You'll get some
newly released features later (I imagine), but the user experience really
shouldn't be affected that much.

~~~
cageface
The Mono guys have been very quick to support new iOS features so far.

------
kefs
> We matured Sharpen a lot, and the result is a much-improved Java-to-C#
> translation tool for everyone. We are releasing this new version of Sharpen
> today along with the code for XobotOS and we hope that many more people will
> benefit from it and contribute to it.

That should be bolded.

~~~
ch0wn
Totally! If Google would actually dump Java in favor of C#, there would be the
huge problem of all the apps that need to be ported. With a tool that has
already proven to be capable of doing that, the required efforts are already
massively reduced.

------
jsight
Interesting, but there's not a single mention of memory usage impact. Dalvik
in particular makes some fairly severe tradeoffs to reduce memory usage.

OTOH, I've often wondered if those tradeoffs are actually worth it in the end.
This may just be demonstrating how weak/slow the Dalvik VM actually is.

~~~
Osiris
I find it interesting that there was such an effort to reduce memory usage
because I've always had severe memory issues on the two Android phones I've
had.

The first, the myTouch 3G had about 100MB of RAM, with only about 25MB free
from a cold boot, meaning the phone is really really slow due to memory
pressure.

My current phone, a G2, has about 350MB of RAM total and about 70MB free on a
cold boot (ICS).

A full Ubuntu Desktop install can use only about 250MB of RAM on cold boot and
even Windows XP would run in 256MB of RAM.

So with so much emphasis on saving RAM, why is 350MB of RAM insufficient to
run basically one app at a time on a phone (plus the various background
processes the system is running)?

~~~
Zigurd
"Free memory" in a garbage-collected managed language is difficult to measure.
If you don't have to GC, the performance-minded choice would to not GC. Every
computation costs battery life, so I would suppose Android's GC is tuned to
not run if it doesn't have to.

If you look at the specifications of system.gc(), it can be implemented as a
placebo, like the "push to walk" button at the street corner. So even
explicitly GC'ing isn't guaranteed to do anything.

Android also has a strategy for "swapping" components within a process, and
whole processes. This is, effectively, Android's GC strategy across processes.
An Android system's memory, especially on small-memory devices, should always
look full-ish, but you can almost always launch a new task, since GC and
components and process "swapping" (the "destroy" phase of component lifecycle)
and GC can almost always make room for more.

~~~
inoop
I think the biggest problem with embedded GC is that you generally don't want
to do pay the memory overhead that comes with generational algorithms. It's a
pity that most Java systems are layered on top of some C-based OS, so that
each process effectively has to have its own heap, with all the memory
overprovisioning that entails.

~~~
reirob
Can you tell what you meant by "most Java systems"? Which are the Java systems
that are NOT running on top of some C-based OS?

~~~
inoop
Managed operating systems such as JNode (Java based) or Singularity (.NET
based) have managed kernels - everything is written in a memory-safe language.
The OS can verify the memory-safety of a program in the loader (bytecode
verification), so that there is no need for an MMU to implement process
isolation; different processes can share the same heap. There is also a big
performance advantage as process switching is essentially as fast as thread
switching. IPC is typically done using message passing, but Singularity for
example also allows processes to set up a shared memory space.

edit: relevant paper:
[https://agora.cs.illinois.edu/download/attachments/28320883/...](https://agora.cs.illinois.edu/download/attachments/28320883/singularity-
sigops07.pdf)

~~~
reirob
Thanks for this information. I am curious to see in which domain such
Operating Systems will be used first. I am wondering actually why Google did
not use such an OS architecture for Android (or Apple for their phones).

------
jeswin
Wow! Congrats.

Isn't this like huge, though? If you can actually make it run faster, I am
guessing it would be possible to spin it off and get serious funding.

I merely watch from the sidelines, but what the Mono/Xamarin guys accomplish
year after year could be a good lesson for any founder. Having spent enough
time in the .Net world, I can tell that any attempt at creating a compatible
.Net framework is a daunting, enormous undertaking. I guess the key thing is,
FOCUS.

------
revelation
I guess Google did make the wrong choice back then. I certainly prefer C# over
Java any day, even by the most basic test like "language features". Using Mono
would've certainly resulted in _less_ fragmentation than they have with Dalvik
today.

~~~
mdwrigh2
> Using Mono would've certainly resulted in _less_ fragmentation than they
> have with Dalvik today

Why would using Mono result in less fragmentation? Most of their
"fragmentation problem" comes from having developers having to develop for
multiple devices (screen size, performance, GPU, android versions, etc.), and
changing the language won't magically fix it.

~~~
revelation
Not that kind of fragmentation; sorry, given that the phenomena runs rampart
in Android world, I should have been clearer.

SUN and Google have both expressed concerns over fragmenting the Java
ecosystem. And with Dalvik, that has certainly happened.

~~~
mdwrigh2
Ah, that makes much more sense. Having said that, where do you see
fragmentation in the Java ecosystem? I don't use Java to write anything but
Android apps, but I've used a few pure Java libs with Android and they all
seem to work great.

That isn't to say it isn't happening, I just don't experience and would be
interested in knowing where it _does_ occur.

~~~
wmf
Blackberry OS and Android are both Java-based, but try writing an app that
runs on both.

~~~
NonEUCitizen
Blackberry is more J2ME-ish and Android is more J2SE-ish. It's possible to
share engine code (I've done it) -- you'd still have to do custom UI code for
each.

------
j_s
I am curious about Sharpen, the automated translation tool used to convert
from Java to C#. It seems like every project that uses it winds up with its
own tweaks that have no centralized location to be upstreamed to.

For example, Sharpen was also used to translate JGit to C#:
<https://github.com/mono/ngit>

~~~
migueldeicaza
The history right now is:

Original Sharpen -> mono/ngit sharpen -> XobotOS sharpen

So the XobotOS one is the most complete, but also requires more setup than the
NGit one.

------
daniel_solano
This is really interesting project, and after taking a little bit of time to
look it over, there are a couple of things that I have noticed:

1\. It's not entirely clear how to use this. Is XobotOS a replacement for
Android, or is it something that can be shipped as a standard application? In
my limited time reading the documentation on the GitHub page, this was not
clear to me.

2\. It looks like a it is a terminated research project, to quote the README:

 _This code is provided as-is, and we do not offer support for any bits of
code here, nor does Xamarin plan on continuing evolving XobotOS at this
point._

From the blog post, it sounds like they are integrating some of this
technology in their products, but XobotOS is otherwise just a code dump. As
such, unless someone is really interested in this, it doesn't seem like it's
going to go anywhere.

------
sosuke
Do those benchmarks suggest that XobotOS is faster for those metrics than
vanilla Android? That seems like a very large performance gain, and I already
wonder what the performance on a device would be like.

~~~
jlawer
Yeah, but this was 1 synthetic benchmark, which heavily uses 2 features they
made a point about being significantly faster. The real question is what is
the difference between dalvik and mono on more balanced applications. I expect
we are talking closer to 10% difference then the order of magnitude their
benchmark shows.

~~~
migueldeicaza
It really depends on the program load. In general, Mono is just a more mature
VM than Dalvik is, so it is rare for Dalvik to match Mono (although there are
a couple of cases where it matches it).

The other problem is that Dalvik uses a model that limits the amount of memory
your app can use, so most of the heavy duty tests could not be ran to compare
the apps, since Dalvik would crash with an out of memory condition while Mono
does not impose this limit.

Dalvik has also other ugly limitations, like their GC being suspended whenever
a JNI invocation is taking place.

------
cageface
The other thing that's holding me back on Mono for mobile is that it really
only addresses the non-UI parts of an app and in most apps the UI code is
80-90% of the entire codebase. So rewriting some core logic and network code
in a portable language isn't really enough of a win to justify using working
with an unsupported (by Apple) and niche tool.

~~~
noveltyaccount
> in most apps the UI code is 80-90% of the entire codebase

Not in my experience. I write software for large enterprises, mostly .NET glue
between systems like SAP, e-commerce engines, search engines, databases, etc.
The UI is a thin little layer on top of complex systems integrations. I'd say
the UI code is 10 to 20% in most systems I've worked on.

~~~
cageface
I'm talking specifically about mobile apps here. Most don't involve
sophisticated processing or logic but need a very slick, polished UI.

~~~
HardyLeung
I think both of you are right. To each his own. I have a few applications that
are algorithmically complicated and it is impossible (or very expensive) to
implement multiple versions of the same thing on different platforms. Even
though the core stuff is say 60% of the codebase (vs 40% in UI), say measuring
in number of lines, the benefit of doing the 60% in a single _productive_
platform is very very important. I'm talking about correctness,
maintainability, consistency between different versions, etc. The remaining
40% UI code can be ugly, platform-dependent, inconsistent, etc, and it won't
bother me as much. After all, an error in the _presentation_ is far less
lethal than an error in the core logic. In this case, a common platform is
strongly favored.

That said, indeed many apps are not like that. Going forward though, I would
conjecture that there will be more and more sophisticated apps.

------
kamechan
not sure that C# is the answer either, given that microsoft is trying to build
a nest in the mobile space. that said, nice work.

poses an interesting question though: if google had to or wanted to switch
platforms/languages, which might they choose?

~~~
untog
The article covers that, to some extent:

 _Unlike Sun with Java, Microsoft submitted C# and the .NET VM for
standardization to ECMA and saw those standards graduated all the way to ISO
strong patent commitments. The .NET framework is also covered by Microsoft’s
legally binding community promise._

It's strange- with the work Xamarind has been doing, C# is one of the few
language choices you have to go cross-platform and native- MonoTouch does iOS,
MonoDroid does Android, and MS themselves do Windows Phone. I've not used any
of these extensively so can't vouch for them, but it's an interesting
development.

~~~
edwinnathaniel
I was reading the wikipedia entry about C# a few days ago and was surprised to
see the following bits:

"As of December 2010, no ECMA and ISO/IEC specifications exist for C# 3.0 4.0,
and 5.0."

<http://en.wikipedia.org/wiki/C_Sharp_(programming_language)>

Does this mean newer syntax updates won't make it to Mono? or not as open as
it used to be in terms of patent and copyright?

~~~
migueldeicaza
Standards take time, the ISO spec is typically 2-3 years behind the current
product.

But cheer up, the ECMA team just updated the VM spec a couple of months ago
and the committee is resuming work on new features.

We are all pretty psyched about the next steps for the ECMA standards.

As for Mono, we already have C# 5 and many of the new class library features.
Having two independent implementations helps coming up with a better standard.

~~~
solutionyogi
Can I use async/await on Monotouch right now? If yes, I think you have a new
customer!

~~~
migueldeicaza
Some assembly is required for that.

MonoTouch is currently based on Mono 2.10, while C# 5.0 is based on the new
codebase on Mono 2.11.

We are waiting for Microsoft to officially bless C# 5.0 as complete before we
can ship it, otherwise we will break people's code.

------
sreque
I like .NET and I like Mono, but I was disappointed that the article showed no
hard evidence of overall performance improvement for XobotOS vs Android. I
understand that they probably have more important things to work on, but I
hoped that if they could show concrete benefits even at this early stage then
their work might pick up more traction. It was a fun idea to read about, at
least.

------
b0sk
How long till Google buys Xamarin?

------
pixie_
They should wrap up the whole working build environment in a VM, and
distribute that, so people can start contributing immediately.

------
Mordor
C# created because Sun didn't like Microsoft. Not at all surprising if Google
drops Java.

------
zanny
I would really love for Mono to take off in a big way, I like the language
features and syntax of C# more than Java, but when I have to work with other
developers it is nice not to have to worry about major memory leaks across the
system.

And the patent wars regarding Java just make me not want to support that
development ecosystem anymore.

------
biafra
Do I need to install Windows to do MonoTouch development for Android?

~~~
darrenkopp
no, you can use monodevelop on osx to develop mono for android applications.

~~~
zanny
Or use monodevelop on anything, it is cross platform and open source from
Xaramin.

------
sll
Why would anybody be interested in a MS-only language in this day and age
(when MS is in decline)?

~~~
amorphid
Microsoft's sales and profits continue to grow. How is that a company in
decline?

~~~
jhuni
Microsoft's relative power over the computing industry has been in decline for
several years now.

~~~
amorphid
I suppose one could make the argument that any company that grows more slowly
than the rest of the industry is becoming less relavent.

