What Will Build 2016 Mean for UWP?

Here is my bold Microsoft Build 2016 prediction: Microsoft will kill the Universal Windows Platform. Or at least they will kill it as we know it today. Let me explain why I think this might happen.

Years ago Microsoft entered the cloud computing business with Azure. And it was intended as a way to run .NET based services in the cloud. At the time, .NET only ran on Windows and so the cloud platform was named Windows Azure. Less than two years ago, Microsoft had expanded Windows Azure to include applications such as Hadoop and languages such as PHP and Python. And to the surprise of many, officially supported Linux. Linux running on Windows Azure didn’t make much sense so the name was changed to Microsoft Azure.

This is precedent for what I think could happen at Build next week. Microsoft has completed the acquisition of Xamarin, which lets developers target multiple platforms using .NET. These platforms are iOS, Android, Windows Phone, Mac OS X and Windows 10. Now Xamarin in the past has pledged support for the Universal Windows Platform and they have made progress towards this with Xamarin.Forms. However, desktop platforms are excluded. With .NET Core coming, many people have asked for WPF support on non-Windows platforms. Microsoft has remained silent on this topic. Could it be that Microsoft will leverage Xamarin to create a truly cross platform desktop application framework using .NET Core, Xamarin.Forms and the Universal Windows Platform? Maybe, except they would have to call it the Universal Microsoft Platform instead. Could this mean Visual Studio (not Visual Studio Code) coming to OS X and Linux? (SQL Server is coming to Linux and Microsoft R runs on Windows)

It makes sense that what .NET Core has done for ASP.NET, and what Xamarin has done for .NET mobile apps could be extended to the desktop with Universal Microsoft Platform. Remember the original goal of Microsoft? A computer for every person (at the time on every desktop) running Microsoft software. This might be the year they make good on that.

Simple Camera Access with iOS and Xamarin

I’m working on a small iOS.Xamarin project right now that requires basic camera access. The process is very conceptually similar to what you would do using Objective-C or Swift.

First I’ll create a Single View iOS project in Xamarin Studio and choose C# as the language:


In the next dialog, I’ll give the app a name of CameraDemoIos and for simplicity deselect the iPad option even though this would work on an iPad:


In the last dialog, the default settings are just fine so click Create to have Xamarin Studio generate a skeleton.

The first thing I’ll do is set up the user interface. The UI will be very simple, consisting of just a button to trigger the built-in camera interface and an image view to show the image taken. Open Main.storyboard and drag a button to the view controller. Use the blue guidelines to place it in the center of the view and the minimum recommended distance from the bottom:


Click on the button again to bring up the handles to create auto layout constraints:


The button needs to be centered horizontally, so drag the center handle up until the dashed green line running down the horizontal center of the view turns blue:


When you release it, a lot of the UI will turn orange because the constraints are ambiguous. To fix that, drag the bottom handle (that looks like an inverted ‘T’) to the bottom of the view until the bar at the bottom of the view turns green. Sometimes it helps to drag it over to the side because it gets cramped:


The constraints now fully define the layout of the button to where it is always centered horizontally and is a fixed distance from the bottom of the view:


The title of the button is not very descriptive, so with the button selected, change the title in the Properties pane in the Widget tab. (The constraints will turn orange again, but that’s ok.)


To constraints turned orange because the text is wider than the current width of the button. Notice the dotted orange line extending outside the button? That is the width that the button needs to be. And if you were to run the application now, the button would be wide enough in the simulator (or on the device) to show the text. This is merely a design time issue. So to fix it, click last button in the Constraints pane at the top of the designer. If you hover over it, the popup will read ‘Update frames based on constraints’:


Click it, the constraints will turn blue, and the button will be wide enough for the text:


Most iOS applications do not live in a single view (except for demo apps). One of the most common patterns is to use a navigation controller. Find a navigation controller in the toolbox and drag it onto the storyboard:


It looks a little cramped, but we’re going to fix that. First, select the view controller added with the navigation controller and delete it. (Click the gray bar at the bottom of the view to select it.) Now we need to set the navigation controller to be the initial view controller that launches when the application starts. Notice there is an arrow pointing to the view controller created with the project that we’ve been working with. This means that view controller is the initial view controller. To change that, drag and drop the arrow so that it points at the navigation controller instead:


The navigation controller will allow us to view a sequence of view controllers (we are just going to have one) and it will act as a manager of the view controllers. It needs to have a root view controller which will be the first one displayed. When we dragged the view controller on to the storyboard, it came with a root view controller but we deleted it because we need to use the view controller that already exists. To make that the root view controller, hold the Control key and drag to the dark gray bar of the other view controller:


In the popup menu, select ‘Root’. Now an arrow will point from the navigation controller to the view controller indicating it is the root. To see this clearly, drag the controllers next to each other:


Now the UI needs an image view. (I promise we’ll get to some code soon.) I won’t go through setting the constraints up in detail because the process is very similar. Drag an image view on the view in the upper left corner using the layout guide for the left spacing. The top spacing, you’ll have to estimate because the designer doesn’t show a guide to the top of the navigation bar, just the top of the view. There is a way to compute this, but we won’t worry about it here. Just make sure the top of the image view is visible. Now drag the right and bottom of the image view to the layout guides on the right of the view and the top of the button. Click on the image view again to get the constraint handles and drag the left one to the left side of the view, and the right one to the right side of the view. Drag the top one to the top of the view, not the bottom of the navigation bar, until the top layout guide indicator turns blue:


Now drag the bottom handle to the top of the button. Again, it works better to drag it over to the side. The top layout of the button will be a dashed blue line when the handle is dragged over it:


The constraints are all blue and the user interface is complete:


In the Properties pane, under the Widget tab, set the Name to imageView. Next, select the button again and in the Properties pane, under the Events tab, find the Touch section and the Up Inside event. In the text box, type the name pickImage. This is the name of the handler method to be called with the Touch Up Inside event of the button is fired:


Press enter and the text editor will (finally!) come up. Use the arrow key to tell Xamarin Studio where to place the stub code for the handler method and then press enter again:


This will leave us conveniently inside of the ViewController.cs file. Here is the plan. In the pickImage method, we will create an instance of a UIImagePickerController. This is a view controller that iOS provides for selecting an image from several sources, including the camera which we will use here. The UIImagePickerController only knows how to select an image, it doesn’t know what to do with the image after that. We need to tell it what to do with the image and for that we will create a delegate class. The delegate class will implement an interface called UIImagePickerControllerDelegate that will declare a method, FinishedPickingImage, which the UIImagePickerController will call after the user takes the picture. The FinishedImagePicker method will need a reference to the view controller with the image view and it will set the image property of the image view to the image which was the picture the user took.

In the pickImage method, first create a new UIImagePickerController.

Now set the SourceType.

In Objective-C, the SourceType would be a constant but in C# it’s an enum.

Now we need to create an instance of the delegate class (which we will define shortly). This class will be called ImagePickerDelegate and will need a reference to the current view controller so it will be able to set the image.

Set the delegate of the imagePicker to imagePickerDelegate.

Now we need to show the imagePicker. We don’t want the user to do anything else until they’ve taken a picture (or cancelled the operation) so the PresentModalViewController method will do that. Also, the method will be called on the NavigationController property which refers to the containing navigation controller. The PresentModalViewController takes the instance of the view controller to be shown (imagePicker) and a boolean which is whether it should be animated in display.

One more thing in the ViewController class. Remember when we gave the image view a name of imageView in the designer? Behind the scenes, Xamarin Studio created something called an outlet which is iOS speak for a variable that represents a user interface object in a storyboard. The problem is, that Xamarin Studio makes outlets private and we need the delegate class to access the image view. So we just need to create a property called ImageView of type UIImageView that is read-only and just returns the imageView field.

The entire class now looks like this: (I omitted the ViewDidLoad and DidReceiveMemoryWarning methods as well as the constructor)

Now let’s create the delegate class. Right click on the CameraDemoIos folder, select Add -> New File and then from General, select Empty Class. Give the class a name of ImagePickerDelegate and click New. In the new class first add a using for the UIKit namespace which is where the UIImagePickerControllerDelegate interface lives.

Then make the ImagePickerDelegate class implement UIImagePickerControllerDelegate.

Add a private field of type ViewController which will be a reference to the instance of the view controller that started the camera and then have the constructor accept a parameter of type ViewController and assign it to the private field.

Finally override the FinishedPickingImage method and delete the generated exception code. FinishedPickingImage accepts the UIImagePickerController that was used to take the picture, the picture that was taken, and some information about it. We will only be using the first two values. First, assign the image to the Image property of the ImageView property of the vc field. That will show the picture in the image view. But we can’t see it because the camera interface is still showing. So simply call DismissViewController on the picker. It takes two parameters the first is a boolean to say whether the transition is animated and the second is a callback for after the view controller is gone. I’ll pass true for the animation and null for the callback.

Here is the code:

And that’s all there is, build and run the application in the simulator, press the Take Picture button and … #sadtrombone. We get an exception.


This is because there is not a camera available on the simulator. The simulator does not emulate any type of media input device. Now in the real world we would check for this exception because some devices don’t have cameras but they are becoming fewer every day. However this means we must test camera apps on a real device. So what follows are screenshots that I took on my iPhone 6 Plus: (you’re just going to have to trust me that it works on other devices! :) )

The initial interface:


The UIImagePickerController:


After taking a picture: (the FinishedPickingImage event does not happen until after confirmation)

After confirming the photo:

And that’s all there is to it. You can do anything you want with the image. Note that this is not the only means available for taking pictures. Since Xamarin is a .NET binding to native APIs, you can create custom camera interfaces or even get detailed with AVFoundation.

A Disturbing Trend in Hiring Policies

For the past few years, I have been a freelancer. However, I’ve found that chasing the next sale is not something that I enjoy. So I have been entertaining the idea of working full time for a company again. I’ve noticed a disturbing trend however in a practice of mandating applicants authorize background investigations to a degree which I feel is not only an overreach, but should be illegal.

Several recent examples have included very broad language. For example, they have all mentioned credit as a potential source. My credit history is only relevant to myself and the companies with which I have credit business. Regardless of whether my credit score is 500 or 800, it is none of my employer’s concern. Also, the language in the releases have not defined an explicit expiration date making it effective for the remainder of the time the company is in business. Finally, and most concerning, the releases have authorized future investigations at any time, without prior notification of the applicant. Combine this with the broad scope and indeterminate expiration date, and it invites abuse.

In a few cases I have requested simple modifications that narrow the scope to where it applies only to the sources which the employer has interest and to restrict the conditions for which the release is valid. In no way would this prevent a company from conducting a pre-employment background investigation. It would however, protect the applicant’s sensitive personally identifiable information from potential misuse. In addition, by mandating such broad and indeterminate language, a company is essentially saying security and privacy of its clients’ data is more important than that of its employees. Both should be considered equally important.

I understand the desire of an employer to take action to ensure the integrity of employees and to protect the sensitive data and intellectual property entrusted to them. However, background investigations such as these are an overreach. In my opinion, they should be illegal in most cases. If an employer is not comfortable with a new hire based on employment history and references, they should reject the candidate. The response I often get to this is that it is “standard practice”. Such an argument is insufficient. At one time in the United States, it was standard practice that only men enjoyed the right to vote. Consensus does not define ethics.

An essential component of any business relationship is trust. It is very important and also very fragile. Optimum productivity is impossible in the absence of trust. Contractual agreements must be equitably beneficial to all involved parties. In these cases, the applicant was guaranteed nothing in return for their trust.

Setting Placeholder Color in UITextField

I openly admit I’ve never paid much attention to designing user interfaces or user experiences. (Even though I have a degree in the arts, it’s in music.) Recently, I’ve started to work on it some and especially in the mobile space. A lot of what gives iOS the unique look and feel can be found in animation and design. And it’s not just window dressing either. It can help with usability too and I am working on a project which (I hope) will show that off. In the meantime, I wanted to share a problem that I recently came across and a solution for it.

When using the stock look and feel of iOS controls, things work well together visually. However, when you start to customize the appearance, visual inconsistencies start to show up. For example, if you add a placeholder to a UITextField and don’t change the appearance, it looks great. (The placeholder is text that is shown when the UITextField is empty.)


But what happens if you change the background color of the UITextField or make it clear and let a background image show through? Sometimes the default gray color of the placeholder cannot be seen easily.


But there is no option in Interface Builder to change the color of the placeholder text, like there is with the text value of the UITextField.

There are several solutions to this issue. The most straightforward is to modify the attributedPlaceholder property of the UITextField. The attributedPlaceholder is an NSAttributedString. I did this in viewWillAppear:

This will simply set the value of the placeholder to a new NSAttributedString with the same text as the placeholder but the color (via the NSForegroundColorAttributeName key) set to white.


Ok, easy enough, but what if we want all of the UITextFields in the app to have placeholders that are white? Well, there a solution for that as well. You can subclass UITextField and then override the drawPlaceholderInRect:rect method. That’s also simple enough. We could go a bit further and expose the placeholder color as a property on that class too:

Now just use the Identity Inspector in Interface Builder to set the class of the text field to ColoredPlaceholderTextField.


And we can now set the color of the placeholder with less code:


This yields the same results as before but now we’ve got something that is reusable. However we still have to run the app to see the results. This is where IBDesignable and IBInspectable come in handy. These Interface Builder specific keywords are related to the IBOutlet and IBAction that you have used many times before. They mean nothing to the logic of the application, they are instructions for Interface Builder on how to interpret your user interface in the designer. Let’s look at IBInspectable first. Modify the placeholderColor property like so:

Go back to the storyboard, select the text field which is an instance of ColoredPlaceholderTextField and look in the Attribute Inspector:


A new attribute has shown up for the placeholderColor property! Interface Builder also looked at the type of the property and since it is UIColor, has given us the color selector to choose a color. So if we set the color to something horrible yet obvious:


We can see the results in the simulator:


But still, we have to run the app the see what the color looks like. This is time consuming but IBDesignable to the rescue! By prefixing the UITextField subclass with @IBDesginable, we can see the results of setting the placeholder color in Interface Builder without running the application. First modify ColoredPlaceholderTextField like this:

Then take a look at the storyboard in Interface Builder. As the placeholder color is changed via the Attribute Inspector, the storyboard will reflect the new color:


Of course, this is only one instance of where IBInspectable and IBDesignable can be used. Check the documentation for the complete rundown.

Connecting Multiple Controls to an Action in Xcode

So here is something that I found interesting. Interface Builder at first may seem unintuitive because the graphical designer does not limit itself only to that which can be seen. Most iOS developers are aware that you can Control-drag from a storyboard (or NIB file) into a code file to create outlets and actions. However, what I recently learned is that you can Control-drag from a control to an existing IBOutlet in a code file to make a connection. In this very simple example I have two buttons. One increments a value when tapped and the other reduces it. I’ve got one IBOutlet function (I’m using Swift) that looks at the button sent to determine whether to increase or decrease the value. So my storyboard looks like this:
And I have the following IBAction in my view controller:

Also, display is a property with a didSet observer:

Now to hook the Increase button to the IBAction, all I have to do is Control drag from the button into the function in the code file. Unfortunately, I am not quick enough with my screen grab app to get a good picture of it but here is something that should give you the idea:


A border will appear around the IBAction in Xcode and when you release the mouse button, the connection will be made.

On a slightly related note, the IBAction is not using the best method for determining which button was clicked. Actually, I should be assigning each button a tag. This is a property that can be set in Interface Builder in the Attributes Inspector:


The tag is a language neutral integer identifier for this control. I’ll set the Increase button to 1 and leave the Decrease button at 0. Back in my IBAction I’ll change it to:

Now I could change the text on the buttons and not have to change the code. Also this is great for localized applications. The words increase and decrease might not mean anything to someone in Japan or Italy. And that’s a simple tip to take advantage of Xcode’s designer.

And I’m back

Long story short I should have done this a long time ago. I finally got sick of my old, slow and unreliable shared host and moved to a DigitalOcean droplet. Problem is that I have never migrated a WordPress install before (and that’s why I’ve been putting it off) and I don’t know how to get the old content back. It’s still on the other server and I can archive it but getting it into this site is something I don’t know how to do .. yet. And I don’t know if I can restore the shortlinks and such. The process of getting the DNS done and installing all of the software was not bad at all. Took less than an hour and a plus is that now I authorize updates and new plugins via SSH instead of FTP so it’s more secure and I don’t have to keep up with the FTP login or run an FTP server. My goal with all of this is that with a more reliable server, I’ll hopefully write more. So let’s see what comes out the other side of this.