Learning iOS Development: A Hands-on Guide to the Fundamentals of iOS Programming (2014)

---

The method viewWillAppear: is called each time this ViewController’s view is about to be displayed on the screen. It is a convenient location to create and call your Car object. Here’s what happens in the numbered lines in Listing 2-8:

1. The myCar object is allocated and initialized as an instance of the Car class.

2. The printCarInfo method is called, but because make and model are nil (uninitialized), it will print the car undefined message. If you look back at Listing 2-7, inside the printCarInfo method, you can see the if statement which checks that make and model are not niland the resulting message when they are.

3. The make, model, year, and fuelAmount are set. The NSString values are prefixed with the @ character before the double quote, and the float value has a trailing f.

4. The printCarInfo method is called a second time, and this time make and model are set so the information for the Ford will print.

5. A new car is created using the custom initializer to set values.

6. Unlike the call to printCarInfo after the plain init in step 2, this call prints out the Honda’s details as both make and model are defined.

When you run the code you will see something like the following in the console:

2013-07-02 08:35:44.267 CarValet[3820:a0b] Car undefined: no make or model specified.
2013-07-02 08:35:44.269 CarValet[3820:a0b] Car Make: Ford
2013-07-02 08:35:44.269 CarValet[3820:a0b] Car Model: Escape
2013-07-02 08:35:44.270 CarValet[3820:a0b] Car Year: 2014
2013-07-02 08:35:44.270 CarValet[3820:a0b] Number of Gallons in Tank: 10.00
2013-07-02 08:35:44.270 CarValet[3820:a0b] Car Make: Honda
2013-07-02 08:35:44.271 CarValet[3820:a0b] Car Model: Accord
2013-07-02 08:35:44.271 CarValet[3820:a0b] Car Year: 2010
2013-07-02 08:35:44.272 CarValet[3820:a0b] Number of Gallons in Tank: 12.50

Properties: Two More Features

The current version of CarValet is all you need for the next chapter. This section covers two different variations of the project. Each variation comes with the sample code for this chapter.

Some of you might be wondering if it is a good idea to change the make, model, and year of a car after it has been created. So far, you have been using properties in their default read and write configuration. However, it is easy to set a property to read only. All you have to do is add a little extra when declaring a property. The general form of the property declaration is the following:

@property <(qualifier1, qualifier2, ...)> <type> <property_name>;

You have already used the type and property_name. The make of a car has a type of NSString* and a property_name of make. Qualifiers let you change a number of things including setting a property as read only, specifying different levels of object ownership for memory management, and even changing the name of the default setters and getters. Another qualifier is covered later in this chapter.

If you do not specify qualifiers, the property is created with defaults: read and write, owned by the object declaring the property, and default setter and getter names. If you want a different behavior, all you need to do is change the defaults.

Creating read-only properties is as simple as including the readonly qualifier. Setting make, model, and year to read only is done by changing their declarations in the .h file:

@property (readonly) int year;
@property (readonly) NSString *make;
@property (readonly) NSString *model;

Do this and try to build the project. You get three errors in the ViewController.m file that you are trying to set the value of read-only properties. Fix the errors by removing or commenting out the code in ViewController.m and setting read-only values.

But say you wanted the properties to be read only outside the class, but read/write inside. That is also easy as you can re-declare property inside the .m file. You add or override class interface declarations by adding the following code to the Car.m file just before the @implementationstatement:

@interface Car ()
@property (readwrite) int year;
@property NSString *make;
@property NSString *model;
@end

A car object uses the new definitions of the instance variables. Note that you do not need to specify readwrite as that is the default.

To see this working, add a method to update the make attribute by following these steps:

1. Open Car.h and add the following method declaration below printCarInfo:

- (void)shoutMake;

2. Open Car.m and add this method just below printCarInfo:

- (void)shoutMake {
self.make = [self.make uppercaseString];
}

3. Open ViewController.m and remove the calls to create and print the first myCar object.

4. Add a call to shoutMake and another to printCarInfo to the end of viewWillAppear:. The end will now look like (new code in bold):

...
fuelAmount:12.5f];
[otherCar printCarInfo];

[otherCar shoutMake];
[otherCar printCarInfo];
}

When you run the code, the last call to printCarInfo shows the car make in all caps. You can convince yourself everything works as expected by trying to set the make of a myCar in viewWillAppear:. You get an error that you are trying to set the value of a read-only value.

Custom Getters and Setters

In another variation, sometimes you do not want the default getters and setters generated by the compiler. As an example, suppose you want self.fuelAmount to return liters instead of gallons, but only if a new property, showLiters, is YES. You also want to access this new property using isShowingLiters.

It only takes one line in Car.h to add the property. Add the following code below the existing properties:

@property (getter = isShowingLiters) BOOL showLiters;

The qualifier sets a different name for the getter. Instead of using aCar.showLiters to check the value of the variable, you use aCar.isShowingLiters, a more descriptive name. Setting the value still uses aCar.showLiters:

if (aCar.isShowingLiters) {
aCar.showLiters = NO;
}

Similarly, you can change the name of the setter like this:

@property (setter = setTheFuelAmountTo:) float fuelAmount;

However, a custom setter behaves a bit differently than a custom getter. You need to send a message to use the custom setter. This works:

[aCar setTheFuelAmountTo:20.0f];

but this does not:

aCar.setTheFuelAmountTo = 20.f;

Atomic and Nonatomic

With the new property defined, it is time to override the getter for fuelAmount. Add this code to the end of Car.m, just below printCarInfo:

- (float)fuelAmount {
if (self.isShowingLiters) {
return (_fuelAmount * 3.7854) ;
}
return _fuelAmount;
}

This custom getter returns liters instead of gallons if isShowingLiters is YES. (Of course, the formula only works for U.S. gallons, not U.K. ones, but world harmony of measurement standards is beyond the scope of this book.) Note this is another case where you must use the underscore version of the instance variable to avoid an infinite loop. See the sidebar, “Why Use Underscore: No Dot, No Accessor.”

After you add that method, you will notice a yellow warning triangle noting something about a “writable atomic property....” A what? In this case, the warning is quite correct. Another property qualifier is the atomicity of the variable. That is, can there be only one object accessing the variable at any one time (atomic or synchronous access), or can multiple objects on different threads access the object at the same time (nonatomic or asynchronous access)?

When you develop in a multithreaded environment, you can use the atomic property to make sure assignment works as expected. When you set an object as atomic, the compiler adds code to automatically lock objects before they are accessed or modified and unlock them after. This ensures that setting or retrieving an object’s value is performed fully, regardless of concurrent threads. However, it is also incredibly expensive and runs the danger of an infinite wait for unlock.

All properties are atomic by default; however, you can use the nonatomic property qualifier, a generally far safer and more performant alternative:

@property (nonatomic) NSString *make;

Marking your properties nonatomic does speed up access, but you might run into problems if two competing threads attempt to modify the same property at once. Atomic properties, with their lock/unlock behavior, ensure that an object update completes from start to finish before that property is released to a subsequent read or change, but they should be used only where required.

Some argue that accessors are not usually the best place for locks and cannot ensure thread safety. An object might be set to an invalid state, even with all atomic properties.

In practice, most properties are marked as nonatomic and other mechanisms are used to deal with possible issues of thread-safe access. For a deeper discussion, see the chapter on properties in Learning Objective C 2.0, second edition, by Robert Clair.

Get rid of the error by changing the declaration of the fuelAmount property in Car.h (and while you are there, you can add the nonatomic qualifier to all your properties, including showLiters):

@property (nonatomic) float fuelAmount;

Now you need to test that the change works. Once again, you only need to add a couple of lines to the end of viewWillAppear: in ViewController.m:

otherCar.showLiters = YES;
[otherCar printCarInfo];

When you run the code, you will see a Honda with 12.50 gallons in the tank and then printed again with 47.32 gallons. Gallons!? But that is the subject of Challenge 3 at the end of the chapter.

Subclassing and Inheritance: A Challenge

While gas and diesel cars continue to improve their use of fuel, your customers are demanding that you model a hybrid car. Your job is to create a HybridCar class that inherits from Car and adds a method to return the number of miles until the car’s battery and fuel are empty. You can name this method –(float)milesUntilEmpty.