Showing posts with label xcode. Show all posts
Showing posts with label xcode. Show all posts

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, 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.

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.

Monday, January 21, 2013

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!

Sunday, December 30, 2012

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.


Sunday, August 19, 2012

More Mayan Madness and Inspiration

So it's been a while since I've posted. Unfortunately in the weeks since then I've had a hard drive "almost" fail, a Time Machine restore TOTALLY fail, the hard drive FINALLY fail, and lots of restore pain. In short, it's been a hell of a few weeks. But now I'm mostly back to normal (well, the laptop is) and running again.
19 Aug 2012 in Long Count
I've been working on the Long Calendar app for the past few days. So far I've added a lot of better graphics to it so it looks better than it did before (see picture to the right). I think it's starting to look a little better. I wasn't planning on working on the glyphs until I had completed everything else, but I'm actually really close now. I have two remaining bugs. For some reason the Haab and Tzolkin calculations are incorrect. I'm guessing I messed something up when I fixed some +1/-1 problems earlier. And BCE dates aren't working correctly right now. Again - I think I managed to break them at some point during development.
One thing I'm not doing much and need to be doing a lot more is the unit test. Xcode 4.2 integrated a unit testing framework into the system, which is awesome. I need to spend some time really beating it up and understanding it a lot. With this applet I feel that it could be beneficial (it would have caught the changes that broke the calculations), but I'm also pretty far down the path. I've got a set of tests that I do whenever I make changes, so I'm not totally out of sync with current development methodologies, but still feel that with all of the agile experience I have that I'm not being "true" to the methodology by not doing it for my own projects. Especially since Apple has done the "right" thing by encouraging developers to do it. Next project I must do it.
Regardless, things are starting to come together with this. I expect that I'll be able to get this completed this week, I hope, and get it into the AppStore next weekend. Earlier would be better, but there's a lot going on right now - lots of swirl and lots of stress.
On a good note, though, I spoke with a friend from my HP days - Cooper. He works at Microsoft right now and I was in Seattle last week and rang him up. He's one of the most talented engineers I know (perhaps the most talented). He's also one of those people who is completely committed to whatever it is that he's working on at the moment. He inspired me to work on things that made me happy when we worked together. We actually started talking about starting our own company before MS offered him riches that would make Solomon blush. But it's Coop who really encouraged me to dream bigger and work harder to achieve those dreams.
I've sort of lost sight of that in the doldrums that are everyday development. It's easy to forget the why of what you're doing in the day-to-day of doing. What do I want to have? The ability to be with my family when and where we want to be. To be able to provide for them while not being beholden to a time clock at a wage-slave job. To not be a sarariman. As you probably know, I have a 9-5 at Comcast. The "job" is good - challenging to be certain, but I'm well-compensated and enjoy working with my coworkers. But it's not what I want to do in the long-term. Before I got this job I told my wife that I wanted my next job to be my last one - that I would make this Otto Von thing work come hell or high water. And what's happened in the 2.5 years since I started at Comcast? Not a whole lot. I've managed to learn a lot but at same time waste a lot of effort not focusing on the end goal.
Talking with Cooper has really re-focused my energies on that end goal. I was reminded of the possibilities we had back at HP. Of the things we talked about doing and the places we'd go. Of the games we'd write and the lives we would change. Of the paradigms we'd create with our innovation. We'd be the Nintendos of the game world. And that's gotten lost.
So, here we are in August. What will the next few months bring? I don't know, but I do know that I'm reconnecting with those "halcyon days of my youth". I'm remembering WHY I'm doing this and why I need to make this more than just a hobby. It just takes a look at my family and a chat with an old friend to bring everything back into focus with a clarity I could scarcely recall. Almost like a haze that slowly dims your vision. Over the years it just seems fuzzier than it used to be. And then you clean the haze away. Now I just need to keep the haze away.

Wednesday, June 6, 2012

More Long Count Calendar Updates

I've been making some awesome progress on the long count calendar application. I've got all of the math working (although I still need to test all of the nasty edge cases to make sure it calculates things correctly), but for anything after 1582 (when the Gregorian calendar came about) it seems to be working just fine. To test the date calculations I'm working on the ability to convert ANY date into a long count. This is a nice feature to have (what was Jan 1, 1900, for instance?) and will be useful for people looking to compare against other date calculations. The other thing I'm going to provide is the ability to put in a long count date (13.17.5.2.1) and see what date that converts to in a Gregorian calendar.
Normally, the main issue about converting from these earlier dates to later ones is that not everyone transitioned to the Gregorian calendar at the same time.Most of Catholic Europe adopted it in/around 1582. The British empire didn't adopt it until 1752 and the Soviet Union was in 1918 (right after the Bolsheviks took power and Russia became the Soviet Union). The Wikipedia article on the calendar has a nice chart showing the adoption times for different countries. So depending on where you were you had a different calendar. I'm pretty sure that the date is the 1582 and using the default NSCalendar objects will fix it for that date, I believe.
I will say that Apple seems to have done a good job with the calendar objects. NSCalendar and NSCalendarComponents are very nice little objects that really do simplify the mathematics. I have to convert to Julian dating anyway, which makes the math about as easy as it can be, but having the system provide some of the common functionality is very handy, especially being able to extract out year, month, and day without any extra divs and mods on my part. It will even provide the day of the week if you need it (which I don't in this particular application). I still need to dig into the objects a little more, especially with the pre-1582 dating - just to make sure they work as expected.
I did get the T'zolkin and Haab calculations into the application, so not only does it show the long count form (12.19.19.8.2 for today) but also the "month" and "day" (5 Sotz' 1 Ok - also for today). So everything is present in the application now from an implementation perspective - all the math works, it grabs the right images, etc. I need to get some better quality glyphs for the application, though, because the ones I have are low-res and won't look good on the iPhone let alone an iPad. That could actually be a major pain in the butt - one I'm not concerned about right now (those two stories are last on my kanban board), but I recognize that I'm going to have to spend some time either finding some good quality ones or drawing them myself (shudder!).
Overall things are looking really good. I think I might be able to make some good progress this weekend during downtime for Yeomen of the Guard. I'm off-stage quite a bit and with 3 shows in 4 days, I've got a lot of potential time to move this forward. I'm setting a goal of having the Gregorian to Long Count conversion done around Saturday night, the Long Count to Gregorian conversion around Sunday afternoon, and the reckonings done by Monday night. Which means that all I'll have left to do is get some good graphics next week and then I could, in theory, put it out on the App Store by the end of June - the first such Otto Von product to be available. All in the course of 3 weeks. Wow.
So keep your fingers crossed - I need all the luck I can get on this rapid development path!

Saturday, October 2, 2010

Alpha 3 Release

The announcement on Facebook!
It's official - I just sent out Alpha 3 tonight. I wish it were a little more solid, but I've been testing it for a while and it seems stable. I've had a couple of bugs that I haven't been able to reproduce, so I'm going to spend a little time this next build working on using the Build and Analyze functionality. The next version is going to be HUGE, so it's important to get it all working solidly.
As I posted previously, the UI and game play changes for Alpha 3 are pretty good. I've added difficulty levels (making the game a lot easier to actually play), and the UI is cleaner. I've also captured some things and sent it over to a designer friend I'm hoping will be able to help with the graphics and the layout. I feel like there are places where it's pretty good but that there are far more places where it's just clunky and not working at all.
Of course the big thing is that this should let people play a little more frequently as the game won't be quite as impossible as the original. Jotto was a pretty niche product (and my mom and I were firmly centered in that niche), but I think it just couldn't really excel as a game because of it's difficulty. I expect that the game will be much more approachable now and to a wider variety of people.
There is still one thing I need to sort out with the word list, though, which is creating a simple word evaluation page so that people can rate words as Easy, Medium, or Hard. That should help segment some of the much harder words from casual players. I'm hoping that some of my Facebook friends will be able to help parse the list (it's pretty extensive) and provide a basic clumping of words by difficulty. It should be a quick change to the code to enable that in the code.
The next big step (and the next Alpha) will be to have two player games, which entails a TON. I need to get user accounts set up, figure out how to deal with people who change phones but want to keep their information, creating friend lists, getting multiple games working, and, of course, manage the basics of having a server-based game as opposed to a device-based one. Definitely a big challenge, especially the back-end piece. Still, I'm hoping that I'll be able to get it done in time for Christmas - that's my big goal. Hopefully before Thanksgiving - that would be awesome.
So, now that Alpha 3 is out the door, I guess I better get working on Alpha 4!

Saturday, September 18, 2010

Potential change for Alpha 3 UI

Original Jotto (tm)
sheet
I've been considering the conundrum I've made for myself with this text coloring issue. I've not be able to get the text to display as I wanted without having to almost completely draw it by hand (and make using the Cocoa Touch classes worthless). I did, however, have something of an epiphany while deciding what to do. What I considered is this - what if the word the player picked was EERIE. Would a blue "I" be that terribly visible to a player? It would like very much like this: EERIE (the I is bolded in that word). In other words, yes, the word EERIE looks good when it's laid out in regular text, but for the game, it might make more sense to instead display the letters independently in boxes/labels, rather than try to just change the colors of individual letters. Stumbling upon this epiphany was kind of interesting. I had been, just to get the bloody thing done, considering doing some "lights" under the letters to show which were correct/right position, etc. But then it dawned on me that it's not a fixed font - it's proportional. Which meant that some letters, like W, would be very obviously green or blue, but that others, like I and J, would be much harder to see with colors.
Detail of the Jotto (tm) sheet
I had been thinking of NOT doing this but in retrospect it's what the original game does as well (as shown to the left). And yes, that was lifted from Wiki. Using the boxes (which will need to be dynamic, based on the number of letters in the game) will change the look of the game a little bit, but I think it will make it a lot cleaner in terms of what the player is viewing and should help simplify the display issues I was seeing. I just kind of wish that I had thought of this sooner.
On an amusing aside, before the advent of real word processors, my mom and I used to play this game a lot. Unfortunately, we ended up going through a lot of sheets and had an issue where we couldn't play without making sheets of our own. The places where we would normally buy the game didn't carry it anymore (it had sort of petered out in popularity by then), so we were kind of out of luck. There's only so much time you want to spend making tally sheets versus actually playing the game. My grandmother lives in New York (on Long Island) and there was actually a distributor of Jotto there on Long Island.
The notice at the bottom of the sheet
I recall the two of us driving there to get what felt like boxes and boxes of sheets. I then took those back with me to Laramie where we probably played a full box in the first two weeks I was home. Ahhh, good times.
I'm hoping this new direction will make things a lot easier moving forward. It should simplify the work that needs to be done and only slightly complicates the code (need to figure out which labels I'll be using for the different length words). Beyond that, though, I'm actually thinking I might be able to get this puppy done by Wednesday if things continue going as well as they have. Which they won't, so we're likely looking at Halloween. Here's hoping!

Friday, September 17, 2010

*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*

Thursday, September 16, 2010

I keep distracting myself...

I've found that when I'm working on things that occasionally I'll focus on things that aren't terribly important rather than getting something working. For instance, I've been working on Alpha 3 and making some good progress - got the entire create new game system reworked and it's acting well. Now I need to start looking at changing the game logic and display to work with the Easy, Medium, and Nightmare modes. And what I did I most recently find myself doing? Taking a snapshot and working on the background for the main game screen.
I mean, the background does need to be completed, but honestly - it can wait until I'm closer to being completed with the game play. It's hard, though, because I know that it needs to be done, it's something I can work on in my mental background, and I'm playing with the colors and layout anyway due to the Easy and Medium play. Still, though - like reading quickly - I sometimes have to remind myself to re-focus on what's important.
The clunky main game
interface screen
It's a little harder with independent projects because I'm not tracking it as closely as I would a project at work. The background IS ugly as compared to the rest of the app now because it's all clunky (as shown to the right). I did ask if the interface seemed non-intuitive and such and got back (from one person) that it seemed fine. I'm hoping that if I can make it a little prettier, use some better images, etc., that I can make it clearer what's being used for what. I need to just make sure that it's not becoming a "high priority" item for me, but rather staying in the background. I know that I'll get it done before I put out Alpha 3 and I'm actually making faster progress than I expected. Still have a couple of changes to make to the data flow to support the additional checks for letters - which ones are right and which ones are in the right position. Sort of brings in some skills I haven't done with Xcode and objective-C, so it'll be a good learning experience. I just hope that I can get it sorted out quickly and back to doing what doesn't matter.
What kinds of things do you do when you're developing to keep yourself focused on the major tasks and not get sidetracked by the "cool" things you still have to do?

Saturday, September 11, 2010

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...

Saturday, August 7, 2010

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.

Tuesday, June 1, 2010

Alpha 1 Updates

Well, it was a busy weekend for the Empire Lyric Players, which meant it was a busy weekend for me (because I'm president of the group). Rehearsal Friday til 10:something-way-too-late, Saturday off (I played a TON of Dragon Age: Origins - definitely needed the break to stave off the pending mental collapse), then move-in on Sunday, which went much faster than I expected. We arrived at noon to help unload and they were finishing getting everything off the trailer into the theatre. WOW. I don't think move-in has ever gone that smoothly or had as many participants (practically the entire cast was there). Then errands on Memorial Day and first rehearsal in the theatre. Hard to believe our show goes up in 2 more days!
But wait - wasn't this a post about Alpha 1 Updates? Why yes, you're right - it is! Thanks for the reminder. So where IS Alpha 1? The short answer is "coming soon". The longer answer is a bit more complicated. I was having any number of problems getting my app debugged. It was working fine in the simulator, but as soon as I installed it on my iPhone it would crash on launch. No warning - just "no longer running". I couldn't attach a debug process, the console log (thank you Xcode Organizer!) showed nothing untoward, NSLog messages showed nothing... I was at a complete loss. I restored my phone to just 3.1.3 and then re-synched with iTunes. Still no love. Then, magically, it started working.
For anyone who's been a developer for any period of time, the "magically disappearing bug" is a frightening thing. Why did it go away? When will it resurface (because without fail it will)? I still can't find anything wrong, though, so it's hard to say it wasn't not some kind of configuration problem, but I'm not happy. I thought I would try to install it on Susie's phone as well to see if it surfaced there (I turned mine into a development device so I could see what was happening, but it didn't help). When trying to install on Susie's phone I got the strangest error:
The application "OttoJotts" was not installed on the iPhone "Susie's iPhone" because an unknown error occurred (0xE8008001).
Whiskey Tango Foxtrot? Why would iTunes not know what the error is? Oh, au contraire, mon frere, but iTunes DOES know what it is. What error 0xE8008001 is telling you is that you have an unsigned application that iTunes won't let you install on an iPhone. In other words, iTunes thinks the application is not a valid App Store or Ad Hoc distribution. Of course the question now is why doesn't iTunes think it's a valid ad hoc distribution? As to that, I'm uncertain at present. I need to dig into why it doesn't seem to think that I'm building an application with the right provisioning certificates. The error I was getting before from her iTunes was that there weren't any valid provisioning profiles for the application, which seemed odd as it was the exact one I was including in the build settings. She's running her iTunes on Windows and I'm on Mac, so that's always a joy, but still I've done it previously without too much trouble. Definitely more digging necessary, but here's the kicker - this is HELL WEEK.
What is Hell Week? In performance parlance, it's the week before a show opens. Every night is a rehearsal and generally you're still working a regular 9-5 (-ish) schedule that week, so you're up at the butt-crack of dawn to get to work, work a full day, then go to the theatre and spend another 5-6 hours at rehearsal. Then back home to bed all to do it again the next day. Good thing the show opens on Thursday. We have a JDBC movie night on Friday and I might end up crashed on the field at Invesco/Mile High. :)
Over the next couple of days I need to figure out what's up with the provisioning profiles and see why this isn't working as I thought. Maybe in a couple of days I'll actually have the Alpha done and out to testers. When I do, I'll make sure to let everyone know via this blog.

Thursday, May 27, 2010

Understanding at last?

So, I was looking at the iPhone Developer Center trying to figure out from the tech notes why symbolicatecrash, which I was reading would be working just fine, was not working just fine. What I believe it is now, though, is that my SDK version is 3.1.2 and my iPhone OS version is 3.1.3. *sigh* Just shows to go you that as a developer you should always stay up-to-date on the latest SDKs when they're released. Now I need to see if there's a way for me to download the old 3.1.3 SDK. Why, you ask? Because of the iPhone SDK 3.2.
The new SDK requires Snow Leopard which I haven't installed yet (I just ordered it). In the interim, I'm just kind of shooting in the dark with what's happening. Given what I've been reading, it seems like that's the issue, which would be nice. If so, it would at least mean that I'm not a complete idiot. :) The worst part is that even if I do get it to symbolicate, I need to find out why it's failing.
Overall it's been a pretty frustrating experience, but at least it looks like things are turning around and this does seem like the most likely answer to the problems I've been experiencing. And it's also not been abundantly clear from the blogs I've been reading what this issue is.
So, there we go. At least for now. *sigh*
Update: I found a link to the old 3.1.3 SDK which I'm downloading now while I wait for Snow Leopard to arrive. I'll at least be able to do iPad development once I get Snow Leopard, but it's not been a big item on my to-do list, so I've delayed. Apparently one version too long. Wish me luck!

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.

Friday, April 30, 2010

Prototyping new game

So I've taken a bit of a hiatus from Daimyo, but just briefly. I'm working on the prototype to a new game that I'll reveal when it's done. I'm going back to Objective-C for iPhone work and, honestly, it's been a bit of time since I worked on anything about it. Good thing is that things are coming back a little faster than I thought it might. I need to get back to some of my reference books, though, because I want to do something that's not really "standard" now (of course). Overall, though, it's coming along nicely as a prototype. I didn't actually think I'd be able to knock this out as quickly as it's been going.
Also had fun checking out an interview with Natalia and Keith at Imangi studios. Ready Set DC did a profile on them and it was quite nice to read about some folks I've been following on Twitter because, well, they're awesome but also the kind of people I could see hanging out with on a Friday. :) The link to the article is here.
So, things are progressing well with the prototype and Daimyo is after that. I think that the weekend may see the completion of the proto, which gives me a week or so to actually knock out the product and get it in people's hands. Then it's off to make the pay version (the proto is of the lite version) and then, maybe, get it up on the App Store.
So, there ya go.

Tuesday, August 4, 2009

Rough Few Weeks

I've been working on trying to get the Alpha 1 ready for release to my test team, but several things have blocked me. First was that I was in the process of interviewing for a project manager position with Examiner.com. The position sounded very exciting and challenging, so I thought I'd pursue it. I ended up spending quite a bit of time preparing and interviewing it - longer than I expected - but it was a good choice and I start tomorrow. Yay me.
The second thing is that I ran across some unfinished functionality in the app when I plugged in quests, mana pool regeneration, and leveling up. MP regeneration went as quickly as I expected, which was nice. Quests took a while longer because even though I was able to write the back-end code quickly and had it working where I could test it thoroughly, integrating it took far longer than I expected. Part of it was the UI, which didn't work the way I'd hoped, and the other part was that I ran into some memory issues.
The third and most major of the entire blockage has been my MacBook. I bought a MacBook in November to do iPhone development and it was working fine until just recently. I began seeing major slowdowns - to the point where it was unusable - and had trouble copying files and building properly. I was a bit concerned when I couldn't even boot it up one day. I took it into the store and they think it's a bad HDD so they've ordered a replacement. In the meantime I hit Best Buy and bought a MyBook external HDD (1 TB). I managed to back up everything manually - although I can't actually do a Time Machine backup. :( Regardless, when they replace the drive I can get things working quickly again, I hope.
So, I hope to have things ready this weekend. We'll see how that goes, of course. More to come!

Sunday, July 12, 2009

CodeSigning Hell

The best advice I can give to anyone who wants to develop iPhone applications is: When you get an error, READ THE ENTIRE ERROR MESSAGE VERY CAREFULLY. Here endeth the lesson.
I had decided to update my code signing certificates for the alpha that will be starting in the not-too-distant future. I also wanted to try to get it building for distribution on OS 2.2 devices because one of my testers is on an iPod Touch that costs $10 to upgrade to 3.0. Eventually I will need to move completely to 3.0 to get the in-app purchasing I require, but for now, compatibility is a good thing.
I made some new certs, read the instructions carefully on the Apple Dev Portal and things were going along smoothly. I had a bit of a hitch when I forgot to copy in the distribution and developer certificates to Xcode, but that wasn't too heinous. Then I tried building for 2.2. Error. And something that seemed completely odd. CodeSigning was complaining that I hadn't provided a certificate for 'Distribution' for SDK 'Device - OS 2.2'. Um, sure. Not terribly helpful. Can I build OS 3 builds? Yes - no problem. OS 2.2? No. I checked the build settings - yup, there's my certificate, it's setup for all iPhone Devices... What's your damage, Xcode? Okay, fine. You win. I'll ADD a special exception for OS 2.2. Bzzzt! Still not happy. What the HELL, man? C'mon, give me SOMETHING.
*sigh* After beating my head against it for a while, I went back and looked at the steps. Yes, I did that. And that. And thanks for the warning about making sure I did that - I did. Okay, let's Google it. I have to completely reset my Xcode to make it happy? I'm not sure that's the right answer.
Okay, one last time. Let's close Xcode, reopen, and try building it again. Nope. As expected, the same error. But wait. What does that error really say? Seriously? What configuration am I editing in the properties? DEBUG?!?! And it needs to be DISTRIBUTION?!?!?! *sigh* *facepalm*
So, let's make sure we're editing the configuration for Distribution and attach the certificate for all iPhone devices. Okay, Xcode, let's see if that makes you happy. And it does. And had I bothered to read the error message and double-check to make sure that I was actually editing the correct properties, life would have been better. But, thankfully, now it is.
Here endeth the lesson.