While experimenting with Core Data, I ran into a little issue with the always annoying ‘unrecognized selector’ exception.
I had created my Core Data model, along with my NSManagedObjectContext classes, and I was trying to use them like this:
Foo* foo = [[Foo alloc] init];
foo.bar = @"This line will crash!";
… which of course results in the aforementioned exception.
This is what happens when you don’t read the documentation. It quite clearly states that you pretty much have to use NSEntityDescription’s insertNewObjectForEntityForName:inManagedObjectContext method to create your objects.
And sure enough, if you create your objects like this instead:
Foo* foo = [NSEntityDescription insertNewObjectForEntityForName:@"Foo" inManagedObjectContext:context];
foo.summary = @"This is a bug";
it works as expected.
That said, making a class called ‘NSEntityDescription’ responsible for creating objects and adding them to a context seems like a somewhat dubious design decision.
For Random Dice Roller, I wanted to have pretty looking buttons with rounded corners. If you google for something like ‘ios custom button with rounded corners’, you’ll find various examples that use setMasksToBounds and a corner radius, like this:
This was my initial approach, and it worked flawlessly. My button corners were perfectly rounded.
However, when I added animations into the mix, things didn’t quite work out so well. There was a noticeable lag when animating my screens full of buttons with modal-segue-style transitions. I tracked it down to the call to setMasksToBounds. With setMasksToBounds set to false, the animations were liquidy smooth, as expected. But turn it on, and things get choppy.
I didn’t want to release an app with noticeably choppy animations, so I started looking for a solution. Turns out that it’s ridiculously easy to solve the problem – just use a transparent .PNG with the corners already cut out!
Check out my sample project to see the difference in performance.
If you run it on the simulator, it will appear to work fine; run it on your device, though – in my case an iPod Touch 4g – and you will see some significant choppiness.
The moral of the story is that setMasksToBounds can cause performance issues, and if you can avoid it, you should.
Your spam is being blocked. Please give up and go bother someone else’s blog.
This blog has been the target of a few hundred spammy trackbacks over the past week. Thanks to the ‘Simple Trackback Validation with Topsy Blocker’ plugin, none of it is getting through.
Anyone have any good tips on how to avoid being the target of spammers?
Random Dice Roller, April’s 2nd app – or May’s first app, depending on how you look at it – is now out the door. As always, it’s time for another postmortem.
Review Time (time spent in the iOS app submission queue):
New technologies I learned and used:
- The main new technology here was networking. This was my first iOS app that touched the network in any way, shape, or form. Aside from the incredibly annoying extra-long default timeouts, it went quite smoothly, and resulted in my open-source class ReallyRandom.
- I ran into some performance issues when using setMasksToBounds: to round the corners of UIButtons. This will likely be the subject of a blog post in the near future.
- Taking good pictures of dice is hard!
Future plans: I have quite a few plans for Random Dice Roller. So many, in fact, that it was a difficult decision to actually release it, instead of spending more time adding new features. But in the spirit of release early, release often, I decided to let it go sooner rather than later.
There are two things that will likely be coming at some point in the future. The first one is the ability to roll multiple sets of dice at once; that is, instead of just being able to roll something like 3d6, you could roll 3d6 + 2d8 + 1d4 all at once. This would be quite handy for those games of D&D.
The second one is in-app purchases of different dice sets. I’m not sure what exactly the market would be for that, but I figure it’s worth a shot.
As always, please let me know if you have any feature requests or ideas!
The ‘Sales and Trends’ section is the worst dashboard/analytics platform I’ve ever seen. It’s combination of uselessness and bugginess is unmatched.
Let’s start off with a look at a few of the issues that I’m sure you’ve all seen before. Eagerly awaiting your sales numbers the morning after your app is released? Too bad.
You would think that Apple would at least do some basic QA to make sure stuff displays properly. But, they apparently don’t.
Grammar? What’s that?
The attention to detail is astounding.
But enough of the minor annoyances. The real problem with Sales and Trends is the lack of functionality.
When you select something from the dropdown above, you aren’t selecting a “week” or a “day”. You’re selecting the end period for some arbitrary, unknown date range. Why can’t I simply choose a date range to view results for? Why am I limited to viewing the results for the past X days or weeks, starting at day or week Y?
Why can I only view data for the past few weeks? Apple is one of the richest companies in the history of the universe, but they can’t even spend a few fractions of a penny on a few extra bytes of storage for historic data?
Why can’t I filter the results by product?
Why does it always show me ‘Free Apps’ by default, instead of remembering that I was previously on the ‘Paid Apps’ view, and that every single time I log in, the first thing I do is click on ‘Paid Apps’?
Why does Apple’s development ecosystem continue to frustrate and disappoint?