Custom UINavigationController back buttons under iOS7

When you first create / get a reference to the navigation controller, set a global custom back image (replaces the chevron) with:

[self.navigationController.navigationBar setBackIndicatorImage:
    [UIImage imageNamed:@"CustomerBackImage"]];
[self.navigationController.navigationBar setBackIndicatorTransitionMaskImage:
    [UIImage imageNamed:@"CustomerBackImage"]];

The title of the back button is owned by the view that it points to, not the current view. You can make it blank by calling

self.navigationItem.backBarButtonItem = [[UIBarButtonItem alloc]
    initWithTitle:@""
    style:UIBarButtonItemStylePlain
    target:nil
    action:nil];

in the view that the back button points to. So call it in prepareForSegue or before pushViewController:animated: or something. Setting a view controller’s title programmatically seems to reset it, so set it after setting the title.

You’ll see lots of advice to set self.navigationItem.leftBarButtonItems (which breaks swipe-to-go-back) then mess with interactivePopGestureRecognizer to fix swipe-to-go-back (which has some exciting doesn’t quite work right edge case problems). Don’t do that. Do this.

NSURL category to return the full path, with trailing slash and query parameters

@implementation NSURL (PathHelper)
-(NSString*)fullPathWithQuery;
{
    // getting a path without the trailing slash stripped is annoying.
    NSString *pathWithPrevervedTrailingSlash = [CFBridgingRelease(CFURLCopyPath((CFURLRef)self)) stringByReplacingPercentEscapesUsingEncoding:NSUTF8StringEncoding];
    if (self.query) {
        return [NSString stringWithFormat:@"%@?%@", pathWithPrevervedTrailingSlash, self.query];
    } else {
        return pathWithPrevervedTrailingSlash;
    }
}

@end

Might even work…

renewing ACAccount credentials on iOS

An iOS 5/6 device can have system-level Twitter/Facebook accounts that become disassociated from the underlying service accounts. This means that the ACAccountStore framework will return you ACAccount objects that can be used to sign requests and get access tokens, but NONE OF THE REQUESTS WILL WORK and you’ll get MYSTERIOUS OAUTH ERRORS and LOTS OF SUPPORT MAIL and be GRUMPY because it WORKS FOR YOU JUST FINE.

I’m not certain how to fake this state. Changing your Facebook password and choosing to log out other devices is pretty reliable, albeit really annoying if you actually use Facebook for anything. Likewise, changing your Twitter password might work. I think restoring the phone from backup will also cause this problem, especially if it’s a iTunes-based non-encrypted backup, because the passwords aren’t saved, but the phone won’t prompt you at any point to enter them again.

When this happens to Twitter account objects, I see server responses to otherwise perfectly reasonably signed requests with the error Bad Authentication data and the error code 215. I used to get This method requires authentication when calling the old 1.0 API, because the 1.0 API interprets a bad signature as no signature (REALLY ANNOYING), but the 1.1 API is a lot stricter.

When this happens with Facebook, I see Error validating access token: The session has been invalidated because the user has changed the password and sometimes Error validating access token: Session does not match current stored session. This may be because the user changed the password since the time the session was created or Facebook has changed the session for security reasons.

The solution to this is the method on ACAccountStore:

- (void)renewCredentialsForAccount:(ACAccount*)account
                        completion:(ACAccountStoreCredentialRenewalHandler)completionHandler;

From the docs:

For Twitter and Sina Weibo accounts, this method will prompt the user to go to Settings to re-enter their password.

For Facebook accounts, if the access token has become invalid due to a regular expiration, this method will obtain a new one.

If the user has deauthorized your app, this renewal request will return ACAccountCredentialRenewResultRejected.

Calling this method on the ACAccount object you’re trying to deal with will make-or-break it. I find that the token either works afterwards, or doesn’t, but now it doesn’t work because the iOS device knows that it doesn’t have a valid token. You may still have to punt the user into the Settings app to fix it. For instance, in the case of Twitter I find that calling renewCredentialsForAccount will pop up a system dialog about the problem.

Facebook is more subtle – the ACAccount object can still be used to get an access token, but that token will fail on the server with The session has been invalidated because the user has changed the password still. However, punting them manually into Settings.app at this point will ask them for a Facebook password and things will work afterwards.

Alas, it’s asynchronous. You can work around that. Call it on the ACAccount instance before you try to do something serious with it, or do work in the callback.

I hope this helps -someone-, because it sure would have helped me 6 months ago.