macJasp

Apple scanning submitted Apps for Private API’s

My previous post regarding taking a chance on submitting an iPhone Application that uses undocumented APIs seems to have turned to high risk or possibly even ‘DO NOT USE’.

News has been leaking in the last few weeks that Apple now have the means (possibly via some form of automated scanning software) to check for the use of Private APIs within code during the review process and some developers are reporting that their recently updated Applications are now being rejected on these grounds.

It’s now likely that my next iPhone application will no longer use the undocumented UIProgressHUD and i’ll turn to the MBProgressHUD implementation instead to get what i’m after.

It’s a real shame, some of the Private APIs are really nice to use and I for one would like to take advantage of them. I don’t see why Apple can’t just make them available through the SDK. As I touched on in one of my previous post, the UIProgressHUD is really nicely implemented and it’s already used by Apple’s own in built applications, so why should they be any different in looks and appearance to user submitted Applications? If Apple’s policy is to have a standard look and feel for iPhone Apps then the use of some of these Private APIs is required i’d have thought?

iPhone settings.bundle issues – Loading Defaults

Here's something i hadn't realised but it's the reason why shrinkURL 1.1 was rejected by Apple recently. ShrinkURL 1.1 uses application settings to store the default shortening service to be used, along with the bitly username and API Key. When an application is installed that has application settings the settings.bundle isn't actually created, at least not until you enter the settings page for that particular application from within the iPhone itself, therefore code has to be introduced to load the default settings from the root.plist.

The root.plist settings bundle

In the example below, the code is checking for the 'service' to see it it exists in root.plist, if it doesn't (meaning the settings.bundle hasn't been created) it will load the defaults for each key from the settings.bundle into the program. This is performed at the start of viewDidLoad.

 // check application settings bundle is there 

NSString *serviceCheck = [[NSUserDefaults standardUserDefaults] stringForKey:@"service"];

if(!serviceCheck) { 

// If the default value doesn't exist then we need to manually set them.

[self registerDefaultsFromSettingsBundle]; 

serviceCheck = [[NSUserDefaults standardUserDefaults] stringForKey:@"service"]; } 

The method to call if the settings.bundle doesn’t exist, this loads the defaults into the program.

- (void)registerDefaultsFromSettingsBundle { 

NSString *settingsBundle = [[NSBundle mainBundle]
pathForResource:@"Settings" ofType:@"bundle"]; 

if(!settingsBundle) { 

NSLog(@"Could not find Settings.bundle"); 

return; } 

NSDictionary *settings = [NSDictionary dictionaryWithContentsOfFile:
[settingsBundle stringByAppendingPathComponent:@"Root.plist"]];

NSArray *preferences = [settings objectForKey:@"PreferenceSpecifiers"]; 

NSMutableDictionary *defaultsToRegister = [[NSMutableDictionary alloc]
initWithCapacity:[preferences count]]; 

for(NSDictionary *prefSpecification in preferences) { 

NSString *key = [prefSpecification objectForKey:@"Key"]; 

if(key) { 

[defaultsToRegister setObject:[prefSpecification objectForKey:@"DefaultValue"]
forKey:key]; 

} 

}
[[NSUserDefaults standardUserDefaults] registerDefaults:defaultsToRegister]; 

[defaultsToRegister release]; }

Thanks must go to Paul Solt's website for the useful piece of code.

UIProgressHUD – The Undocumented Alert Type

I really like this type of alert view to inform a user that some background processing is going on but it’s a real shame that it’s an undocumented and private class, meaning therefore you run the risk of your app being rejected by Apple if used.

What’s odd however is that I've seen many approved applications use this particular alert view so i guess it’s not 100% guaranteed of breaking Apple’s policy. I'm personally very keen on implementing this into my next iPhone application, it simply looks the part. Implementing UIProgressHUD Using the undocumented approach in your project is nicely explained here http://tmdvs.me/post/uikit-alert-types and i've tested it against the current iPhone OS version 3.1.2 and it still works well, however if we wish to avoid all possible risk of rejection by Apple, i found some code that someone has took time to develop that does a good job of replicating the undocumented alert, called MBProgressHUD

http://www.bukovinski.com/2009/04/08/mbprogresshud-for-iphone/

I’m personally going to try the undocumented method first and see if Apple accept it with my next application submission.

Change back button title on Navigation Controller

I was getting a bit frustrated when pushing a new View within a Navigation Controller, as by default the back button title on a new View is always the title from the preceding View;

however i want the View I'm pushing onto the stack to have consistency in the title but with the back button stating exactly that ‘ Back’.

After some digging around i finally cracked it by using this bit of code on the initialisation step of the calling View.

UIBarButtonItem *temporaryBarButtonItem = [[ UIBarButtonItem alloc] init]; 

temporaryBarButtonItem.title = @"Back"; 

self.navigationItem.backBarButtonItem = temporaryBarButtonItem; 

[temporaryBarButtonItem release];

By creating a custom navigation bar button on the preceding View Controller, the newly pushed View shows correctly

Beginning iPhone development

I've been programming since around the age of 10 or 11.

I actually started on a ZX Spectrum 48k, writing code and developing games with a good school friend of mine at the time, developing football and music related games that we just ended up playing between us.

My career in IT initially started within development, around IBM AS/400 using RPG/II & RPG/400 and it was a job i loved, however after moving into management i didn't quite keep up with as much programming and playing with code as i'd have liked but my love for the iPhone has really got me interested in picking up development again for personal enjoyment