204 – App architecture

Let’s take a moment to discuss architecting our app. After all, we don’t want to go racing into the night without a map, at 100 mph screaming “I don’t know where we’re going, but we’re making good time.”

MVVM – The preferred design pattern for C#/XAML applications

As mentioned earlier we will be using a design pattern tailored for C#/XAML and proven with over a decade of use in WPF applications for Windows. This pattern is MVVM: Model, View, ViewModel. I’m not going to make an entire book here for MVVM, but it behooves us to touch on some basic principles so we are all on the same sheet of music as we move forward.

  • Model – That’s an object. An instance of your ‘Monster’ class in a game, or your ‘Animal’ class in a pet tracking app.
  • View – That’s a collection of UI Elements used to visually interact with your data. A view could be an entire page, or it could be a reusable control.
  • ViewModel – That’s the backing data for a view. Commonly it will have several properties that are instances of different models.
    • Let’s cover that just a bit more. The ViewModel for scheduling a work shift would probably have a Permissions property on it that governs what the current user can do. It might also have a Week object that represents the coming week being scheduled. It might have a SelectedWorker property of type Employee representing a given user that the manager might be looking at to see if they can be scheduled for the coming week. And so on. The ViewModel is a collection of properties for a given need.
    • Do not confuse that with ‘this view model is for this page’. That one-to-one relationship is a common mistake. The ViewModel is the properties and methods that go together for a need or purpose. But it can be the backing for many different views. That same ViewModel used by the manager for scheduling a work shift might also be used by the HR person on a similar but different page for scheduling vacation time. Someone in the maintenance department might use the same ScheduleViewModel to see when a machine is out of use for a week so it can be torn down and rebuilt.

In other words: Your page is a view, and it is binded to a ViewModel. When properties on your ViewModel change values, the UI elements on the page are updated and vice versa. The ViewModel is the BindingContext of the view (page).

If that’s all gibberish then check this entry that goes a bit deeper. If that is still gibberish then stop and study:

Despite my disclaimer that a ViewModel and View do not have to have a 1:1 relationship, that doesn’t mean that can’t have it either. In fact, it’s fairly common and there are even several NuGet packages built around navigation based on the idea that if you push a given ViewModel you want a de-facto page to appear. And let’s be honest, the mobile app space is mostly straight-forward programs with a limited purpose in life that tend to not have 50 variations on a page or have 200 different and unrelated functions. So, it’s not unreasonable to say a lot of mobile apps primarily have a one-ViewModel-to-one-Page relationship.

It’s also common to have a hybrid of relationships on one app. For example, your HomePage will probably always be your one and only HomePage: The center of your app where the user always returns to when done with something. Meaning it gets and keeps the same instance of the HomePageViewModel for the lifespan of the app. But you might want your DownloadFilePage to be fresh every time with no memory of the previous file downloaded. When you push a new DownloadFilePage you give it a new DownloadViewModel every time. And the UserViewModel probably backs 10 different views that each handle one aspect of the user: One for changing their password, one for assigning a new avatar image, one for assigning a new social media service to them. The other reason for this regards the built-in Navigation object that we are about to discuss. It has few methods but on is .PopToRoot() meaning clear everything and go back to your first page. If that first page is the Home page your user thinks of as ‘Home’ it makes your life a lot easier than if you push the LoginPage first and have to constantly unwind the Navigation queue to the 2nd or 3rd element.

Let’s keep that one part as a decision about our app: We are going to have a HomePage backed by a HomePageViewModel and they both live for the lifecycle of our app.


We have a decision about our home page (architecturally speaking). Now what? Probably navigation. Let’s discuss how navigation works in a mobile app. First when we say ‘navigation’ we aren’t talking about turn-by-turn driving directions. We are talking about internal navigation from one page to another. Most mobile apps are designed around the idea that a cell phone isn’t a bunch of real estate and thus you move from one page with a small dedicated purpose, to another page with a small dedicated purpose. Take a social media app for example. One page is for viewing the current feed of posts. Another page is for setting your preferences. Another page just searches for new friends.

Xamarin.Forms provides a stack-based Navigation queue so developers don’t have to roll their own. This means you push pages on to the navigation stack to move forward to that page, and pop them off to go back. That’s it: Push/forward, Pop/back.

A couple things about The Xamarin site page for Navigation.

  • CarouselPage – This is still experimental, under development, being replaced by (or going to make use of) a CarouselView that you can put on any page, and basically something that nobody is happy with YET. Especially since the CarouselView doesn’t support binding so you can’t bind a collection of pages to it, like anyone would expect. I mean… Really?
  • MasterDetailPage, NavigationPage and TabbedPage – All good choices for a quick start and for your first few projects to get used to building Xamarin-based applications. At some point you’ll probably out grow them when you want to customize beyond what these read-to-go pages support. Maybe you want more control over the look and feel of the Tabs, or to redefine the ‘Hamburger’ menu icon look.
  • ContentPage – The most generic so you have to do more work up front. But also the most versatile since nothing has been done in advance to limit you.

NavigationPage – yes, we mentioned this already. If you look at the NavigationPage it is a page with content below a Navigation bar at the top, the bar has a back button and title etc. You provide a ContentPage as the content that is going below that title bar. Let’s break down the code that does that so we can better comprehend it; versus copy/paste somethis mysterious that ‘just works’ but we don’t know why.

Xamarin.Forms.Application.Current.MainPage =
new NavigationPage(new HomePage());

See that NavigationPage constructor taking another page as an argument? We’re passing in a new HomePage class (derived from ContentPage). Here’s the part I like about the NavigationPage… You can hide the Navigation bar at the top. That means your ContentPage becomes the full screen page with nothing added that you didn’t put there. My control freak enthusiast self likes that. My suggestion for starting out our test app is to use a NavigationPage with our own custom HomePage class. For now, we can keep the Navigation title bar because there is no reason not to and it gives us stuff for free that we can use: Like a standard ‘Back’ button. As we progress and want to customize beyond what it can do, then we will hide the built-in bar and make our own: Without having to change big parts of our underlying infrastructure.

When you create your app one of the early things you do is set the app’s MainPage. MainPage is special term to Xamarin navigation and not a class we make. We’re telling the app “Your Main Page is this: xyzPage”. As we just discussed we’re going to set it to a new NavigationPage and provide one of our ContentPages as the Page to be shown. Let’s look at that code again. At this point both sides of the assignment should make sense.

Xamarin.Forms.Application.Current.MainPage =
new NavigationPage(new HomePage());

I have seen many forum posts where people are having trouble with navigation usually to the effect of “how to go back”. In every one of them the person was not pushing new pages onto the queue. Instead they were using that same line of code: Constantly making the new page the MainPage – Wiping out the navigation queue so there was no history to traverse back. So as a rule, once you have set your HomePage – Leave it. Also, do not think of the HomePage as the first page your user will encounter. Commonly the first page is a Login page… Or maybe it’s a Welcome page… or maybe it’s a splash screen. None of those really fit the name “Home” page though, do they? The HomePage should be just that: The page is that is the central home of the user when they aren’t doing something specific.

The Xamarin site tutorials always show something like this, where you are pushing a new instance of a given page.

async void OnNextPageButtonClicked (object sender, EventArgs e)
await Navigation.PushAsync (new SomeOtherXamlPage());

There are pros and cons to that, that I never see discussed.

  • PRO:
    • You have a clean instance of the page with no old information on it.
    • It’s good for simple tutorials where you don’t want to confuse the reader or have to answer a bunch of questions about “What is an instance?” and why something isn’t working as expected and it later turns out to be two different instances of a page or its ViewModel
    • You’re not holding on to anything so you release memory back to your device and the app.
  • CON:
    • You have a clean instance of the page with no old information on it. Meaning you’ve lost any existing state you might have wanted.
    • Your app has to render the new page instance for the first time everytime, which is visible processing time. Read “visible UI lag”. The more your new page has to calculate to set itself up for the first time, the longer the lag. This is especially true for grabbing images off the device. For example, if your page has to calculate if something should be red or green based on a binding… should something be visible depending on a binding to an enum converter… Do you have 34 icons to read and render…
    • You have to bind the Page to its ViewModel object every time. Or generate a new ViewModel instance. Again, this is clean for one-off examples of navigation but don’t always play into the kind of re-use we have in live application.
    • Basically you’re exchanging memory for performance.

If your page can be rendered once and not thrown away… then re-pushed later… without fear of its state being wrong, then it might be worth keeping your page(s) as properties of your application view model so you can re-use them. One example might be your PreferencesPage. If you have a page where you set up your preferences to English, blue theme, large font, soft volume {…} you know those are going to be the same values the next time the user opens that page. They might open it 10 times in one session because they make an adjustment then try it out, make another adjustment and try it out. If you keep that page you can push it out again and again without having to reload the VM or re-render the page itself, making the UI feel ‘snappy’.

When you have a concern about the page state, such as more data downloaded from a server or the user has logged off and a new user logged in, then you can nullify the existing page instance and make a new instance. This pattern does require a bit more attention to detail on the part of the developer which is probably why it’s not discussed in the intro tutorials by Xamarin. But the boost in responsiveness can be worth it for the moderately experienced developer. If all of that was gibberish don’t panic. It will either become clear when you see it in code, or it is something you’ll dissect & study and grow to understand.

Design flaws to avoid:

  • Doing too much
    • Separation of responsibility is paramount to create coding that can be easily maintained for years. You want your “ReadFile()” method to ONLY read a file. It does not also populate the page, it does not make decisions about what to do next based on the content, it does not perform a NavigationBack when it is done. It reads a file and returns the contents to the caller: That’s it.
    • The same goes for your XAML pages. A page describes where things go. A stack of labels here, 4 com port status controls there, and a button. The page does not define the theme of the app, it does not choose colors, it does not choose font sizes etc. If you put those things on the page, and you have 20 pages, and you decide to re-theme from red to blue… What do you the developer now have to do? You have to scrub through 20 pages and re-colorize everything.
  • Moving too fast
    • Everyone wants to see everything yesterday. Especially bosses. The guy that knows nothing about software development wants to tell you how to develop. That’s never good. Usually it’s something like “Just throw together something that looks good so I can get a screen-shot for approval from the 7th floor. We’ll go back later and make it all better next quarter.” Does anyone ever get the chance to go back and clean up crap from last quarter? NO! So, stand your ground. Don’t call something ‘done’ unless you consider it a work of art that you would sign your name to.
    • If you’re just doing a project for learning you’re the boss. Don’t talk yourself into doing crap just so you can move forward. If some bit of code, you wrote isn’t right… isn’t robust… Fix it. When you move on to the next part you want that last part in your rear-view mirror and not have to return to it later.
  • Don’t bring old ways into new projects
    • If you’ve been a developer since WinForms (or earlier) you have a lot of habits and ways of doing things that have served you well for decades. Most of them are still good. But remember some of those tried-and-true ways of doing things really are DECADES old, and may not apply to second decade of the 21st century hardware, operating systems, and probably not to strategies for cross-platform apps with 90%+ reusable code.
    • Logic doesn’t know anything about the UI
    • We do not use Button.Click()
    • We do not make 15 extra properties just for UI formatting needs. (Because our logic does not know anything about the UI)
  • Your ViewModels knowing too much about each other.
    • Sometimes you need for one ViewModel to know something specific about another. Good or bad is arguable but even the best of pros will say sometimes its unavoidable. But you don’t want everyone to know everything about each other because then you have the same spaghetti and interdependent mess you have with WinForms of the 1990’s.
  • Avoiding work up front often leads to 10x more work later
    • Let’s say you have 10 pages and they all know how to call back to the Application Navigation queue. Seems like a good idea at first: When you click the ‘Settings’ button it pushes the ‘Settings’ page to the top of the queue. It works fine when you start your solution and it’s a small project. Then it grows. And grows. Then you have 40 pages that all do this. Then your boss says “Oh, we need to be able to move forward and backward.” Well… You can’t do that with a stack because you’ve popped off the pages and their gone. Now you have to make your own navigation scheme. Wait for it… Then you realize you have 40 pages that all make their own calls to the built-in scheme all over the place. Oh crap…
    • This is where abstracting away some things is good. If you had built a NavigationLayer class and given it the “PushPage” and “PopPage” methods that did nothing more than call the build-in queue you wouldn’t be looking at working the weekend because you wouldn’t have to change 80 calls. You would just update the methods in your NavigationLayer.
    • The same goes for any major mechanism. If you have 100 direct SQL database calls and the boss says “We’re changing database engines” then you’re crapping your pants. But if you have a DataAccessLayer with methods for “GetRecord” and “SaveRecord” you just have to change engine support in one place.

203 – Now for the left foot

Second step

So far, we’ve managed to get the program created from the default solution templates to build. But we aren’t going to actually to go real far with the project like this. There are things we want to change away from the default and closer to how things need to be for a real app.

There are certain things that are just staples in a XAML/MVVM application so we might as well take care of a little housekeeping now so we can continue to build cleanly and not have to clean up a big mess later. Let’s make some folders in our PCL project. Every project involves making some controls that are going to be reused, so we need a folder for ‘Controls’. This being XAML, we are going to have ‘Converters’. And without some ‘Icons’ our app might be a bit boring.

If you’ve done any reading about Xamarin you already know that each platform project needs its images in a special folder. In Android it’s the ..\Resources\drawable
folder, for example. So, you’re probably wondering why we just made a folder for icons in the PCL project. It’s so we can keep all of our icons in one place, and link references to them in all of the other platform projects. We aren’t going to copy them into the other projects because that just becomes a maintenance problem. Every time the boss says to ‘change the download icon’, you have to be sure to change it in all 5 platforms. In our case, since we will have the actual file in the PCL project and just have reference links in the other projects we only have to change one file in one place one time.


Let’s touch on converters for just a moment. If you’ve done WPF XAML in the past you should already know what these are. For those that don’t let’s explain something really quick. XAML is a markup language we use to describe our GUI. One of the key concepts is bindings.

  • EX: We bind the text of a label to the string property that holds the value we want to display.
  • We bind the visibility of a control to the bool property that determines if we should see the control. For example, we may not want to even show the [Submit] button on a form until all the entry boxes are filled in.
  • EX: We bind entire views to the currently selected user. If a label is binded to SelectedUser.NameFirst all we have to do is change the SelectedUser and the label will update itself automagically. Consider the implications of that across the entire app. Maybe a given user has poor eyesight. When they log in the theme changes to high contrast and larger type.
  • EX: We bind the volume to the time (through a converter) so the app is only half as loud between 9pm and 8am.
  • With me so far? Well converters are really small reusable classes that do some converting for us for specific purposes. For example, we may want to show a button only when some property is false instead of true. We can’t bind directly to that property, right? And making a second property just to show the opposite value would be a mess. So we use a BoolInvertConverter. We can attach that any time we want the opposite value.

If you’ve never seen this before don’t panic if it’s a bit vague. We’ll do some of this soon and seeing is understanding.


Styles are another key concept of XAML that you should have seen if you’ve done WPF. If you’ve done web work and used Cascading Style Sheets then you’ve also got some idea where this is going. A style describes how we want a given type of UI element to look. Maybe we want our normal labels to all be white text, 20 point, vertically centered, horizontally at the start. Well we don’t want to have to put all of that on every label every time so we define a Style for that. And, styles can inherit from other styles making it easy for definitions to exist in just one place.

Activity (we’re doing this in our new solution)

We’re going to define a few styles first so we can apply them to some controls we’re going to build later. If you open the app.xaml file you’ll see a fairly bland document. But you might have guessed just by the name Application.Resources, that within this tag is where you will put all of the resources for the application.

Let’s add in a pair of tags for ResourceDictionary. Then inside of them we are going to add a few font size definitions. We’re going to take advantage of Xamarin’s OnPlatform concept to define different values to different platforms. We do this because of how each platform handles fonts just a little differently.

UPDATE (24aug2017) – OnPlatform is all one word

A couple people have asked about Intellisense popping up a suggestion of “On Platform” with a space.  Ignore that. If you put in a space then it is two key words: On and Platform not OnPlatform – and everything goes sideways quickly after that.

To see this in action we can open the MainPage.xaml and use this on the label provided by the solution template.

What makes this even nicer is that resources can use other resources. Let’s define some sizes and colors then reference those in our styles.

Hopefully you can see where we are headed with this. Once you define the small bits you can then make them part of the medium bits and so on. Once you have defined the LabelStyleSml you can use that as the basis for a LabelStyleMed with nothing more than a change to the font size. Since everything is based on some other resources you can change the entire look of your UI with only a couple changes: Change the primary font color in one place and everything that uses it updates, and everything that use something that use it updates, and everything that uses something that uses something that uses it updates {…} Call it ‘inheritance’. Call it ‘Cascading’. Call it whatever you like; I call it really, really nice.

I’m going to give you the markup for a few resources and styles. Sure you could copy/paste it but I might suggest taking the extra 5 minutes to read it and type it into your solution. That simple act helps drive it into your brain, and gives you some hands-on with your IDE so you can get a feel for it popping up helpful Intellisense suggestions and how it marks what it thinks are errors until you complete your typing.

Once you have these in your solution go back to the MainPage a play a bit. Change the style and re-run the app on your device to actually see it in operation. Play around with it a bit… We’ll wait for ya.

06dec2017 – The move to a new host lost some included code. One of the reasons I like the screen shots. I’ll get this style markup replaced as soon as I can. Sorry for the problem.

<!--?xml version="1.0" encoding="utf-8" ?-->

<!-- Application resource dictionary -->

<!--#region Font Sizes -->
<!--#endregion Font Sizes -->

<!--#region Colors -->
<!--#endregion Colors -->

<!--#region Styles (Labels) -->
<!--#endregion Styles (Labels) -->

202 – Starting on the right foot

*Updated March 2017 for Visual Studio 2017 retail release.

The Foundation

Just like any structure, having a solid foundation is critical. Starting our solution out correctly and implementing good practices from the start makes your day to day life so much easier. For example, it’s a ton easier to plan for your app to be multi-cultural than it is to quickly whack in a bunch of text on all your buttons and labels, then 6 months from now have to go back and retro fit. It’s a lot of man-hours to comb through every line of code to find hard-coded strings and shoehorn in all the infrastructure for being culture aware. But if you do it as you go, with each button you don’t have to ‘go back’ at all.

This isn’t always popular with new developers who are anxious to see something happen. Bosses are often the same way: They need to be shown something doing anything to satisfy their immediate gratification needs. But trust me when I say it’s worth the fight to convince people (including yourself) to work methodically and deliberately, getting these ‘big concepts’ in early so the effort can be distributed to everyone on the project, every day, instead of one or two people for 400 hours at the end of the year.

The big items we talked about for user expectations in today’s app world include:

  1. Cross-Platform
  2. Multi-cultural
  3. Multi-user
  4. Value added features

Items that should go unmentioned, but I’m quickly realizing do have to be mentioned:

  1. Good OOP design
  2. Adherence to MVVM pattern
  3. Good XAML that is smart and dynamic rather than heaping in more and more C#. Meaning use of DataTriggers and ControlTemplates where they were meant to be used.

1 – New Cross-Platform Solution

Don’t be mad that I walk through this a bit even though you you’ve been a developer for years and you know how to make a new solution. There are some details to be aware of.

There are really two types of solutions that could be used: Portable and Shared. You want portable. It is more versatile and suffers less from misc. ‘weirdnesses’. Portable will make the structure you saw earlier with the Portable Class Library (PCL). It is the more widely used solution type. Shared has its place in certain situations where you are sharing classes with other solutions, other teams etc. But if you can’t point to a solid reason where you KNOW this is the type you have to have, then it isn’t.

Visual Studio 2015:

Visual Studio 2017:

With VS2017 this became a two-dialog process in order to walk users through their needs in a more ‘wizard-like’ flow, rather than confuse them with too many options in one dialog.
Step 1: Do you want an app or a library or a UI test?

Step 2: What kind of app? We want a Xamarin.Forms app using PCL for our common (non-platform specific) code.

One final question to answer and you can just blindly click [OK] unless you have some very unusual reason to not target the suggested version:

After a couple minutes the built-in templates will generate this multiple-project solution for you:


Why are the Windows 8.1 projects missing from VS2017?
Because – Its dead Jim: You get his watch, I’ll grab his tricorder.

Don’t try to execute this yet. I know you want to. Despite having the latest version of the Xamarin plugin already installed in Visual Studio, the project templates may not be up-to-date – Especially if you’re still on VS2015. This is something everyone gripes about on the Xamarin forum, or causes confusion because it’s natural to expect that a new default solution should compile and run out-of-the-box. If it’s any consolation, it’s not as bad as it used to be. There was a while where Xamarin.Forms was version 2.x and 1.x of Xamarin Forms was the default of the project templates.

This might seem odd but… Close the solution. Now open the solution.
In the Solution Explorer pallet, you’ll notice each project going through a (Loading…) phase. I don’t pretend to know exactly what all that entails, but I can tell you that with a brand-new solution something important happens as part of (Loading…) that makes the solution happy enough to not go sideways when we do the next step.

Open the NuGet Manager for the solution. (Right-click on the Solution then choose ‘Manage NuGet Packages for Solution)

It will open to the Installed list. There are important details here that a lot of people overlook. The first is thinking that since this is the installed list, the version seen on the product is the installed version: Its not. Look at the icon for the package and you may notice an up-arrow: That indicates an Update is available. It’s the right hand pane that shows which version is installed to which project. Yes, you can have different package versions in different projects. Sometimes you have to because of compatibility issues.

Next and very important: Notice the dependencies of the package. Xamarin forms dependencies in particular. If you are running Visual Studio 2015 you may still be on Cycle 8 of Xamarin, and may still have Xamarin Forms – The Xamarin.Android.Support.xxx libraries with that version are frozen at 23.3.0. You cannot update past that version.

Choose the ‘Updates’ list. There will be a block of updates Xamarin.Android.xxx.xx, and some others above and some below that block.

Depending on your version of Visual Studio, which workload and options you installed with Visual Studio, updates to the Xamarin extension since this tutorial was written, there could be different packages that need updating. You may not see ‘Universal Windows Platform’ but may see 5 other packages. That’s perfectly normal.

  1. Update the ones above the block, one at a time.
    Wait until the console actually says
    ‘======= Finished =========
  2. Update Xamarin.Forms package
  3. If you are on Xamarin.Forms or lower
    DO NOT MANUALLY UPDATE the Xamarin.Android.Support.xxx packages.
    Ever. It will tell you there are newer versions: They lie! Many of these updates are actually for the older Xamarin.Forms v 1.x family, but they changed the version numbering from 4 places ( to 3 places (24.2.1) and it screws up the automatic version comparison. When you update the Xamarin.Forms package it knows which versions of dependency packages it needs and will get what it needs.
  4. If you are in Visual Studio 2017 it pre-installed Xamarin.Forms (or later) – or if you updated your VS2015 installation to Cycle 9 and Xamarin.Forms or later – you can install the updates to the Xamarin.Android.xxx.xx packages. Versions 25.1.1 as of this writing.
    But you don’t have to. And maybe don’t want to at this time. We’re just getting set up, so if it ain’t broke don’t fix it. At least get through all the initial setup, running of the program on your device etc. before messing around with these. – If you can’t tell, I’m still a little apprehensive about updating these packages. As of March 2017 (today) these updates are still very new and the long-term benefits and issues to a Xamarin solution have not yet been truly explored by real-world developers (as opposed to the “oh its perfect” hype from Microsoft). So what I’m suggesting is: If you can’t point to a reason just yet for needing these updates, don’t do them just for the sake of doing them.
  5. You will probably get a message at the top of the NuGet manager telling you to restart Visual Studio. Do it. If you don’t get a message saying this, do it anyway, then load the solution.
  6. Clean the solution.
  7. Build each project one at a time starting at the top: The portable project, then Droid, then iOS {…}
    1. If you don’t have a Macintosh build machine, or haven’t set up provisioning etc. that’s fine. We’re not dealing with that right now, just ignore that project: You can even unload that project if you like.
  8. If you have a physical android device that is already set up for debugging
    1. Set the droid project as the default project.
    2. Plug in the device. Visual Studio should show it as the target device.
    3. NOTE: I strongly suggest a physical Android device for development. 8″ Android tablets are cheap. You can get them at Sam’s Club and WalMart for $50. Your cell provider will probably give you one for free when you renew your contract. The Android project is, in my opinion, the best center-line for development. Build and test on this to get all your code and UI working. Later in development you can spend some time doing a tweak to the left for iOS and a tweak to the right for Windows UWP.
    4. WARNING: Ignore what anyone says about Android emulators. They are slow and suck. If you use them just accept that you want to launch the simulator as soon as you start your PC, then go get coffee and a doughnut before you even bother opening Visual Studio and your project. Keep the emulator open as much as possible. You don’t want to shut it down at the end of the day, forcing you to lose another half-hour the next morning. I’ve also recently seen a few threads where people are seeing odd rendering in emulators, having to do with some sort of conflict with their PC graphic cards. It doesn’t do you much good to use an emulator that doesn’t actually show you property WYSIWYG output.
  9. If you don’t have a device and are just doing this on your Windows machine, then we’ll use the UWP project as our default.
    1. Set the UWP project as the default.
    2. Visual Studio will show “Local Machine” as the debug target.
    3. Open the Configuration Manager, and tick on ‘Build’ and ‘Deploy’ for the UWP project.
      Why these aren’t ticked by default is a mystery. Again, if you are on Visual Studio 2017 you may not see the end-of-life project types of Win8
  10. Go ahead and debug the solution. You should get a basic “Welcome to Xamarin!” application.
  11. Congratulate yourself and open another Mt. Dew: You just built and ran your first cross-platform application.

201 – Managing expectations

User Expectations:

We are into the second decade of the 21st century. People don’t want a program that just runs on their desktop PC and expects the user to have 50 hours of training to do one thing. In today’s fast paced, on the go, order-a-Frappuccino-from-your-cell-phone-while-walking-up-to-the-coffee-shop-door-because-we-just-don’t-have-time-to-stand-in-line world, what do people just automatically expect, etc.?

  • Cross-platform. Everything we do has to work on iOS, Android and UWP.
    • More than just work, it has to work intuitively and consistently. Nobody reads manuals. Heck nobody even provides manuals anymore. People expect to open an app and just know how it works and trust that it will keep them from hurting themselves (like not losing 2 hours of work because they didn’t explicitly hit ‘save’ before shutting down).
    • If they’ve used the app on their own iPhone then they expect to be able to grab the boss’s Android phone and be able to show them how it works, with all the same features in the same place. Yet at the same time it should feel like an iPhone app or an Android app to users familiar with the nuances of their devices.
  • Value added features such as social media, mapping, photos. More and more this is just expected. It’s not enough for your app to do its job. The user wants to post about themselves doing whatever it is your app facilitates. If it’s a recipe book program it can’t just show a recipe. It also has to have a built-in cooking timer, camera access (to photo the finished cookie) and Facebook access (to post the recipe along with the photo of the cookie). If it’s an on-line ordering app for a restaurant it also has to have a map/directions feature to guide the user to the restaurant and be the loyalty rewards tracker such as the Starbucks ‘Stars’ rewards or Burger-21 “punches” towards free food. If it’s an app to make labels, then it should also be able to order more label supplies directly from your client’s eStore.
  • Multi-cultural. It should work equally well in English or Klingon or whatever.
  • Multi-user. Mostly for the point of just doing it in our app, but we want to implement some sort of user-based operation and permissions system. If it’s a checkbook app the wife should see her files, the husband his, and the kids their allowance accounts but kids don’t have administrator permissions. If it’s a Point Of Sale app like the Ziosk tablets at TGIFriday etc. then the customer can pay their bill, but not have permission to alter the bill or change prices of dishes.
  • Bug reporting. It’s really nice for the developer if they can get direct reports from the user. It also helps the user feel like their experience and feedback is important. You may have done it with Visual Studio itself; using their bug/feedback reporting system to report a bug and include a screenshot from within the reporting system.
  • Instructions. Don’t laugh, lots of programs get released every day that either have no instructions because the developer just expected everyone would be able to intuitively figure it out, or they have a quickly written text document. I know I just said that nobody reads manuals and I stand by that statement. People do however sometimes need little examples or guides. They won’t take two hours to read a manual cover-to-cover. But they will take 30 seconds to read the single-screen guide on how to use the “make me skinny filter” of a selfie app. Nowadays people expect a nice slide show, or walk-through wizard showing them the overview of where everything is, what that funny squiggly icon means and so on. Maybe your app just needs a semi-transparent overlay pointing out where each button is and what it does, that pops up the first time the app is launched.
    • Proof read. Let your app and instructions sit for a couple days. Then proof read again. Then have someone else read them when you give them your app for testing. It makes you look really sloppy when you can’t even write the instructions for your own app without a bunch of typo’s and wrong words (to/too/two or than/then etc.).

Client Expectations:

You always have a client and stake holders when it comes to your programs. Sometimes the client is yourself, and the stake holders are you and maybe your friends and family if they are also going to receive copies of the app. If you have a full-time job developing, then your client is your employer and the stake holders are the end-users. If you are a freelance developer, then the client is the client that hired you. In the end, the client is the person signing the front of the paycheck and you are just the code monkey signing the back of the check. Meaning, they get whatever they want so you better manage what they want.

Depending on your client you may be granted a lot of latitude, or none at all. They may be reasonable about limitations, or not. But one thing is for sure: They will answer ‘yes’ to everything if you ask “Do you want blahblah?” So don’t offer what you don’t want to code. Clients often expect certain things as just automatically included and you get labeled as a bad developer if you don’t deliver even if it’s never been discussed and not in the contract. For example: Settings. Everyone just assumes there should be a Settings dialog somewhere for the user to pick folder locations and color schemes and who-knows-what-else. Nowadays people seem to just automatically expect social media integration. It’s just sort of “Well, yeah duh… Of course, I thought users would be able to post a Facebook review of our service from the app. Isn’t that just included in every app these days?” So, it’s incumbent on you to ask questions smartly, educate your client, and well define the project. You have to actively managing client expectations.

104 – Keeping up to date

Once your PC is set up there are a few things you should do periodically to stay up to date.


James Montemagno, one of the most prolific Xamarin evangelists out there has a great article on preparing your PC for everything that has to be in advance of updating the Visual Studio Xamarin plug-in. I’m not going to plagiarize his work. Go there, read it, follow it, live it, become one with the process of getting all the prerequisites in place before you update the actual Xamarin plugin. Because if you don’t, Visual Studio will become very, very cranky with you; your projects won’t be happy, things won’t compile, and most of all the Xamarin update installer is not smart enough to first check for all the prerequisites and will merrily try to updates when your machine is not ready for and f’up a lot of stuff. http://motzcod.es/post/150380059392/preparing-machines-for-xamarin-cycle

Xamarin plugin for Visual Studio

Once you have run out of things to update on your PC: Android, Java, Windows, Android emulators, other Visual Studio updates, your dog’s shot records… everything… Then it’s time to update the Xamarin environment plugin. From Tools|Options, open the4Xamarin group then select Other. In the right pane, you’ll see a link for ‘Check Now’: Click it. If there is an update to the plugin you’ll be prompted to download and install it. Once the installer is ready to start, close Visual Studio so it doesn’t have to fight to install updates to files that are in use.

Any time you update the environment in Visual Studio you need to update the environment on your Macintosh build machine. They like having synchronized versions so they can keep a good connection, speak the same protocol, have the same expectations etc. The same guidelines apply here: Update everything else first, then update Xamarin.

Open Xamarin Studio on the Mac. Updating the Xamarin environment on the Mac is about the only thing I ever do with Xamarin Studio. From Xamarin Studio menu choose “Check for Updates“. Download all the updates. Click the “Restart and install updates” button. “Restart” in this case is restarting Xamarin Studio, not your entire mac. Even though none of these updates said to restart your mac do it anyway: What does it cost you?

103 – Understanding the Xamarin way

Xamarin as a system will let you build apps specifically for a given platform. If you want to build just an iOS application, you can do that. But its real strength and the focus of this series is on how to make cross platform apps with a single code base. With maybe 5-15% more work & planning you can have 400% more customer potential by having your app run on Android, iOS (including everything from Mac desktops, iPhones, AppleTV and even a little AppleWatch), WindowsUWP (so desktops and Surface tablets alike), and even Windows phone if those 9 users interest you. As of the Connect() 2016 conference announcement, Samsung is also jumping onboard with support for the Tizen operating system used on appliances, wearables and other embedded devices as part of the IoT (Internet of Things) movement.

Xamarin.forms uses XAML markup language for creating the UI (views/pages/controls) and C# for the ‘code behind’; the properties, data, logic and executable code that actually ‘runs’. This separation of UI and code-behind is exactly the same as Microsoft has used for years for their WPF system. Xamarin.forms applications just like WPF applications are primarily architected around the MVVM design pattern. Model View ViewModel is a design pattern that separates data from UI while providing a system for binding that data to the UI in a loosely coupled way so the UI updates automatically when the data changes, and the data is updated when the user makes a change in the UI. The MVVM pattern has proven itself for years in WPF and is well worth the learning curve if you haven’t used it before. If you have experience with WPF/MVVM then you’re going to feel right at home in Xamarin.forms.

A solution consists of multiple projects. 90%+ of your code will be common to all platforms and contained in the Portable Class Library (PCL). This is your UI, logic and models (objects). Then there is a project for each platform. Each of these platform projects will have a file that launches the actual app: That’s just a few lines. Then you might have a bit of code here and there for very specific needs on a given platform. For example, maybe you want to render an octagonal tile for a game you’re making and that level of graphic work is done differently on iOS than Android.

At first there is a little bit of a re-think for experienced desktop program developers when transitioning to having most of their code in a PCL. Since you’re now working in a device-platform-agnostic space you have to consider that your program may launch when you have internet, then loose connection as the device travels. Your program might be running on a landscape 1920×1200 PC monitor or it could be running on an 800×500 low-res smartphone in portrait orientation. You might be running on Wi-Fi, or you might be running on a metered cellular connection where every kb has a dollar figure associated with it. Your app will be launched/backgrounded/resumed/backgrounded/killed at the whim of the user. Even something as simple as file paths and application permissions change between platforms: The path separator for Windows is ‘\’ and on Macintosh its ‘/’.

If there’s any advice I can impart on the subject it’s this: Think generic, plan from the 30,000-ft. view, separation of responsibilities/concerns, code in layers. Let’s say you know you’re going to have some data that you store, fetch, and update. Don’t get bogged down in the details of *how*. You know that C# is an Object-Oriented Programming language. In other words, C# deals with objects, not data. If you’re going to take photos plan to take photos but don’t worry about how to directly access the camera on an Android tablet right off the bat. Just realize you’re going to take a photo at the PCL level (the common, platform-agnostic level) and at some point, that will become a device specific block of code in each platform project that your PCL really doesn’t have to know or care about.

Using a database as a more specific example: At a PCL level your program just needs to know it’s going to save in a database. On iOS, it might be a SQLite database while on Windows it might be a Microsoft SQL database; but the logic of your program shouldn’t be aware or depended on knowing which. The logic tells the Data Access Layer to save. The DAL then calls the specific database implementation to do its job. Maybe that implementation comes from a NuGet package. Maybe it comes from a class you write just for WinPhone. This type of layered approach when combined with good separation of responsibility means if you change choices in databases or you move to a different device you only have to change code in one file without risk of breaking a dozen different classes.

We’ll get into actual code doing this later in the series. For now, it’s just important to grasp the concept and let your brain wrap itself around that for a while. Building software in a layered approach is new to many. Planning for a variety of platforms and screen real estates and hardware capabilities is new to most.

Terminology – The same only different

Windows Forms worked in “Forms”. WPF worked in “Windows”. Xamarin works in “Pages”. A screen of content by any other name is still a screen of content. WPF has a “TextBox” and “StackPanel“. Xamarin has an “Entry” and “StackLayout“. Don’t let yourself get too caught up on the terms. It’s all basically the same thingies you’ve used before, with a new name or slight twist. Some of the twists are actually improvements upon WPF. For example, WPF horizontal text alignment was left, center and right. Xamarin is Start, Center, End. This makes more sense when we consider that not all languages are left-to-right reading. For English ‘Start’ will be left alignment. But for Yiddish, ‘Start’ will be right alignment. With no extra work on the part of the developer.

What sets Xamarin apart is the eco-system under the XAML/C#. Xamarin took the mono port of .NET and hitched it up to their Xamarin.forms XAML implementation on all the popular platforms: Android, iOS, UWP, Windows, Mac. So, when you make an “Entry” in your shared code the mono runtime on iOS will make an iOS native textbox, and on android it will make an Android native textbox; regardless of what those platforms might call them. It maps from a common set of controls to the native controls on each platform – so you don’t have to learn all three. Thus, your program will always be native running code on any device.

You do not build a program “In Xamarin”. You build your program in C# and XAML, using Xamarin.Forms.

102 – Resource for success

The best place to start learning Xamarin is… Xamarin Resources. Go figure. Xamarin even has their own Xamarin University set of courses you can take live on-line as well as pre-recorded classes. Not just on Xamarin, but also C#, F# and a bunch of other stuff. It’s not free – or even cheap. But do you really want a ‘cheap’ education as the basis of your career? I think it was like US$2400/year per person. If you can afford it, it is the fastest and best source available. If you can afford it you will learn 5 times faster and better and that of course has a dollar value to you. If you can learn faster you can be earn faster and that might be important to you. Also, by becoming a Xamarin Certified developer you are granted access to a closed area of Linked-In where companies and developers are introduced. Small companies looking for freelancers, or looking for full-time hire. That alone can be worth the cost.

Remember that Xamarin XAML for building your pages is just a different implementation of XAML, which is the markup language used for WPF. So if you’re not well versed with WPF there is a LOT of free resources for it and it all pretty much applies. Once you have a solid understanding of WPF concepts it translates nicely to Xamarin. The differences are basically “StackLayout” instead of “StackPanel“… “Entry” instead of “TextBox” etc.

The de-facto text/reference book on Xamarin is by Charles Petzold and you can download it for FREE.

Xamarin Forums is a great place to ask questions. I would point out the first step is always to try to learn. Don’t spend 1 day in Xamarin then hammer people with day 1 questions because you’re too lazy to spend some time self-educating. The forums are also a great place to just spend some time reading. Read through the questions others ask because it gives you some insight into problems other had, and how they resolved them. Better to have that in the back of your mind when you get started so you can avoid going down the wrong path.

Stackoverflow has a Xamarin specific area and tag for questions. The good folks at Xamarin monitor it, as well as the general community of Xamarin developers.

Xamarin components – While there are numerous NuGet packages you may want, this collection is always your first stop. It includes components for cross-platform implementation of everyday needs from Compass to File Storage.

Xamarin Bugzilla – If you have found a real bug. A true bug in Xamarin. Not that you can’t figure it out in 5 minutes or it doesn’t work the way you thought/expected. But an honest-to-goodness bug. Here is where you report it. Be sure you have asked around on the Forum first. Be sure you can reproduce it in a small sample, then include the sample in the bug report.

The prep list for doing an upgrade – This step-by-step by James Montemagno will save you lots of headaches.

Visual Studio Documentation at Microsoft

Visual Studio Keyboard shortcuts (2012, 2013, 2015)

Visual Studio (2015) features and tips

The definitive guide to String.Format. Using the right codes such as {0:c} for currency can save you so much B.S. trying to re-invent the wheel when it comes to formatting.

101 – Setting up your environment

Physical environment

Many people consider their development environment to be their PC and the software on it. They overlook the actual physical environment. Take some time to put some planning into this. Odds are you’re going to spend 8-12 hours a day in this space, so it really does matter.

Get the ergonomics right. If your chair isn’t comfortable and promote the right posture for the long haul you’re going to suffer. If your monitors aren’t at eye level you’re going to suffer. If you’re on a laptop put it on a riser so the screen is at eye level and use an external keyboard and mouse or trackball. Use a decent keyboard like the Microsoft ergonomic models to avoid issues like carpal-tunnel.

Spend a couple bucks on extra monitors of decent quality. A couple extra monitors pay for themselves in improved productivity: Not wasting lots of time opening and hiding various pallets due to limited screen real estate etc. Plus you’re probably going to have Visual Studio, email, a task list and a web browser that lives on Google as its home page all open at the same time. That’s not accounting for a device emulator if you need one or two. You can eat up screen space in a heartbeat as a developer.

Quality monitors such as a Dell with good specifications and wide viewing angle will save your eyes and reduce aggravation when compared to low-end monitors like Acer that can only be viewed if you are at the exact right angle; especially if you rotate one of the monitors to portrait so you can have a tall monitor for viewing lots of code at once (hint, hint).

Pet peeve: Developers belly-aching about spending money on software or other aspects of their environment. Get over it. Everyone else pays for their tools: Mechanics, plumbers, electricians.

Windows PC

The Windows machine is where you’re going to spend your day. Make it comfortable. Use a machine with as much processor, ram and SSD space as you can afford. Use a fast SSD for boot and applications. Leave the applications and all their required files on the C: drive. Don’t try to get fancy with moving them to a second drive etc. Microsoft applications and Visual Studio in particular don’t handle that well. Use a fast second drive dedicated to Visual Studio code. Drives are cheap these days. A drive with one purpose in life (your code) shouldn’t be a problem. Do not use the default Visual Studio project path because it’s a freaking mile long and will cause a lot of your files to exceed to file path length limitation. Something like “d:\\” is a good place. Don’t bury your projects. “d:\\Code\Projects\Clients\2016\A\AdvarkMoving\” is going to be a problem. If you’re that busy with work then use contract/ticket numbers: “d:\\556677\” is much better.

If you’re going to be using an Android emulator instead of a physical device you’ll need more RAM. Personally, I’d suggest a physical device as soon as possible. Cheap android tablets are everywhere. Spend $50-100 on one. Your cellular provider will probably GIVE you one with a new phone purchase or contract extension; which you know you are going to do anyway.

All flavors of Visual Studio 2015 include Xamarin, including the free community edition. However, when you run the Visual Studio installer the options are not ticked on by default. Choose ‘Custom’ then go through the options turning on all the options for Cross Platform. Personally, I prefer to download the offline installer and run it from my own drive, than using the web installer. But that’s me. If I ever have to re-install I already have the ISO and don’t have to wait (again) for a 6gig download. This is a really good approach if you are on a metered connection such as satellite internet with monthly data limit.

There are a few plug-ins for Visual Studio that make your life easier. Again, you’re spending 40+ hours in this environment so it’s worth making it nice.

  • XAML Regions, free
  • XAML Styler, free
  • VS Color Output, donation ware.
    • Spend a couple bucks and make a donation to the guy. It’s really nice to have key output standout, like errors be in red. Five bucks for this less than your morning latte.
  • Visual Studio Spell Checker, free
  • Automatic Versions
  • Clar MEF Component Cache
    • This free extension is really important because once in a while Visual Studio can get confused about this cache and give you various problems. This extension forces the cache to clear and thus avoid the issues.
  • ReSharper, paid but so very much worth it
  • TabsStudio, paid but really worth it.

Macintosh build machine

Once you get everything set up, you’re not going to spend a lot of time on the mac. It can be a Mac Mini that you keep on a KVM… It can be a paid Mac time-share… It exists as a build machine to keep within the licensing requirement for Xamarin, and to produce the native Swift code via Apple’s XCode IDE.

  • Update everything on the Mac
  • Install XCode
  • Run updates again
  • Install Xamarin from their installer
  • Run updates again.
  • Run Xamarin Studio and have it check for updates
  • Connect your iPad or iPhone.
  • Run XCode
    • Make a new default project. Run it on the iDevice.
    • Follow all the prompts about activating developer mode etc.
    • Provisioning the device will take place as well.
    • Provisioning tends to be a pain in the arse the first few times. There are articles on-line specifically about this that go into great detail. I’m not going to repeat all of that here.
    • Once you have all that working you should be able to make Xamarin.Forms solutions on your Windows PC in Visual Studio and run them on the Mac. Here’s what I do when I start a new solution in Visual Studio.
      • Make a new XCode solution on the Mac settings the company name and program name: com.mycompanyname.supercoolprogramname
      • Run it on the iDevice just to have it fetch provisioning permissions for that name.
      • Close it.
      • Now on the PC in Visual Studio make your new Xamarin.Forms solution.
      • In the properties for the iOS project set the name to exactly match (case sensitive) the one you just made on the mac. Since the device is already provisioned for that product you’re golden.
    • As a tip though: Provisioning on a per-software basis is case sensitive. Just get in the habit of doing everything in all-lower case and it won’t be a problem.


Wi-Fi is inherently unstable even under the best of conditions. Have your mac and your PC on the same network switch, preferably on either static IP or reserved DHCP so they always have the same address.

The Xamarin’s Mac Build Agent in Visual Studio will offer up all the Mac’s it finds on your network by DNS resolved name. Don’t fall for it. Add a Mac and give it the actual IP address.

Before going any further, make sure all this works a few times with a bunch of ‘disposable’ default applications. Be sure you can make 10 projects and have them all work, getting a solid grasp on the process.

Other tools


There are lots of programs out there for keeping you on task and helping you keep track of your to-do list. Maybe you’re good with just a simple Notepad document or you love spreadsheets. Maybe you have something else you already use. Personally, I’m a huge fan of ToDoList by AbstractSpoon. First of all its free for a very well equipped lite version. It works in node-subnode paradigm which to me reflects how most projects go. And it has built-in time tracking for each line item: Just click the stopwatch when you start working on that item. This is invaluable for all of us but especially for new developers that aren’t good (or honest with themselves) at estimating their time to complete something. It’s really easy to think it only took an hour to make up a graphic, but forget to include the two hours of back-and-fourth with the client for approval on the final version. If you can’t estimate a task you can’t estimate the entire job and suddenly the kid at McDonalds is making more for taking out the trash than you are as a freelance developer.

Move in

Once you get all that going, take some time to move into your environment. Get all your Visual Studio palettes where you like them. And browser. And Outlook/Office. And other tools. Even with 3 monitors I still have programs stacked behind each other. Do it in a way that makes sense: Have your browser on a monitor not covered by Visual Studio so you can read from one screen and type on the other. Put Word and the code page on the vertical monitor because you can see the entire document that way. Etc.


Let’s start with the title. Unless you’ve been living in a cave you’ve seen the Matrix series of movies. As Morpheus says to Neo:

You take the blue pill—the story ends, you wake up in your bed and believe whatever you want to believe. You take the red pill—you stay in Wonderland, and I show you how deep the rabbit hole goes.

The red pill takes you to the real world – that’s what this series is about: Going down the Xamarin rabbit hole and making cross platform apps for the real world.

What this series is NOT…

This is not an introduction to coding or intro to C#/WPF/XAML/MVVM. We aren’t going to walk through console apps for a year, then WinForms for another year, then SQL for 6 months. This is not a college course where the goal is to stretch things out as long as possible in order to charge as much as possible for course credits. There are lots of resources for that approach. I’m not going to waste my time or yours trying to duplicate what so many have already done and done well.

It is not about ‘How to use Visual Studio’ or ‘How to use Xamarin Studio’. Everything we do in Visual Studio on Windows you can do in Xamarin Visual Studio on Macintosh. The screen might be slightly different but you’re an experienced developer and can figure out that “Options” on Windows is “Preferences” on Mac and so on. UPDATE Nov2016. Microsoft announced Visual Studio for Macintosh and made it official that Xamarin Studio would be going away. If you’ve already been using Xamarin Studio you probably want to start transitioning to Visual Studio.

What this series IS…

This series is going to take your existing development experience and help you transition it to a new space: The creation of cross-platform mobile apps, using Visual Studio and the Xamarin eco-system. If you’re like me you’re past all the ‘intro’ books and spend your time actually *doing*… Writing code… Making applications… Developing for a living… And now you want to move forward, out of your comfort zone and out of the legacy world you’ve been in; and into the future of mobile apps.

You wouldn’t be here if you didn’t already have some idea of what Xamarin is and the potential it offers you, but let’s hit the key points really quick to make sure you’re in the right place.


Xamarin is a company that pioneered a cool eco-system of support for C# and XAML that lets developers use a single code base to create applications that can run on Android, iOS, Windows UWP and Windows Phone. Let me say that again because it’s pretty amazing. Using just C# and XAML you can create a program that will run on your iPhone, Windows desktop, Mac desktop, Windows Surface tablet, iPad, Android phone or tablet… Even the new Gen4 AppleTV or AppleWatch… Without having to learn Swift, Cocoa and Java… Without having to master all the minutia of all these platforms… Without having to re-code for each one… Without having to make 20 different specific UI layouts… If that’s not what you’re looking for then you’re in the wrong place.
UPDATE: As of the Connect() 2016 conference you can add Tizen as a Xamarin friendly target OS, because Samsung has jumped on board as well.

Visual Studio

While Xamarin-based applications can be built from a Macintosh-centric environment that’s not what I’m going to do. This series is Windows-centric using Visual Studio as the IDE. If you’re a Mac developer, there is still plenty here for you. I am not a Mac hater. I love my Macs and have had everything from a MacClassic running OS 6, to my own Xserve and XRAID, Quad Tower, MacBookPro… iPhone gen 1-7plus, iPad, AppleTV, AppleWatch… But I like putting food on the table and developing for Windows gave me more job opportunities: It’s that simple. And now that I can use Windows to develop across multiple platforms it’s not an issue. So Mac users, don’t run away. Remember this is about embracing all the platforms. At the Evolve 2016 conference 90% of the attendees were on Mac’s virtualizing Windows so it can be done.

There is another more practical reason for this being a Windows-centric series. If you develop on a Mac you still need a Windows environment to make the Windows projects in… If you develop on Windows you still need a Mac to be the build server for your iOS project. But with the latest improvements to Xamarin your Mac can run headless. It’s just a build server. It can be a little Mac Mini sitting on the side of your desk taking up next to no space. It can even be a hosted/shared cloud-based Macintosh service you subscribe to without having to buy a Mac. Visual Studio accesses it remotely and shows you most everything you need from the one Windows environment. So in one place you can do Droid, iOS, Windows. That’s just dead-nuts common sense easy from my perspective.

The third reason for suggesting you take the Visual Studio route is simple: Microsoft owns Xamarin, as of 2016. Before that Xamarin was its own company but it was bought by Microsoft. Microsoft created the XAML markup language. They also created C#. Well… Hmm… Who would have the best tools for dealing with two Microsoft languages built around using Microsoft’s .NET framework? Plus if you were Microsoft and you bought a company making its own IDE would you put as much resources into keeping it powerful, or would you put the money into the eco-system and tell people to use the IDE that you’ve been developing for decades that is part of your Enterprise-grade development infrastructure and major part of your revenue model? Update: As of the Connect() 2016 conference they made this official. Seems I predicted well.

Fast paced

Once we get passed all this introduction non-sense we’re going to move with a purpose in life. This series is about making cross-platform apps. This series is about actually getting your skills up to date with 21st century needs of employers and expectations of today’s users. I might even lose you here and there on some points because of the pace and the assumption that you’ve been in the industry for a while. Since this is the real world… Google it! If I lose you because of a casual reference to ‘singleton pattern’ don’t sit there like a lump being lost: Use the resources at your finger-tips and find an article or tutorial that covers that one item in more detail-BEFORE you move on. Do not move forward when you are lost thinking you will pick it up later or that it will be covered again.

Who am I?

That is a totally legitimate question. One you should ask of everyone trying to teach you including university professors. The education you gain is only as good as the person teaching it.

I’ve been a Windows developer for about 15 years and other systems before that. I’ve developed programs used in a variety of industries but mostly centered in the retail or entertainment sector. Point of sale systems, photography systems, radio station software etc. Software that interacts with hardware such as controlling cameras, RFID readers, industrial controllers. Software that interacts with sales clerks, digital artists and the paying customer. The software I’ve made has been used by industry leaders in environments that make a ton of money every year so they have high expectations about performance, ease of use, ease of learning for new staff, long-term reliability, scalability and even globalization to their locations where English is not the dominant language. Yeah, that really does happen in the world.

I’ve worked (and still am working) in the big businesses with multiple teams in several states, TFS code repositories and dedicated build machines. Following all the buzz-word principals of AGILE and SCRUM and Continuous Delivery. But my first real paid developer gig was in a shop with just a few people, one other developer that had his head firmly planted in the past with no desire to move forward… Where ‘code repository’ meant a folder on a server and ‘version control’ meant making a copy of a folder at end of each week or feature. But I was lucky enough to have a boss that was all about robust coding and being innovative. His fearless approach to diving head-first into new things while scary sometimes also gave me the environment and outlook to always grab the next technology and charge ahead of the competition. That approach keeps me from sitting on my arse skill-wise like so many other developers do. I’ve gone from Windows-only development in C to C++ to C#, from MVC, WinForms to WPF, to Xamarin and cross-platform development that works on desktops as well as mobile devices and set top consoles.

I’m here to as a member of the previous generation of developers that has already lived through the transition from small company to large and through the endless transitions of new development technology. I’ve watched everyone jump onto the latest thing of ‘thin-net’ or Silverlight. Nobody has a crystal ball to predict the next hot technology that will stick around a while, but I’m going to try to impart some of that experience and some of those lessons on you the next generation of developers. Hopefully you can learn from some of it to jump start your progress.

Programming is a huge topic and everyone wants and needs different explanations. So it’s important to narrow down the scope of the series. As the reader you should know how that was done to know if these tutorials will even apply to you. Many of the main points being talked about in this series come about in response to questions I see on the various coding forums where I participate. I have answered literally thousands of questions on various sites… Heck thousands of questions on one site alone. Which means I’ve seen thousands more and have come to recognize the questions that get asked over and over (and over and over and over and over and over). Common sense tells you that the more something is asked, the less it is understood. Combine that with having been in this field for a couple decades seeing where students have had to be re-trained in order to become worth-while developers and you have the basis of this series and how certain things were prioritized.

FAQ (Frequently Asked Questions)

I notice a fair number of questions that get asked over and over. You’d almost think nobody checks to see if someone else has already asked before them. This page will get updated regularly.

Last updated: 24dec2016

  1. Why doesn’t my code format right on Xamarin Forums?
    1. The Xamarin forum does a pretty decent job of trying to guess that your text is actually pasted in code. But if you don’t tell it that a given block is meant to be code, then it’s still guessing. Xamarin Forums uses markdown for adding tags and such to comments/posts. You will see a link to an article on markdown on the Xamarin Forms page where you are making the comment. But I find this one to be more complete.
    2. When you are entering code, tag it as such with three backticks (on the tilde key) on a line by itself above your code, and again below your code. Optionally including the coding language name
  2. iOS Remote Simulator for Windows
    1. As of late 2016 the remote simulator requires an Enterprise license of VS2015. So if you’re used to this working in your Community Edition of Visual Studio and now doesn’t, that’s probably why. There are several alternatives. The simplest (and yes, free) is to just run the simulator on your Mac and remote into the Mac with VNC or some other remote viewing/controlling software. There’s plenty of article on how to remotely access your Mac from Windows such as this one.
    2. UPDATE. As of December 2017 the iOS remote Simulator is available to all versions of Visual Studio 2017.
    3. iOS remote simulator is not part of the Visual Studio installer. It is its own package you download from Xamarin. This package is still in development and updates now and again and you don’t get notices of it updating through Visual Studio, so check the Xamarin page maybe once a month.
    4. Once you’ve installed it (and restarted Visual Studio) you still need to turn it on. Tools | Options | Xamarin | iOS Settings then check the box.
    5. More details about the options such as mocking the GPS location can be found on the Xamarin site.