Before I eventually get to the protocol layer underlying the new build host in Xamarin 4 (as promissed
in a previous post that introducing it,
I wanted to mention how we architected it from the get go for a key scenario that we’ll want to enable
in the future: side-by-side (SxS) versioning.
Why would I care about SxS?
Visual Studio update and release cadence has been accelerating, and we want to support users that are on
the bleedging edge. At the same time, there is a very real world of users that are still on Visual Studio
2012 or 2013 that we also need to support. At the same time, Xamarin also has a different release cadence
than Visual Studio, and it even supports the concept of Stable, Beta and Alpha channels, as well as the
occassional web preview for new features.
The way this currently works in Xamarin is you install from whichever channel (or VS-bundled version),
and you get a single Xamarin install that applies to all IDEs you have installed in the machine. This is
clearly not SxS ;). That’s not at all how Visual Studio itself works, where you can have an early CTP of
vNext (i.e. Dev15 right now) while using a very stable Visual Studio 2013 Update 5 for your daily work.
This is obviously a good place to be: you get early feedback on upcoming versions, with minimal disruption
of your daily work environment. We want to get there for Xamarin for Visual Studio (XVS from now on) too.
Step by step
The first part of such a SxS story, and you might even say the most critical one, is the build host.
The build host is tightly bound to the matching XVS version, since it’s a core part of the iOS MSBuild
infrastructure, and there must be an exact match of tasks inputs/outputs, serialization, connectivity
and the like.
So it was clear from the beginning that we needed to version the install location on the Mac for the
build host and all its agents. For versioning, we use the very awesome (if I might say so myself)
GitInfo package which versions all assemblies automatically
without patching AssemblyInfos ;). We use the semver-like version on the build host (we call it the
“broker” for reasons that will be evident when we talk about the protocol ;)) and the agents to
determine which process to talk to on the Mac side.
NOTE: our version numbers are like [platform version].[cycle counter within platform].[service release].[build],
so currently, our latest stable release as of this writing is Xamarin 4, shipped in our first “cycle 6” release,
Service 4, so it’s: 4 (platform) .0 (cycle 6) .4 (service release 4) .4 (fourth build of the bits after we
branched for the release. The upcoming cycle7 release is 4.1.0.x (4 = same major platform version, 1 = one cycle
on top of the original cycle 6 when it shipped first, 0 = first release, x = whatever build)
When XVS detects that the specific version of the broker that bundles isn’t installed on the Mac, it will
automatically deploy a new broker and all agents. So if as a user you use VMs to isolate your production vs
“cutting edge” environments, and connect with them to the same Mac, the build host will happily install
side-by-side with other build hosts.
NOTE: this does not necessarily mean that Xamarin.iOS or Xamarin.Mac on the Mac support this kind of
side-by-side right now, it’s just that from XVS’ point of view, we do. We hope to get there eventually.
Updating the Build Host
You may have noticed (or figured out if you read carefully), that there is no self-update process from the
broker/build host itself. Since the whole install/run/update is drive by XVS, there is no need for it, and
this significantly simplifies the user experience.
On the Mac, you can notice this versining scheme when looking for logs, which are located at
~/Library/Logs/Xamarin-[MAJOR.MINOR], as well as the actual broker and agents, installed under the
$HOME/Library/Caches/Xamarin/XMA (XMA stood for “Xamarin Mac Agent” originally). You can see a structure
like the following there:
Broker/ ... 188.8.131.52/ Agents/ IDB/ ... 184.108.40.206/ Build/ ... 220.127.116.11/
1. Add the Xamarin.Forms nuget (and reference the platform)
When you add the Xamarin.Forms Nuget, four assemblies will be referenced (including the iOS Platform assembly for Xamarin.Forms). The using statements need to be added too – don’t forget to add the Xamarin.Forms.Platform.iOS namespace:
2. Create a Page and App as usual
In both classes it’s a good idea to create public properties for elements you want to manipulate in the workbook.
This allows those controls to be referenced later in the workbook…
3. Hack the FormsAppDelegate
The biggest hurdle to getting Xamarin.Forms to run is that in a normal iOS app, the AppDelegate must be a subclass of FormsApplicationDelegate to wire up various bits of Xamarin.Forms. Peeking into the open-source, the key thing we need to do is set the RootViewController… the following code does the initialization we need to get a Workbook running:
WARNING: obviously this approach misses some of the other code implemented in FormsApplicationDelegate so some things might not work as expected. This is a bit of a hack 🙂
4. Run It
The public properties on the App and Page classes mean the workbook can manipulate those elements to demonstrate various Xamarin.Forms capabilities.
Try it out with the WorkbookFormsTest workbook:
Check out the more complex ListView1 workbook too:
p.s. the irony of included screenshots of code is not lost on me – but hey, it’s actually a good reason to download and us Xamarin Workbooks to try these samples out 😀
Nuget packages can now be added, meaning you can teach or demo almost anything in a Workbook 🙂
In the Workbook app, choose File > Add Package… to open the Nuget package explorer:
Then search for the Nuget and add to the workbook:
Try out this Json.NET Workbook example to see how it works
Coming up next – adding the Xamarin.Forms nuget!
p.s. for a video demo of Nugets in Workbooks, check out this community contribution on brax.tv
I’ve given a lot of talks over the years, with varying amounts of live coding and moving parts. For many of them it wasn’t uncommon for me to have some sort of notes jotted down as an emergency reminder if my memory fails in the moment, and I always have local fallbacks for any network-dependent demos to avoid being completely hindered by bad connections.
When preparing for my talk at this year’s Xamarin Evolve, I found myself in need of more than in previous talks. This talk was, by definition, completely network dependent, as well as totally dependent on a host of third party services I had no control over. Basically this was a nightmare scenario for me as a presenter, and made me question what I was smoking when I pitched the talk. In addition to the prospect of demo fails, I also found myself with far more things on my pre-flight checklist to remember to do before even beginning the presentation. My default way to write notes and lists is to use Markdown, which then lead me to:
Anyone have any recs for Markdown editors/viewers on iOS? Preferably with support for GitHub-flavored Markdown (like checkboxes)
— Greg Shackles (@gshackles) April 18, 2016
I was surprised at the lack of good options I was finding after some initial searching, since it seemed like my needs were extremely basic:
- support for viewing Markdown
- support for GitHub-flavored Markdown (namely checkboxes that you can interact with)
- avoiding the urge to write something myself the week before Evolve
- ideally with split-screen support on an iPad
If you saw my talk at Evolve you might have noticed my sticker-covered laptop, but next to it you can see my iPad assistant:
After trying a bunch of different options that didn’t quite scratch my itch, including some web-based, my colleague Chris Krycho recommended 1Writer which ended up being perfect for my needs. It also has nice writing and editing support, but I won’t really go into that since I didn’t actually need that for this use case.
1Writer has built-in Dropbox support, which meant that it could connect to my account that was already being used to store my presentation and notes and load it directly from there. In the rest of this post I’ll outline how I set up my flow and used 1Writer to organize my talk’s flow and significantly ease my anxiety over missing something.
Create Copy of Base Notes
As I was writing my notes I would store them in a file named
script-base.md in Dropbox. This would serve as the starting point for any run through the talk, be it a practice run or the real thing. 1Writer makes it was to create a duplicate of a document, so each preparation round for a run of the talk would begin by duplicating the base script and giving it an appropriate name:
Checking Off Items
The first section of my script was a list of things that need to be done prior to stepping on stage and delivering the talk. This includes everything from bumping up font sizes, logging into services, turning on Do Not Disturb, etc. Nothing is too simple to leave off the list here, so it’s a great way to have a master list of everything you could forget in the moment. As I completed each step I would check it off in the document:
Since this is working off a fresh copy of the script there’s no need to worry about having to uncheck everything to start over.
Including Steps for Demos
My goal was to be totally driven by memory for my demos and not have to refer to my assistant, but since it was there anyway it would have been silly to not include details of the entire thing in there. Since I was working in Markdown, it meant that I could easily annotate code that I was planning to write from scratch, which could serve as a reminder of what I needed to write in case of temporary memory loss:
Unlike the earlier section where I’d check off items as I completed them, that was not a goal of mine for the demo section since that would break the flow of the presentation. In my case these checkboxes could just as easily have been bullets, but I left them as checkboxes since it was occasionally useful during preparation when working on timing.
One of the nice-to-haves I was after was support for running in split-screen mode on my iPad. The main reason for this was that it allowed me to run 1Writer side by side with the built-in iOS timer app, which was awesome for being able to have something I could look to and see where I was at without having to break my flow and look somewhere else.
1Writer also offered a lot of nice options for theming, fonts, text size, etc, which made it easy to tailor the view to just how I wanted it. I should also note that 1Writer is not a free app. It’s currently just $4.99 in the iTunes app store though, which was an absolute bargain for the value I got out of it. I suspect that I’ll be taking this approach more often for future talks.