From Silverlight to Android Dev using Xamarin Day #1
So, I'm working on my first official, professional Android application. Or at least I have my environment set up and I've started bashing out some preliminary code. This isn't the "purest" form of Android development, I'm using Xamarin and I've only just gotten started so my feelings on this may change over time and some of those feelings may be more as a result of Xamarin, but we shall see.
My initial feelings. This is terrible. An utter mess. Even the parts (and perhaps in some ways especially the parts) which have nothing to do with Xamarin are driving me crazy. Looking back on Windows Phone development I feel down right spoiled. Getting the Andriod SDK and AVD's installed, set up and running is like pulling teeth. The emulator is ugly and slow and there are more options than you could possibly care for. I'm sure it was an entirely different animal several Android releases ago. In fact, as I go back in versions in the AVD manager the number of options shrink and life gets simpler. There was likely a time when this was fairly simple. But that time is not today.
Anyway, moving on. I'm using Xamarin and I'm going to be coding inside Visual Studio 2010. My first thoughts on this were. Fantastic! This will be a walk in the park, I get to code for Android and do it in C#. It turns out the truth isn't quite that simple. I haven't yet hit any real limitations in what little back-end code I've written so far, as this basically supports all of the common core libraries. But lets face it, I was a Java developer before I was a .Net developer. I really would have absolutely no issue writing back-end libraries for Android. That was never a doubt or a concern. Where I was really hoping for Xamarin to shine was on the UI development.
So, UI development. Xamarin you broke my cardinal rule. If you're going to invest in multiple approaches to the same result they should either be equivalent or at least cover 95%+ of the functionality. My first screen was a log-in screen. I have a few labels, a button, a username field and a password field. Guess what? If it is possible to generate a password field in C#, there is no documentation anywhere on it. The parameters you set in the axml file are nowhere to be found in the C# equivalent object. That is an automatic fail. While not every type of application needs a password field, it is an absurdly common element in a wide array of applications. Why bother allowing people to build the UI in C#?
All, of the samples do the screens in axml (for I think obvious reasons). And the few tutorials that showcase building the UI in code stick to incredibly basic examples. Now, my understanding is that those axml files are either directly what Android uses, or analogous to something used in typical Android development. So there is probably documentation somewhere on them but the "promise" of Xamarin was to bring Android development to .Net developers, not to bring it half way. Or that was how I read into it at least.
At the end of the day, I'm going to need to write the screen layouts in axml as it seems vast and very important parts of the API are either non-existent or hidden otherwise. The back-end code will be in such basic C# that I could have easily written it in Java, and the bits I do end up writing in C# that drive the UI will likely be a fraction of the code. Do not get me wrong. I understand the purpose of Xamarin and see how it would help if I were building a cross platform application. Those back-end libraries wouldn't need to be ported from Java to C# or even objective C. And, by the time I'm done my application there will likely be a lot of code in those libraries, so it would certainly be valuable.
Where I land after 1 day of such programming is; if you are doing cross platform, Xamarin would be an excellent tool that would save a ton of time despite all of my complaining. However, do not waste your time if you're not going cross platform however as it will likely force you to learn more pieces than if you just invested solely in that platform. Also, do not think that you will be able to avoid the particulars on the UI side associated with each platform. I would have loved to see the Xamarin team take a subset of the WPF/Silverlight controls and allow the screens to be created in XAML that they then simply mapped to those axml files, and obviously to see that any attribute available on in the markup language also be AS EASILY available to one developing in C# code.
When you can eliminate that need for me to learn the tools and languages underlying the non-.Net platform I'm writing for you will have succeeded. For now, this is a hybrid beast and a mess and it forces me to deal directly with the ugliness and differences of the underlying platform.
Disclosure Item: The decision to use Xamarin was not mine. I didn't simply choose the tool and then opt to whine about it. Also, I probably would have used it anyway. This project will last more than just the one day I've spent on it so far and I certainly hope to find my opinion of both the Android SDK and Xamarin much improved by the end. Consider this a brief introduction to how a .Net developer would feel on average on day #1 switching to Android development using Xamarin.
My initial feelings. This is terrible. An utter mess. Even the parts (and perhaps in some ways especially the parts) which have nothing to do with Xamarin are driving me crazy. Looking back on Windows Phone development I feel down right spoiled. Getting the Andriod SDK and AVD's installed, set up and running is like pulling teeth. The emulator is ugly and slow and there are more options than you could possibly care for. I'm sure it was an entirely different animal several Android releases ago. In fact, as I go back in versions in the AVD manager the number of options shrink and life gets simpler. There was likely a time when this was fairly simple. But that time is not today.
Anyway, moving on. I'm using Xamarin and I'm going to be coding inside Visual Studio 2010. My first thoughts on this were. Fantastic! This will be a walk in the park, I get to code for Android and do it in C#. It turns out the truth isn't quite that simple. I haven't yet hit any real limitations in what little back-end code I've written so far, as this basically supports all of the common core libraries. But lets face it, I was a Java developer before I was a .Net developer. I really would have absolutely no issue writing back-end libraries for Android. That was never a doubt or a concern. Where I was really hoping for Xamarin to shine was on the UI development.
So, UI development. Xamarin you broke my cardinal rule. If you're going to invest in multiple approaches to the same result they should either be equivalent or at least cover 95%+ of the functionality. My first screen was a log-in screen. I have a few labels, a button, a username field and a password field. Guess what? If it is possible to generate a password field in C#, there is no documentation anywhere on it. The parameters you set in the axml file are nowhere to be found in the C# equivalent object. That is an automatic fail. While not every type of application needs a password field, it is an absurdly common element in a wide array of applications. Why bother allowing people to build the UI in C#?
All, of the samples do the screens in axml (for I think obvious reasons). And the few tutorials that showcase building the UI in code stick to incredibly basic examples. Now, my understanding is that those axml files are either directly what Android uses, or analogous to something used in typical Android development. So there is probably documentation somewhere on them but the "promise" of Xamarin was to bring Android development to .Net developers, not to bring it half way. Or that was how I read into it at least.
At the end of the day, I'm going to need to write the screen layouts in axml as it seems vast and very important parts of the API are either non-existent or hidden otherwise. The back-end code will be in such basic C# that I could have easily written it in Java, and the bits I do end up writing in C# that drive the UI will likely be a fraction of the code. Do not get me wrong. I understand the purpose of Xamarin and see how it would help if I were building a cross platform application. Those back-end libraries wouldn't need to be ported from Java to C# or even objective C. And, by the time I'm done my application there will likely be a lot of code in those libraries, so it would certainly be valuable.
Where I land after 1 day of such programming is; if you are doing cross platform, Xamarin would be an excellent tool that would save a ton of time despite all of my complaining. However, do not waste your time if you're not going cross platform however as it will likely force you to learn more pieces than if you just invested solely in that platform. Also, do not think that you will be able to avoid the particulars on the UI side associated with each platform. I would have loved to see the Xamarin team take a subset of the WPF/Silverlight controls and allow the screens to be created in XAML that they then simply mapped to those axml files, and obviously to see that any attribute available on in the markup language also be AS EASILY available to one developing in C# code.
When you can eliminate that need for me to learn the tools and languages underlying the non-.Net platform I'm writing for you will have succeeded. For now, this is a hybrid beast and a mess and it forces me to deal directly with the ugliness and differences of the underlying platform.
Disclosure Item: The decision to use Xamarin was not mine. I didn't simply choose the tool and then opt to whine about it. Also, I probably would have used it anyway. This project will last more than just the one day I've spent on it so far and I certainly hope to find my opinion of both the Android SDK and Xamarin much improved by the end. Consider this a brief introduction to how a .Net developer would feel on average on day #1 switching to Android development using Xamarin.
Comments
Post a Comment