Following up on my previous post the next steps seemed to be get the Xamarin bits installed on my machine.

There are a number of Xamarin editions (https://store.xamarin.com/) with the ones that sounded more attractive to me being the ones that offered Visual Studio support. Those come in at $999/$1899 per platform, per developer per year so it’s clearly got to be something that you or your company sees value in before you’re going to invest in that license fee.

Luckily for me, I was able to get an edition that I can use for demos and so on without having to cough up my own $ so I moved to the next step which is downloading and installing bits.

I’m primarily interested in Android in the first instance but I figured I may as well tick the iOS box as part of the installation;

then I got a nice 2GB of Android SDKs (about the same size as the Windows Phone 8 SDK if I remember rightly);

and then various bits of SDKs (JDKs) downloaded and installed. This takes quite a chunk of time but you do get a dialog letting you know which bit is going on;

Whoever would have thought that you’d need all these bits from all these organisations/companies just to build an app for a phone?

I left this installing while I went off for a few hours so I couldn’t say exactly how long it took but it finished up neatly and successfully and my next run of Visual Studio 2013 took a little longer to launch than usual while Visual Studio sorted itself out but then I noticed that I have a number of new project templates inside of Visual Studio;

and I figured what the heck I’d go make an Android application just to see how that worked out and I got stuck for a little while;

until I managed to get some temporary credentials and then that got me to my blank project;

which felt pretty familiar to me both from the point of view of building an app for Windows/Phone and from the point of view of having made one or two things inside of Eclipse for Android previously.

I had a quick play with the designer and was pleased to see Document Outline support and some level of Properties window support;

where the properties window seemed to have some support for an idea of resources in the sense that clicking on an entry would raise this dialog;

and I played around with the Toolbox a little, randomly adding controls onto the layout on the screen;

I also spotted the various different device layouts I could work with;

I was curious as to how these resources worked and so I went and read the AboutResources.txt file included with the project which I thank whoever included because it was really useful. It taught me a little around how the app can deal with resources at different DPI (this is perhaps trying to achieve similar ends to the WinRT way of doing things).

Based on that I had a look at the supplied String.xml resource file;

and felt obliged to add a string to it, hit compile and see if a suitably generated property turned up on the Resource class. Sure enough, A led to B;

I was a bit curious about how the Activity1 class generated by the template related to the Main.axml UI that I was playing with on the designer and I resolved that really by looking at the code in Activity1.cs;

and while I don’t have that quite figured out, I can at least see how the pieces fit together (including that FindViewById<Button> call on the next line) and the manual syncing of the event handler.

I presume (just a guess at this point) that the MainLauncher property on that Activity attribute also perhaps sets this as the “main” activity for the app.

In looking at the project’s references;

I felt obliged to wander into the object browser on some of these and I was pleased to see (alongside LINQ 2 XML which I really like) things like XmlReader, XmlWriter, XmlDocument in there and I was relieved to see that System.Threading.Tasks was in there. I was also a bit surprised to spot that .NET Remoting seemed to be in there too.

I had a glance into AssemblyInfo.cs where I wasn’t really expecting to find surprises but I did spot;

so I guess that’s one way (at least) of specifying what permissions my app needs. I had a look at Android.Manifest.Permission which was interesting in itself having first thought it was an enum but it turned out to be a class full of constant strings set up presumably to match names of Android permissions that I think I remember putting into a manifest/config file when working with the ADK directly in Eclipse;

Speaking of manifests, I took a quick peek into AndroidManifest.xml and was surprised to see that I was targeting SDK version 8 as I expected somehow to be on 18 or something like that;

I found a properties page on the solution itself;

which seemed to provide a graphical way of editing at some/all of the values in that manifest XML file. I thought the next page;

might also edit my AssemblyInfo.cs file to add more attributes to define the permissions required but it didn’t seem to be doing that so perhaps I need to figure that out a bit more.

The last thing I thought I’d try in poking around here was just to see if I could get the code up and running in a debugger. I set a breakpoint in the generated activity code;

Then wasn’t exactly sure what I was meant to be doing to get the debugger up and running. There’s a dropdown;

and I wasn’t sure whether this related to debugging or something else (it’s on its own toolbar). I tried the button next but one on the right to it in order to open up the Android Emulator Manager which gave me a dialog that I remember from the ADK (or somewhere like that);

and I wondered whether I should be defining a new device here to match my random selection of API level 18. I imagined that it might be worth a try so I tried it and then realised that the tool didn’t seem to let me go beyond API level 15 so I tried to run what I’d got on that level 15 device. At that point, it turned out that I didn’t have the right .jar file installed for level 18 so I reverted my project back to level 15 and tried again.

The tooling even told me what I already knew about the emulators;

but I went along with it. I don’t want to appear partisan but compared to the Windows Phone emulators, the Android ones have always seemed to be “not very good” to me but after a short eternity (about 10 minutes) the OS booted.

I think my next step might be to get better emulators – these are shockingly poor (I like the Windows Phone ones on my touch screen as I can then drive the emulator via touch).

I waited a long time and nothing happened other than the OS booted up. Visual Studio thought it was in the middle of a build but it did let me cancel that “Build” and so I tried again, once again waiting for the lethargic (Google) emulator to spring into life.

I had a few attempts at this and didn’t quite get it to work. I decided that I might have broken the project in some way so I made another blank project and tried to run that.

Once again though I got Visual Studio stuck in a “Build” phase.

Finally, I just grew a lot more patience and, after monitoring the Output window in Visual Studio I realised that things weren’t broken. They were just so slow as to appear broken.

And, in the end the app showed up on the Android device in the emulator.

By that point though I’d got to reading the Xamarin page about getting hold of Intel emulators (link is here http://docs.xamarin.com/guides/android/deployment,_testing,_and_metrics/configuring_the_x86_emulator/ ) and that will be my next step when I get some bandwidth to do the download because, as they stand, the emulators feel unusable to me even on a decently spec’d laptop.