Pig on a Hill Productions

I first started writing this article before WWDC 2016, then I stopped. For starters watchOS 3 was announced and I wondered if a lot of my initial points would be resolved by the speed increase it sounded like we’d get there. And then I just got busy and didn’t manage to update my post. Such is life. But we’ve had watchOS 3 for a while now, and we’ve gotten the new Apple Watches, Series 1 & 2, with the improved S2 SoC. While we did get the speed increases from watchOS 3 we were promised (in the new and old hardware) looking back, I think a lot of my points still stand. So here we go, take 2 of this post.

So let’s face it watchOS 1 & 2 were a good start for the platform, but they were way too slow. watchOS 1 had limitations due to the fact that the main part of each Watch app was still running on our iPhones, and where watchOS 2 fixed that point the limitations that Apple had in the OS on the amount of available memory and resources was too stringent ¹. With watchOS 3, Apple fixed that though, with the addition of the dock and keeping more apps in memory, apps became a LOT more responsive when opening (if they’re in your dock), but in my mind they’re still not fast enough.

Apple have said to developers since the watch first came out, interaction on the watch should be kept to a minimum. So much so as to be only a few seconds ². In that respect, opening an app and waiting for it to update is still too slow. I know with watchOS 3, the majority of that lies on the shoulders of us developers ³, but it still stands that it’s still too slow for the types of interactions we generally have with the watch. That is to say, trying to have an interaction with an app, like it’s an app on our iPhone or iPad.

Where I feel the Apple Watch excels is in passive activities. When I say passive activities, I mean things that the watch just does, without input from the user. In my mind such activities range from counting steps and taking heart rate readings over the course of the day to receiving notifications and viewing complications on the Watch face.

Puck 3.0 is finally here!

It’s taken a while now of me messing around and technologies I was going to use changing, but I finally managed to finish and release Puck 3.0 for the SHL 2016/2017 season.

So, what’s new? Well I did a major redesign of the app around a year ago. It brings Puck more inline with how iOS looks generally these days. A little bit cleaner and more direct to get the content to you. Secondly, there’s now video highlights in the app! You can now view video highlights for games, right from the app, or you can stream these to your AppleTV.

There’s also been a few other little changes, like being able to see the SHL arena website for a game that is currently live or has been played, allowing you to see play by plays right from the app. There is also now an app for you AppleWatch owners out there that allows you to see live games, standings and news summaries.

All in all I’m very pleased with this new update and looking forward for people to get hold of it.

Puck 3.0 is a free update to all existing users, and can be downloaded here: https://itunes.apple.com/se/app/puck/id571254467

I’ve got some ideas for extra features going forward, but if you have any suggestions, please let me know at james@pigonahill.com.

Click below for screen shots of Puck 3.0!

So over the last few weeks I’ve been on a bit of holiday. Some time away from work is always nice, some time to relax, and yet, I continue coding. 😛

However, I finally got myself an Apple Watch, as I managed to get my hands on one when I was over in the UK (I wanted to see what the colours really looked like) and they also came out in Sweden. So obviously I’ve been trying to make watch apps for my apps, namely Puck and Dog Bins. I thought it might be useful to post some of my findings from playing around with WatchKit in watchOS 1.

So I’ve been quiet for a little while about my own apps. I keep getting back to them every now and again, but the main thing is that simply, I just haven’t had the time. Let’s face it, none of my apps are “big” apps. They don’t make me any money that I could live off of, maybe enough for my developer licence and a beer.

Though that doesn’t matter to me. I don’t make my apps to make loads of money (however that wouldn’t be something I’d be against 😉). I make my apps to satisfy needed I have that I can’t find some other existing app to fill that need, and mainly, I make my apps to learn new things. Going though my current apps on the store:

• Pixel Pals was made for my dissertation at University.
• Colour Cubes was made in about a week after seeing a very basic version of a similar game on my mates BlackBerry, and I wanted to see if I could remake it myself.
• Dog Bins was made when my step-mum suggested it would be a good idea for the app, and I took it as a change to learn how to make an app with cloud feature, so I made it using Parse for the backend.
• Puck was made because when I moved to Sweden, I got into Ice Hockey, and I wasn’t amazingly impressed by the apps available at the time, so I made my own. It also gave me the chance to learn Python and setup my server, along with push notifications and all that fun stuff.

PRE-POST NOTE: The origins of this post really starts in another post. I was having issues with Apache and my Wordpress setup, and those issues made me move to Nginx and then to using a static site generator. To read more of those details that got me to this point, read here: Apache Woes, Hello Nginx!

I have been using Wordpress since I started my site, I think it must have been back in 2010-2011, and it’s done all I’ve wanted it to do, and more. But it’s always felt too much than I needed. I’ve tried to dive into making my own themes a couple of times, but swiftly given up, just because the amount of stuff there was, it overwhelmed me. So after the problems I was having with my server (see pre-post note), I decided to move to a static site.

What is a static site? Static site generators are programs that take templates and content you make and render the content into separate, compiled files. This means, unlike a dynamic site, the content is already created and ready to serve to the requesting web browser, unlike a dynamic site, like Wordpress, that renders the content and creates the web page (in Wordpress’ case using PHP) when and every time it is requested (though obviously facing systems can and are used, but still).

A couple of weeks ago I started getting emails from Jetpack¹ telling me that my Wordpress blog was down. I was too busy at the time, but I came back to look into it around a week later. I was amazed to see that what the issue was that MySQL wasn’t running on my server. It took a while to work out what was wrong, but the long and short of it is I ran out of memory.

Now my server isn’t the most powerful one out there. It’s a 2GB Linode VPS² but that should be more than powerful enough to run a simple Wordpress site. A deeper look into it showed me that Apache was using 1.99GB/2.0GB! So there’s the culprit.

Optionals are something that I had never heard of before Swift came out. I have coded in quite a few languages, but as far as I’m aware, I hadn’t come across this thing. But it seems to be everywhere in Swift, so what is it? It took me a little while to sit down and work that out, but I now feel like I’ve wrapped my head around it.

nil is something I use on a daily basis, but it’s not the same in Swift. It looks like it is, but under the hood, it really isn’t. Below I’m going to talk about how Swift deals with optionals, this new way of thinking of nil and why I’ve come to realise and really love this new way of looking at things.

There are some awesome things happening when you look at Swift as a basic language. Swift is not another language built off of C, it’s a brand new language. This means that there are no performance or historical drawbacks to Swift, as it doesn’t rely on an underling langue.

let name = "James"
var greeting = "Hello "
greeting += name
println("\(greeting)")
>> Hello James

So in this simple code snippet you can instantly see some differences compared to the normal Obj-C code you might be used to. For starters their aren’t any semicolons ;. You just don’t need semicolons in Swift. You can use them if you want, but they’re not required (unless in specific circumstances).

On Monday of this week Apple introduced the world to Swift. The new programming language to, eventually, replace Objective-C. There’s a lot of major improvements that Swift brings and I will never be able to go through everything, but I’m going to try to go though the “main” points or just as much, the points that excite me the most. If there’s anything that I’ve missed that you won’t to hear about, post it in the comments and I’ll try to look into it.

Swift has made me very excited. It’s the most excited I’ve got about coding since I first started learning Obj-C. It’s a language that seems to make an awful lot of sense when you look though it. It is a language that in its simplest form can be very easy to learn. However it can be harder for beginners to coding when you get to some of the more advanced topics, a lot sooner than, say, Obj-C would.

With that in mind, the majority of what I’m going to write about will assume that you have some previous coding knowledge, mainly in Obj-C. If you’re a complete beginner, some guides for you will be coming out by someone (I might try some myself) when Swift comes out properly later this year.

Dog Bins 2.0 is here!

So it’s been a long time coming but I finally made some time out of my work hours a couple of weeks ago to blast through the final bits I had to do with updating Dog Bins. This morning it got passed through the review process with Apple and is currently being “processed for the App Store”. So hopefully by the time you read this, you’ll be able to update, if you iOS 7 device hasn’t automatically done it for you that is.

Dog Bins 2.0 is totally rebuilt, pretty much from the ground up. DB was my first app that felt with external sources for getting and saving information. So it had quite a few rookie errors in it. They’re the type of things you don’t realise you did something badly until you’ve gone away, learnt how to actually done it, come back and look at you old code and cringe. It happens a lot in the computing world, mainly due to the fact you are constantly learning something new as people are constantly creating new things and ways of doing these things.