The view controllers of your application coordinate between your data and what is actually displayed on screen. In a well written MVC application the view controllers will be where much of your essential app logic lives and in turn where you will spend a lot of time. UIKit supplies many built-in view controllers and view controllers of view controllers such as UITabBarController or UINavigationController. With these you can accomplish an amazing amount of tasks, but sometimes you need or want something a bit more custom! This article will discuss a few helpful techniques for developing and working with custom view controllers.
Working with Xcode can sometimes be a frustrating experience…
However, Xcode has a few times saving features that really make a difference in day to day development. In this post we are going to break from the traditional format in order to examine a few of these features.
Xcode snippets have gotten a bad wrap since they were introduced. This is mostly because they seem to lack some obvious features and are poorly documented. However, this doesn’t stop them from being an immensely powerful addition to Xcode. So let’s dive into using existing snippets and creating new ones.
- You’re familiar with UIAlertView.
- You have good understanding of the delegate pattern.
- You have at least heard of Blocks in Objective-C.
Have you ever found yourself wanting to present an alertView to the user to get simple yes or no feedback? If you’re anything like me you were very annoyed that you were required to implement the UIAlertView delegate protocol just to handle this simple task.
Is There A Better Way?
This recipe will demonstrate how to use CAGradientLayer to add gradients to a custom UIView.
- You should have basic knowledge of UIView and Core Animation, specifically CALayer.
- Basic knowledge of autolayout usage in interface builder.
Setting Up A Sample Application
- Create a new Single View Application in Xcode named GradientViewDemo. Make sure to check Use Automatic Reference Counting and uncheck Use Storyboards. Our demo app will also be iPhone only to keep things simple, but go ahead make a universal app if you like (everything we will do is applicable on both iPhone and iPad),
- Create a new UIView subclass named NSCBGradientView. We added the NSCB class prefix, because this may be a valuable component to reuse in future projects and the prefix will help avoid name clashing.
- Next, we need to add QuartzCore to the target. Do so by selecting the project file in the source list on the left, then ensure the GradientViewDemo target has been selected, select the Build Phases tab from the tab bar at the top, expand the Link Binary with Libraries, and finally click the + button in the lower left corner. Search for QuartzCore, and then add it to the target.
This Recipe will cover using GHUnit to unit test the Weather Application we developed in Recipe 15: Building A Weather Application. GHUnit is an open source unit testing framework for Mac and iOS that (in my opinion) has capabilities superior to the unit testing capabilities built into Xcode. Many developers have there own philosophy on unit testing and this Recipe will not attempt to define another. We will not be defining unit testing best practices or even go into detail about writing particular tests. This Recipe is purely about getting started with GHUnit and how it can be used in the context of a real application. Oh and did I mention? GHUnit makes writing asynchronous unit tests a breeze!
- This recipe uses the Weather Application created in Recipe 15: Building A Weather Application, it is highly recommended that you work through or at least familiarize yourself with that recipe before continuing on to this one.
- Source code for the weather app can be downloaded via GitHub. The revision of the Weather App after Recipe 15 has been tagged recipe-15, make sure to start there.
- This recipe also relies heavily on CocoaPods, it is recommended you watch NSScreencast’s video tutorial if you are not familiar with CocoaPods.
Download The Starting Application
- First download the source code for our starting application, which happens to be the Weather App developed in Recipe 15.
- Refer to Recipe 15 for details on setting up a Weather Underground developer account in order to obtain a personal API key. You will need this key in order to access Weather Underground’s services.
- The Weather App was built using CocoaPods, so after getting the source code you will need to navigate to the project root directory (where the .xcodeproj file lives) and run the following command in terminal. Note this will not work if you have not yet installed CocoaPods, learn about doing so here.
1 $ pod install
- This will add all of the necessary external dependencies the Weather App needs. It will also create an .xcworkspace file which you will need to open when accessing this project (not the .xcodeproj file).
- Add your person API key for Weather Underground to WeatherAPIKey.h, then build & run the application. If everything has been done right you should now have a functioning weather application!
In Part I of this recipe we left off with a UITableView that Displayed some creatures which were grouped by type. In this Recipe we’ll be extending the functionality a bit and emplement a delegate in order to handle a touch event. In addition, we’ll take a minute to explore styling of the table view and cells.
- You Have already read through Part I, if not read through that first.
Styling The Table View
The next two sections will be brief, but I thought it was worth visiting since there are a few things that can be done right from the property inspector.
First of choose the tableview object from the storyboard and go to the property inspector tab on the top right hand pane. Choose Grouped from style section and go ahead and change default to some color, I change mine to blue.
In most apps you’re sure to find a table view whenever a list of items needs to be presented. UITableView, similar to UIPickerView, declares both a data source and delegate protocol. The data source protocol is required while the delegate is optional. We’ll need to make use of the data source protocol for the UITableView class. For this recipe I chose to show a table view with bugs and animals shown. The bugs and animals will have seperate sections.
- You are familiar with Xcode, if not familiarize yourself here.
Setting Up the View
First start with a single view controller project. Now drag a UITableView object onto the existing view from the object library and then drag a UITableViewCell onto the newly created table view. When you’re done you should have something that looks like this:
In my last article I left off on the UIPickerView with some basic functionality. This week I want to expand on that functonality and show a few other bits of functionality that can be used. What we did in Recipe 7 was show a picker with a single column. In this article I want to expand on that and show how to use two columns: The second column will change the alpha value for our color.
- You Have already checked out Recipe 7 and gone through that example, If not head over there here: http://nscookbook.com/2013/01/ios-programming-recipe-7-using-the-uipickerview/
Reworking the Data Source
Alright, let’s get into this! The first thing we’ll want to do is edit these two methods:
// returns the number of 'columns' to display.
- (NSInteger)numberOfComponentsInPickerView:(UIPickerView *)pickerView
- (NSInteger)pickerView:(UIPickerView *)pickerView numberOfRowsInComponent:(NSInteger)component
//set number of rows
return [self.colorArray count];
The first data source method should be obvious! We’ll simply change the return value from 1 to 2 this sets it to two columns (components). The second data source method requires a bit more work, Although it’s not too much. The second method just sets up a return value based on which column was selected.
Everyone wants to make their app look unique! Well the UIAppearance protocol can help you! In iOS 5.0 Apple introduced the UIAppearance proxy API which allows you the developer to customize many of the appearance aspects of UIKit elements. I know what you’re thinking… Can’t I already do that? Well sure, but not on the same scale as UIAppearance will allow, and furthermore, changing the appearance of UI components on a per object basis gets really old, really fast.
So let’s dive into an example right quick…
Say you have an app with a UINavigationBar and you want something other than the default background color (tint color). You would probably try something similar to the following
Then you decide another part of your app needs a navigation bar and you end up writing the same code to change the background color for that one as well. This continues as time goes on and before long you end up with an unmanageable mess, leaving you sad and depressed wishing there was a better way… enter UIAppearance…