Objective-C Article

There is an interesting article at
http://www.psynixis.com/blog/2008/04/25/did-apple-make-a-mistake-choosing-objective-c-for-iphone-sdk/ about Objective-C and iPhone application development. The best part of the article is the list of responses that follow. The author is not a fan of Objective-C, but the follow-up posts make some very good points about why Objective-C was chosen and give some interesting glimpses into the history of the platform and development environment.

JK

While cleaning up my code, I realized that I had gone hog-wild with @properties and @synthesize, so I was attempting to clean up un-necessary instances of them. What I found was that I could remove them all and my code would compile and run just fine. What are the circumstances when @property and @synthesize are mandatory?

1. Never

2. Whenever the property will be set in the format of “var = [[varitype alloc] init];”

3. Whenever the property will be read in the format of “anothervar = var;”

4. Whenever the properties attributes will be directly accessed as in “var.property = 2;”

Thanks.

JK

Storing Data

Chapter 8 (Handling Data) ends with a discussion of how you can store and retrieve data in your iPhone apps, including a nice modification to the CityGuide app on pages 219-224, using SQLite. I almost got the modification working, but had problems when I made an error in my citites.sqlite file. I deleted the previous cities.sqlite from my Resources, added the new file, and still got the old data. It turns out that to really "clean" your app data, you need to remove the old version of cities.sqlite (or whatever data file you're using) from /Users/yourname/Library/Application Support/iPhone Simulator/3.1.3/Applications/bigrandomkey/Documents/. (The bigrandomkey is just an arbitrary code that the simulator uses to generate temporary directories in which to store your data.)

Typo and an Omission

A typo on page 180 (middle of the page) reads "Then make the change shown in bold to the top of MainViewController.h:" It should be MainViewController.m:

Also, on page 183-4 he has us make new helper methods for the WeatherForecast object, but they were undeclared in the WeatherForecast.h file. We added these lines in WeatherForecast.h before the @end:
-(NSString *)fetchContent:(NSArray *)nodes;
-(void)populateArray:(NSMutableArray *)array fromNodes:(NSArray *)nodes;

Email App on pages 161-165

Josiah and I ran this app on the simulator, and got no email output at all. We decided to try it on the iPhone itself, and I got a pretty little email from him that ended with "Sent from my iPhone." I think it only works from the iPhone itself because the simulator has no email address attached to it.

The Story of Mel: A Real Programmer

"When the light went on, it nearly blinded me."

(Asynchronous) Reachability

Okay, here's the full(er) story on Apple's Reachability class, which we use in the NetworkMonitor app that starts off this week's assignment (Chapter 7).

For some reason (probably a typo by a programmer at Apple), the actual name of the method that starts notification is not startNotifier, but rather startNotifer. Allan, the textbook author, uses the actual method name ( startNotifer), but in copying his code into XCode I automatically changed it to what I thought he meant (or what I thought the name should be). If you do exactly what he says, it works fine.

So, how exactly does Reachability work? It seems to work similarly to the Unix ping command: anything that can be resolved by ping comes back as reachable, and anything that cannot comes back as unreachable. So a URL like foo is unreachable: consisting of letters, it is sent by ping to the Domain Name Server (DNS), which cannot resolve it. On the other hand, a bogus numerical address like 123 appears to dodge the DNS, so ping (and the Reachability) class don't reject it, even though ping fails to retrieve any packets (test messages) back from such addresses:

~: ping www.apple.com
PING e3191.c.akamaiedge.net (96.16.93.15): 56 data bytes
64 bytes from 96.16.93.15: icmp_seq=0 ttl=53 time=8.789 ms
64 bytes from 96.16.93.15: icmp_seq=1 ttl=53 time=8.535 ms
64 bytes from 96.16.93.15: icmp_seq=2 ttl=53 time=8.526 ms
^C
--- e3191.c.akamaiedge.net ping statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 8.526/8.617/8.789/0.122 ms

~: ping foo
ping: cannot resolve foo: Unknown host

~: ping 123
PING 123 (0.0.0.123): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
^C
--- 123 ping statistics ---
3 packets transmitted, 0 packets received, 100.0% packet loss

Now, it's a bad idea to fiddle with DNS (and it requires root privilege on the server anyway), so how would one simulate a server becoming (un)reachable? That is, how can we test our asynchronous NetworkMonitor app? I'll leave this as an extra-credit riddle for you to solve.