Week Four: A Microsoft Developer’s Introduction to Xamarin and Cross-Platform Development

This was a week of humbling frustration for me. I didn’t get much, or much consecutive, time to work on achieving the goals laid out in Week 2. The VPs of the companies I support were preparing for meetings that often require some analytics that they task me to accomplish in a short amount of time. There are a few learnings, though, I’d like to share:

1. We FINALLY got our D-U-N-S number. I was, incorrectly, told that all we needed to do was send an email to Dun & Bradstreet to initiate the process. Turns out, when you register your email with Apple, you can then request a D-U-N-S number. That turned out to be the fast path and we ended up getting our number late Friday afternoon.
2. From a coding perspective, I was intrigued by pulling in device information to enable my app to include this in crash reporting and such if the case came that I wanted to be able to perform the same functionality as Insights or HockeyApp (coincidentally, now both owned by Microsoft). I am glad I went down this road as I am not sure what the future holds for either of those features as they both do rather the same thing and with different pricing models.

What I messed up with here was that I created a folder called “System” to report on System information. This caused a LOT of errors and I couldn’t compile the application, nor deploy it to the emulator. It took a back-and-forth with the support staff at Xamarin (thanks Jimmy G.!) to figure out what was going on. This was quite humbling. I still feel that it was a bug in this area because, using the fully qualified namespace for the classes should not cause confusion for the compiler to determine the difference between System.CodeDom.Compiler.GeneratedCodeAttribute and my class defined in MyApp.System.MyClass but it is what it is. I renamed my folder to SystemInformation and away we go.

The other learning in this area is the Visual Studio will display a number of “Errors” but yet the application will still compile and run successfully on the emulator or physical device. This is disconcerting because I have never had apps that compile when there are errors listed.

For example, I am using XAML Forms for my user interface. Apparently the error: “The name ‘InitializeComponent’ does not exist in the current context” is not actually an error but, rather, a warning.

In my experience it can either mean that your XAML view is not an embedded resource or it can mean nothing; carry on wayward son. This is hugely frustrating because I am not used to seeing errors and having them a) not mean anything, and b) not provide clear information as to how to resolve the issue.

 

 

Either way, I was able to accomplish the “Set up solution for Unit and UI Testing” and (newly added) “Collect Device Information for Crash Reporting” tasks from week 2. Now that we have our D-U-N-S number, we should be able to get set up with continuous integration and start to see some iOS features of the application.