Detecting Emoji characters in Swift

I recently had to write some code to check for the presence of Emoji characters in a UITextField in Swift. I tried a few approaches before arriving at the conclusion below. Credit to Ziewvater for helping.

Adding this code as an extension to String makes useage simple: “string”.containsEmoji()

That’s it!

 

Setting bool, int and other properties to a Parse object

Working with Parse is great. It’s quick, easy, scalable and for the most part, the documentation and community support is fantastic. I just want to share (more as a reference than anything else) a quick list detailing how to set certain property types like bool and ints to a PFObject in Objective-C. I’m also including how to set a Pointer to another PFObject, both automatically and manually. It’s really easy, but not immediately obvious the first time you have to do it. See below:

 

Declaring a block as a method parameter in Objective-C

Just a quick post as I came across an extremely helpful website dedicated to those of us who consistently need to declare Objective-C blocks in our applications. Most often, I require them when writing network operations and want to provide a callback once the operation has been completed (you could use NSOperation for this as well). Take the example below:

In the code above, we declare a callback block which takes one argument of type NSString. I think you’ll agree calling it is also quite easy.

Check this website out for more resource on objective-c block declarations.

Reading and writing NSArray into Core Data with Transformable types

Core Data is great, but coming to grips with it can be a bit of a headache for first time users. Out of the box, iOS allows you to declare model properties with a variety of types: String, Float, Date, Boolean, Int 16/32/64, but annoyingly, not arrays. Enter Transformable types.

With Transformable types, you can store anything as NSData and load it back to a format that’s useable for you. This includes, NSArrays.

This brief post assumes you already know how to get setup with Core Data, and how to create an NSManagedObject subclass of your own Entity.

Take the example below:

Above, we create a new Car entity which has an attribute named “wheels” of the Transformable type. We set this attribute to be the wheelsArray we declared earlier, and save.

How do we get this data back? All we do is initialise a new NSArray with the contents of car.wheels and we’re good to go. In a real application, we would have more code in place to perform various checks and error handling, but this should give you a good idea of what’s required:

Scrollview autolayout constraint setup in Xcode

This seems to be quite a common issue for people using the Interface Builder and AutoLayout in Xcode to manage a ScrollView. The main headache that people encounter is the Scrollview just doesn’t scroll, which is pretty useless. But the solution for this is actually pretty simple, it just takes a bit if tinkering to get it right.

Firstly, you want to put all your content inside a View and then embed that view in the Scrollview. In your inspector, the hierarchy would look like the image below:

Screen Shot 2015-12-11 at 15.29.29

The “Scroll View” here has only one child, everything else that appears in the Scroll view should be a child of this “View”.

The next thing you want to do is add constraints to the top, bottom, trailing and leading spaces on the Scrollview:

Screen Shot 2015-12-11 at 15.32.36

Now comes the interesting part, you need to set a constraint on the “View” child in Scrollview to be equal widths to the main View in your ViewController. To do this, ctrl drag from the child View to the main View, and select “Equal Widths” on the popup that appears:

Screen Shot 2015-12-11 at 15.37.18

Next, ctrl drag from the View to the ScrollView, and add constraints for top, bottom, trailing and leading as we did earlier.

If you were to run your app now, everything would appear correctly, but the ScrollView would still not scroll. This is because we need to tell the child View how high it is. This is the important bit. We do this by adding a “Bottom Space to Container” constraint on the bottom child element of the View. In the image below, our bottom element is a button called Finish:

Screen Shot 2015-12-11 at 15.41.28

In the image above, I have ctrl dragged from the button “Finish”, to the parent view, “View”, and selected the “Bottom Space to Container” constraint. Run your app now, and you should have a fully working ScrollView constructed with AutoLayout!

The important thing to remember is whatever element you have at the bottom, make sure you set a bottom constraint to the parent view. In the example above, if I were to add another button below the “Finish” button, I would have to remove the bottom constraint (to parent view) on the “Finish” button, and add a bottom constraint (to the parent view), on the new button I had just added.

Getting your app bundle version in Swift

Just a quick post, more for reference than anything else. It’s common practice nowadays as an App Developer to display the current app version somewhere in your app. Sometimes in loading screens, login screens, or in menus. It’s super easy to do this, all you need is the following code:

If your app version was 1.2.3, the above code would set the text property of a UILabel named appVersion to “v 1.2.3”.

Migrating to Swift 2

I was recently tasked with migrating an iOS codebase from Swift 1.2 to the latest Swift version, which at the time of writing is 2.1. Anyone else having to do this will no doubt, like myself, have had mixed results.

If your codebase is small, the Xcode migration tool should take care of most of it for you. However, if your codebase is more mature, you’re going to run into some issues!

Unfortunately for me, the app I was migrating fell in the “super mature” category. I still decided to run the migration tool and see how it coped – not well is the answer. It took about 20 minutes to run and the most helpful thing it did was update some Classes to new versions (e.g. Printable becomes CustomStringConvertible). It also changed some occurrences of “var” to “let”, which got rid of some of those pesky warning messages. But other than that, everything else had to done manually.

When trying to build my app, it instantly failed with hundreds of errors….

The first thing I noticed, were some new function signatures that now throw errors, a new feature of Swift. These new function signatures are basically there to say, “Hey, this function could make a boo boo, so you need to make sure you cater for this”. It’s actually quite straightforward to handle, take the example below:

If for some reason, you can guarantee a function will never fail, you can get rid of the do/catch block and simply write:

Note the difference here of “try!”, not “try”.

There was also an update to SCNetworkReacabilityFlags which means you can no longer compare it to an Int using the equality operator. Instead you now use the .contains() function to do the same thing. Where previously you would write something like:

You now achieve the same result by doing:

Excellent!

There are many more APIs that were updated, luckily for me these were the main and most frequently occurring ones I had to deal with.

Happy migrating folks.

Robert DeLong – The Long Way Down

robertDeLongGame

Over the last few weeks I’ve been working on a game in collaboration with Glassnote Records to co-inside with the release of a new track by one of their artists “Robert DeLong”. The track is called “The Long Way Down”, a electronic/pop track with a nice beat that offered quite a lot of potential in terms of visual design and gamification.

The game was done on a shoestring budget and if I’m honest, I barely broke even on it. Having said that, it was an exciting project and I wanted to get involved purely because of this. Over the years I’ve learnt that sometimes you just have to work for less (or even free), this project definitely fits that description.

We decided to create a 2D WebGL game using Unity, and although only in beta, I have to say the WebGL support provided by the guys at Unity was actually quite impressive. Yeah there are a few bugs and annoying things to get around (most of the issues I had was with audio), but that’s no different to any other game I’ve ever made.

The main challenge for the game was time. We only had 3 weeks to come up with an idea, design, illustrate, animate, program, test, fix bugs and release. It was quite a challenge and I have to say I’m really pleased with how it turned out.

The game was also picked up and premiered by MTV, so I was quite happy with that!

Play the game online here

Designing for mobile VR

Over the last few years we’ve seen an explosion in VR games for mobile devices. Game developers all over the world are slowly starting to experiment with some of the many VR options available to consumers. What’s also appealing, is the price point of some of the VR units. Some, like Google Cardboard cost as little as $30 and all you need to do is strap your mobile phone in and you’re good to go.

If you haven’t experienced VR gaming yet, it’s a truly amazing and unique experience. It can be a little strange at first, especially since positional tracking has yet to be fully integrated (i.e. you walk forward, the world you see moves with you). This doesn’t take anything away from the experience though, head tracking is remarkably accurate and extremely fun on it’s own.

Designing for mobile VR presents an entirely new set of challenges for developers. Given the current limitations on positional tracking and considerations for motion sickness, you have to be very careful when designing your environments. For example, in real life if you walked into a room that was in some way “off” you would immediately notice, even if it was very subtle. Because the VR experience is so immersive, you would likewise feel something was off in the VR world, whereas the same environment displayed on a TV would not have the same effect on the player. This can be used to your advantage if executed correctly.

The aim of this article is to highlight certain areas you should consider when designing your VR environments.

Motion sickness
Motion sickness can be a problem with mobile VR. It’s a little weird when you move your body up/down/left/right and nothing happens. Some people will find this extremely disorientating, but until positional tracking is rolled out there’s not much we can do about this.

There are things we can do to minimise the effects though. One of them is to reduce the amount of camera movement as much as possible. This spells doom for the camera shake lovers out there (I’m one of them), but the last thing you want is your players taking the headset off because they feel sick.

Performance
You also need to be concerned with the frame rate your game is running at. This is an absolute requirement and one I can’t stress enough. You should be aiming for a solid 60fps, anything less than that will ruin the experience for the player. Take into account you’re actually rendering 2 versions of the game (one for each eye), and we’re looking at 120fps. Performance is therefore an absolute requirement.

You should use occlusion culling techniques to control what is rendered in your game. I won’t go into it here, but there are plenty of resources available for this topic online.

Gestures
Unless you have a controller hooked up, the standard mobile gestures like shake, swipe, drag, and multi-finger won’t work in mobile VR. The only gesture really available to you is “tap”.

We do however have the head, and this as it turns out presents some interesting ways to control your game. You can do some pretty cool stuff using just the head, experimentation is advised here so have some fun!

Use space wisely
Moving around takes longer and is more annoying without a controller, i.e. using the click to move scheme. That doesn’t necessarily mean the environment needs to be more cluttered, it just means that the player should be able to interact with most of the elements in your world. The player will get bored fast if they spend all of their time trying to navigate, instead of actually interacting with your game.

Properly size your environments
I touched on this earlier, your brain knows what it feels like to be in a room that is architecturally correct/incorrect. It therefore helps to use existing buildings you have knowledge of as reference when designing. This isn’t as important with outside environments, but certainly it will be when designing for indoor.

UI is hard
UI in VR is hard, you should try to make it as real as possible, e.g. if it’s a document or a large piece of text, present it in a real world object, like a book. You can also embed UI into your world, on a wall, or on the floor. Having text appear and hang in front of the camera is weird and will take the player out of the game. This is bad so don’t do it!

 

There will definitely be other issues you’ll face when designing your game (as there always is with game development), but the points above should help you come up with a design that won’t leave your players feeling queasy!

Crop image in UIScrollView with Swift

I recently had a project where I had to crop a UIImageView based on it’s scale, after having been resized within a UIScrollView. The solution to this task turned out to be incredibly simple – see the code below.

Note:
imageScrollView – reference to our UIScrollView
editingImage – reference to our UIImage used to create our UIImageView which itself is a child of imageScrollView.

Happy coding 🙂