iOS Tutorials / Objective-C Tutorials / Basic Course

Using more UIKit components like UISlider, UISwitch or UIAlertView in your iOS app

iOS Tutorials / Objective-C Tutorials / Basic Course IMG_0605.JPG

In our first tutorial we have learned how to create and use two basic elements. A label and a button which modifies the content of the label when tapped.

In this tutorial I would like to show you how you can use other basic UIKit components like UISwitch, UISlider and give you an example use case for a UIAlertView which is a native iOS dialog box

All files will be always available in a git repository on:

Every step/milestone mentioned in the tutorial will have it’s own release here:

You should start with our files from the previous tutorial, please go to the following URL and download version 1.1 Tutorial 1 (finished project):

First we need to set a goal for ourselves so let’s say we need an app that will update our existing label with values our interface has received last. That means if we move a slider the label will show the actual value. If we flip a switch we will instantly see the change and if the switch is on or off.

We will also create a second switch which will disable our entire interface if we confirm that’s exactly what we want to do.


First if all we should get our interface ready. Go to your Main.storyboard and add a slider under our existing button and than two switches right under there, in the properties of our second switch, checked that it is “on”! I would suggest you put some labels next to each element as I have done on an Image 1 here:

Image 1

At the moment we won’t worry about layout and scaling much as we need to learn how to control the layout. I will be covering some basics of autolayout in one of the coming tutorials. For now, just layout elements on the canvas (view of your ViewController) so they fit well on your iPhone or iPad or whatever device you have.

Now that you have the visuals, we need to sort out outlets in ViewController. First of all, we should optimise the header file a bit first. In our first tutorial I have intentionally told you to put your outlet property and action method to the header file to show you how the structure works. The truth is that as we don’t need to access the property nor the action method from outside of our class (storyboard access doesn’t count as we work with same controller there) so to keep our code nice and clean we’ll move the current code to our private interface in the implementation file.

The the screenshot below shows what goes where just to be sure

Image 2

Ok, now that we have cleaned the header file, we have to add some additional outlets to our private interface. Add property for UISlider called mySlider, UISwitches mySwitch and controlsEnabledSwitch. We also have to add a property outlet for our button (UIButton), let’s call it myIncrementalButton. Now please connect properties with the storyboard elements through their outlets. The process is exactly the same as what you have done in the previous tutorial with your UILabel.

We should be now able to control all the elements on the screen through their assigned properties. That’s great but we need to get some feedback from them first.

In the Actions section of our app add three action methods:

Now we’ll have to connect our new methods to their storyboard counterparts. Last time we have been connecting an action, it was a button which needs to action upon a press. Slider and switch need to trigger an event on value change (not edit change!). In case of the slider the value is a float number, by default between 0 and 1. Switch obviously only has two states which are YES and NO (yes, I know, in Objective-C we are using these instead of true and false)

I have prepared a little catch there, now if we try to add the connections, they won’t appear in the Interface Builder. Why’s that you ask? Or you already see the problem?

The issue is that our action methods don’t contain the right return type. They are marked as void instead of IBAction. Void is perfectly fine if you making the association from code (it’s called adding a target) but if you need to link anything to the storyboard, you need to use IBOutlet or IBAction.

We should also change our buttons action method to have IBAction too since we deleted its declaration in our interface.

Image 3

So, now I assume we have all connected together, all active elements have at least one outlet or action, if not, please refer to our previous tutorial which explains all this in detail.

Now for the logic. Firstly, we will reuse what we have learned in our previous tut and will set a different message for each action that will change the text on our label.

Following code shows exactly that.

The next step in our acceptance criteria is to create a switch that will disable or enable or our controls. You have probably guessed rightly that that’s why our remaining elements, even the control ones have an outlet too.

We will be enabling/disabling them from our -didChangeControlsEnabledSwitch: method. See the code below on how this is done.

Please run your app and see how it all “clicked” together. The force is strong with you, can sense that already!

By now the app should be reporting status of all the components + you should be able to disable all the components with one switch.

All we have done so far is available here:

Alert view

Update: Please note that UIAlertView has been deprecated in iOS9, we will be publishing an updated version of this tutorial soon!

UIAlertView is a very special UIKit element. When you presenting it, you don’t have to worry about where the view is placed or how big it will be, you are not even adding it to the storyboard. The dialog box needs to be just initialised and than presented using a show method.

We will do this in a two step process. First we will only inform the user that the other interface elements have been disabled. And in the second step will use the dialog as a final confirmation of our action.

First of all, we have to create a new instance of our dialog box. When you look at the line you’ll se that in order to get our variable we need to first allocate an instance of UIAlertView so we can in the same line later instantiate with parameters. We will be passing through a string @”Confirmation” as a title and for now and either @”Controls have been enabled” or @”Controls have been disabled”. We will be also passing Ok as a title of one of our buttons.

Once we have our instance set, we can finally present it by calling method “show” on the dialog itself. iOS will take cace of the presentation and all the rest.

So now that we have a dialog window I say we take it step further and will turn our announcement into a confirmation request. To do so we will need to get some feedback from our alert view. This is done through a method called delegating.
To allow for our view controller to be acceptable as a delegate we have to make sure its interface states it is an UIAlertViewDelegate in the interface.

Once we tell Xcode that our class is a delegate to something, all the delegate methods stated in the protocol (UIAlertViewDelegate in this case) will be available to us through autocomplete.

I always put all my delegated methods to the bottom of the file for better orientation and so far I have seen most of the developers doing the same thing so I would dare to say it might be a good practice to do so. Also, do not forget your pragma marks, you’ll see in time how useful they are when you get larger files.

The delegate method receives an instance of the alert view that has triggered the method alongside an index of a button that has been pressed. The delegate needs to be set on the alert view during initialisation.

When a button is pressed a delegate method is triggered if exists. The method looks like this:

When you run the code, you should get a confirmation message as we have set to ourselves in the beginning … and yes, you an an iOS developer :)

Code optimisation

We have almost forgotten one very import thing which is internalisation (yes, that’s how we spell it here in Britain! And Yes! That’s exactly what I am talking about). In today’s world we have to think global. We have to think about all the untapped or already very thriving mobile markets around the world. Having your paid app available in French, Spanish, Portuguese, Japanese, Russian and Chinese means that you have covered most of the world languages and that your revenue and user retention could go up in a pretty steep trend.

It is really wise to make your app at least localisable as you go along with the development, I can tell you from my own experience that having to localise an existing complex app is never even a bit of fun. You can’t just search for strings as you will be using loads of these for other stuff than just an actual copy that will be presented to your users.
The best practice is to encapsulate all translatable strings in NSLocalizedString() method which will later enable you to add as many translations as you’ll like. You can also go for a system that will enable you to add localisations on the fly without having to submit your app for approval. This is really useful when you tap into a market that you originally haven’t thought of, which has a great potential but it is hard to retain any potential customers that just don’t speak any of the languages you have made available through the app.

See our modified source code here:

Please take a look at the latest production release of our app here if you have any trouble running your own (which you should not!) :)

Thank you very much for staying with me till the end. Just keep up the great work and you’ll see how iDevelopment will change your life.

Ondrej Rafaj

Ondrej is a developer, director in several startups and manages XPROGRESS just like that, just for fun!

More Posts - Website - Twitter

Categories: iOS Tutorials, Objective-C Tutorials, Basic Course
Read more:

Post a new comment