I had the privilege to present this talk at MN Developer Conference this afternoon.
The talk is partially a re-hash of a talk I did back in 2011 on iPhone Games Programming, and it’s partially a re-focusing of a talk I did last year on Generic Game Model (my small collection of Objective-C classes for game development).
Today I had the privilege of giving a talk at Mobile March about Realm, a mobile database that I have been using. I spent about three months last year creating a trivia game with Moai Technologies, and we used Realm to store the trivia. Anyway, here are the slides from the talk:
I’m backing up my iPhone in prep for a new device, and one of the things I did was spend ten minutes taking screenshots of every folder, just in case I need to restore things “manually” later. (Actually, I may decide to start “from scratch” on this new device, and I’ll use these images as reference if I need them.)
Anyway, nobody probably cares about my home screen, but I thought these screenshots of my “TetrisLike” folder were pretty cool. Enjoy!
This week has been all about learning, and specifically about watching videos to learn. Mostly because this week is Apple’s big WWDC conference. The list of developer-specific stuff they’ve announced this week is perhaps slightly larger than usual (including a new programming language called Swift — more on that later), and I have been watching a ton of talks pouring out of San Francisco in video form. (Special thanks to Apple for releasing them so expediently!)
Normally I am fairly un-enthusiastic about watching videos to learn. I’m much more of a do-er than a view-er. I’ve got to be working with the code in order to absorb a new programming language, so the Swift videos in particular have been somewhat frustrating. I did spend most of Tuesday with the OSX 10.10 and Xcode 6 betas, and Swift specifically, but after spending a lot of unnecessary time tripping over syntax, grammar, (and copious crashes) decided to go back to videos (and getting some actual work done).
My impressions of Swift are pretty mixed. On one hand, I love that they’re trying to make a language that is simultaneously more accessible and also less prone to bugs. That is as fantastic and commendable as it is self-serving. On the other hand, I’m not yet convinced it’s going to be an instant switch for me. I had lots of little niggling problems with the syntax. For example, I’m not sure the benefit of declaring strongly typed variables using generic keywords (var and let). In the c-based syntax languages I know and love, you declare the variable with the type. So in swift:
var view = UIView()
vs Objective-C:
UIView *view = [UIView new];
Now, the first example isn’t ambiguous or anything, but how about this one:
var views = UIView[]()
This is how you declare an array of UIView objects. I do like that it will always (and can ONLY) be an array filled with UIView objects, but I do think it’d be incredibly easy to miss the brackets. Overall though, most of the problems I had weren’t with the language itself, but with the tools, which I think are just not ready yet. I mostly agree with Austin Zheng when he says (from the comments of his 2048 port to Swift): “Xcode is as unstable as always. The background compiler/code analyzer kept on crashing and restarting itself. Xcode was functional enough to allow the project to be brought to some state of completion. The debugger is horribly broken though.”
All my video learning this week actually started on Monday (while waiting for the WWDC keynote to start) with watching Facebook’s video on building the paper app. This is also the one in which they announced their open-source animation framework pop. (And was recommended to me to learn about why it might be useful.) At an hour and a half, it’s a long video, but worth watching not just for the pop stuff (which is absolutely interesting, particularly if you already use Core Animation in your code), but for a multitude of other insights into how Facebook writes it’s apps. (There is some seriously interesting iOS engineering going on over there, something I did not expect given their history and track record, particularly in the quality department.)
Finally, yesterday (after fully maxing out on more WWDC videos), I randomly stumbled onto a talk about SpriteKit and grid-based games. The first half of the talk, by Scott Kim goes into great detail about several different kinds of grid-based puzzle games (on iOS specifically). He more or less breaks the talk into categories organized by gesture, which I think is an arbitrary distinction. (I’ve talked before about how I think the best games provide both tap and drag control schemes that are not incompatible.) Otherwise I think he does a really great job with the topic, and while it’s nowhere near comprehensive, it’s a very nice introduction / survey of the topic. This is very close to a talk that I’ve been thinking seriously about writing. (I first mentioned this idea in a previous blog post.) But since I haven’t (yet) written my taxonomy of grid-based games, Kim’s talk is, at the moment, much better than mine.
So I mentioned in a previous post that the For The Win app I worked on for Tasty Minstrel Games was removed from the app store, (embarrassingly right before I spoke about it at GDC). When I emailed Michael at TMG, he revealed that it was just not making enough money to justify paying the $99 to apple to keep it there, and he was happy to let me put it back in the app store under my own account.
So I spent some time last Friday and updated it for iOS 7, fixing a few minor cosmetic bugs here and there, finally submitting it around the end of the day.
Long story short, Apple rejected the app, for the following reason: “11.1: Apps that unlock or enable additional features or functionality with mechanisms other than the App Store will be rejected” They clarified with the following statement: “We found your app inappropriately unlocks or enables additional functionality with mechanisms other than the App Store, which is not in compliance with the App Store Review Guidelines. Specifically, your app allows users to unlock avatars by subscribing to a newsletter, following on Twitter, or liking on Facebook.”
Okaaaay… So a couple of reactions: 1. Obviously, this functionality was approved in the original app. But maybe they just didn’t catch it then. And 2. Doesn’t like every 3rd game in the app store do this? I mean, seriously, I see games giving extra currency for FB likes or even just twitter comments ALL THE TIME. Doesn’t candy crush unlock each level pack with Facebook interactions? (Although now that I think about it, those interactions take their friends back into the app, which is maybe how they get around this issue.)
Alright, so my arguments probably amount to “But everybody else does it!” I’ll be making some changes to just give everyone the avatars all the time (and probably re-word the achievements) and upload a new binary… probably sometime later today.
Oh, and by the way, since the app was in the store for about a year, and presumably some people paid for it in that time, I’m just going to put it up again for free. So the folks who downloaded it before can get it again without having to pay. I am considering adding the following functionality in an update: making it Universal, and asynchronous multiplayer. If and when I do that, I’ll probably shout about it some, and then make it paid again.
It’s pretty amazing that it’s been five years today since I had my first app approved.
It’s been a fun ride.
So I occasionally have the problem where I want to store a bunch of x,y coordinates. I have solved this a number of ways in the past, but most recently had the idea of writing a category on NSNumber that simply stores two 16 bit integers, bitshifted together. So without further ado, here’s the github project for NSNumber+XYCoordinates.
My first version of this I couldn’t get negative numbers to work, but after some patient binary math explaining today at the coffee shop from my friend Matt, I finally got it to support numbers between -32767 and 32767.
Essentially, my category just adds the following methods:
NSNumber *xyNum = [NSNumber numberWithX:10 andY:10];
int x = [xyNum xValue];
int y = [xyNum yValue];
This seems to work pretty great, and is way less annoying than my previous favorite technique, which was to convert between NSString and CGPoint all the time.
So I got to thinking tonight… this should be fast, right? But I have no idea how fast, really, or how to compare it. So I wrote some test cases. Each of them assigns and then reads back out again some number of sequential integers using various techniques that I’ve used in the past. I compiled the following lists for different numbers of values:
100 Values
CGPointToNSString – size of 100 string objects in multidimensional array is 2263 (0.002 seconds).
NSDictionary – size of 100 objects in NSDictionary is 2413 (0.001 seconds).
NSSet – size of 100 objects in set is 1545 (0.004 seconds).
NSNumber+XYCoordinates – size of 100 objects in multi-dimensional array is 2033 (0.001 seconds).
10,000 Values
CGPointToNSString – size of 10000 string objects in multidimensional array is 241803 (0.162 seconds).
NSDictionary – size of 10000 objects in NSDictionary is 289593 (0.076 seconds).
NSSet – size of 10000 objects in set is 199798 (0.044 seconds).
NSNumber+XYCoordinates – size of 10000 objects in multi-dimensional array is 203503 (0.046 seconds).
1,000,000 Values
CGPointToNSString – size of 1000000 string objects in multidimensional array is 31702088 (10.187 seconds).
NSDictionary – size of 1000000 objects in NSDictionary is 38735561 (121.886 seconds).
NSSet – size of 1000000 objects in set is 25866828 (118.003 seconds).
NSNumber+XYCoordinates – size of 1000000 objects in multi-dimensional array is 25919832 (114.918 seconds).
You see that the technique compares favorably against CGPointToNSString, at 100 and 10,000 values, but somehow, the CGPointToNSString technique just blows it out of the water in terms of speed when we get to a million objects. (Still much smaller though.) I don’t fully understand this, but I guess maybe the C API is faster at high volumes? Let me know if you think you might have some insight!
An AdHoc build is how you get iOS apps onto an Apple device without going through the App Store. They are typically used for testing. I was asked this question recently, and spent 15 minutes writing up this reply, so I thought I’d post it here. The obvious caveat is that it can of course vary from project to project. A bigger more complex project has more “moving parts” that can need fiddling with when creating a build.
So… How long does it take to make an iOS AdHoc build?
I use TestFlight to distribute my AdHoc builds, and typically, I tell clients an AdHoc build takes between 15 and 30 minutes to complete. Thankfully this work “stacks” quite a bit, so doing a few of them at once might only take 20 or 30 minutes. This process basically just involves opening the project, verifying a few settings related to provisioning profiles and “targets”, building an “Archive” of the project, uploading the new build to TestFlight, and writing some release notes as well as picking the users to receive the build. (Thanks to the awesome TestFlight OSX app, those last two steps can be done while the upload is in progress.)
This assumes, however, that all the devices are already registered with TestFlight. Everything takes longer when I need to add additional devices. This stacks too, so adding 1 to 10 or 15 new devices only takes another 15 or 20 minutes. The main additional thing that I need to do in this case is upload the device identifiers for the new devices to Apple’s provisioning portal, and download a new (or updated) provisioning profile that includes those new devices. This additional work has to happen BEFORE I can make the AdHoc build for those devices.
What I find frustrating is when all these tasks are split up over the course of hours or days. For instance, when I’m asked to send a build to some new individual, but they’ve never used TestFlight, and aren’t yet registered there. Then I have to send them an invite, wait for them to accept the invite, wait again for them to register their device, then finally I can get their identifier and begin the process. This means either waiting for the new person before creating the build (sometimes this can take days, of course!), or just creating two builds, one with the devices I already have, and another when I get all the important information from the new person. Considering the adage that a “a 15 second interruption results in 15 minutes of programmer downtime” (which is more or less verifiable), these build requests can really add up to lost productivity for me.
One final note about what AdHoc builds are not.
After an app is in the app store, unless you are testing a new version, you should really be using that version, and not an AdHoc build. There are many reasons for this, but notably: 1) AdHoc builds will expire when the provisioning profile expires. 2) You get the peace of mind that what you are seeing is what your users are seeing. 3) You will get the updates via the app store, as your users do. 4) You can instal the app on multiple devices without needing to provision all of them. Don’t forget about using promo codes to get “free” versions of apps to your testers or employees after an app goes live! (In my experience, you rarely use all of them for press as you should, and you get a “fresh” batch after each update anyway.)
AdHoc builds are an integral part of iOS app development, but creating them is annoying to me because it’s not programming. Of course, neither is wring this blog post.
This is probably as good a time as any to mention the next project I’m working on. It’s a turn-based (yes, asynchronous) board game. I decided to work with an existing game, because I wanted it to be really awesome, but also really simple. It’s an abstract game that is well respected in some circles. (I’m not going to reveal which one just yet.) Anyway, I’m working closely with the game’s designer, as well as with the same AI programmer I worked with on For The Win. The main goal of the project is to get the async code really solid, so I can feel like I really understand how it works, and re-use it in future projects.
Anyway, I think I’m also going to try something I’ve wanted to do before, and that is implement a variable color scheme for the app. Essentially you’ll be able to change the app’s background color, and that will also programmatically change the color scheme. I spent about two hours and had the basic color change functionality working pretty great with some code based on an already pretty great open-source color picker.
Anyway, one tiny piece remained… I would need to be able to programmatically tint images I get from the designer on this project. He’s going to give me some icons and other assets that we’ll no doubt want to change colors along with the rest of the app.
Some unknown number of hours later, I’ve got a solution. The number of hours is probably around the same as the number of lines of code in the solution. Here are those lines, implemented in the drawRect: method of a UIView subclass with a UIImage property named image, and a UIColor property named colorToChangeInto.
CGContextRef context = UIGraphicsGetCurrentContext();
CGContextScaleCTM(context, 1, -1);
CGContextTranslateCTM(context, 0, -rect.size.height);
CGImageRef maskImage = [self.image CGImage];
CGContextClipToMask(context, rect, maskImage);
[_colorToChangeInto setFill];
CGContextFillRect(context, rect);
I hope this is fairly straight forward. These few lines stand on the backs of many stack overflow answers. (And I did actually write this up into a question of my own at some point.) None of the other answers were exactly what I needed, but several of them got me close. In the end, I was super frustrated because it really seemed like I should be seeing what I wanted to see, but the background of the image was black… turned out I was instantiating the image in IB (in a storyboard), but I hadn’t set the background color. Somehow that defaulted to black. That particular issue probably wasted me an hour or two.
And then writing this blog post… another half-hour, at least.
This week, I’ve spent some of my time integrating MailChimp into the client work I’m doing. I found some of the documentation lacking, and there is no example for how to add your email signups to a MailChimp’s list “Group”, so I thought I’d document that here.
(Astute readers who are actually reading from chesstris.com will notice the fact that I’ve got a MailChimp signup form on Chesstris.com also. I haven’t done anything with it, and so far, I’m the only person who has signed up, but it’s there. I’m still sort of trying it out.)
MailChimp has an iOS SDK they call ChimpKit, which is available up on github. In general, it’s a great SDK, but the README has some installation instructions that are both incomplete and also pretty stupid, as far as I’m concerned. After fiddling around with it for a couple of hours yesterday, I’ve concluded that there is no reason to include their sample project as a git submodule of your project. The instructions I’m going to suggest basically don’t do that, so if you are ultra concerned with keeping up to date with the ChimpKit project (keep in mind it hasn’t been updated since 9 months ago), then read-no-further, and go figure out how to actually use the classes in their sample project yourself (since that’s what’s missing from their instructions). Personally, I think git submodules are a PITA, and not worth the effort anyway.
OK, so what you really want to do is the following:
1) Download the ChimpKit code. You can clone it on github, or just download, your preference.
2) ChimpKit requires SBJson, so you’ll need to include that project’s files in your project. You can do this as a git submodule if you really want, but you already know how I feel about those. You can also just add the files to your project and be done with it.
3) Grab just the files in ChimpKit’s “Core” folder and drag them into your project (or use the “Add files…” dialogue). Personally, I like to organize code in my projects in a certain way, so I copied the directory into my project’s “Externals” directory, and renamed it from “Core” to “ChimpKit”.
4) If you don’t care about adding your subscriber to a group, you just need to do the following:
4.a) Add the include: #import "SubscribeAlertView.h" to the top of your view controller or wherever.
4.b) Add this code somewhere, maybe after an IBAction or something.
SubscribeAlertView *alert = [[SubscribeAlertView alloc] initWithTitle:@"Newsletter Sign-up" message:@"To sign up for the newsletter please input your email address below." apiKey:mailChimpAPIKey_ listId:mailChimpListID_ cancelButtonTitle:@"Cancel" subscribeButtonTitle:@"Confirm"]; [alert show];
Of course you’ll need to define mailChimpAPIKey_ and mailChimpListID_, but both are strings. If you don’t know your list ID, you can find that on the mailchimp website. (Or by using the “lists” api method, and you can see an example of that below.)
…and you’re done!
5) But assuming you care about adding your subscribers to the group, there are two ways you could go. You could modify the code in SubscribeAlertView, or implement the subscribe form yourself. I’m going to assume the former, and not go into the latter, even though it’s what I’m probably going to do since I think their popup looks like toasted a$$.
6) Next we’re going to find your list’s groups. You might be able to skip this step if you already know the name of your grouping and groups, because the API also supports adding by name, but I think this is a better way because a) you can use the ID, and b) you are sure to use the right strings, because you’ll be copy/pasting them out of the JSON. I actually had to perform this step because I’m not the MailChimp admin, I just have access to an API key.
6.a) First, set up the object you’re going to be calling this code from as a <ChimpKitDelegate> in your header, and #import "ChimpKit.h" in the source file.
6.b) Then implement the chimpkit delegate methods:
#pragma mark - chimpkit delegate methods
- (void)ckRequestSucceeded:(ChimpKit *)ckRequest {
NSLog(@"HTTP Status Code: %d", [ckRequest responseStatusCode]);
NSLog(@"Response String: %@", [ckRequest responseString]);
}
- (void)ckRequestFailed:(NSError *)error {
NSLog(@"Response Error: %@", error);
}
6.c) Finally, you’ll need to run the following code to call the MailChimp’s ‘listInterestGroupings‘ API method. Again, you’ll need to define mailChimpListID_. (I just ran this in a ViewController’s viewDidLoad method.)
ChimpKit *ck = [[ChimpKit alloc] initWithDelegate:self andApiKey:mailChimpAPIKey_]; // get the lists // [ck callApiMethod:@"lists" withParams:nil]; // get the list groups NSMutableDictionary *params = [NSMutableDictionary dictionary]; [params setValue:mailChimpListID_ forKey:@"id"]; [ck callApiMethod:@"listInterestGroupings" withParams:params];
(There’s your example in there of how to get the lists.)
With any luck, you’ll get a response that is a big block of JSON. Use your favorite online JSON parser to turn that into something readable, and it’ll probably look something like this:
[
{
"id":9501,
"name":"Web Signups",
"form_field":"hidden",
"display_order":"0",
"groups":[
{
"bit":"1",
"name":"likes chess",
"display_order":"1",
"subscribers":0
},
{
"bit":"2",
"name":"likes go",
"display_order":"2",
"subscribers":0
},
{
"bit":"4",
"name":"likes puzzle games",
"display_order":"3",
"subscribers":0
}]
}
]
7) Add your group subscriptions by modifying SubscribeAlertView.m around line 140 to look like the following:
NSMutableDictionary *params = [NSMutableDictionary dictionary]; [params setValue:self.listId forKey:@"id"]; [params setValue:self.textField.text forKey:@"email_address"]; [params setValue:@"true" forKey:@"double_optin"]; [params setValue:@"true" forKey:@"update_existing"]; NSMutableDictionary *mergeVars = [NSMutableDictionary dictionary]; [mergeVars setValue: [NSArray arrayWithObjects: [NSDictionary dictionaryWithObjectsAndKeys: @"9501", @"id", @"likes go, likes puzzle games", @"groups", nil], nil] forKey:@"GROUPINGS"]; [params setValue:mergeVars forKey:@"merge_vars"]; [self.chimpKit callApiMethod:@"listSubscribe" withParams:params];
You’ll also note that double_optin was set to false by default. That’s a stupid default, IMHO.
So there you have it. I think you could probably replace the @"9501", @"id" key/value pair with @"Web Signups", @"name", according to the API docs, but I only tried the ID. I also added some code to the SubscribeAlertView‘s requestCompleted:(ChimpKit *)request method to actually let me know that the submission was successful, but other than that, I think I’ve outlined everything pretty well. Let me know if you find this useful.
Oh, and so life happens and it’s July and Oppo-Citrus isn’t out yet. It’s still “right around the corner”, but as you can see I’ve started this exciting (no really!) freelance project. I was definitely hoping this would happen when I set out on my own, and it’s been going great! It’s 20 hours a week of my time, and it turns out that’s actually more than half my time as an indie. (I don’t think it’s because I’m not working 40 hours either, I think there are just hours you end up “losing” to email or twitter or whatever.) Anyway, last week was a holiday week (the boss gave me two days off!), and I’m planning on slacking some this week too, so I haven’t worked on Oppo-Citrus as much as I’ve wanted. The next goal is to get it at least submitted to apple before I leave for vacation the last week of this month. We shall see. We shall see.