Corona SDK and Code Signing

It's been forever since I posted anything here. A lot has happened since I last posted. I left my old 9-5 to start an agile training, coaching, and consulting company called Artemis Agile Consulting. A LOT of my effort has been focused on trying to get that moving forward. As a result, I've been working in my "copious free time" on games. I ran into some problems with OttoJotts that I was having a REALLY hard time solving so I decided to take a break, get some fresh perspective, and work on something simple that's based on an idea my daughter had.

Basic app with VERY placeholder graphics

The game I'm working on right now is called Cats and Dogs. You play a secret agent cat or dog trying to prevent a bad guy from taking over the world. It's quite simple, in a Flappy Bird kind of way, but I hope it will be enjoyable. And silly. Silly is the key. I decided to try Corona SDK as my app bed because it allows multi-platform support. I really don't want to learn Java at this point in my career, so this seemed like a good solution.
I've had success with Corona in the past. I wrote a simple app to help developers on my teams at the old 9-5 estimate story points using a Magic 8-Ball. You'd shake your device and it would show you an estimate - anything from 1/2 to infinity using a modified Fibonacci sequence. They had complained about "how hard it is to estimate", so I made it easier for them. And we laughed about it. But the experience was great - everything worked seamlessly for both Android and iOS and I was happy.
I've been working on Cats and Dogs for a few months off-and-on and decided that it might finally be in a place where I could put it on my daughter's phone for her to play with. It's nowhere near "done", but it's enough that she can at least play it. So I began the process to build it for iOS and get it going. And that's when I ran into the dreaded "The application does not have a valid signature" issue in Xcode. This is a common error based on the number of stackoverflow questions about it.
Corona has quite a lot of documentation about how to build your application using their simulator. There are also quite a few gotchas. Corona lists several things that can prevent your app from installing on your device: expired profiles, spaces in your project name, etc.
First, let me say that I was using the Xcode Devices window to install the application. I tried iTunes, which seemed to work, but after it put the app on the device it greyed out the icon saying it was "Installing" - iOS speak for "not gonna work, broh". Second, I was using a version of the SDK from November but downloaded the new version (2511) in the process. DO download the new version - the shell console makes it worth it.
For me, I had made sure that I created new certificates for both development and distribution - it had been a while and was worth refreshing everything. Then I created App IDs for both dev and distro and then provisioning profiles. Everything looked shiny and new. I had some old profiles that had expired, but as I wasn't using them anymore, it didn't seem like a big deal. I thought I was pretty much golden.
When I built the app, I made sure I was using the development profile and provisioning profile. Looked like everything was happy when it built but when I tried to install it I got the "Application does not have a valid signature" problem. If you right-click on the device in Xcode it will show you what profiles are installed - and all four of the new ones were, so I was confused.
After I began exploring the issue, I saw a couple of things that might be causing problems. First, I had expired profiles. So I followed the directions and deleted them from ~/Library/MobileDevice/ProvisioningProfiles (the shell console will show you the expired profile IDs). But if you got into Xcode | Preferences and refresh your profiles from iOS Developer Center, it will simply re-download them, which doesn't do you any good. So what I did - unnecessarily, I believe - was to edit all of my expired profiles and renew them. Rebuild, re-install, failure. So it wasn't that.
Then I found that you can't have spaces in the project name. I was using "Cats and Dogs" as my folder for my project, so I made a new folder called "CatsAndDogs" and tried it. Rebuild, re-install, re-fail. Check that one off the list.
I went through the shell console and noticed that it tells you what it actually puts into the bundle. I've been using an Excel spreadsheet to check some things and saw, in the build, that it was putting my Excel sheet in the app. Say what? So - let's remove that from the source folder and try again. Rebuild, re-install, re-fail. Okay - so, not that.
More searching, more looking at parts of my app and source and folders. Nothing. Then I decided to see if it was my project or if it was iOS Developer stuff and I opened the Hello World sample. Build, install, fail. Aha! So it's not my project, it's my provisioning profiles somewhere...
One of the threads I read say to go through your keychain and remove old profiles. I searched for "iPhone" and found a few items but now something stuck out a little. I had two Developer profiles. So I went to iOS Developer Center and downloaded my brand-spankin'-new developer certificate, removed both certs from keychain, and then reinstalled the new one. Then - rebuild, reinstall, and - success!
So, what worked for me (for development, at least) was to remove my old certificates and install my new ones. If you're still running into problems and don't have a "resources" folder in your project, don't have spaces in your project name, and aren't using expired profiles, maybe delete your certificates and install ones freshly-downloaded from iOS Dev Center. Hopefully it works for you!

Autolayout and UIScrollView

Just a quick update on a small problem I uncovered. I was working on OttoJotts last night trying to get Beta 1.1 out the door (I did eventually get it out, although it was Beta 1.11) when I stumbled on a problem with the UIScrollView I'm using for the help file. When I created the first Beta 1.0 I ran into an issue with the buttons not working on 4 inch screens (I originally wrote the app for iPhone 3G to give you an idea of how long this has been). I went through all of my xib's in Interface Builder and updated them to use auto layout and - ta da! - everything worked. Except for help.
My help screen has two elements - a UIButton to close the help screen and a UIScrollView to view the incredibly long png I created for the help (it's over 2k pixels in length). When using auto layout with a UIScrollView, the scroll view interprets the setting meaning a slightly different experience than what you'd expect. When I turned off auto layout, the scroll view worked perfectly well and I was able to view all of the help text correctly - with one exception: the UIScrollView was now positioned at the bottom of the interface rather than directly under the button.
I still have some things to work out with the 3.5" and 4" screens so I'm holding off on fixing that until a later date. Still, it's something to keep in mind - UIScrollView and auto layout are not good buddies.

Lessons learned

So last night I was working on getting a singleton¹ created to store the player data so that I don't have to track it through all the different view controllers in OttoJotts (there are quite a few). I had done it with the dictionary already and that was working beautifully, so I thought this would be a piece of cake. I created the new class (using NSObject as the base), pretty much copied and pasted the code, made the requisite changes, and compiled. And I got this cryptic message:

The unusual error

I was a little surprised. I had declared that PlayerAccountData was a singleton. I mean, hadn't I just copied and pasted the code? Hadn't I made the changes that I needed to make? I went back and checked - yes, everything looked correct and all the changes had been made. What the heck was going on here? Why would this not compile? Obviously I'd done something wrong. Oh wait - this was the Xcode 5 developer preview; could that mean something? I searched online to see what I could learn and was stumped. Nothing seemed to work. And no one else seemed to have seen this. What on earth was going on?
Then I noticed that things seemed "not quite right" in the file. And here's what I mean by "not quite right":

Comparison of the new and old code

The original code had coloring for the SYNTHESIZE_SINGLETON_FOR_CLASS macro which the new code didn't. Now what the hell did that mean? Why didn't it recognize it as regular code? I tried adding the #import for the SynthesizeSingleton.h - no luck. I tried removing it - no luck. So back to the web! And nothing. And I had a sad face.

Something made me open the right-hand side bar for the file - and that's when I noticed something interesting. There was a check box under the section called "Target Membership". It was unchecked for the new file. But right there was my app logo next to the check box. And when I clicked it? The syntax coloring changed for SYNTHESIZE_SINGLETON_FOR_CLASS! Well, how 'bout them apples?

So what was the lesson learned or, in my case, re-learned? Really check to see what's happening with the error messages you get from Xcode. Sometimes they seem cryptic but actually contain the exact information you need to fix the error. But I think in this particular case it means that sometimes the differences between what you expect and what you get may be slightly hidden from you. I didn't even think about the right-hand properties sidebar for my .m file - and it didn't dawn on me that when I added the file to the project that it wouldn't be appropriately associated. But the next time I add a class, I'm going to be double-checking to make sure that the target membership is set correctly. And maybe this saves you a little time in the end too.

Happy coding.

1. The SynthesizeSingleton macro I'm using is from the incredibly awesome Matt Gallagher of CocoaWithLove.com. The singleton code is located here.

UITableViewCells and Forgotten Wisdom

I've been playing around with a new game for my daughter based on an old game called Electronic Detective. I'm actually making a version of it for her to play (since my old solid state system, for some reason, only plays about half a game before crashing out). I had originally planned on making everything fit onto a single screen (which would have been better on iPad, but I'm a sucker for pain which is why I'm making it for iPhone), but decided to be considerate and moved from a single UIViewController view to a new UITableView layout. But the new version of Xcode makes creating UITableViewCells a little, um, wonkier than I remembered.
NB: I'm sure this is all 1,000,00% easier with storyboards, but I'm not using them as I'd like to target devices more than 6 months old. And yes, that was some slight sarcasm.
The first thing I ran into is that when you add a UITableViewCell .h/.m to your project, it doesn't allow you to create a .XIB with it. You need to create the .XIB separately. Then, the thing I've learned, is that you need to set the class for the VIEW to be the new .h/.m class name you selected. Do not set the File Owner to be the new class - leave it as UITableViewCell.
If you don't do that and leave the view as the UITableViewCell or if you set the File Owner to be the new class, you're likely to run into a dreaded "this class is not key value coding-compliant for the key XXXX" error. This is not terribly useful but some searching on slashdot and other places guided me in the right direction. If you've come here because you searched for that and you're using UITableViewCells, then here is likely what you're seeing as a problem.
This is one of those problems that I continue to stumble upon as I work through things only periodically. I forget some of the tricks and tips I've learned previously. But as my spousal unit and I have decided that she will not be returning to her job at Lockheed-Martin (as they have recently changed their leave-of-absence policies denying her the ability to take a second year off to watch our illness-prone son), I need to start getting some more titles in the App Store - and quickly. Given that, I will be working more feverishly to get things completed and released and will be sharing far more on this blog than I have been of late. And I will hopefully be retaining more of this forgotten wisdom.
Wish me luck!

Care when posting from the web

I've been working on a new application (Electronic Detective for my daughter) which will be the basis for a longer-term game effort and ran into a strange thing. I decided that how I was going to be doing the UI for a particular portion of the game was just incredibly clunky. I had remembered a piece of information that needed to be included and rather than shoehorn it in, I decided to take a step back and see what made the most sense. In this case it was changing things from a static UIView to a UITableView. This opened up a lot of potential real estate and made it possible to do some things I was struggling to fit on the screen before.
I was searching to find the best way to get UITableViewCells working with the new Xcode (4.5) since they've sort of changed how they operate since last I'd done one (a long time ago - in a galaxy far, far away). I found a good sample from a blog post and decided to just copy/paste and modify the sample code. And things were fine - until I got a very strange build error - "unexpected '@' in program". Um, whiskey tango foxtrot was that? I searched a bit more and the answers proposed didn't seem to really address my particular error. Here was the offending code (from a code blog I found):

- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath

{

 static NSString *CustomTableCellIdentifier = @”CustomTableCellIdentifier”;

 UITableViewCell *cell = [tableView dequeueReusableCellWithIdentifier:CustomTableCellIdentifier];

 if(!cell)

 {

   NSArray *nib = [[NSBundle mainBundle] loadNibNamed:@”CustomCell” owner:self options:nil];

 if(nib.count > 0)

 {

   cell = self.customCell;

 }

 else

 {

   NSLog(@”failed to load CustomCell nib file!”);

 }

 }

 

There didn't really seem to be anything wrong. The highlighted lines were the ones causing the problem and I couldn't really see a problem. Each of the literals was perfectly correct. What the hell was going on with this code? Then I stumbled upon a stackoverflow question and answer that provided a little insight. What was weird about the editor was that it wasn't showing the text formatted as "text" - it was just showing as black text, not the typical red you'd see. Then I read the part about the "smart quotes". I replaced the first "quote" with a regular "quote" and the text higlighted. That's when I realized I must have pasted in smart quotes and that's what was causing the problem.
I replaced all six quotes and things started working the way I expected. So, as a word of caution, Xcode apparently will maintain some special characters when you paste code from other sources. Make sure that if you're pasting that you double-check the characters. If things don't look correct to you, they probably aren't. It may be a bit weird, but it may be worth your effort to retype some of it manually in the editor to see if it's a problem with the paste or with the code. You could save yourself a little mental anguish by trying a couple of simple things. Good luck and happy coding.

*headdesk*

I've been working on OttoJotts all night and now I'm starting to get a headache from something I'm trying to do. The plan I had was to change the color of the letters in the word a person guessed to show them which letters were correct (blue) and which were correct and in the correct position (green). The problem is that there doesn't appear to be an easy way to change the color of a single letter without making a single UILabel object (which I don't want to do) - it would separate the letter and make it look pretty funky.
There is a type called NSAttributedString and NSMutableAttributedString which seem to satisfy my needs, but what I need (apparently) isn't available on iOS 4. And while I can create these objects, I can't seem to modify them easily. Or even difficultly. The problem seems to lie in a constant called NSForegroundColorAttributeName (jeez, Apple) that's not declared anywhere but AppKit. Unfortunately, AppKit is not an iPhone/iOS framework - just Mac OS X. So while I can create these things, I can't seem to manipulate them and change colors like I want. *headdesk*
I've got the code working for the new game play for the difficulty levels - that came together surprisingly quickly. I still need to do a little work on serializing (saving/restoring) the data, but for now, within the bounds of a single instantiation of the game, it seems to be working beautifully. I've got a lot more testing on it to make sure it's solid, but so far it's looking good.
Now all I need is to get it to display properly. *headdesk*

Alpha 3 Update

It's been over a month since I sent out Alpha 2 and the main comment back from testers was: this game is really hard! I've decided I need to focus for Alpha 3 on adding in game difficulty. It's something I wasn't really planning on doing quite yet (it was going to be after this next release), but I think that in order to get the most feedback and to make the game approachable I need to get difficulty levels sorted out.
There are two main changes I need to make to get it working. The first is that I need to redesign the "create new game" functionality. It's kind of clunky right now design-wise, so I'm going to delve into that and get it cleaned up and segmented a little better than it is. The second is that I need to change the main game screen UI to support the easier levels.
The current UI looks like the image on the right. It's obviously very basic (and not terribly helpful), but the idea is that you find out how many letters from your word are in the computer's word. For TOMBS, none of those letters are in the computer's word. FIRED and GLYPH both share one letter, but that letter may or may not be in the right place. (In case you're wondering, the "Debug" button in the corner will show you the word in case you get stuck - but just in the Alpha games.)
I'm envisioning 4 different levels of game play. The first - Easy - will show you which letters are correct and in the right place and also which letters are correct but not in the correct position. Medium will display which letters are correct, just not whether they're in the right position. Hard will be the standard game - you only see how many letters in your word are correct, but not which ones. And Nightmare (because I do love me some Quake and Doom) will only let you know when you place the right letter in the right position (but won't show which letter). Yeah - nightmare indeed.
This is going to require quite a bit of redesign to the UITableViewCell to display this additional information. Plus, the whole background for the game board is very bland and uninteresting right now - just white with controls on it. I think it makes sense to beautify it a bit so it's not so jarringly different from the rest of the screens. So Alpha 3 will be a significant release. I just hope that I can get it working in relatively short order. I guess I better get cracking on it...

Alpha 2 Love

It's official. On Thursday evening I sent out OttoJotts Alpha 2 to testers. I've picked up 3 more testers since Alpha 1, which I'm hoping will help when I start getting into needing to test multiplayer. The Alpha 2 has a LOT of stuff in it, including:

• Statistics for game play, including games played, won, and average guesses per game
• New help file - this is a huge improvement and MUCH better than Alpha 1's
• New background images - basic changes, but look pretty good; not final, though
• Server-based word lists (the entire word list is on the server now)
• Persistence between launches. Less of an issue with multitasking in iOS 4, but a major pain in anything previously
• Automatically scrolls to the bottom of the guesses list on load - something that should have been done for Alpha 1
• Upgrade to iOS 4 support - this was far more involved than I expected it to be
• Numerous UI improvements and tweaks - just a lot of pet peeves and usability tweaks to make it easier to use and understand (I hope)

So quite a lot, but the lion's share of the time was spent in migrating from iOS 3.1.3 support to iOS 4, primarily because some things just didn't work as expected in iOS 4. Part of that arose from needing to refactor a bunch of stuff and reworking some of the child/parent messaging, but overall things seem pretty stable with Alpha 2 (on my devices), so I'm happy for the nonce. I'm hoping to get some feedback on the build while I start work on Alpha 3 (almost completely multiplayer stuff). It's coming together - slower than I expected, but I think it's going to end up being pretty good when I'm done.
Back to the salt mines.

Continuing Hurdles

As I've posted previously, there are some things I really appreciate about Microsoft's approach to supporting its developers (at least back in the day when I was writing Windows code). Primary among them is that Microsoft gives you the source code to their framework, the Foundation Classes. You get to see everything that the framework does, all the way down to the Win32 calls. And even then you can see the disassembly if need be. Apple has taken the opposite approach - they hide everything. I was talking with my mom tonight and I likened it to a server in a restaurant. You tell her your order - "I'd like to put a button in this location with this text" - and then she runs off, makes your order, and delivers it to you, but you never get to see how the secret sauce is made or if the cook spit in your food. Well, right now I'm feeling like Apple's spitting in my food.
I had been working diligently on getting my Alpha 2 completed. iOS 4 had just been released and I figured I'd get A2 out and then upgrade to the new Xcode version that supported iOS4. Then I got my new phone - iPhone 4, yay! (except for the antenna problem - boo!) - but it had iOS4. *sigh* So while I could install my iOS 3.1.3 version of software on my iOS4 phone, I couldn't debug it. And wouldn't you know, I experienced a crash. So I figured - well, maybe I'll just upgrade, recompile for iOS 4 and things will magically work! Okay, I didn't really think that, but I figured I was really close and this upgrade was: a) ultimately necessary, and b) worth the investment. So I bit the bullet and upgraded. And compiled. And fixed some problems.
But then I tried to run it. And found that now it crashes, but in a very unusual way - the stack is getting blown somewhere. Not that I changed anything that would cause that - it's just the combination of the code I had written for 3.1.3 apparently had a bug or there was a feature of the compiler that made it play nice. And this is where the first paragraph comes into play. The crash is happening deep inside Apple's code and I can't figure out where it's crashing.
Because of the crash, I've been unable to actually locate the place where the stack goes "kaboom". I've run into this a couple of times in the past on Windows - unallocated memory in release mode that overwrote the call stack pointers - but this is in debug mode, which should be a lot nicer and friendlier. But because I can't quite figure out where in the framework code it's crashing (because I don't have the source code), I'm stuck now doing another task that I'd postponed until after Alpha 2 and redesigning part of the code to help identify the general area that's causing the problem.
So, while I'm actually pretty close on having everything complete, I'm spending more time refactoring something that I'd planned to do later and am being forced to do now. I guess I should be looking at the glass as half-full as I now don't have to do this in the future, but at the same time my general timeline for Alpha 2 has gone out the window.
So because of a bug that I couldn't track down on the new OS I had to do two additional tasks that I'd planned on doing later. This has actually been the general story of my experience with iPhone development. Of course, Apple does tend to schedule all of their upgrades around the June timeframe (because of WWDC), so maybe I should just stop starting apps in April. And then maybe I'll feel like Apple's not spitting in my food.

Alpha 1 Troubles Continue

I've been trying a variety of different methods to characterize what's happening with my application, but, to date, they've been unsuccessful. I was looking at some crash logs from my phone, but I've been unsuccessful in getting symbolic information for the crash logs. I've been looking online for a solution, but no luck. What I know is that it's not crashing in my code directly - rather, it's buried pretty deep in some core Apple code (which is never terribly helpful). I've been trying to undo the changes I had done to see if that resolves the problem, but, again, no love. I did add some logging to my app and it all seems very happy - my code loads fully and THEN I have a crash.
This is probably the most difficult kind of issue to resolve. First, you don't have anything but the crash logs. Using symbolicatecrash is not an ideal solution to resolving problems. I may need to turn my phone into a dev device and see if I can debug from there. I actually still have several avenues of attack, but they're more alleys than avenues or boulevards. :)
Will keep you updated.