My current project relies heavily on Core Data. Since writing queries with Core Data really sucks, I have thrown together a little helper project called ios-queryable to ease the pain.
From the readme:
ios-queryable is an Objective-C category that provides IQueryable and IEnumerable-like functionality to Core Data.
It supports query composition and deferred execution, and implements a subset of IEnumerable’s methods, such as where, take, skip, and orderBy.
It lets you write code like this:
NSArray* widgets = [[[[[self.managedObjectContext ofType:@"Widget"]
where:@"Type == 'abc'"]
instead of like this:
NSFetchRequest* fetchRequest = [[NSFetchRequest alloc] init];
NSEntityDescription* entity = [NSEntityDescription
NSPredicate* predicate = [NSPredicate predicateWithFormat: @"type == 'abc'"];
NSSortDescriptor* sortDescriptor = [[NSSortDescriptor alloc]
NSArray* sortDescriptors = [[NSArray alloc] initWithObjects: sortDescriptor, nil];
NSArray* widgets = [self.managedObjectContext executeFetchRequest:fetchRequest error:&error];
Please send me your feedback, and keep in mind that ios-queryable is still a work in progress!
I recently attempted to purchase an app from the app store on my iPhone, and I must say, the experience was quite hilarious. Here is a rough overview of the process (from memory, so apologies if a few details are off):
- Tap the price
- Tap buy
- Enter my password
- Get prompted to enter in three security questions
- Tap not now
- Wait a while, notice that nothing is happening
- Tap buy
- Tap OK when prompted to enter in my security questions
- Select my questions and answers
- Tap ok
- Tap buy
- Get prompted to verify my credit card into
- Tap continue
- Enter in my credit card info
- Tap done
And there you have it – buying apps in only 15 easy steps!
I was going to make a snarky comment about how Apple should license Amazon’s one-click buying patent, but apparently they already have. Joke’s on me.
I’ve been looking into third-party app analytics services such as Mopapp and appFigures for a while now. There’s something that worries me about these services, though: they ask for your Apple ID and password.
Wait, what? Are you sure this is a good idea? Am I even allowed to give out this information? I’m not sure, so I decided to check. And here it is, straight from the horse’s mouth – Section 1 of Apple’s developer agreement (emphasis mine):
The Apple ID and password you use to login as a Registered Apple Developer cannot be shared in any way or with any one. You are responsible for maintaining the confidentiality of your Apple ID and password and for any activity in connection with your account.
That seems pretty cut-and-dry. Sharing your login information is a violation of the agreement. So what’s the deal? Is it only ‘sharing’ if I give my login info to a person? Do we simply ignore the issue because these third-party analytics services are so useful?
Considering that you can get banned from the app store for violating the developer agreement, this seems like a pretty serious matter. Granted, fraud might be a completely different level of violation than sharing your login info, but given Apple’s history of somewhat arbitrary decisions, I’m not sure that I want to risk it.
What do you think?
Apple recently released Xcode 4.4. The list of new features is quite intriguing.
- The compiler automatically calls
@synthesize by default for unimplemented
- For the
NSDictionary classes, support is provided for Objective-C literals.
- Subscripting using
'[ ]' syntax is supported for Objective-C container objects.
- Compatibility with the C++11 standard is improved.
- New static analyzer checks for common security mistakes in API and malloc usages.
- The caller and callee for selected methods can be displayed in the Assistant Editor.
- Code completion is enhanced with QuickHelp.
- Scene Kit is supported with a viewer-editor for 3D document files.
- Improved localization workflow uses base language
- Git supports staging of individual changes.
Leave it to Apple to introduce core language features in a point release of their IDE!
Anyway, it got me thinking about Objective-C, productivity, and John Siracusa’s comments from a few years back:
A framework with methods like this:
NSInteger myCount = [[myDict objectForKey:@"count"] integerValue];
NSArray *myArray = [myString componentsSeparatedByString:@","];
myItem = [myArray objectAtIndex:i];
is just not going to fly in a language that (hypothetically) supports this:
myCount = myDict["count"];
myArray = myString.split(",");
myItem = myArray[i];
Looks like John finally got his wish! And quite frankly, it’s about time. It doesn’t get much more basic than strings and arrays, and it boggles my mind that it took Apple this long to give us a non-eye-gouging syntax. Don’t get me wrong; I’m glad to have these improvements. It’s just that in my opinion, ObjC still lags far, far behind the rest of the civilized world when it comes to programmer productivity.
Over the next little while I will be taking a closer look at some of Objective-C’s productivity failures in comparison with languages like C#, Ruby, Python, and F#.
You’ve all seen the standard, iOS buttons. Although functional, they are, well, plain, to put it mildly.
Perhaps you’ve even tried to make some prettier buttons in photoshop. But if you’re like me, and you have no artistic skills, this can be a challenge. Fortunately, Michael Heyeck has put together a slick little piece of code for generating stylish, glossy buttons.
It’s ridiculously easy to use, and the results look great.
Step 1 – download UIButton+Glossy.h and UIButton+Glossy.m and stick them in your project.
Step 2 – #import “UIButton+Glossy.h” in the view controller that holds your buttons.
Step 3 – style the buttons! This is done by calling the setBackgroundToGlossyRectOfColor:withhBorder:forState method. The color parameter specifies the button’s color. The withBorder parameter specifies whether or not the button should have a border, and the forState parameter is the UIControlState that the style should be applied to.
You can put this code in your view controller’s viewDidLoad method. So, given a UIButton* named button, we can style it like so:
[button setBackgroundToGlossyRectOfColor:[UIColor colorWithRed:.05 green:.65 blue:.05 alpha:1] withBorder:NO forState:UIControlStateNormal];
And with that, you have a stylish looking button!
A little style can go a long way into helping your app stand out from the crowd.
Download the Sample Project
Since I’m currently playing the app store review process waiting game once again, I started thinking about how different the app store is from the rest of the technology world.
As we all know, the time it takes from the moment you submit your application to the moment it is live on the app store can be days, weeks, or even more. I find it quite amusing that the app store is essentially moving in the opposite direction as the rest of the industry.
We live in a world of push notifications, live streaming, real-time everything, instant deployment via git push, and ultra-short feedback loops between the developer and the user. Comparatively speaking, Apple’s app store processes are stuck in the 80’s. Nothing says agile and proactive like waiting two weeks for your app to be reviewed, only to have it denied by Apple due to a two-minute bug fix, right?!? Yeah. Not quite.
But doesn’t Apple need these processes to protect its users? What about security? Reliability? Spam? Blah blah blah. All I hear are excuses.
I want to be able to push new versions of my apps with git. I want to be able to fix bugs without a two week lag time. I want Apple to use their vast brains and pocketbooks to figure out how to make things better. I don’t want more excuses. Besides, it’s not like the current process are perfect anyway.