Today Novell released Mono for Android 1.0 and MonoTouch 4.0 (blog posts from Miguel de Icaza detailing the releases can be found here for Mono for Android and here for MonoTouch).
I’ve used MonoTouch quite a lot, hence the rather detailed tutorial I released, which was detailed here.
I’ve also been spending quite some time getting up to speed with Mono for Android. Indeed in February, I gave a talk on building apps with Mono for Android (or MonoDroid as it was referred to back then) in conjunction with Delphi Prism at a conference in Las Vegas. Also, today I spoke at a User Group meeting about building an Android app in C# using Mono for Android.
Over the next few weeks I’ll be working on a tutorial that shows the use of Mono for Android with C# and will post when it becomes available.
In addition, I’ve kept notes of various interesting things, such as issues, gotchas, solutions to problems I’ve encountered and so on. As I write up the tutorial I’ll be posting some of those tidbits as and when they crop up in the coverage.
One thing I learned today from Miguel’s release blog post, though, is that when you build an app for distribution the Mono linker is engaged. This generates a single binary containing only the items known to be used (and their dependencies) – everything else is stripped out. Smart linking in other words.
This is in contrast to how things work during development where you link against a shared runtime that is deployed to your emulator or device. The idea during development is that the executable generated will be smaller, thanks to linking against a shared runtime (well, two shared runtimes actually – there’s the main Mono runtime and a much smaller runtime specific to the version of Android you are targeting). With a smaller executable it takes less time to build and deploy to the emulator or device.
With a single executable generated for distribution this simplifies the question of how these separate entities are to be managed.
Update: This is an old post, and it should be noted that the current versions (at the time of writing this update in Jan 2012) are Mono for Android 4.0 and MonoTouch 5.0.
Brian - any idea what this smart linking means in practice for the app storage overhead and loading times? Have you had a chance to try this approach with your demo app from DG?
ReplyDeleteThat's a sensible question, Mike. I hadn't checked, but your question prompted me to test it out on the final Preview version, Preview 14.
ReplyDeleteWith the Debug configuration, the files generated to disk by the compiler looked like this:
bin\Debug\TimeSheet.dll = 41 kB
bin\Debug\com.blong.TimeSheet.apk = 329 kB
bin\Debug\com.blong.TimeSheet-Signed.apk = 332kB
On the phone the figures were as follows. The first figure is the size when the item is installed on the external storage (SD card, as in App2SD). The bracketed figure is the size if installed solely on the phone.
TimeSheet 1.0 = 556 kB (892 kB)
Mono Shared Runtime = 3.87 MB (18.02MB)
Mono Platform Support for API Level 8 = 12 kB (12.27MB)
With the Release configuration chosen, and the Linking mode set to link in the SDK and user assemblies the figures look like this. I didn't go through the steps of manually signing with a custom certificate using the JDK's jarsigner tool, as it was already signed with the debug certificate. I also haven't run the package through the Android SDK's zipalign tool.
bin\Debug\TimeSheet.dll = 38 kB
bin\Debug\com.blong.TimeSheet.apk = 5601 kB = 5.47 MB
bin\Debug\com.blong.TimeSheet-Signed.apk = 5567 kB = 5.44 MB
TimeSheet 1.0 = 4.40 MB (9.84 MB)
- Brian
Thanks Brian.
ReplyDeleteSo you're getting back maybe 20MB of SD space, but the phone storage consumed is essentially unchanged - if I've understood correctly.
Are you seeing any load time improvements with the new model?
Mike
That is about the size of it, yes.
ReplyDeleteI haven't yet found out how the device decides how much stuff stays on the phone when you move things to the SD card. It seems to vary from case to case.
But yes, SD card usage drops significantly but the phone usage stays about the same.
On older phones (!) like the original HTC Desire, which had somewhat limited app space on the phone, this can still be of concern.
But my understanding is that more recent phones (such as the Desire HD etc.) increase this, and so this becomes less of an issue.
Of course some people overcome the issue entirely by rooting the phone and installing a custom ROM, which makes more space available, but it's not something I've yet tried.
As mentioned yesterday, if I need some space, a careful look at the things installed typically yields a bunch of frivolous things that aren't actually used barely at all.
Not an ideal user solution, I grant you.
Definitely things to bear in mind...
Oh, and load times may be fractionally improved. But on the device it's not noticeable.
ReplyDeleteYou do get a hit from the Mono runtime.
However... it's a first time hit. Since the Android way is to not kill processes until absolutely necessary, you tend to find going back to an app, even much later, is very quick to hit the first screen (splash screen in my case).
I was playing with the option of really physically exiting my app at one point, but found that is not a good plan and goes against the Android ethos.
As does use of a Task Killer.
I used one of those for the first few months of owning my Android phone, thanks to reading about how they were necessary from the user reviews.
I only realised much later that they are actually a potential problem for the phone - killing processes is not the way. Android will pare things down if it needs to when under pressure.
Hence I've uninstalled the Task Killer and things are all fine and dandy.