Monday, February 16, 2015

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!

Monday, June 2, 2014

Realizations and Level Setting

I had a bit of an epiphany lately that I think is worth sharing at this point. I am following someone on Twitter who's handle is @HobbyGameDev (his G+ is +Chris DeLeon (HobbyGameDev)). It was through the work Chris has been doing that I've started realizing that maybe I've been looking at Otto Von through the wrong lens. In particular, am I truly committed to making Otto Von a "going concern" that could provide a career for me - with all the associated risks - or is it more of a "hobby".
I think the answer that I've been leaning toward, at least presently, is that it's more a hobby than a career. Would I like to do Otto Von all day, every day? I think I would probably say "not really". Not that I like having a job and I would love to work for myself rather than someone else, but all of the uncertainty around being an actual indie developer may be more than my risk-averse situation allows for at present.
When I think about doing that, I realize there are some prerequisites, skills, and connections I need that I don't have. First, I would need several months worth of savings available to really take a stab at doing this as a career and right now I have several years of negative savings available. It's been a very rough year financially. In all honesty, we weren't really able to afford to send my daughter to Waldorf for as long as we did, but we've finally figured it out. It's also a great time for her to transition out as she's going to be starting middle school next year.
Secondly, there are definitely some skills that I don't have (some very well documented here), nor do I have connections with people who DO have those skills. Or, rather, have connections with people who have those skills and are willing to do this kind of thing as a partnership with profit sharing. Maybe I just need to find some HS students who have tons of free time and lots of drive. Regardless, it's been challenging and while I can put out some apps, they're not going to have the kind of polish and "oomph" that I'd like them to have. Will they be "good enough"? Probably. Will they provide the kind of income I need to make this a career? Probably not.
So, given that Owen Goss (of Streaming Colour Studios and Milkbag Games fame) did a survey a couple of years ago and learned that the average lifetime income from an indie game is $1200, I would need either a TON of games out there, or I would need to be better than average. And that's the mean, which means that 49.9% of games earn less than that. And that would require a lot more games.
So, what does all of this mean? It means that I'm not an indie trying to make it in the bigger world. What I really am is a hobby developer enjoying what he does.
Happy coding!

Monday, April 7, 2014

One more gotcha

As I was writing about UIScrollView and auto layout I remembered another problem that gave me apoplectic fits last night. I had just published OttoJotts Beta 1.1 out onto TestFlightApp.com (one of the greatest resources for developers) and found a small bug. I went in, fixed the issue, recompiled and got a very strange error. I was able to build the application, create the archive (Product | Archive), and distribute it, but when I tried adding it to TestFlightApp it would prevent me saying that a required flag in the Entitlements.plist wasn't set.
This perplexed me because I had just done this not an hour earlier with no problem - why was it now beginning to give me flak? I tried thinking through what had changed - just code, I thought - and what might now be causing the problem. "Fine," I thought. "I'll add the damn flag." But I couldn't. Well, now what?
I thought the problem might have been associated with the different provisioning profiles I had set up, so I decided to clean them out. I went up on to my developer account, removed some old, expired certificates and some newer, active (but unused) certs. Then I went back to Xcode and synched my account. It looked like everything got set up properly, so I went back and tried to compile. Success. Then I tried to archive. Failure. And the failure was weird - it couldn't find a provisioning profile. I had cleaned up several and had specifically built using one profile but it was trying to find another one. What the heck was going on?
I searched the interwebs and came upon something in the Xcode project file. I think it was on stackoverflow.com that I found the solution, but I apparently needed to remove some lines from the project file that were referencing the old profile. I made my changes and tried it again - and everything was happy. Even when I put it up on TestFlightApp it went up seamlessly. Yay. *headdesk*
What's the lesson from this little excursion? Perhaps to be careful about when and where you manage your profiles. Or perhaps it's just to be a little wary of how well Xcode integrates with the developer center. I wish I could say it's a matter of reading the whole error message, but in this particular case it wasn't useful in the slightest. Good luck and happy coding.

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.

Saturday, February 8, 2014

Facepalms

Before the holidays, I was really focusing on OttoJotts by trying to finish up what were a dozen or so tasks that needed to be finished before I could release the game. I had determined, based on the lack of response I was getting from my artist on a separate project, that I should focus on something that I had a lot of control over and had made some good progress on completing. After I broke everything down that remained to be done, I found that I had a month or so of work left on OttoJotts to finish it off. I blazed through several different tasks, had to create some new ones, but overall was making some good progress on it. Then the holidays happened.
Catniss in Nutcracker
The Thanksgiving to Christmas period at my house is one of lightly ordered chaos. Catniss has several performances of The Nutcracker with the Colorado Ballet during that time and the spousal unit sings professionally as a caroler for different functions. Toss in a couple of illnesses and the whole time is just ridiculous. I was certain I wasn't going to get much done over the break so I didn't really even bother. And then for Christmas I received Call of Duty: Ghosts, so I had at least a campaign to complete before I could get back to anything. Then it was January and I joined a CoD clan and then we had a clan war and then... Long story short - nothing really happened on OttoJotts from November through January.
When I tried to get back into it, though, I found it more and more difficult to get back into the groove. I found plenty of opportunities to procrastinate and not work on OttoJotts at all - including finding some data from fiksu.com about iOS 7 adoption (you need to check out that site). Given that adoption rates are around 82% for iOS 7 and I've been having trouble getting OttoJotts to draw properly in iOS 7 (something changed in the basic UIView stack I still don't understand), it put even more of a downer on wanting to work on it. Plus, I had something else potentially brewing at the 9-5, so my motivation was a little more depleted than I thought it could be (without being completely disinterested).
BUT (and it's a big but), that's when things started heading south. The "something else" dried up and I started feeling like the 9-5 isn't going to be terribly viable for much longer (which suxors hardcore). Suddenly, without really feeling like I was up to it, I decided that I need to get back to doing what I should be doing, even if I didn't feel like it. I started checking out what needed to happen with OttoJotts and just couldn't, for the life of me, actually open up the project. I'm just a little burned out on it. It was supposed to be a pretty quick little app that would go into the App Store and then maybe make a buck or two. Instead, it's turned into months and months of continuing development that don't quite seem to be going as well as I'd hoped. All of the backend work is challenging for me (I'm a front-end - but not UI - guy). While there are still only about 80-100 hours of work left on it, I think I'm going to put it on back burner while I reinvigorate with something else for a while.
I thought I had been recharging a bit by playing some other games and taking some time off, but I think it's had the opposite effect. It's put new and interesting distractions in my path to getting anything done for real. Unlike some acquaintances, I haven't hit it big on the App Store and can't just semi-retire at the moment. Until then, it's nose to the grindstone no matter how distracted I want to be.
It's not that I don't love doing this - I do - but it's that I just find myself in the same position over and over again: unable to complete some portion of the game because I lack some skill. I need to either acquire said skill or find someone who is willing to help - and unfortunately I haven't found people who are likeminded about doing this. Or I do and they totally flake. *sigh* As a result, I have a hard time being motivated to work on things.
My favorite captain
All of this said, I have about 4 games that are in various stages of completion. If I can just get ONE of them done and out, I think I can make enough to either hire the people to finish the others or perhaps attract enough interest to get people engaged. And then I'd have a small group of games earning a little money in the store for me and that might be enough to get the ball rolling. Which would be totally cool.
So, I am once again ditching my current project (OttoJotts) for something else - for now. Hence the facepalm (to left). It's been a rough few months and I am not at all motivated to do this, but I am motivated to not be dependent upon a salary. I'm not thinking of quitting any time soon, but going to work when you don't have to makes the trip a whole lot easier and more pleasant. And THAT'S the goal - to have the flexibility to do what I want to do when I want to do it. Don't we all?


Saturday, September 14, 2013

Cautions and issues with iOS 7

I've been working on OttoJotts quite a bit over the past few weeks, making some great progress. One thing I've had to do is perform all of my testing in iOS 6 and earlier because I'd been seeing weird display problems with iOS 7. I thought it might have been just some issues with the betas of iOS but now that I have the gold master of iOS 7, I'm seeing the same problems. And now you can too:
iOS 6 on left, iOS 7 on right
What you're seeing is what the screen looks like in iOS 6 and 7, side-by-side comparison. Each letter is a label and I load a box and place it behind each label. On everything but iOS 7 it displays properly as you can see. I thought it might have been a problem with the background color on the label being something other than clearColor, but that doesn't seem to be the case either. I don't know why the boxes aren't displaying at all right now. Definitely going to require some additional work before I put this out to the App Store.
I am pretty surprised by this pretty major change in iOS. This seems like pretty basic functionality that has been changed. I know that a lot of it is because of the new UI paradigm that Apple is trying to introduce, but this seems like quite a major change in implementation from previous versions. What this seems to me is that every app developer is now going to have to be extremely careful about this upgrade and what it means to their apps.
Good luck with your apps.

Sunday, September 8, 2013

Crawling toward the goal line

For several months I've been using a Kanban board (via www.kanbanflow.com - a great FREE resource) to track the work I need to get done on OttoJotts. It's been helpful seeing both the work that I've been getting done (very minimal) and what's still left to do (big and growing daily). That said, it's been nice going through and moving things from Ready to Pull to In Progress to Done. I'm keeping my WIP (work in progress) limit to one because, yeah - I'll get distracted if it's more than that.
Part of my Kanban board
Almost all of the work left to do is around the two player game. I will need to go back and sort out all of the bad decisions I made around single player games when I get into Beta, but until I complete these remaining 11 stories, that's not worth my time. The nice thing about the board is that I can see how much time I've estimated it will take to complete each story. And when I sum them together, I get 176 hours remaining. Which is actually pretty cool. I am, in theory, 4.25 weeks from being done with OttoJotts. Assuming that I worked 40 hours a week (which I don't) and that I haven't terribly over- or underestimated any of these stories (which is kinda likely).
STILL! 176 hours is actually reasonable. There is real potential to be done with this thing before I sprout daisies. And bringing together a lot of technologies and pieces that I have only some familiarity with (and certainly wouldn't claim proficiency or expertise). Well, beyond using agile methodologies to track the work (and even that was a latecomer to the project). Overall I'm feeling, well, accomplished.
I had this gigantic negativity about the project when I put it on the back-burner last year. The size of the work that needed to be done seemed ginormous and insurmountable. But when I picked it up again and poked at it I saw some small successes and those kept building into other successes - small, to be sure, but present. And then when I finally took an accounting of all of the things that I wanted to complete before I could explore the possibility of releasing the game - 176 hours were all that remained. And out of those 176 hours there are 80 hours that I put in for what I consider will be some large efforts - things I don't have any idea how to do. The good thing is that they're down well-trodden paths - I just need to find the guide map and make my way down those paths.
So, it's been a LOOOOOONG winding road getting here, but the end really truly is in sight. And thanks to tools like KanbanFlow I've been able to focus on prioritizing the work I need to do next and focus on the current item only. And, hopefully, this is the beginning of something really exciting.

Thursday, August 1, 2013

Strangeness with cryptography

I've been working on user logins for OttoJotts over the past few days. I made quite a few changes to the back-end and now need to make sure the app on the device can access the database. Unfortunately, I've been running into a bit of strangeness around the cryptography that, quite honestly, really makes me "wanna go Hmmmm". And here's what's going on.
I originally compiled this application for iOS 4.2 because I was looking for the broadest acceptable application I could make. And things seemed to be okay. But when I started compiling for other versions (different makes of iPhone and different iOS versions), I started running into problems matching the hashed password I created with the one in the database. At first, I thought I might have just entered the password incorrectly. Then I thought that perhaps I'd forgotten the password I used. But as I've been experimenting, I've been seeing some extremely odd behavior. I've been using the awesome HashValue.m/.h from Matt Gallagher over at CocoaWithLove.com. I thought it was going fantastically until this weirdness. So, here's the weirdness:
  • iOS 5.0 hashed password:
    • 688c25748beb3803ad93d8988517c460bb15b6373d0d67ad7167726a0ecafaa6
  • iOS 5.1 hashed password:
    • 1199821a832d0101cec47672ad52dfeba2fc72e9e4afbe1d9d2f53918d9fb581
  • iOS 6.0 hashed password:
    • 0640e82d98943f4856dc687618e458178caaf696151235271f689d634f861c69
  • iOS 7.0 hashed password:
    • c19c441adbd2f45366d28a9dcb45cb9858bc721f09d11cd958a7b065a4976f19
I have to assume that I'm doing something wrong here. I mean - SHA256 and MD5 should be the same result regardless of what kind of OS is calculating it, otherwise it would be worthless as a check. But I'm definitely seeing different behavior from the different iOS versions. Changing devices doesn't seem to change anything - just the iOS version.
I dug into the HashValue.m code and all it does is call CC_MD5 and CC_SHA256, which is standard iOS. So I'm a bit perplexed, at this point, as to what I'm doing wrong. If anyone has any idea what's going on, I would really appreciate what you think is the problem.

Update: 01 Aug 13 @ 21:51
Looks like the wrapper I was using had some oddness about it. When I changed over to calling it directly, everything worked perfectly - I get the same hash every time, regardless of the OS version. Which is exactly what I expected. So now that I've resolved that, I need to stick all of this stuff in the keychain and I can call it a day. F*k me.

Tuesday, July 30, 2013

Lessons learned

So last night I was working on getting a singleton1 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.

Sunday, July 28, 2013

OttoJotts REBORN!

Once, a long time ago in a land far, far away, there lived a wanna-be game developer who decided oh-so-frivolously that he would write a game based on a game from his youth. One that he had played with his very erudite mother and worked wonders to both improve his vocabulary and his spelling. He thought that he could write the basic game in a few weeks and then the multiplayer version in a few months and be done by the end of summer. But alas - our wanna-be game developer had a case of the hubris.
He was able to complete the core game mechanics in a week or so and then spent far, far too many days working on getting the user interface to work. For, you see, our developer wasn't "graphically inclined" (read: his artwork suxors). So he spent many a day trying to get some basic things looking good enough to play. And then - amazingly - the single player version was complete! And there was much rejoicing!
As he began to work on the two player version, however, he stumbled and stuttered and fell flat on his face, for his game required a "back-end" (read: database and middleware to talk between the device and the database). And he despaired because again, alack, his database skills were "lackluster" at best and his middleware skills were, perhaps, rated "mediocre". He worked diligently, though, trying to connect all of the pieces. And finally, he got some of the information he wanted to get from the device to the database and back again! And there was more rejoicing!
But then came the actual "two player" work. And there was much gnashing of teeth and grunting of exertion and swearing of curses. And the developer grew weary and tired and despaired of ever completing his opus. He feared that perhaps he would always just be a "wanna-be" game developer.
And then the Great Fruit From Which A Bite Has Been Taken decided that the manner in which he getting information from and to the database was WrongTM. And it was deprecated (read: removed). And the developer was despondent. Not only would he have to actually finish the work to allow two player games to work but he would also have to change all of the code that worked to do that work. And he despaired. And exerted. And cursed. And gave up.
One day, he found that his current hosting provider was deprecating the product he had grown to love these past 10 years and would require that he move to one that was far more limited or one that was WAY more complicated. He decided to move his website and his databases and his code to a new provider who offered a product more in line with his old product. And it was good.
Then, while distracted with another as-yet-fruitless pursuit, he decided to open up the old code and see whether it was possible to make the needed changes for the new database host and make sure he followed the rules of the Great Fruit From Which A Bite Has Been Taken. After looking at the code and the middleware he decided that it wouldn't be that bad after all. And he poked and prodded the middleware, making a tweak here and a revision there until - it worked! And there was astonishment!
And our poor, despondent wanna-be game developer is no longer so despondent (although he is much poorer). He had Purpose. He had Intent. He had - a real opportunity to actually get back to finishing the damn thing.
So now, to you, my gentle reader who has so patiently put up with this long and purposeless fable, I make claim to the Twitterverse, the Facebookverse, and general Internetverse that OttoJotts is REBORN! And it WILL. BE. DONE! (By Halloween.) (No seriously, I mean this.) (Stop laughing.) (Dicks.)