One such change came out of their trying to adhere to their own naming conventions of methods. The second kind of late polishing is if there are new structures introduced without a matching Make macro for easy filling of said structures. I have an example for you, also in CoreLocation.

In this post I’m exploring two such changes and tell you how I dealt with them in a backwards compatible way.

A New Make Function

CoreLocation has a structure CLLocationCoordinate2D which contains latitude and longitude in decimal degrees of any coordinate on Earth. Before 4.0 was introduced I figured that it would be handy to have a CLLocationCoordinate2DMake to go with it, just like you have CGRectMake to create and fill a CGRect.

Turns out, Apple thought so too, and because I guessed the naming convention correctly they introduced this exact method in 4.0 causing my Xcode to complain like this, if I expanded the build results.

In file included from ../DTFloatingIconView.m:9:
../DTFloatingIconView.h:42: error: static declaration of 'CLLocationCoordinate2DMake' follows non-static declaration
/Developer_Stable/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS4.0.sdk/System/Library/Frameworks/CoreLocation.framework/Headers/CLLocation.h:125: error: previous declaration of 'CLLocationCoordinate2DMake' was here

In the code itself you could only see the first line, but the enlightening detail is found right underneath it. There’s obvious now a “previous declaration” of my helper function. It’s previous to my definition, because it’s in a header and headers precede your code always. And indeed if we have a look at CLLocation.h, there it is. Clearly marked as not available on Mac and available on iOS as of 4.0:

/*
 *  CLLocationCoordinate2DMake:
 *
 *  Discussion:
 *    Returns a new CLLocationCoordinate2D at the given latitude and longitude
 */
CLLocationCoordinate2D CLLocationCoordinate2DMake(CLLocationDegrees latitude, CLLocationDegrees longitude) __OSX_AVAILABLE_STARTING(__MAC_NA,__IPHONE_4_0);

The question in this case was how I could modify my definition such that I could build with 4.0, targeting 3.0 and above and get no warnings, errors or crashes. Here’s how:

#if __IPHONE_OS_VERSION_MAX_ALLOWED < __IPHONE_4_0
// this method was introduced in SDK 4.0
static inline CLLocationCoordinate2D CLLocationCoordinate2DMake(CLLocationDegrees latitude, CLLocationDegrees longitude)
{ 
	CLLocationCoordinate2D coord;
	coord.latitude = latitude;
	coord.longitude = longitude;
	return coord;
}
#endif

By using the preprocessor macro __IPHONE_OS_VERSION_MAX_ALLOWED I can check the used SDK version and if it is below 4.0 I define it. Marking it as static inline means that this is built into the binary not as function call, but this code is actually inserted into the calling method as if it were local code.

This way I have a function to satisfy the compiler regardless whether I’m building with SDK 3.x or 4.x. The reason for doing so is that I’m using this in DTAugmentedRealityController where I don’t want to force my customers to build with a specific SDK. So that’s how I implemented it in version 1.1 of the component.

BUT, thinking about it, there’s a problem when building this code with SDK 4.0 which happily compiles it and omits the new function. But what happens if this runs on a 3.x device? A crash with an unrecognized selector. In debugger you’d get something like this:

dyld: lazy symbol binding failed: Symbol not found: _CLLocationCoordinate2DMake
  Referenced from: /var/mobile/Applications/0E8F890C-F78A-4092-99A5-9466AF298D60/test.app/test
  Expected in: /System/Library/Frameworks/CoreLocation.framework/CoreLocation

So how do we make it backwards compatible?

The easiest way I could think of is somewhat brutal, because it involves basically redirecting all calls to my own function. But looking on the bright side, by making it an inline function we actually gain a few nanoseconds by not having to have the function call overhead.

static inline CLLocationCoordinate2D CLLocationCoordinate2DInlineMake(CLLocationDegrees latitude, CLLocationDegrees longitude)
{ 
	CLLocationCoordinate2D coord;
	coord.latitude = latitude;
	coord.longitude = longitude;
	return coord;
}
 
#define CLLocationCoordinate2DMake CLLocationCoordinate2DInlineMake

This replaces all CLLocationCoordinate2DMake in your code with CLLocationCoordinate2DInlineMake which is an inline function we define regardless of the used SDK or running OS.

It’s a nasty workaround, but at least it does not cause a crash. And we can keep on using the CLLocationCoordinate2DMake function name. That’s some consolidation until we can drop 3.x support later this year.

Renamed Function

In 3.2 the method of CLLocation getDistanceFrom got renamed to distanceFromLocation. You might wonder why. Simple explanation really, Apple reserves the prefix get for methods that are using one or more of their parameters to return a value in addition to the regular return value. This is generally achieved by passing a pointer (= memory address) to the method which the method then can follow and modify the referenced piece of RAM.

Consider for example the method – (void)getValue:(void *)buffer of NSValue where the value of NSValue will be copied into the memory pointed to by “buffer”. There are very few such methods on the higher level APIs. Many more can be found on the Core Foundation level.

The naming convention seems to go that the first part of the method name tells you what is being returned, namely a distance and the last part before the first colon should tell what this parameter actually is. A name that at the same time tells it’s function. So they could have called it distanceThatWillBeCalculatedByAVeryComplicatedFormulaAndSoWeNeedASecondParameterThatIsALocation:, as long as the first and the last item in this camel-cased name. The second rule though is to non unnecessarily prolong method names if it’s possible to get by with 3 or 4 words. A distance from a location, distanceFromLocation. A sorted array by using a selector, sortedArrayUsingSelector.

There are a few such methods in the SDKs that snuck in under the radar of the Naming Convention Adherence Subcommittee at Apple HQ, so they chose to make the switch when introducing 3.2 because at this time that was the first iOS version running on the iPad and thus this change would not cause any problems there. I betcha there was somebody having sleepless nights over this until 3.2 was released in the form of the iPad. Now he can rest in peace.

But to bring balance to the force, somebody being able to rest means that somebody has extra work, we.  Because if we want to keep our code working and warning-free then we have to work around this change.

Since we will be using the latest SDK version for building the new method is valid and the old one is causing a deprecation warning. BUT because we want this code to work on previous iOS versions we cannot exclusively use the distanceFromLocation method, because this would cause an “unrecognized selector” exception (read “crash”) if somebody is running our app on iOS 3.1.x.

Usually you can work around this by using performSelector after having checked that the instance of the receiver responds to it. But in this case there’s a problem: we have a return value that we need to get hold of. I found some workarounds on the Internet that would hack and typecast around. But these methods upset my stomach, so I chose to go for the following method.

- (CLLocationDistance)distanceBetweenLocation:(CLLocation *)location1 andLocation:(CLLocation *)location2
{
	if ([location1 respondsToSelector:@selector(distanceFromLocation:)])
	{
		return [location1 distanceFromLocation:location2];
	}
 
	SEL sel = @selector(getDistanceFrom:);
	if ([location1 respondsToSelector:sel])
	{
		NSMethodSignature *mySignature = [CLLocation instanceMethodSignatureForSelector:sel];
		NSInvocation *myInvocation = [NSInvocation invocationWithMethodSignature:mySignature];
		[myInvocation setArgument:&location2 atIndex:2];
		[myInvocation setTarget:location1];
		[myInvocation setSelector:sel];
		[myInvocation invoke];
 
		CLLocationDistance distance;
		[myInvocation getReturnValue:&distance];
 
		return distance;
	}
 
	// should never get here
	return 0;
}

Of course this could have been made as a category extension, but I chose not to because I didn’t want to have to name it distanceBackwardsCompatibleWith3xFromLocation. Reason being, that if you name a category extension method the same as an existing one you overwrite it and there’s no way (similar to super) to call the original method.

Let me explain the above code.

First location1 is asked if it knows distanceFromLocation, if YES, then this is called and we’re done.
Then I’m creating a variable of type SEL to hold the signature (read “selector”) of the pre 3.2 method.
At this point I could assume that this has to be present here, but just to be safe I’m asking again.
Then I’m building an NSInvocation for this signature and setting as target location1.
I’m executing the method by calling invoke.
Then I’m creating a local variable which essentially prompts the compiler to reserve sufficient memory for it.
Finally I’m retrieving the return value of the invocation.

Do you remember what I said about methods prefixed with “get”? That’s another example: it takes a pointer (which we get by the address operator &) to point to the memory it is allowed to modify. Of course it’s your responsibility to have sufficient memory space allocated. We know that this method will return a CLLocationDistance (which is really just a double) I can take the above shown shortcut. Otherwise I’d have to inquire about the size of the return value. Possible, but unnecessary if you know the type.

Conclusion

Regardless if it’s a new convenience function/method or a renaming, as a developer you have to start thinking on several levels at the same time:

1) which methods and functions does my building SDK know about
2) which methods and functions does the executing iOS version know about

Of course you could keep ignoring deprecation warnings, or even go as far as keeping building against an outdated SDK. But your customers expect from you to offer them features that only became available in 4.0. At the same time you still want to get the money from the 3.x crowd.

It boils down to the necessity of having a 3.1 device next to your development Mac just so you can test the backwards compatibility.

So you have to create the compatibility methods, because Apple does not care about backwards compatibility. It’s in their interest that customers update as soon as possible because this decreases the possibility of jailbreaks.

Fun Fact: NSMakeRange still does not comply with Apple’s naming conventions (should be called NSRangeMake instead) and they HATE that.

• iOS 4.1 release is imminent, if not today then this week. GameCenter being released, update your games! Ah and you don’t need any HDR app any more, the iPhone shots 3 images at the same time and combines them. Groovy!
• iOS 4.2 coming in November, for all devices being able to run 4.x, but the main focus is to bring all the 4.0 niceties to iPad: Multitasking, Folders, etc. And the best new feature for productivity apps: Wireless Printing!
• There are 230,000 iOS devices being activated every day, NOT including updates. Steve kind of hinted that the number that Google mentioned is not really honest in that regard.
• The new iPod Nano is square indeed and clearly runs iOS. For the time being Apple does not give us ability to code apps for the small screen, but that might be coming eventually.
• New iPod Touch is now an iPhone 4 without the phone. Retina display, Gyroscope, A4 Chip. Even more reason to update your artwork and add a 2x version for all images. And since the iPod Touch now has two cameras any apps making use of AV capture devices has a way bigger audience
• New Apple TV is now at a price point reachable for everybody. The previous Apple TV was running an old OSX version, this new version clearly is iOS based, also because it has an A4 chip. But just like the Nano, no third party apps (yet?). It does not have storage though, so where would you store apps?
• One of the new things in iOS 4.2 will be AirPlay which allows HD videos to be streamed from you iDevices straight to your AppleTV. Do we see a wireless UIScreen that we can do the same from our apps in 4.2?
• New social music service directly in iTunes 10. You see which music your friends like. How about adding the same for apps?

So half of the news is great for us, more iOS devices that we can develop for with new tech. And more iOS devices that we WILL be able to develop for. Everything points to Apple wanting to keep enough news to themselves to not over-excite us iOS developers.

BUT! (one more thing) I foresee another Apple event happening at the beginning of 2011 filling all the above mentioned holes.

The Past

One of the multiple streams of income that a holistic iOS business can generate are sales of software components. Often there’s a functionality that you wished Apple would provide or made simpler to use but you lack time and expertise to write such a component. And you lack funds to hire a professional at a rate of several hundred dollars per day. What if you could share the development cost with dozens of other fellow developers? The pro would still get payed, but you trade exclusivity for availability.

This is what I created my Dr. Touch’s Parts Store for.

Often I get asked, how this is going for me. Here’s my first go at answering that: pretty well! I’ve been doing that for 7 months now, which provides a bit of data that we can slice and dice. Also I’ll tell you about the present state of affairs as well as present to you my vision of the future: The Ultimate iOS Source Store.

So far I created and mailed about 100 invoices since end of January. That’s about 14 per month or 1 every other day, roughly. It does not feel as much because I have a fast and efficient process set up:

1. If somebody has a question about how to order, I send them to my terms and conditions summary.
2. Once they e-mail me their order I add them to my Mac address book
3. I add them as a new client into Billings. (For EU customers I add the VAT ID number and “Reverse Charge” in the comments so that this get printed on the invoice as well)
4. I create a new project “Dr. Touch’s Parts Store” and add the ordered products from my blueprints
5. The invoice is mailed as PDF to the client, bcc’ed to my CFO and accountant.
6. Then I await payment either via bank transfer or PayPal.
7. Finally, after payment is secure, I mail a “Quick Start” e-mail to the client explaining how to access the Subversion repository and how to take the first steps integrating the purchased component.

This looks like much, but since this process only takes a couple of seconds every time I would never have guessed that it have been so many already. And I didn’t have any complaints so far, some customers apparently appreciate how I structure my components and are happy to return for more.

Billings is great for invoicing and tracking billable time, but I could not find any better way to get the invoice sums out of it to make a chart but to add them manually with my Calcbot.

Please forgive how this looks, I made a conscious effort to use Numbers and not Excel for this. But you can see that component invoices alone made on average 2000 Euros. This equals to about 2500 US Dollars. I intentionally decided on Euro as invoicing currency because a) it’s more convenient for me being in the Euro-Zone and b) PayPal converts it like a champ.

I find that due to the diversity of iOS developers and the diversity of apps they are making you have to have a wide selection of different things in your store because you cannot hope to match people’s current taste consistently with just one component. Sufficient diversity causes the above demonstrated consistency.

I have even more unreleased components up my sleeve that I am developing at the side. You know whenever I find myself creating something I stop and think if it would be of future value to me in a different project. And if the answer is yes or maybe then I prefix the class with DT (for Dr. Touch) and code it extra clean and extensible. This causes two things to occur: 1) my code is even cleaner more easier to maintain down the road and 2) with a bit of polishing and marketing I have a new component to sell.

The Present

At the moment that’s the way how it’s working for me. I’m quite busy with a big contracting project that at the same time builds up some Intellectual Property that I will be licensing exclusively to a US-based partner. So I’m certainly busy to an extent, that I have to pass on many contracts. Whenever I have some breathing space I’ll go into my tool chest and take up new components for my store, besides performing some long overdue overhauling of my own apps.

I have to admit, that I am not the original inventor of the idea of selling source code or libraries. There’s a myriad of such sites that sell PHP, JavaScript and other code. The first company I found selling something for iOS developers is Plausible Labs. They are selling a CoverFlow implementation, pre-compiled from $300 (indie license) up to $2500 for the source code. If you are a serious about app development that you probably make more than the $10000 which is the limit where you can no longer get the indie license but need to shell out $900 for the “standard license”.

I always felt these prices to be something over the top, so I’m setting mine in the range of 100 to 400 Euros based on how much work I have to invest. But hey, let me be honest, I just don’t have the balls (yet) to charge what other people are charging. Plausible labs charges $150 for contracting, my maximum rate is $75 per hour. Maybe next year.

But I’m not the only one who is selling components. Only recently I have been approached by several people who are trying it as well.

• Tarek Sakr is offering Sensible Tableview, making creation of tableview-based apps a breeze. Use promo code SCSTVOD6210 to get a discount. Get it while the starting price is only $30!
• iCodeSource offers URL Manager for $199 (single seat), $499 (5 seat) or $999 (25 seat) license.
• Red Laser barcode reading library (no source), $2500 minimum license for free apps, then 10 cents per user in several tiers.
• Brian Stormont (Stormy Productions) sells the RadioKit SDK, allowing you to make a streaming radio app. $100 per unique app.
• The game Sapus Tongue is available as source code from $199 (“Basic”), $249 (with updates for 6 months) and $349 (“Premium”, allowing you to ask questions)

Even Cocoa Superstar Matt Legend Gemmell is thinking aloud on how to do it right, selling source code. Although many people are glad that he doesn’t charge for his source so far, especially MGTwitterEngine which powers quite a few iPhone twitter clients.

So we see that there is a need which more and more devs are trying to fill it. There’s a wide spectrum between free and ruinous. Personally I believe that my approach to be the one the balances income and liberties for the customers the best. If I had an online system that would manage pricing tiers for me then I might be tempted to also go with tiers from no-source-cheap all the way up to full-source-lifetime-support.

The market for iOS source software is in it’s infancy and more and more developers will find that selling components can supplement their income to a level where it might be sufficient to “do it fulltime”. Please bare with me as I lay out my vision on how it could be done in a smarter and more profitable way.

The Future

What I really would like to achieve mid-term is to get a business going where several developers offer their components in on standardized online way for people to see demos, maybe get a time limited static library to try and then purchase access to an svn repository where they can always get the latest version of the components they purchased.

Possibly multiple pricing tiers: cheapest is a one off static library, middle is source code access and most expensive is with personal integration support. There might be an option for customers to subscribe so that you get a credit every month that you can spend on a product or service or save for something that needs more credits.

Having (almost) all of your heart’s desires represented in a single store has several advantages:

• developers can concentrate on what they love: write great code and get money for it.
• customers can browse and are tempted to buy more
• representing a large share of the market there can be common marketing activities that will benefit all participants.
• Other people would be taking on all the hassles of account management, hosting, support etc.
• by bringing together developers of multiple calibers in one location multiple synergies become possible: we could have a suggestion box where people interested in specific components could suggest and vote on them and then one or more developers could set out to make them, sort of like a “Part Kickstarter”.

Also the owners of this business would vet other developer’s components for possible inclusion into this system. We would take a commission, say 30%, from those sales. Additionally a shared blog and advertisement revenues are thinkable.

This would need to be founded, funded, stocked and run as a real business. To succeed the goal would be to make this the only site people think of then wanting to save time purchasing a component instead of building it. There are sites out there that are doing that for WordPress templates and PHP or Javascript code, but I don’t think that this exists for Cocoa Touch yet.

Don’t know about funding yet, but I believe for this to work it has to been done professionally, with one or two people taking care of the administrative tasks and creating/running the website. And also doing marketing. This means there need to be sufficient funds to pay for hosting and manpower for at least half a year.

There are several levels to enter into this:

• founder, brings funds, receives share in business and profit in relation to percentage of founding capital
• admin, gets paid for his parttime or fulltime work creating and running the business
• dev, brings his components to the table. Receives 70% of sales

Forgive me if this sounds like a brain dump, because it is! I have no management training and I have founded and I am playing my iOS business “by ear”. So if you have something to contribute to this cause or would like to help me get this baby on it’s wheels then contact me.

UPDATE: I created a private Google Group so that the many people who are interested in participating have a somewhat more private forum to speak their mind.

The Show Notes and script after the break.

News

Apple has begun testing three new devices as can be seen if you disassemble the latest BETA of the 4.1 SDK. Apparently new devices cannot be activated via the iTunes production server and so Apple apparently has a short cut for certain device strings to skip activation altogether. The three devices are two minor updates to the current iPhone 4. Likely one of the iPhones will be a CDMA version that Apple bitterly needs to catch up to Android on the US carrier Verizon. Pundits are pretty certain about that it will be CDMA. But they are less sure of what variant the third iPhone 4 will be. Maybe 4G, also called LTE which stands for long term evolution. Another theory that I have is that it might be like an iPhone 4GS, with a Near Field Communication antenna.

Now the third device uses the same code as the iPad and judging from the version number it would be version 2 of the iPad. There is talk of a possible 7″ iPad, but I don’t really think that Apple would want to dilute their brand like this. It’s more likely that the current iPad will become the cheapo version at like 200 dollars and the iPad 2.0 will be the latest and greatest. And iPad with a Retina Display would really be something, but to pull this off the graphics power would have to be quadrupled.

So when will we see these devices hit the market? Sources tell us that in the past new device ids always appeared about half a year before launch. So if I’m calculating correctly that would be end of January, or put differently: Q1 2011. Can’t be wrong with that prediction.

Deutsche Bank released a report that compares the global portable computing market share. This report holds two very interesting facts for us.

One, the iPad apparently cannibalizes other manufacturer’s netbook and notebook sales. They where growing steadily for at least the year prior to the iPad’s launch. But when the iPad got released in Q1 2010 you can see all lines bending downwards. Except MacBooks which took off and crossed Acer to become number two in notebook market share.

Two, if you add the sales of iPad to the category it turns out that Apple is number one in mobile computing year-over-year unit growth. That’s units, the number of devices sold, not the money being made. But as usual a good info to know that you are betting on the right horse.

Big names Capcom and Bioware are reported to be “disappointed” in their app store income. Well what do they expect? Their experiments on the platform are not really innovative, reviews for their games are lukewarm. While it is true that a couple of companies like Gameloft are taking home the biggest portion of the app store pie, small companies like Rovio show us that a new experience that plays to the unique strengths of the platform can be extremely successful. Actually today I have somebody on the show who is living proof of this.

Apple revamped iTunes Connect, specifically the app management pages. When they did that they also disabled the previous method of uploading apps. From now on you need to download and use a Mac app for that, the Application Loader which is available for free from the website. Basically you set up your app’s marketing materials and then when you are ready to upload you start the loader, select the app in the list box and choose the zip file to upload.

After there have been a lot of complaints about lacking security for iTunes accounts Apple has silently introduced a new security feature. If you are accessing the iTunes account from a new device you have to re-verify your payment info. This should make it less possible to create a multitude of accounts with the same credit card.

For devices running iOS 1.1.3 up to 3.1 Apple relied on Skyhook Wireless to locate uses in the absence of GPS data. In a response to federal legislators Apple revealed that starting with 3.2 and above OS versions they moved to their own database. Apple tries to build their own asssets in the mapping and location services arena, maybe to become less dependent on Google. They purchased Placebase about a year ago and last month they acquired small Canadian mapping firm Poly9.

After lots of haggling Apple finally reached an agreement with sellers of paper-based magazine subscriptions. The argument was about Apple insisting on their cut of 30% from apps, whereas magazines wanted to sell bundle subscriptions that would allow them to charge the users directly and have a free app to access their subscribed content. Apparently this has been worked out, or rather Apple seems to have given in. People magazine will be the first publication by Time, Inc. to follow this model.

With the new release of the operating system 4.0 we developers got a great deal of new toys to play with. One question we keep asking ourselves is: when do we reach the point that it makes business sense to release an app that requires 4.0 and above? Well, we’re coming close to the tipping point. According to Chitika, who sampled 9 Million page views on their network, 4.0 has surpassed an adoption of 50% at the end of July. If you take into consideration that it had only been launched about a month before that’s an amazing adoption rate.

If this keeps up then I would say you can already plan your next iPhone-only app in 4.0. Only if you want to go hybrid then you are still stuck with 3.2 as 4.0 remains notably absent for iPad. I hope they merge the versions back again real soon, because this is kind of a pain.

Google claims to be activating 200,000 Android handsets every day, but two studies show that the app store is still the choice for the majority of mobile developers. Beginning of June there have been around 43,000 iOS developers and around 10,000 Android developers, with 1,400 being cross-platform. The growth of Android must be a bit of a headache for Apple since it’s obviously their lock-in with AT&T that’s costing them lots of growth in the US. And I know from experience here in our small country of Austria that the exclusive contracts with number 2 and 3 of our cellular providers leaves number one, Mobilkom, in the rain selling Android and Blackberry instead.

Tbere are other reasons why people, like myself, prefer the iOS platform. On the android marketplace you don’t have a possbility to charge for apps in the majority of markets. It’s not like with the app store where you can sell apps in every country that has been opened. And also the customer mentality with Android handsets is “it’s free, it’s me. Me pay, no way!”.

And the funniest bit of news came last week: Oracle is suing Google to “impound and destroy” Android, or more precisely everything that infringens on Oracle’s rights in Java. Google had hoped to get around all licensing by creating their own Java implementation and compiler, but in Oracle’s opinion that still means they are using ideas Oracle owns. Owns because they purchased them in the form of Sun earlier this year. Pundits smile and suggest that Steve Jobs and Oracle CEO Larry Elison are close friends, so Larry is doing Steve a big favor. It’s suspected that some companies might distance themselves from Android while the outcome of the lawsuit is open. Investing in Android is something of a business risk at the moment. Good for us Apple fanboys.

Interview

I’m talking with Ken Seto who together with his brother made $100,000 with iMockups for iPad. How did he do it? What advice does he has for us?

Fortunately there is a great sample on the Apple Website that you might have heard it’s name mentioned in many circles: Reachability. The first version of this was difficult to use but Apple staff keeps polishing their works and so we have reached version 2.2 already, recently updated for iOS 4. The major change that 2.x gave us is the ability to get continuous updates on connection availability. This enables us to have our apps work similar to the iTunes app which displays a message to this effect when there’s no connection and has the UI return as soon as the connection is back.

So, let’s explore how to add the source for Reachability to our project and have some live checks.

First you need to download the latest version of the sample source from the developer website. Here’s the direct link. Click on the “Download Sample Code” button to retrieve the ZIP file.

If you open the sample project you might get “Base SDK missing” if you’re using the latest Xcode and SDK beta. Just switch it to one that you have, by going Project – Edit Project Settings – Base SDK. I use 4.1 at the time of this writing.

From the sample project you need Reachability.h and .m, copy them over to your project. The Reachability class actually wraps up functionality available in the SystemConfiguration.framework and so you need to add a reference to that as well.

There are two ways how you can make use of the Reachability class. The synchronous mode lets you query for the current state, the asynchronous mode sends notifications. Usually you’d want a hybrid solution, because you want a view to look correct for the current network state when it appears as well as react to subsequent changes in reachability. Every instance of Reachability is initialized with a host name that you want to be able to reach.

You can have several running at the same time if your app requires connectivity to seperate hosts. It’s up to you to decide how likely the second host will not be reachable if the first one isn’t. Reachability tests if the host name can be resolved and if there is a TCP/IP path that allows to reach the host. It does not check for the availability of certain web pages. So in all likelyhood you get by with just a single Reachability instance. That’s because not reaching one host usually means that the iPhone does not have internet connectivity.

Here’s the code to demonstrate the use within a view controller:

- (void)configureForNetworkStatus:(NetworkStatus)status
{
	// do something with status
	switch (status) 
	{
		case NotReachable:
			NSLog(@"Not Reachable");
			break;
		case ReachableViaWiFi:
			NSLog(@"Reachable via WiFi");
			break;
		case ReachableViaWWAN:
			NSLog(@"Reachable via WWAN");
			break;
		default:
			break;
	}
}
 
- (void)awakeFromNib
{
	// subscribe to notification
	[[NSNotificationCenter defaultCenter] addObserver: self 
		selector: @selector(reachabilityChanged:) 
		name: kReachabilityChangedNotification object: nil];
 
	// init one watcher, instance variable
	siteReachability = [[Reachability reachabilityWithHostName:@"www.apple.com"]
		 retain];
 
	// get first status
	NetworkStatus siteNetworkStatus = [siteReachability currentReachabilityStatus];
 
	// do something with it
	[self configureForNetworkStatus:siteNetworkStatus];
 
	// start continous updates
	[siteReachability startNotifier];
}
 
- (void)dealloc 
{
	[[NSNotificationCenter defaultCenter] removeObserver:self];
	[siteReachability release];  // also stops notifier
    [super dealloc];
}
 
- (void) reachabilityChanged: (NSNotification* )note
{
	// get Reachability instance from notification
	Reachability* curReach = [note object];
 
	// assert that we actually got Reachability instance
	NSParameterAssert([curReach isKindOfClass: [Reachability class]]);
 
	// get current status
	NetworkStatus siteNetworkStatus = [curReach currentReachabilityStatus];
 
	// do something with it
	[self configureForNetworkStatus:siteNetworkStatus];
}

In this sample I’m initializing everything in the awakeFromNib because I’m getting my view controller from a XIB file.

The code shows how to query a fresh instance for the current status. Then it starts the notifier which will send an NSNotification as soon as the connectivity state changes. As you can see there are three different values to NetworkStatus: no connection at all, site reachable via WiFi, site reachable via WWAN (= cellular data). So you could react differently if you know a big pipe is available as opposed to cellular where people might have limited bandwidth or volume.

Checking for reachability of a specific host is the most practical use case of Reachability. In much rarer cases you might want to check for availability of local WiFi or the internet in general (if you don’t need to access a specific host). Specialized initializers are available for these cases, check the header if you need these.

Enabling your apps for reachability checking is easier than ever. The most difficult part now is to design a nice screen, message or graphic to tell the user that he has to wait until he’s out of the tunnel.

Yet once more we see that technology has advanced to a level where it is no longer the limiting factor, but instead the human body is. For all intents and purposes of my iPhone business I deem the quality of the iPhone 4 video recorder more then sufficient. If only there was something that would help me steady my aim and frame. Well, there is, because this problem is one that photographers and videographers have been having for a long time. And most of the solutions revolve around contraptions that allow you to levitate your lens in a fixed distance from the floor.

I am of course talking about the tripod. You might remember from geometry that any surface can be described by 3 points. Tripods define a point by three feet. The point where you can mount a camera usually has two or three degrees of freedom which you an restrict by tightening screws. One or two of these screws might be attached to a handle that would allow you to move the tripod head around and adjust the tightness of one scree by turning your wrist.

I shopped around for a 3-way tripod to mount my iPhone 4 on and ended picking the Cullmann Nanomax 250 which is a sturdy but extremely lightweight tripod that almost fits into my backback. Because it is made out of aluminum it weighs only 2.3 lbs (1 kg). So it’s ideally light and compact to work for a blogging developer like myself. Cullmann in Germany grants you 10 year warranty on the tripod if you register on their website.

But this article is not about my choice of tripod. Once you got one you are presented with the challenge to somehow mount your pretty iPhone on it. That’s where special cam mounts are necessary. I asked around on Twitter and two options were recommended to me. I purchased both and now I’m going to compare them so that you don’t have to.

Mosy Mount

When I received the Mosy Mount package they made it as much an Apple experience as possible. You receive a metal box with a clear window at the top that presents the mount. Or rather, A mount, because inside the box you find another one to make TWO mounts for the price of one. One is already attached to a clear case that fits the iPhone 4′s rectangular frame. The other is affixed to a temporary piece of cardboard with instructions on how to mount this on your own case. Disclaimer: nothing sticks to silicone. You also get a foldable mini-tripod for use on tables.

You have a choice of three motives that all are basically a rectangular foamy plastic piece with an embedded 1/4″ screw. Once the iPhone is in the case there is no chance in hell that it can fall out, removing the case takes a bit of fiddling which is a good thing if you worry about that. A bad thing if you are impatient and are not planning to use it on rough rides. Through the Mosy Mount the mounting screw is placed near the center of gravity on the back of the iPhone. This is the reason why out of the box you require a 3-way head on your tripod. With 2-ways all you can hope to film is the heavens.

With the 3-way head of my tripod I can have the camera point at a target with the handling sicking out to the right side. That’s fine for shots that don’t require an up and down movement. Horizontal panning and steady shots work perfectly if that’s all you require. When I ranted on Twitter about this the maker of Mosy Mount contacted me and sent me a list of materials plus plan on how to to convert the Mosy Mount with an right angle bracket. He’s a very friendly guy, an incredibly personal level of support. He warned me not to tighten the mount screw too much or else I would pull out the metal piece of the mold.

The clear case tightly grips the sharp edge of your iPhone 4. The 3D mold is a piece of art but it has a bit of a drawback. The surface is not flat and thus you don’t quite feel how much you can tighten the screw. Also it does not feel like there is a good contact which still permits a bit of rotation around the screen. That’s another con. You might feel that your iPhone is safe in the case when mounting it onto a moving vehicle, but you should take extra precautions because of this weak spot.

U+G4 Holder

I found the website for the U+G4 holder even before Mosy Mount because they are more SEO-savvy: www.iphone-tripodholder.com. My first impression was to think that the screw is on the wrong place, namely on the small side. Wouldn’t that mean I can only shoot portrait video?

I received the holder without any trimmings in a padded envelope. But what the packaging understates the holder itself talks all the more loudly. You find the holder to be made out of strong plastic with a professional screw embedded in the smaller side and 2 small 3M Bumpon pads to keep the iPhone from sliding out once you moved it into place. You can slide the iPhone in both ways due to a small window in the mount, a sort of rail fits the device perfectly.

The bottom of the mount is flat to allow for good fastening of the mounting plate which is standard with all modern tripods. It’s a plastic rectangle that you screw onto the 1/4″ thingy which itself can be fastened to the tripod by a simple lever. You feel that some thought went into this method, enough to be pending a patent.

Having the mounting screw at the side allows for the tripod handle to be where it should be: in the opposite direction of the lens. Mounted like this you can pan vertical and sideways with ease. In this case tightening the handle will restrict the up/down motion. It’s logical and intuitive this way which makes this mount my favorite for any kind of moving targets.

What remains to be seen is how the life of the pads will go. That’s only something that repeated use of a longer time span can show us. If you’re planning to use the U+G4 on a moving vehicle you might want to add an additional rubber band to secure your phone into the mount. While it stays inside against gravity a short jerky movement can move it out of its secure position inch by inch.

Conclusion

For both cases you will need to remove any Bumper or other case you might have to fit. The Mosy Mount itself is a case that will protect your phone a bit, at least from scratching and it comes with the benefit of letting you transform a protective case of your choice into a mount (as long it’s not silicone). The U+4G is way less artsy, straight to the point and gives me more confidence in the screwing. Also it costs half as much as the competitor.

After having evaluated both mounts for some time in direct comparison I formed my opinion. Personally I prefer the U+4G over the Mosy Mount because of the more logical way of “steering” via the handle and because of the tighter fit with my tripod mounting plate. You might have noticed that I have a red sticker around the edges of my iPhone (by :blueMac) to protect it until I get my official bumper. The Mosy case threatens the life of this sticker because of how tightly it hugs the device.

My summary of the pros and cons of both mounts follows below.

Mosy Mount

Pro: Stylish, 3 Motives, two mounts let you convert your existing case, great personal support, foldable mini-tripod included

Con: area around screwing hole not flat, inconvenient mounting position for moving targets

$19.95 by Art4Media LLC

U+G4

Pro: Sturdy plastic, professional screwing hole, allows usage of “steering handle” in tripod, patent pending

Con: Open side might allow iPhone to shake out, not designed for protecting iPhone

$9.95 by G Design LLC

I still believe that Apple’s Bug Reporting system should be open for everybody, but since Apple is still run like a small startup they feel that it helps them conserve more resources to have it closed. That’s why there is Open Radar which somebody put on Google App Engine.

So, here’s my full bug report plus the demo project and screen shot. See if you can reproduce it and find a workaround.

NavigationController from NIB produces sticky gray empty status bar on rotation

16-Aug-2010 06:40 PM Oliver Drobnik KG:
Summary:

If you load a navigation controller from MainWindow.xib, but add the first view controller in appDidFinishLaunching, then there is a problem on rotation. A gray empty status bar appears underneath the regular status bar which cannot be eliminated.

Steps to Reproduce:

• Create a Navigation based project.
• Set status bar to be initially hidden.
• Set navigation controller to want full screen and have nav bar hidden
• Implement a tap method in the view controller to hide and show the status bar
• Move the view controller outside of the navigation controller in the IB
• Add a line to app delegate to push the now separate view controller onto the navigation controller.
• Start the app, rotate once sideways with shown status bar
• tap to hide the status bar

Expected Results:

No extra gray status bar.

Actual Results:

A sticky gray status bar appears underneath the disappearing regular status bar.

I’m attaching a project to demonstrate the behavior. Plus a screenshot.

The behavior is inconsistent with creating a navigation controller in code. There no extra status bar appears.

Discussion

I filed this bug report on Open Radar as well. Here’s the Project file I’m referencing: StatusBarBug.zip

To see the bug for yourself launch the demo project in iPad Simulator. Tap the screen to show the black status bar. Then rotate the simulator once. Tap the screen again to hide the status bar. Behind it this gray bar appears.

This is how the screen looks like with the extraneous status bar showing.

Iif you set the navigation controller’s root view controller already in the NIB (as it’s usually the case) then this behavior does not occur. So for this demo I moved the view controller outside of the navigation controller.

If you don’t instantiate the navigation controller via a NIB file, but instead put the following code into the applicationDidFinishLaunching, then you will not see this extra bar.

- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions
{
	// could also initWithRootViewController, same effect
 
 	navController = [[UINavigationController alloc] init];
	navController.wantsFullScreenLayout = YES;
	navController.navigationBar.hidden = YES;
 
	[navController pushViewController:viewController animated:NO];
 
	[window addSubview:navController.view];
	[window makeKeyAndVisible];
 
	return YES;
}

This leads me to the conclusion that something funny is happening when getting your navigation controller from a xib (without root view controller set) versus instantiating it in code. Which prompted me to file this bug. If you find that it is actually something that I am doing wrong here, please let me know.

First the “old way”. It needs to customize touch handling for the tableview cells themselves, which means you have to subclass UITableViewCell.

TouchAndHoldCell.h

#import <UIKit/UIKit.h>
 
@class TouchAndHoldCell;
 
@protocol TouchAndHoldCellDelegate <NSObject>
@optional 
- (void)didTouchAndHoldForCell:(TouchAndHoldCell *)cell;
@end
 
@interface TouchAndHoldCell : UITableViewCell 
{
	id <TouchAndHoldCellDelegate> delegate;
}
 
@property (nonatomic, assign) id <TouchAndHoldCellDelegate> delegate;
@end

TouchAndHoldCell.m

#import "TouchAndHoldCell.h"
 
 
@implementation TouchAndHoldCell
 
@synthesize delegate;
 
- (id)initWithStyle:(UITableViewCellStyle)style reuseIdentifier:(NSString *)reuseIdentifier 
{
    if (self = [super initWithStyle:style reuseIdentifier:reuseIdentifier]) {
        // Initialization code
    }
    return self;
}
 
- (void)touchAndHold:(NSDictionary *)params
{
	NSSet *touches = [params objectForKey:@"touches"];
	UIEvent *event = [params objectForKey:@"event"];
	[super touchesCancelled:touches withEvent:event];
 
	if (delegate && [delegate respondsToSelector:@selector(didTouchAndHoldForCell:)])
	{
		[delegate didTouchAndHoldForCell:self];
	}
}
 
- (void)touchesBegan:(NSSet *)touches withEvent:(UIEvent *)event
{
	// 1 second holding triggers touchAndHOld
	[self performSelector:@selector(touchAndHold:) withObject:
		[NSDictionary dictionaryWithObjectsAndKeys:touches, @"touches", event, @"event", nil] afterDelay:0.5];
	[super touchesBegan:touches withEvent:event];
}
 
- (void)touchesMoved:(NSSet *)touches withEvent:(UIEvent *)event
{
	[NSObject cancelPreviousPerformRequestsWithTarget:self];	
	[super touchesMoved:touches withEvent:event];
}
 
- (void)touchesEnded:(NSSet *)touches withEvent:(UIEvent *)event
{
	[NSObject cancelPreviousPerformRequestsWithTarget:self];	
	[super touchesEnded:touches withEvent:event];
}
 
- (void)touchesCancelled:(NSSet *)touches withEvent:(UIEvent *)event
{
	[NSObject cancelPreviousPerformRequestsWithTarget:self];	
	[super touchesCancelled:touches withEvent:event];
}

This works by calling a selector with half a second delay. If the finger is lifted before this expires the delayed call is cancelled. If it does get to expire then we have a long press and thus the cell can tell it’s delegate (the tableview controller) that a long press (that’s how Apple calls it) transpired.

To use this you would override the cellForRowAtIndexPath method and provide a method to react to the long press.

- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath {
 
    static NSString *CellIdentifier = @"Cell";
 
    TouchAndHoldCell *cell = (TouchAndHoldCell *)[tableView dequeueReusableCellWithIdentifier:CellIdentifier];
    if (cell == nil) {
        cell = [[[TouchAndHoldCell alloc] initWithStyle:UITableViewCellStyleDefault reuseIdentifier:CellIdentifier] autorelease];
		cell.delegate = self;
    }
 
	// Configure the cell.
	cell.textLabel.text = @"Text";
    return cell;
}
 
 
#pragma mark TouchAndHoldCell Delegate
- (void)didTouchAndHoldForCell:(TouchAndHoldCell *)cell
{
	UIActionSheet *action = [[UIActionSheet alloc] initWithTitle:@"Actions" delegate:self cancelButtonTitle:@"Cancel" destructiveButtonTitle:@"Destruct" otherButtonTitles:nil];
	[action showInView:self.view];
	[action release];
}
 
- (void)actionSheet:(UIActionSheet *)actionSheet didDismissWithButtonIndex:(NSInteger)buttonIndex
{
	if (buttonIndex==0)
	{
		NSLog(@"Destruct");
	}
	else
	{
		NSLog(@"Cancel");
	}
}

That’s the historic evidence of past ingenuity. Next we’re going to examine how that’s done today. Easier, faster, more Apple if you will.

iOS and SDK 3.2 gave us one of the most ingenious things that Apple could ever invent. For two years we had to code all our touch handling ourselves which resulted in a variety of different approaches, all with a different feel to them. Gesture Recognizers changed all that, 3.2 brought them first to the iPad and they are also part of iOS 4.x. Unfortunately they are not backwards compatible.

All it takes is to create such a gesture recognizer instance and attach it to the appropriate view.

- (UITableViewCell *)tableView:(UITableView *)tableView 
            cellForRowAtIndexPath:(NSIndexPath *)indexPath 
{
    static NSString *CellIdentifier = @"Cell";
 
 
    UITableViewCell *cell = [tableView dequeueReusableCellWithIdentifier:CellIdentifier];
    if (cell == nil) 
	{
        cell = [[[UITableViewCell alloc] initWithStyle:UITableViewCellStyleDefault 
		reuseIdentifier:CellIdentifier] autorelease];
 
		UILongPressGestureRecognizer *longPressGesture = 
			[[[UILongPressGestureRecognizer alloc] 
			  initWithTarget:self action:@selector(longPress:)] autorelease];
		[cell addGestureRecognizer:longPressGesture];
    }
 
	// Configure the cell.
	cell.textLabel.text = @"Text";
    return cell;
}
 
- (void)longPress:(UILongPressGestureRecognizer *)gesture
{
	// only when gesture was recognized, not when ended
	if (gesture.state == UIGestureRecognizerStateBegan)
	{
		// get affected cell
		UITableViewCell *cell = (UITableViewCell *)[gesture view];
 
		// get indexPath of cell
		NSIndexPath *indexPath = [self.tableView indexPathForCell:cell];
 
		// do something with this action
		NSLog(@"Long-pressed cell at row %d", indexPath);
	}
}

Gesture Recognizers employ the same methodology as we have seen before for adding target/actions to UIControls, for example UIButtons. The target is the instance of a class to receive the message, the action is the selector. And the parameter that’s being passed is the sender of the message. For UIControl events that’s the sending view, for UIGestureRecognizer events it’s the instance of the gesture recognizer you have set up.

In the above example we simply create a UILongPressGestureRecognizer (which has the appropriate expiration time interval already built in) and attach it to each cell we create. If the tableview is long enough so that we get to recycle cells it would still work, because we don’t care which cell a recognizer is attached to, as long as there is one for each cell you can tap on, recycled or new.

In the longPress: method we can query the tableView for the “line” we tapped on. For a while I was setting the cell’s tag value to the number of the row, but I found that this ceases to work if you allow for deletion of rows, because then the indexes you put into the tags have incorrect values. Better to ask the tableView itself at time of the pushing via the conveneient indexPathForCell method.

Also note that this method is being called twice, namely when the gesture is recognized (when the finger was on the cell long enough) and when it’s ended (when you lift the finger). Usually you’ll want to only react when it’s started.

You see, that gesture recognizers really reduce the amount of code we need to write to achieve some advanced touch handling.

1. Pre-configure the account for iTunes Connect such that you don’t have to give your credentials to your partner
2. Filter sales reports such that only the apps come through that the partner is receiving a share of sales for

… and all of this without impacting the other features like review downloading.

Since I have such a partner myself for which I’m now publishing 3 apps, I sat down and – after fighting with Xcode over a second target – added a couple of lines to the MyAppSales trunk to enable the “Partner Version”.

In the PCH file you enable and configure this special version by removing the // in front of the first define. Then you need to specifying your ITC credentials and an NSSet of Apple App Identifiers.

// to enable the partner version, re-enable the following define and fill in the three values below
//#define PARTNERVERSION
 
#define PARTNERVERSION_ITC_LOGIN @"account@server.com"
#define PARTNERVERSION_ITC_PASSWORD @"SECRETPASSWORD"
#define PARTNERVERSION_FILTER_APPS_SET [NSSet setWithObjects:@"335519920", @"329678407", @"374457741", nil]

I’ve added a filter for the specified PARTNERVERSION_FILTER_APPS_SET in two places to ignore all lines on sales report where neither the Apple Identifier nor the Parent ID is in this list. Since the app never sees any apps outside of this filter those also won’t pop up on the apps page.

For the preconfigured account, the app adds this ITC account if there are no accounts defined. So if your partner were to remove this account accidentally it would be configured once more on next app start.

All you need to do after configuring and building a release version is to zip and ship the app and provisioning profile to your partner. Easy enough?

DTBannerManager solves this problem for you. It allows for easily adding both networks to your code. Under iOS 4 it will first try to get an iAd because those also pay for just being displayed. If none is available then it automatically switches to AdMob, so your banner space is never wasted. It also features elegant sliding in and out of the banners and is able to display ad banners even over a tab bar controller, so they are always visible for maximum effect.

You might argue that there are free ad networks out there who promise to do exactly this for free. So why would you want to get this component from me. Well, from you you get full source code and you see exactly what is happening. Also there is no server-side ad mediation happening that might get you in trouble with Apple. I believe that as developer you don’t want to involve too many additional parties and introduce too many external dependencies. With DTBannerManager you continue own all parts of your code and have full transparency.

What’s also great is that you can use this component will work on both 3.x and 4.x iOS Versions. This way you can target the broadest possible audience with reaping the benefits of iAds if available.

Adding advertising is exceedingly simple:

#ifdef FREEVERSION	
	[[DTBannerManager sharedManager] addAdsToViewController:tabBarController];
#endif

Then you can just subscribe to the notifications to adjust the viewing area of your view controllers.

DTBannerManager is proving it’s worth already in GeoCorder [FREE]. There was a bug preventing “clicking through” in Ads that I have since fixed. The component is available through the Dr. Touch’s Parts Store.