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:

VS2017
VS2015

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 2.2.3.180 – 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 2.3.3.180 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 (23.0.1.3) 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 2.3.3.193 (or later) – or if you updated your VS2015 installation to Cycle 9 and Xamarin.Forms 2.3.3.193 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.

One thought on “202 – Starting on the right foot

Comments are closed.