I recently had a situation where I needed to chain together two modal sheets off the same window. When the first sheet was presented, I obviously had the
NSWindow object for the window I wanted to attach to. Since my sheet had its own controller object, I could have simply stored this
NSWindow object and used it later for the next sheet.
However, I decided – largely as a matter of taste – that I’d rather figure out the sheet’s “parent” window programmatically in the
didEndSelector when the first sheet is dismissed. That way I don’t need to store the parent window anywhere in my controller.
Update: This calculation is now part of BikeWatts v1.1. Check it out!
I recently received a question from a customer about how to convert the Watts measurement given by BikeWatts to Calories burned. I figured that this might also interesting to others, so below is a high level explanation.
A long time ago, I developed a couple of small shareware products: Ugly Multiclip (a simple clipboard manager) and Ugly CD Player (a small CD player application design to take up only a small amount of screen real estate).
These applications were both developed with Codewarrior using PowerPlant as the framework, and as a result these are PowerPC apps. Mac OS X 10.7 (“Lion”) does not support PowerPC applications, and as a result these no longer work. Furthermore, there isn’t an easy way to simply just recompile these projects and make them run on Lion. Furthermore, even if they could be rebuilt fairly easily, they could really use a thorough rework to modernize their user interfaces.
So, as of now these products are officially unsupported. There’s a chance that one or both may be resurrected in the future as time permits, but I’m in no position to make an announcement to that effect at this time.
To those who purchased these products in the past, I thank you for your support.
In one of my previous posts I discussed my approach to starting development of a game. I’m still working on this, but I’ve come to the point where I may upgrade my drawing code a little bit.
In my initial development I was simply drawing into a UIView via its CGContext. Now I’m thinking about changing to drawing into CALayers. This gives me a few advantages. First, it lets me separate drawing a little bit more. I already have most of the drawing broken into separate methods in my view, but now I can set a layer for the score, and a layer for the objects (or even a layer per object). These aren’t too much of an advantage, but I think the biggest gain is that I can put a background image in a layer and then draw the rest of the items on top of it. I won’t need to redraw the background on the view for every frame of animation.
The second advantage is for some animations – I can just set them up and let them run. Take, for instance, an event like an explosion. I could create a few layers for some particles in the explosion, set them up on a path (maybe with some rotation), and then just let it run. I don’t have to add state tracking to animate these by hand with every frame.
I’ve only just started researching this, but I think this will work out nicely.
If you read my last post you know that I’m working on a game for iPhone. As part of my experimentation, I ran across a small issue I thought I’d share.
I’ve finally found some time to start working on an iPhone game that I’ve been thinking about writing. I won’t give out too many details of the game itself at this point, but I thought it might be interesting to some of you if I share a few notes about my approach so far. I’m fairly new to iPhone development and certainly to iPhone game development, so this will be a learning experience that I’ll share here.
A couple of weeks ago, I made the sad decision to retire my old LaserWriter 4/600 PS printer. It has served me well for a long time, but it is now time for me to let it go.
Buzzard Software is now officially enrolled in Apple’s iPhone Developer Program!
For those of you who are about to enroll yourselves, below is a summary of our experience. For comparison, you can also read some other enrollment stories here and here. For us, the whole process took almost 5 weeks, though your mileage may vary.
- We started our enrollment on April 26, 2009 as a company under the standard program. We received an email confirmation from Apple stating that they were processing our application.
- On May 11th, we received an email requesting information to confirm our company’s identity. As requested, we faxed (yes…faxed) our business documents.
- On May 18th, we received an email stating that Apple was waiting for information and that we should send it, or contact Apple if we had already sent it. Since we had already sent the information, I sent an email to Apple to figure out was going on.
- We received a response from Apple on May 23rd, confirming that our company information had been received and that our enrollment was being processed.
- I received a phone message from Apple late on May 28th requesting that we contact them. I called them on May 29th. They just wanted to confirm our mailing address and contact phone number. As a result, I was told I’d get an email pointing me to the license agreement I would need to agree to.
- I read the license agreement on May 30th, agreed to it, and was then able to purchase membership in the iPhone Developer Program ($99). After purchase, I received an email with my activation code within a few hours, after which I activated my account.
Now, we need to finish up our application and get set up to sell it in the App Store.
Greetings! Just a quick note to kick off this blog.
I have no predisposed plan for blogging in terms of frequency of posts. However, I do intend to provide some business and software development insights from a Mac and iPhone developer whenever I have topics to discuss.
So, welcome! And stay tuned!