We’ve come a long way since lesson 1, and now it’s time for some final touches before laying Tutorial1.xcodeproj to rest. In a previous lesson, we learned how to write methods by appending one to our detail view controller. Given the functionality of the method, however, it’s not very clean. Let’s fix it up.

Custom Property Setters

In case you blacked out after the past few lessons, this is the method declaration we added in DetailViewController.h.

- (void)applyColor:(UIColor *)color;

However, it would make more sense to have color as a property that we can assign and retrieve at our leisure. Let’s remove the line above and instead add this line next to our @property declarations:

@property (strong, nonatomic) UIColor *color;

Now switch over to DetailViewController.m. As we discussed before, properties declared with @property need to be synthesized. Add this line next to our other synthesize operations:

@synthesize color = _color;

If you recall, synthesize generates your setter/getters for you, and the declaration to the right of the equals sign becomes a private variable that physically stores the value of the property. We’ll still be writing our own setter even though we synthesized, but at least half our work has already been taken care of. The implementation for our old method is…

- (void)applyColor:(UIColor *)color {
     self.view.backgroundColor = color;

but since it no longer exists, let’s replace it with this:

- (void)setColor:(UIColor *)newColor {
     if(self->_color != newColor) {
         self->_color = newColor;
         [self configureView];

If you attempt to write this code out yourself, the code-hinting kicks in and will complete the setter declaration for you. This goes to show that Xcode recognizes the method name as a setter, and knows that you’re writing it for the color property. Unlike AS3, where set and get are explicit keywords for defining setter/getter methods, Objective-C creates the association implicitly based on the method’s naming structure. By the way, we don’t actually need to write the getter out, since it is already synthesized, but this is what it would look like if we did:

- (UIColor *)color {
    return self->_color;

Now, let’s talk about this “self->_color” business. The synthesize operation made _color a property, but the dot syntax has been replaced with an arrow notation. “But Steve, you said dot and square-bracket notation were the two options for accessing object properties. What’s with the lies?” you might say. However, I cleverly hid a loophole back in lesson 4. As I said, “Dot notation can be used to access properties defined by @property, hence the (dot)navigationController,” but here’s the catch: _color isn’t a property defined by @property! For these such occasions, arrow notation is the way.

With the logic we added, “configureView” gets called whenever a new color is passed to the setter. It’s good practice to consolidate component configuration, to ensure the state is properly updated. Like in Flex, views in UIKit follow an asynchronous lifecycle, therefore its possible to produce unexpected bugs if calls are made out-of-turn. Now, to update configureView:

- (void)configureView {
     // Update the user interface for the background color.
     if(self.color) {
         self.view.backgroundColor = self.color;
     // Update the user interface for the detail item.
     if(self.detailItem) {
         self.detailDescriptionLabel.text = [self.detailItem description];

Finally, we need to change the way our master class sets detail’s color. Open MasterViewController.m, and scroll down to the code at the bottom. There should be a glaring error icon at this line:

[self.detailViewController applyColor:color];

Let’s change it to this:

self.detailViewController.color = color;

That should do it! Doesn’t it feel so much cleaner now?

Making Our App Universal

Right now our app is only for iPhone, but what if we decided at a later point that we needed an iPad version? Luckily, this process is very painless. To begin, select the Tutorial1 project file at the top of the Project Navigator. You should see a state in the main view unlike both the code and Interface Builder states.

The Project Editor

This new state is the Project Editor. Here is where you can configure the project settings. There’s a lot of stuff happening in here, but we’re mainly concerned about the Devices drop-down under iOS Application Target section of Summary. Select the drop-down and change its value to Universal. Now, in the scheme drop-down in the top left corner of the Xcode window, you should see an option to run the iPad simulator. Select it, then press Run.

Well, at least it looks better than some of the apps I’ve downloaded. We’re Flex developers, though, and we have standards. So, what went wrong? Unfortunately, when we set up our button component, we didn’t account for liquid layout. To fix this, we need to go into the IB. Select DetailViewController.xib, and make sure the Utilities panel is enabled. In the upper section of the panel, select the Size Inspector tab.

The Size Inspector

Select the button component to observe its settings in the inspector. Roll over the example window to see how the component behaves in different sizes. Autosizing is the culprit here. Let’s take a look at what the autosizing indicators mean and their different configurations:

  • Edge constraints maintain a constant distance between the component and its corresponding view edge.
  • Disabled edge constraints allow the component to maintain a proportional distance from the edges of the view.
  • Resize arrows allow the component to scale horizontally and/or vertically.
  • Combining edge constraints with resize arrows allow the component to scale such that its opposite edges maintain a constant distance from the edges of the view.

Let’s say we want our button to maintain a vertical position to the label and the rest of the view, but stretch horizontally to fill the dead space to the left and right of it. In such a case, our autosizing indicators should look like this:

Set yours to look like the image above, and run the simulation again. The button should now be in the correct place and stretched accordingly.

Let's just pretend this looks awesome, OK?

That’s it for Tutorial1! In the next few lessons, we’ll be focusing on specifics between Flex and Objective-C.

Tagged with:

One Response to Flex to Objective-C: 7-Tutorial1 Touchups

  1. [...] “tech” via Pdemo in Google Reader This entry was posted in iPad and tagged 7Tutorial1, Flex, ObjectiveC, Touchups by iPad Developer. Bookmark the permalink. [...]

Leave a Reply

Your email address will not be published. Required fields are marked *


You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre lang="" line="" escaped="" highlight="">

Set your Twitter account name in your settings to use the TwitterBar Section.