Global Nerdy

Click the screen capture to see the original tweet.

It’s tweets like this that make her my favorite singer/songwriter/information security expert.

IFA 2014, Europe’s largest consumer electronics show, takes place in Berlin starting tomorrow (September 5th) and runs until September 10th. It’s a great forum to do international launches for consumer devices that you want to sell during the holidays, and the mobile hardware vendors are promoting their wares there right now. Here’s a quick review of some of the new phones that have been presented so far by Samsung, Sony, HTC, and Microsoft Devices.

Samsung Galaxy Note Edge

Samsung’s Galaxy Note Edge is going to be its next flagship “phablet”, a portmanteau of “phone” and tablet, typically used to describe mobile devices with screens between 5″ and 7″ diagonally. It takes its name from the way the screen curves around its right edge like so:

This curved right edge functions as a sort of second screen. By default, it holds the icons for often-used applications, functioning in the same way the taskbar in Windows or the dock in MacOS does. Apps specially written for the Note Edge can take advantage of it, using it as a place for a menu bar or toolbar for often-used functions. It’s even possible for an app to only use the edge — a stock or news ticker is one possible application, as is an alarm clock app that lets you see the time without having to take your head off the pillow. It’ll be up to developers to come up with creative uses for the edge of the Edge.

It’s got some nice specs and features:

• A fast processor – either a 2.7GHz quad-core chip or a 1.9GHz octa-core one, depending on the country and carrier where it’s purchased
• Lots of memory for a mobile device: 3GB RAM
• Decent storage: 32GB, plus a micro SD slot that lets you add another 32GB
• A large, high-resolution screen – a 5.6 inch quad super HD AMOLED display with 2560-by-1440 resolution
• Two high-resolution cameras:
  • A rear-facing 16 megapixel auto-focus camera with “Smart OIS”
  • A front-facing 3.7 megapixel camera
• A heart rate monitor and “S Health” software that uses it
• The “S Pen” for accurate handwriting and drawing

No price or release date has been announced at the time of this writing, but it should come out this fall.

Here’s are some “hands-on” reports showing the Edge in action:

The Edge will be available through AT&T, Sprint, T-Mobile, and Verizon this fall.

Samsung Galaxy Note 4

If the Galaxy Note Edge’s screen and flagship status don’t excite you, or if it’s outside your budget, you may want to consider the Galaxy Note 4. Apart from a very slightly larger conventional screen (it’s 5.7 inches, a tenth of an inch bigger than the Edge’s) it’s got the same specs as the Edge.

Sony Xperia Z3, Z3 Compact, and Z3 Compact Tablet

Sony’s new flagship smartphone is the Xperia Z3, which takes the Xperia Z2’s features — 5.2 inch 1080p display, a 20.7 megapixel camera, and waterproofing — puts them in an aluminum frame, gives the processor a slight speed boost (2.5GHz vs the Z2’s 2.3), and adds a wide-angle 25mm lens and extra light sensitivity to the camera.

If you like the Z3’s features but want a slightly smaller version, you may be interested in the Xperia Z3 Compact. It has a smaller, lower-resolution screen (4.6 inches, 720p) and skips the aluminum frame, but its other specs, including the processor, 20.7 megapixel camera, and waterproofing, are the same as its bigger sibling’s.

If you like the Z3’s features but wanted a bigger screen instead of a smaller one, the Z3 Compact Tablet is for you. It’s got the same processor, camera, and waterproofing as the Z3, but has an 8-inch screen and a larger battery (which can accommodate, thanks to its larger form factor, and which it needs, thanks to the larger screen).

Owners of the PlayStation 4 gaming console will have an additional incentive to choose a member of the Z3 family for their mobile device: if a Z3 is on the same wifi network as the console, they’ll be able to stream and play games away from the console. You can even attach them to a Sony game controller!

Here are a couple of “hands-on” reports showing the Z3 family:

T-Mobile has confirmed that they’ll carry the Z3 when it launches in the fall.

HTC Desire 820

The HTC Desire 820 is one of the first Android devices to ship with a 64-bit processor, which will enable it to run larger, more complex applications and even gain a little speed boost. These advantages won’t be realized until there’s a version of Android that supports such a chip, but that will happen with the upcoming release of Android L. It also features a 5.5-inch screen with 720p resolution, a rear camera with a 13-megapixel sensor, and for videoconferencing and selfie fans, an 8-megapixel front-facing camera.

Here are some “hands-on” reviews of the Desire 820:

Microsoft (a.k.a. Nokia) Lumia 830

Microsoft Devices — the organization formerly known as Nokia’s phone division — have refreshed their mid-level mobile device offerings with the Lumia 830, which they’re billing as “the affordable flagship”. With a decent processor (a quad-core running at 1.2GHz), 5-inch 720p display protected by Gorilla Glass 3, and a 10-megapixel rear camera with a Zeiss lens, this phone is aimed squarely at the middle of the market.

Here are a couple of “hands-on” reviews of the 830:

Here’s a 1989 ad from Radio Shack Canada for the Tandy CT-300 mobile phone, which went on “sale” for $1499 Canadian, an $800 price cut.

What’s that worth in 2014 dollars? If we do the math based on this data:

• In 1989, $1 Canadian was worth about $0.84 US on average (according to this PDF document from the University of British Columbia), and
• $1 in 1989 would be worth $1.91 today (according to Dave Manuel’s inflation calculator).

Then:

• The full price of the phone, $2299 Canadian, would be US$3689 in present-day money, enough to pay for 5 16GB iPhone 5S or Galaxy S5 smartphones, including sales tax.
• The sale price of the phone, $1499 Canadian, would be US$2405 in present-day money, enough to buy 3 16GB iPhone 5S or Galaxy S5 smartphones, including sales tax.

Another big difference between then and now: 28 ounces, the CT-300 is a cinder block compared to today’s phones. The “Big Two’s” flagships are much lighter: the Galaxy S5 weighs 5.11 ournces, and the iPhone 5S weighs 3.95 ounces.

And finally, there’s that “40-number memory”. The photo for just one person in your smartphone’s address book would fill the RAM allotted to that 40-number memory several times over.

Ain’t modern technology grand?

In the last installment of the Enlightened Laziness series (my new series of articles on cross-platform mobile development with Xamarin), I gave you the code for a slightly more complex “Hello, World!” app: a “Magic 8-Ball” app for Android and iOS. It’s pretty simple: the user is presented with a button which gives a random yes/no/maybe answer.

My options

I had a choice of approaches I could take when writing the app. I could’ve written it the standard way, which is diagrammed below:

The standard way — the one that’s been available since Xamarin 1.0 — is to write some iOS-specific C# code (typically for the UI and other iOS-specific APIs and features), some Android C# code (once again, typically for the UI and other Android-specific APIs and features), and some C# code common to both versions, typically the app’s “business logic” and other code that’s specific to the app’s domain rather than the platform. It’s still less work than dealing with an iOS Xcode project with code in Objective-C and an Android ADT or Android Studio project with code in Java, but it’s still not quite the “write once, run anywhere” dream.

The other way — the way I chose — is new to Xamarin: the Xamarin.Forms route, which is diagrammed below:

With Xamarin.Forms, you’re coding to a single, platform-independent UI toolkit, and Xamarin does the necessary conversions during the compilation process. This sounds like the “write once, run anywhere” dream, and I’ll be spending the next few weeks playing with it. If you’ve used similar tools or platforms, you know that these sorts of systems are never perfect, and one of the things I’m going to be exploring is the set of trade-offs you have to make when using Xamarin.Forms for cross-platform development.

The full code for the Magic 8-Ball app

Here’s a screenshot of Xamarin running on my Mac that shows the structure of the Magic 8-Ball solution:

Click the screenshot to see it at full size.

The solution has three projects:

1. Magic8Ball: Contains the code for the app itself
2. Magic8Ball.Android: Contains the necessary code for building the Android version
3. Magic8Ball.iOS: Contains the necessary code for building the iOS version

If you look at the contents of the MainActivity.cs file in Magic8Ball.Android, you’ll see this. It bears a strong (if C#-flavored) resemblance to the sort of MainActivity.java file that gets auto-generated when you start a new Android project in ADT or Android Studio:

using System;

using Android.App;
using Android.Content;
using Android.Content.PM;
using Android.Runtime;
using Android.Views;
using Android.Widget;
using Android.OS;

using Xamarin.Forms.Platform.Android;


namespace Magic8Ball.Android
{
	[Activity (Label = "Magic8Ball.Android.Android", MainLauncher = true, ConfigurationChanges = ConfigChanges.ScreenSize | ConfigChanges.Orientation)]
	public class MainActivity : AndroidActivity
	{
		protected override void OnCreate (Bundle bundle)
		{
			base.OnCreate (bundle);

			Xamarin.Forms.Forms.Init (this, bundle);

			SetPage (App.GetMainPage ());
		}
	}
}

Note the last line of code: it contains a call to the GetMainPage() method of the App class. The App class is defined in the App.cs file of the platform-independent project, Magic8Ball.

There’s similar code in the AppDelegate.cs file in Magic8Ball.iOS. It looks like the AppDelegate.m or AppDelegate.swift file that gets auto-generated for new iOS projects in Objective-C or Swift, but in C#:

using System;
using System.Collections.Generic;
using System.Linq;

using MonoTouch.Foundation;
using MonoTouch.UIKit;

using Xamarin.Forms;

namespace Magic8Ball.iOS
{
	[Register ("AppDelegate")]
	public partial class AppDelegate : UIApplicationDelegate
	{
		UIWindow window;

		public override bool FinishedLaunching (UIApplication app, NSDictionary options)
		{
			Forms.Init ();

			window = new UIWindow (UIScreen.MainScreen.Bounds);
			
			window.RootViewController = App.GetMainPage ().CreateViewController ();
			window.MakeKeyAndVisible ();
			
			return true;
		}
	}
}

As with the Android version, there’s a call to App.GetMainPage() in the iOS version. That’s where your part of the app begins — let’s look at the App class and its GetMainPage() method.

Since it’s simple and the point of the exercise is to provide a quick-and-dirty intro to Xamarin.Forms, I’m foregoing the general rules about keeping interface and implementation separate (you shouldn’t stuff all the code into the view in a “real” app). The code for the entire “Magic 8-Ball” app is in the GetMainPage() method:

using System;
using Xamarin.Forms;
using System.Collections.Generic;

namespace Magic8Ball
{
	public class App
	{
		public static Page GetMainPage ()
		{	
			var answers = new List<string> {
				"Yes.",
				"Sure thing.",
				"But of course!",
				"I'd bet on it.",
				"AWWW YISSS!",
				"No.",
				"Nuh-uh.",
				"Absolutely not!",
				"I wouldn't bet on it",
				"HELL NO.",
				"Maybe",
				"Possibly...",
				"Ask again later.",
				"I can't be certain.",
				"Clouded by the Dark Side, the future is."
			};

			var randomAnswerSelector = new Random ();

			var layout = new StackLayout {
				Padding = 20,
				VerticalOptions = LayoutOptions.Center
			};

			var answerButton = new Button {
				Text = "I need an answer!",
				Font = Font.BoldSystemFontOfSize (30),
				HorizontalOptions = LayoutOptions.CenterAndExpand
			};

			var answerLabel = new Label {
				Text = "",
				Font = Font.BoldSystemFontOfSize (50),
				HorizontalOptions = LayoutOptions.CenterAndExpand,
				XAlign = TextAlignment.Center
			};

			answerButton.Clicked += (object sender, EventArgs e) => {
				answerLabel.Text = answers[randomAnswerSelector.Next (answers.Count)];
			};

			layout.Children.Add (answerButton);
			layout.Children.Add (answerLabel); 

			return new ContentPage { 
				Content = layout
			};
		}

	}
}

The Magic 8-Ball app’s UI structure

As you can see in the code, the GetMainPage() method’s job is to draw the app’s main (and only) screen, which in Xamarin.Forms parlance is a Page. Xamarin.Forms’ Page class represents different things on different mobile OSs:

• An Activity in Android
• A View Controller in iOS
• A Page in Windows Phone

Xamarin.Forms pages come in 5 different flavors:

A page can contain a single child. Typically, this child is some sort of container for other controls.

For this app, our main screen is a ContentPage, the simplest type. If you’d like to find out about the other page types, see Xamarin.Forms’ Pages documentation.

Since a page can have only one child and we need two controls, we’ll need to make that child something that can hold other controls. That’s what the various subclasses of the Layout class are for:

For this app, we’ll use the StackLayout layout, which is used to lay out controls in a single horizontal or vertical line. We’ll give it two children:

• A Button, which the user will tap to get a random yes/no/maybe answer, and
• A Label, which will display that random yes/no/maybe answer.

As I showed in the previous article, Xamarin converts these UI-independent views into their equivalents on their respective platforms:

A walk through the code for C# newbies

If you’re familiar with C# programming, you can skip this final section. This is for the benefit of people who are new to C# or haven’t coded in it in a while.

Creating the set of answers

Here’s the first line of the GetMainPage() method. It defines the app’s randomly-selected answers:

var answers = new List<string> {
	"Yes.",
	"Sure thing.",
	"But of course!",
	"I'd bet on it.",
	"AWWW YISSS!",
	"No.",
	"Nuh-uh.",
	"Absolutely not!",
	"I wouldn't bet on it",
	"HELL NO.",
	"Maybe",
	"Possibly...",
	"Ask again later.",
	"I can't be certain.",
	"Clouded by the Dark Side, the future is."
};

C#’s var keyword lets you declare variables at the method level without having to explicitly specify their type — given enough information, the compiler is smart enough to figure out the type all by itself. After all, why type in this redundancy-filled line:

Thingy myThingy = new Thingy();

when you can simply type:

var myThingy = new Thingy();

If you’ve been coding in Swift, you’re familiar with this sort of implicit declaration.

C# has a built-in array type, but it’s generally recommended that you ignore it most of the time in favor of using the the List<T> type instead. Lists offer more features than arrays (even when you factor in LINQ), and unlike arrays, they’re resizable. Like arrays, the List collection has an initialization syntax that filling it simpler.

Setting up the random number generator

The next line sets up the random number generator by initializing a new instance of the Random class:

var randomAnswerSelector = new Random ();

This is pretty close to the way you’d do it in with Android in Java. Both the .NET and Java libraries have a class called Random which is used to generate pseudorandom integer and real numbers. In this case, we want to generate a random integer that we’ll use to select an answer to give the user.

Random number generation is a little different in Objective-C/Swift and iOS. There, we’d use some version of the arc4random() function from the standard C library  — most likely arc4random_uniform(), which avoids the “modulo bias problem” — to generate a pseudorandom integer.

Setting up the controls

These lines initialize the controls: the Button, the Label, and the StackLayout that will contain them both. These are pretty straightforward:

var layout = new StackLayout {
	Padding = 20,
	VerticalOptions = LayoutOptions.Center
};

var answerButton = new Button {
	Text = "I need an answer!",
	Font = Font.BoldSystemFontOfSize (30),
	HorizontalOptions = LayoutOptions.CenterAndExpand
};

var answerLabel = new Label {
	Text = "",
	Font = Font.BoldSystemFontOfSize (50),
	HorizontalOptions = LayoutOptions.CenterAndExpand,
	XAlign = TextAlignment.Center
};

Note the object initialization syntax. This:

var answerLabel = new Label {
	Text = "",
	Font = Font.BoldSystemFontOfSize (50),
	HorizontalOptions = LayoutOptions.CenterAndExpand,
	XAlign = TextAlignment.Center
};

is the equivalent of this:

var answerLabel = new Label ();
answerLabel.Text = "";
answerLabel.Font = Font.BoldSystemFontOfSize (50);
answerLabel.HorizontalOptions = LayoutOptions.CenterAndExpand;
answerLabel.XAlign = TextAlignment.Center;

It makes for less typing, which according to Corbato’s Law, is a good thing (as long you don’t make the code hard to read).

Responding to a tap on the button

Let’s define what happens when the user taps the button, which raises the Clicked event. We want to attach an event handler to the Clicked event that selects a random answer and sets the text of the label on the screen to that answer:

answerButton.Clicked += (object sender, EventArgs e) => {
				answerLabel.Text = answers[randomAnswerSelector.Next (answers.Count)];
			};

The => is C#’s lambda operator. The ability to define anonymous functions which can then be passed about is also available in Objective-C in the form of blocks and in Swift in the form of closures, and well as in Java 8.

Defining and returning the page

With the UI completely defined — layout, controls, and even an event hander — it’s time to lay out the content of the page and return it:

layout.Children.Add (answerButton);
layout.Children.Add (answerLabel);

return new ContentPage { 
	Content = layout
};

Keep an eye on this blog — I’ll be doing a lot of exploring of Xamarin and especially Xamarin.Forms and sharing my findings here!

Found via Joe Martinez. Click the picture to see the source.

Of course, if you’re caught doing this, it’s likely that a number of business travellers and people looking to charge their tablets for a long trip will draw and quarter you, and no court in the land will convict them.

This article also appears in The Adventures of Accordion Guy in the 21st Century.

How I decided to take up Xamarin development

Six years ago, I was a newly-minted developer evangelist with Microsoft Canada, and mere days into the job, I’d been sent to the Professional Developers Conference in Los Angeles. As part of my initiation into the fold, my fellow evangelist John Bristowe was assigned to me as a mentoring “buddy” to help me learn the ropes.

As part of my training, he had me conduct a number of video interviews with the .NET community’s bright lights, one of whom was Miguel de Icaza, then-leader of the Mono Project. The project’s goal was to create an ECMA standards-compliant set of .NET framework-compatible C# compiler, CLR, and other tools to other operating systems. I got a chance to hang out with Miguel and a bunch of guys from the Mono team over the next few days, during which they showed me all sorts of interesting stuff, including a rough 3D jet fighter game written using Mono and running on the then still-pretty-new iPhone.

Over the years, Miguel’s work has been one of those things that I’d been meaning to check out. I kept an eye on Mono’s ups and downs, and expected the project to disappear forever when Novell laid off the entire Mono team three years ago. Miguel quickly put together a new company, Xamarin, which I didn’t expect to live very long. I was pleasantly surprised to see it not just survive, but even thrive mere months after it got started. Even after that, Mono, now Xamarin, remained one of those things that I’d get around to eventually.

Then, a few things changed…

For starters, I joined GSG, a company that makes an enterprise mobility management / mobility managed services platform. That’s industry jargon for “helping medium- to large-sized companies stay on top of their wireline and mobile telecom stuff”. I’m their Platform Evangelist, and one of my roles is to make sure that GSG’s sales team, partners, and customers know all there is to know about our platform, which means that I’m responsible for a lot of the promo and educational material.

Some of that material is in the form of smartphone and tablet apps. These all come down to me, and while I can put together a half-decent iOS app, I’m still an Android newbie, and I’m just one guy. And wow, do I dislike Java, especially after working with C# for some time. I needed something that would let me write apps for both iOS and Android without doubling the work I’d have to do.

Since I’m new to the Tampa area, I’ve been attending some meetups to get to know local techies. One of these meetups was the Xamarin one, and it got me interested enough to download the latest version of the Xamarin development tools, which have come a long way. It’s actually quite pleasant to use, and I found myself having fun coding in C# — which I’ve used in an on-again, off-again fashion since 2001 — and seeing the output run on iOS and Android. I also found Xamarin.Forms, which I’ll talk about a little later in this article.

I’ve heard a number of developers talk about how they’ve switched to Xamarin, and a number of apps created in Xamarin, such as Rdio and Tom Hanks’ vanity app, Hanx Writer (which merges Notepad with a beautiful old-school mechanical typewriter’s interface) have come to my attention.

The last Tampa Bay Xamarin User Group meetup had a session led by Russ Fustino, who announced that he’d become a Xamarin evangelist and led us through what he’d learned at the Xamarin University online course series. What I saw was quite impressive, and it led me to set some time aside and take Xamarin out for a proper spin.

At the post-meetup gathering at a nearby bar, I ended up chatting with Russ and his brother, who told me how they’d used Xamarin to build an apps for classic rock band Jethro Tull that ran on Android, iOS, and Windows Phone.

And finally, there’s the $54 million Series C round they recently raised. You might think that such a thing wouldn’t matter to a developer, but it does for an important reason: if I’m going to invest my time in a tool in a quick-moving field like mobile, I’d like some reassurance that the toolmaker has the resources to stick around for a while and to keep up with all the changes in devices, operating systems, and services.

Together with the fact that I got pretty decent at coding in C# from my days at Microsoft, the factors above have led me to revise my “Mobile Dev Tools Skills Portfolio” to the following:

• Xamarin/C# for cross-platform development
• XCode/Swift for straight-up iOS development

And yes, that means that there’ll be both Swift and Xamarin development articles on this blog, and they’ll be coming increasingly often as I’m ramping up my development work.

Xamarin Indie: $25/month/platform, but only until the end of August

The version that best suits my needs is Xamarin Indie, which is for independent developers with fewer than five employees. It’s normally $300/year/platform (which means it’s $600/year if you want to develop both Android and iOS apps), but for the month of August 2014, Xamarin’s experimenting with charging monthly ($25/month/platform, or $50/month if you want to develop for both Android and iOS). This approach will be less painful for developers short on cash, and if you find that Xamarin’s not for you, you can cancel the subscription and pay only for the months during which you subscribed.

Xamarin.Forms

One of the key features of Xamarin Indie, which is a step up from the free version, is that it lets you use a new development model: Xamarin.Forms.

Until now, the way to write a cross-platform app with Xamarin was to write two different categories of code:

• The common code used across all the platform versions, typically be the back-end or “business logic” of the app.
• The platform-specific code, typically code that accesses platform-specific features and UI

With Xamarin.Forms, you’re coding to a single “platform” and API that abstracts away the differences among Android, iOS, and Windows Phone. The compiler does a of the work that you’d have to do to address each platform’s different approaches. For me, this is a very valuable feature — valuable enough that I’m willing to give it a try even though it’s still 1.0.

Building a quick and dirty “Magic 8-Ball” app with Xamarin.Forms

In order to show Xamarin — and Xamarin.Forms in particular — in action, let me walk you through the process of building a quick and dirty “Magic 8-Ball” app. In order to follow this exercise, you’ll need a Xamarin with an Indie or higher account for at least one of the supported platforms. Unfortunately, Xamarin.Forms isn’t available with the free version of Xamarin.

Start a new solution with File → New → Solution…:

Click the screenshot to see it at full size.

The menu in the left pane lists the various solution categories. Note that Xamarin supports development not just for a number of platforms, but in a number of languages as well. The two languages you can use for developing mobile apps are C# and F# (an ML-like functional programming language). Choosing a category from the left pane menu gives you a list of solution types.

Expand the C# item in the left pane menu and select Mobile Apps. This gives you a list of Xamarin.Forms solutions you can create. Choose Blank App (Xamarin.Forms Shared), and give your solution a name. I named mine “Magic8Ball”. Click OK, and Xamarin will create the solution:

Click the screenshot to see it at full size.

Expand the Magic8Ball folder to reveal App.cs, and then double-click App.cs to see its contents:

Click the screenshot to see it at full size.

Let’s run the app as it is on iOS. Right-click on the Magic8Ball.iOS project and select Set as Startup Project from the contextual menu that appears. Then, near the upper left-hand corner of the Xamarin window, select the way you want to run the app — either on the simulator or on an iPhone connected to your computer:

Click the screenshot to see it at full size.

Click the Run button near the upper left-hand corner of the Xamarin window to run the app. Once the compilation and transfer process is done, you should see something like this:

Stop the app, and replace the contents of App.cs with the following:

using System;
using Xamarin.Forms;
using System.Collections.Generic;

namespace Magic8Ball
{
	public class App
	{
		public static Page GetMainPage ()
		{	
			var answers = new List<string> {
				"Yes.",
				"Sure thing.",
				"But of course!",
				"I'd bet on it.",
				"AWWW YISSS!",
				"No.",
				"Nuh-uh.",
				"Absolutely not!",
				"I wouldn't bet on it",
				"HELL NO.",
				"Maybe",
				"Possibly...",
				"Ask again later.",
				"I can't be certain.",
				"Clouded by the Dark Side, the future is."
			};

			var randomAnswerSelector = new Random ();

			var layout = new StackLayout {
				Padding = 20,
				VerticalOptions = LayoutOptions.Center
			};

			var answerButton = new Button {
				Text = "I need an answer!",
				Font = Font.BoldSystemFontOfSize (30),
				HorizontalOptions = LayoutOptions.CenterAndExpand
			};

			var answerLabel = new Label {
				Text = "",
				Font = Font.BoldSystemFontOfSize (50),
				HorizontalOptions = LayoutOptions.CenterAndExpand,
				XAlign = TextAlignment.Center
			};

			answerButton.Clicked += (object sender, EventArgs e) => {
				answerLabel.Text = answers[randomAnswerSelector.Next (answers.Count)];
			};

			layout.Children.Add (answerButton);
			layout.Children.Add (answerLabel); 

			return new ContentPage { 
				Content = layout
			};
		}
			
	}
}

Run the app again, and now you’ll see something like this:

Try it for Android — right click on the Magic8Ball.Android project and select Set as Startup Project from the contextual menu that appears. Then, near the upper left-hand corner of the Xamarin window, select the way you want to run the app — either on an emulator or on an Android device connected to your computer:

Run the app once more, and you’ll see something along these lines:

I’ll cover the app in a little more detail in my next article.

California Governor Jerry Brown signed a “Kill Switch” bill into law, making his the first state to require that anti-theft features for smartphones sold there to be enabled by default. The feature allows smartphone owners to remotely lock down their phones if stolen, rendering them inoperable and useless to and unsellable by thieves.

Minnesota has a similar law, but it’s an “opt-in” one: it simply required that smartphones sold there need to present users the chance to enable the kill switch feature during the initial setup process.

Smartphones (not tablets or other mobile devices) sold in California after July 1, 2015 will be required to have an enabled kill switch feature. Anyone who sells a non-compliant smartphone will face a penalty ranging from $500 to $2500.

The law is meant to combat increasing smartphone theft. In the US, one in 10 smartphone owners has had one stolen, and in 2013, more than 3 million Americans — double the number in 2012 — has lost a smartphone to theft. The problem is a particularly big one in California; mobile device theft accounted for 65% of robberies in San Francisco and 75% in nearby Oakland.

The two biggest smartphone vendors in the world, Samsung and Apple, already have kill switch features built into their devices:

• Samsung has Reactivation Lock, which when activated by the phone’s owner, makes the phone unusable, even after a factory reset.
• Apple has Activation Lock, which requires the user’s Apple ID/password credentials in order to disable location tracking or reactivate a locked phone.

Google and Microsoft have announced that they’ll build in kill switch features into upcoming revisions of their mobile operating systems.