August 2014

magic 8-ball

enlightened lazinessIn 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:

standard xamarin apps

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:

xamarin.forms apps

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:

screen 1

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 file that gets auto-generated when you start a new Android project in ADT or Android Studio:

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#:

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:

The Magic 8-Ball app’s UI structure

magic8ball'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:

xamarin forms page types

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:

xamarin forms layout types

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:

eightballforms screenshots

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:

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:

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:

Note the object initialization syntax. This:

is the equivalent of this:

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:

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:

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!

{ 1 comment }

Feeling bored and evil at an airport? Try this prank.

by Joey deVilla on August 30, 2014

power outlet sticker at jfk

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.

{ 1 comment }

Taking up Xamarin

by Joey deVilla on August 29, 2014

How I decided to take up Xamarin development

six years ago

enlightened lazinessSix 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…

gsg site

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.

xamarin 3 interface

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.

hanx writer

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.

russ fustino

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.

cat with money

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

indie-25The 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.


ios android windows phone

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

eightballforms screenshots

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 FileNewSolution…:

screen 0

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:

screen 1

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:

screen 2

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:

screen 3

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:

screen 4

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

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

screen 5

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:

screen 6

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

screen 7

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


California’s “Kill Switch” bill is now a law

by Joey deVilla on August 28, 2014

jerry brown - killswitch bill

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.

more than 3 million

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.

samsung galaxy s5 iphone 5s

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.

this article also appears in the GSG blog


US mobile rates vs UK mobile rates

mobile bills in us and uk

The New York Times has a comparison of the prices for similar mobile plans in the US and the UK. Here’s how they compare:

Feature US Carrier UK Carrier
Phone provided iPhone 5S with 16GB storage iPhone 5S with 16GB storage
Voice Minutes Unlimited Unlimited
Text Messages Unlimited Unlimited
Data 2GB / month
(with additional gigabyte during introductory period)
Commitment 2 years 2 years
Cost $90 / month, not including taxes,
plus $99.99 upfront fee.
Spread over 24 months and adding an average tax of 17%, this comes to
$109.47 / month.
 £41 / month, which includes 20% tax
($67.97 / month based on exchange rate at time of writing)

Data from the New York Times.

Not only is the UK plan cheaper by $41.50 per month (or just shy of $1000 cheaper over the two-year commitment), but it provides unlimited data. The 2GB limit has been described as being enough to stream 15 minutes of music and 10 minutes of video daily (although at least one carrier doesn’t count data from a number of music services).

Many plans feature unlimited voice and text, because that’s not where the money is these days. Regular readers of this blog already know that:

more than half is from data

We posted this graph in an earlier article, as well as in this video.
Click the graph to see it at full size.

One of the factors cited in explaining the difference is regulatory policy. In the UK, companies are legally required to lease their networks to the competition at cost; this is not the case here in the US. Without this requirement, US carriers are protected from competitors, but they’re also spared from having to compete on price. The result, according to the Open Technology Institute’s Sascha Meinrath, is that “U.S. consumers may overpay by over a quarter of a trillion dollars for worse levels of service than customers in other countries receive” over the next decade.

US/UK mobile rates vs. Australia, China, Germany, and Japan

global mobile

A couple of weeks prior to the New York Times article, TechHive posted an article titled No, U.S. smartphone costs aren’t highest in the world.

According to the article, our costs are somewhere in the middle:

Country Device Charge Monthly Fees Cost of Ownership Over 2 Years
UK $45.95 $62.79  $1553
Germany $41.06 $92.13  $2252
Japan $522.28 $73.62  $2301
China $0 $96  $2304
US (two-year contract) $200 $97  $2520
US (month-to-month) $27 – $32 / month
($648 – $768 over 2 years)
$60 – $90  $2528
Australia $0 $116  $2784

The article points out a couple of interesting things to keep in mind when comparing US rates with those in other countries:

  • The quoted cost for the UK doesn’t include roaming or international calls.
  • In Europe, you’re more likely to call another country, and will have to pay extra to cover those costs.
  • Plans in Australia factor the cost of the device into monthly fees, so you pay nothing up front for a new phone, but your monthly bill will be higher. Over 24 months, the costs of ownership in the US and Down Under are close.
  • Phones are often cheaper in the US, thanks to carrier subsidizing them.
  • “Unlimited” plans like the ones from Japan’s Au Kddi are unlimited only when calling other people on the same carrier, otherwise charges apply. Many other countries’ carriers’ plans have similar hitches.

It also points to some trends which may indicate things to come:

  • Expect to see “innovations” in the way mobile devices are financed: bundling into monthly costs, financing for prepaid devices, and options to lease or rent devices from carriers.
  • With the rate at which people trade in old phones for new ones, carriers are setting up buyback programs, which give customers some money towards their next purchase, and carriers the chance to use the devices for parts or resale.
  • Carriers have been getting creative and flexible with the plans they’ve been offering, from freeing users from contracts, to other incentives to attract new customers away from the competition.

this article also appears in the GSG blog

{ 1 comment }

Huawei, the #3 mobile phone manufacturer in the world

by Joey deVilla on August 26, 2014

huawei logo

Here in North America, a good number of people have never heard of Huawei. Many people don’t even know how to pronounce their name:

In case you were wondering, Huawei is pronounced “wah-way”.

“Huawei” is the transliteration of the Chinese name 华为, which can be interpreted as “achievement for China” or “action for China”. No matter which interpretation you prefer, both are fitting, as they’re the number three mobile phone vendor in the world in terms of market share, after Samsung and Apple:


2Q14 Shipment Volume

2Q14 Market Share

2Q13 Shipment Volume

2Q13 Market Share

2Q14/2Q13 Growth

Samsung (Android)






Apple (iOS)






Huawei (Android)






Lenovo (Android)






LG (Android)












Data from IDC’s 2Q14 Quarterly Mobile Phone Tracker.
See this article for details.

Founded in 1987 and headquartered in Shenzhen, Huawei has grown to become the world’s largest maker of telecom equipment, surpassing the former leader Ericsson in 2012. They count most telecom carriers worldwide as their customers, and the next market they plan to conquer is mobile devices.

The plan seems to be working; Huawei nearly doubled their shipments from 2Q13 to 2Q14, and analysts says that Samsung should be eyeing their rear-view mirrors very carefully. They’re more of a threat to Samsung than Apple, as they’re in the same business: selling Android devices at various price points to a price-sensitive clientele.

richard yu (yu chengdong)
The Wall Street Journal recently posted an interview with Richard Yu (Yu Chengdong), the head of Huawei’s consumer business group, in which he talked about Huawei’s foray into consumer devices, the advantages they have as a result of being a telecom equipment manufacturer, and their plans for using various operating systems in their smartphones: Android (yes), Windows Phone (on hold), and Tizen (“We feel Tizen has no chance to be successful”).

this article also appears in the GSG blog


Infographic: How today’s carriers came to be (and how one didn’t)

This recent infographic created by the folks at GigaOm shows the origins of the “Big Four” carriers, the sizes of their subscriber bases, and what might have been if Sprint and T-Mobile had merged (they would’ve been second-largest in subscribers, behind AT&T, but ahead of Verizon).

twisted tangled web of wireless

Click the infographic to see it at full size.

And the competing continues…

big 4 carriers

After months of pursuing a merger with T-Mobile, saying that they needed to team up in order to compete effectively against the giants AT&T and Verizon, they merger called off, Sprint and its parent company SoftBank called it off and are going it alone. Now that the marriage is off, the smaller half of the “Big Four” carriers are back to poaching each other’s customers.

Not only did Sprint get a new CEO, they got a new, more aggressive approach to pricing. They’ve recently introduced plans that give customers more data for the same price as similarly-priced plans offered by the competition and have even borrowed a page from T-Mobile’s book of tricks: reimbursing customers who switch for their early termination fees. Sprint have also announced a new plan featuring unlimited talk, text, and data that “$20 cheaper than T-Mobile”.

In response, T-Mobile have promised more “offers and Uncarrier moves” this week, and CEO John Legere retorted with this spicy tweet:

Here’s Bloomberg Newsweek’s take on the Sprint/T-Mobile fight:

While AT&T and Verizon may be in the more comfortable position of being content to let Sprint and T-Mobile battle it out with price cutting, they’re not completely insulated from the battle. AT&T, through their subsidiary Cricket Wireless, are taking the fight to the pre-paid market by offering a $100 credit to users who switch from T-Mobile and its pre-paid subsidiary MetroPCS to Cricket.

this article also appears in the GSG blog

{ 1 comment }