Building an Alexa Skill

I recently bought an Amazon Echo, which I absolutely love. It’s great in the kitchen as a hands-free music player, as the speaker is really good, and has replaced the slightly unreliable Siri completely for setting timers when cooking.

Obviously I wanted to develop my own Alexa skill, so I’ve built one to tell me about the latest Halesowen Town scores and fixtures information. Right now there’s almost certainly an audience of one for it, but it makes me very happy!

Here’s a video showing the exciting things it does …

Technically the easiest way to write a skill is on AWS Lambda, Amazon’s on-demand compute engine. Alexa skills can run on Lambda with minimal setup, and looks a lot easier than running code on your own server.

The Alexa Skills SDK explains pretty well how to get set up - not always a given on Amazon’s platforms in my experience - so I won’t repeat anything here that isn’t covered in detail in the documentation.

In essense, to get your skill running you have to complete the following tasks:

1. Add a list of intents you want your skill to answer
   • You can add custom content slots for known lists of names (think Enum) e.g. I have a list of teams in Halesowen’s league to match against
2. Add sample phrases which will match to each of your intents
   • The content slots are used here e.g “FixtureIntent when is the game against {Team}”
3. Point to where the skill code runs
   • Trivial to do if you are using AWS Lambda, but you can use your own https server with a bit more effort
4. Upload your skill code in your AWS Lambda functions
   • The code can be written in Python, Java or Javascript/NodeJS - I chose the latter as I prefer the easy extensibility.

The example skill code for Lambda is pretty easy to understand and adapt as necessary. Note you can either update the code directly in the browser-based Lambda console, or upload a ZIP file containing your code. The latter is much preferable if you have any node modules you want to include in your solution.

My code simply loads existing JSON data from my server used in the iPhone/Android apps for the fixtures, results and latest score, parses it appropriately based on the user’s intent, and then returns a string which the Echo reads back to the user.

The voice recognition accuracy isn’t too bad - I suspect it struggles because of the slightly obscure names of some of the teams in the Northern Premier League!

All in all, it was pretty easy to knock together something based on existing data, and it’s really cool to be able to ask Alexa what the latest Halesowen score is. I look forward to be able to do this on Siri in about 3 years time at Apple’s currently glacial pace of opening up their systems.

The code is all available on Github at https://github.com/bravelocation/yeltzland-alexa/ which hopefully makes things a little clearer if you want to dive in and take a look.

Building an iMessage app

Now that iOS10 is out I thought it was about time I built an iMessage app for Count The Days Left.

To be honest, it took very little time once I’d written a script to generate all the “progress images” I needed i.e. 100 images that show the percentage completed in the progress bar.

The UI is just a standard Storyboard + UIViewController for layout, and then hooking up an event handler to a ‘Send Message’ button (see below for details).

    @IBAction func sendMessageTouchUp(sender: AnyObject) {
        if let conversation = self.activeConversation {
            let now: NSDate = NSDate()
            let model: DaysLeftModel = DaysLeftModel()
            
             // Make a new layout object
            let layout = MSMessageTemplateLayout()

            // Set the caption on the layout
            layout.caption = model.FullDescription(now)
            
            // Set the correct image on the layout
            let percentageDone: Float = (Float(model.DaysGone(now)) * 100.0) / Float(model.DaysLength)
            let intPercentageDone: Int = Int(percentageDone)            
            let imageName = String(format: "progress%d", intPercentageDone)
            layout.image = UIImage(imageLiteral:imageName)
            
            // Make a new message and set its' layout
            let message = MSMessage()
            message.layout = layout
            
            // Insert the message into the conversation
            conversation.insertMessage(message, completionHandler: { (error: NSError?) in
                print(error)
            })
        }
    }

Other than the usual fun with making everything look OK with Storyboards and Auto Layout at the different screen sizes, it all worked out pretty well as you can see from the screenshot below:

I’m not sure how useful this will be, but it was very easy to build and I’m pleased with the result.

Getting Ready For iOS 10 Widgets

It’s summer, which means updating all the Brave Location apps for the new version of iOS.

Thankfully this year the UI changes weren’t too big, and the real work was because of how the Today widgets are changed in iOS 10.

In iOS 9, the widgets are on a dark background, so it makes sense for the text to be generally white. Here’s how my stunning well-designed widgets look in the Today section on my iPad running iOS9 …

Now in iOS 10, the widgets are much more accessible - can be accessed directly by right swiping even on the lock screen - but the design has also fundamentally changed. The background is now a light, semi-transparent color by default, on which obviously the white text of the existing widget design is basically unreadable.

Now I didn’t want to have an iOS10 only release ready, as all of my apps currently target iOS 9.0 and above and I want to keep it that way for a while.

So what I do at runtime is detect whether we are iOS 10.0 or above by the following code snippet:

let ios10AndAbove:Bool = NSProcessInfo.processInfo().isOperatingSystemAtLeastVersion( NSOperatingSystemVersion(majorVersion: 10, minorVersion: 0, patchVersion: 0) )

I can then set the background and text colors of the widgets to appropriate for iOS 10 when necessary, buy keep the “traditional” look and feel on what will soon be legacy versions.

Quite happy with the way it’s turned out, even though I say it myself.

Updates are should all be in the App Store shortly (in case anyone else is running the iOS10 beta), and for everyone else in September I assume!

Taken Down by Microsoft Lawyers

So my “Bing Translate” Chrome extension got taken down by Microsoft lawyers.

It was actually quite popular (the last number of weekly users data I have was 9924), and just did one thing pretty well - you could highlight some text in Chrome, and the extension sent it to the Bing/Microsoft translation service and translated it into English.

It was in no way pretending to come from Microsoft or Bing - despite the fact that I was actually working there when I wrote it - but I suspect an automated search by Microsoft lawyers found the word “Bing” in the title and sent a takedown request to Google, who quickly took it down.

Now I changed the title and text to make no mention of Bing, and resubmitted to the Chrome Web Store, but it didn’t pass and is still not available.

I guess I could start a new extension and maybe work around it, but to be honest I can’t be bothered starting a fight with the Microsoft lawyers.

This is a real shame - not for me as I truly don’t care especially now I hardly use Chrome - but for all those users who clearly found it useful.

I can’t find a similar extension in the store - especially any sign of an official one from Microsoft - so it’s tough for the users and Microsoft missing out on the small about of traffic they were getting to help improve their translation service.

Really glad I don’t work for a lawyer-driven company any more!

More Reliable Background Notifications

I’m really happy with the “Show the days left as a counter on the app’s badge” feature on Count The Days Left, but unfortunately due to the way Apple implements background fetches makes it a little unreliable in staying up to date.

The latest version of the app fixes this by using push notifications to regularly wake the app to update itself.

Background fetch is unreliable

The problem was that I was using the background fetch feature to run the app in the background every so often, and when it runs update the number of days left on the badge.

However, the frequency the background fetches are run is completely down to the operating system. Now as far as I understand, iOS will allocate background processing time based on how often the app is used.

Obviously this causes a bit of a logical error. If the user enables the badge to show the number of days left, they are a lot less likely to open the app - which obviously means it’s less likely to run in the background, so is more likely to be wrong :(

Push notifications solve the problem

The best way of fixing this issue is to send out regular push notifications to the app, so it’s guaranteed to wake up and refresh the badge count.

In an earlier post I wrote about how I’ve found Azure the easiest way to set up the server side of things, and I did the same here.

I then send out notification with "content_available": 1 in the payload, which will not show anything in the Notification Center to the user, but the app will wake up in the background and run the code to update the app.

Obviously this means setting up some (minimal) server infrastructure to manage this. I’ve written a NodeJS script that triggers the push notification via the Azure API, and setup a cron job to run the script every 6 hours.

So far for me this has worked a treat, and I’m much happier with the solution even though it took a bit more work.

The new version of the app (v2.0.4) is available on the App Store right now.