Ethical Paul Rants

Apple Watch Lego charging stand

Mobile: There are three possible ways that our users can be able to retrieve content: our login, iTunes receipt, or free trial period. I have an idea which one is valid, but I don't know for sure until I call each API. I'd like to supply all credentials to an API and have it check them and return to me which one is valid with the content itself to save API calls for the client app.

API: No. Each API should handle one individual task. They should be "get in, get out" to free up sockets.

Mobile: My users don't care about sockets, and it must also be better for you to receive fewer calls too, no?

Mobile App: I would like it if the game retrieval API also included the currently-saved state for that game since I'm going to immediately turn around and request the saved state anyway.

API: No, I don't want to do that because if I put user information into the game retrieval, I won't be able to cache it.

Mobile App: My users don't care if your server which is plugged into super fast internet, with super fast processors with unlimited power has to do a little extra work. They care about their battery and time.

I've been doing work in Game Center, and testing changes on two devices. So I see this sheet a lot because I start building on the second device before the first one is complete.

NSDateFormatters are great to use especially in Mac OS X apps because they work so well with Cocoa Bindings in Interface Builder.

There are two kinds of them. One with an OS X 10.0 behavior and one with an OS X 10.4 behavior. iOS uses only the more modern one. In OS X the 10.0 behavior is deprecated and you should use the 10.4 version. But there's a problem.

Let's say you have a text field with a date formatter attached to it in Interface Builder. Now when you run your app, put a date string into the text field and hit enter. So far so good. Then delete the date string and hit enter. It seems that the 10.0 behavior supports this. But the 10.4 behavior complains that it is not a valid date format. So once your text field has a value in it, there's no way to remove that value. Weird!

If you were using an NSNumberFormatter, there is a pair of methods, -setNilSymbol and -nilSymbol, that help you deal with this. You can call [myNumberFormatter setNilSymbol:@""] and then the number formatter will know that if it sees an empty string, it should make the resulting number be nil.

But there is no -nilSymbol for NSDateFormatter. And the weird part is there is almost no mention of this on the internet. How is this possible that more people aren't having to deal with this? Here is about the only mention of it I can find, in a post about NSNumberFormatter:

http://osdir.com/ml/cocoa-dev/2009-08/msg01350.html

Note at the very bottom of the mailing list post, the respondent makes a comment about how it's too bad that NSDateFormatter doesn't have that attribute.

So what is the solution? There is a project on github that adds -setNilSymbol to NSDateFormatter. It's https://github.com/oriontransfer/SWApplicationSupport

You can go a little simpler and just create a subclass of NSDateFormatter that will allow an empty string to be converted to a nil date like this:

@implementation EPDateFormatter /** It is INSANE that NSDateFormatter doesn't allow empty values to resolve to a nil date!!!. */ - (BOOL)getObjectValue:(out id *)obj forString:(NSString *)string errorDescription:(out NSString **)error { BOOL result = [super getObjectValue:obj forString:string errorDescription:error]; if (result == NO && [string length] == 0) { *obj = nil; result = YES; } return result; } @end

Turns out there is a "hidden" slow animation toggle consisting of pressing CMD together with the Shift key. Not the best key combination to use, Apple!