Hey,
So, my iPhone app has finally been released. My work had me develop this for them over Christmas, then it kinda fell between the cracks for a bit. But, it's out now and in the wild.
The app lets you take a picture (or select a picture from your photo album), and converts it into a "coloring book," where you can select a color then touch a segment to fill it in. You can turn on and off the segment lines, and adjust how much the underlying image shows through.
If you have an iPhone, search for "ColorIt!" in the app store.
-Rich-
Sunday, August 23, 2009
Wednesday, April 22, 2009
Something's up with the source code
First, I want to apologize to everyone whose emailed me. I'm sorry I haven't gotten back in touch with you. I've been incredibly busy the last few months, and I just haven't had a chance to look into the issue yet.
Having said that, let me backtrack and start at the beginning. Apparently (judging from the emails) there is a problem with the source code for my 2-part iPhone Productivity Application article in MacTech. And the code does not compile.
As I said earlier, I haven't had a chance to look at this yet. However, here is some background information. As you may know, MacTech accidentally printed the articles out of order. To make things even more confusing, I changed some of the source code between the first and second version. No, I don't remember exactly what I changed--just cleaned things up a bit as I remember. Anyway, I provided MacTech with two copies of the source code. Both compiled fine on my machine (though I didn't test them on others). I think they should be pretty compatible, but obviously I only tested the first set of source code with the first article, and the second set with the second.
So, if MacTech only has one version online, I'm not sure which one it is. Also, the SDK has changed somewhat since I originally wrote the code. It shouldn't have affected anything, but if you're compiling against a newer (or for that matter, an older version of the SDK), the code might not work. I believe I compiled it against version 2.0, but I'm not sure.
I will try to look into this more in the near future. If you've had any success with the source code, please go ahead and add a comment with whatever information you have.
Thanks, and sorry for the confusion.
-Rich-
Having said that, let me backtrack and start at the beginning. Apparently (judging from the emails) there is a problem with the source code for my 2-part iPhone Productivity Application article in MacTech. And the code does not compile.
As I said earlier, I haven't had a chance to look at this yet. However, here is some background information. As you may know, MacTech accidentally printed the articles out of order. To make things even more confusing, I changed some of the source code between the first and second version. No, I don't remember exactly what I changed--just cleaned things up a bit as I remember. Anyway, I provided MacTech with two copies of the source code. Both compiled fine on my machine (though I didn't test them on others). I think they should be pretty compatible, but obviously I only tested the first set of source code with the first article, and the second set with the second.
So, if MacTech only has one version online, I'm not sure which one it is. Also, the SDK has changed somewhat since I originally wrote the code. It shouldn't have affected anything, but if you're compiling against a newer (or for that matter, an older version of the SDK), the code might not work. I believe I compiled it against version 2.0, but I'm not sure.
I will try to look into this more in the near future. If you've had any success with the source code, please go ahead and add a comment with whatever information you have.
Thanks, and sorry for the confusion.
-Rich-
Wednesday, February 25, 2009
iPhone Production Application Articles
Well, this is really old news by now. I wanted to post something about it earlier, but never seemed to find the time.
Apparently there was a mixup at MacTech magazine, and my two-part article on developing productivity applications was printed out of order. Part II came out in February's issue. I'm not sure whether Part I will follow in March.
However, there is an upside to this. The good folks at MacTech have released both articles in their entirety onto the web. So, I encourage you to check them out:
Part I: http://www.mactech.com/articles/mactech/Vol.25/25.03/iPhoneProductivityApplicationsPart1/
Part II: http://www.mactech.com/articles/mactech/Vol.25/25.02/iPhoneProductivityApplicationsPart2/
I'm also currently working on a third iPhone article, this time focusing on immersive apps, images and Quartz 2d.
-Rich-
Apparently there was a mixup at MacTech magazine, and my two-part article on developing productivity applications was printed out of order. Part II came out in February's issue. I'm not sure whether Part I will follow in March.
However, there is an upside to this. The good folks at MacTech have released both articles in their entirety onto the web. So, I encourage you to check them out:
Part I: http://www.mactech.com/articles/mactech/Vol.25/25.03/iPhoneProductivityApplicationsPart1/
Part II: http://www.mactech.com/articles/mactech/Vol.25/25.02/iPhoneProductivityApplicationsPart2/
I'm also currently working on a third iPhone article, this time focusing on immersive apps, images and Quartz 2d.
-Rich-
Wednesday, February 4, 2009
Things that bug me about Objective-C (and iPhone development)
Ok, before I get started, don't get me wrong. Objective-C is still one of my favorite programming languages. But, as I continue to use it, I can't help but feel that it has some rough edges.
First, it has the same essential flaw as Java. It's not a pure Object-oriented language. There is this dichotomy between things that are objects and things that are not. For example, you cannot put a raw int or a c-style array into an NSArray--not without wrapping it first.
In some ways, this gives us a lot of power. We can drop down and write lower-level code when the performance demands require it. And, when working on a limited device (like the iPhone), those demands can be frequent. But I feel it's a bad design choice. It encourages mixing C and Objective-C, and I think the two programming styles are best kept separate.
I guess the biggest problem with Objective-C is really just C. Anytime I have to use C code, I loose many of the strengths and benefits of using Objective-C. I also expose myself to pointer and array-overrun errors. These are often the hardest to debug, since they may appear as mysterious errors in unrelated parts of the application.
And then we get to the iPhone. I love Xcode and I love the iPhone, but sometimes the two just don't play well together. Yes, debugger, I'm looking at you. I mean, really. What's up with the breakpoints? Sometimes they work. Sometimes they don't. Sometimes I can trick them into working again by cleaning all targets and rebuilding. Other times I have to reboot the computer. One time I could only fix the problem by reinstalling Xcode.
OK, that's it. Enough complaining for one day.
-Rich-
First, it has the same essential flaw as Java. It's not a pure Object-oriented language. There is this dichotomy between things that are objects and things that are not. For example, you cannot put a raw int or a c-style array into an NSArray--not without wrapping it first.
In some ways, this gives us a lot of power. We can drop down and write lower-level code when the performance demands require it. And, when working on a limited device (like the iPhone), those demands can be frequent. But I feel it's a bad design choice. It encourages mixing C and Objective-C, and I think the two programming styles are best kept separate.
I guess the biggest problem with Objective-C is really just C. Anytime I have to use C code, I loose many of the strengths and benefits of using Objective-C. I also expose myself to pointer and array-overrun errors. These are often the hardest to debug, since they may appear as mysterious errors in unrelated parts of the application.
And then we get to the iPhone. I love Xcode and I love the iPhone, but sometimes the two just don't play well together. Yes, debugger, I'm looking at you. I mean, really. What's up with the breakpoints? Sometimes they work. Sometimes they don't. Sometimes I can trick them into working again by cleaning all targets and rebuilding. Other times I have to reboot the computer. One time I could only fix the problem by reinstalling Xcode.
OK, that's it. Enough complaining for one day.
-Rich-
Wednesday, January 28, 2009
Lessons in iPhone Development
I've been spending a lot of time working on iPhone projects, and I've learned a couple of important lessons (the hard way).
1) Computationally intensive code runs slow on the iPhone. When it comes to raw number crunching, code ran 60 times slower on the iPhone than on my old MacBook Pro. If it takes one second on the simulator, it will need at least a minute on the phone.
Even worse, something that is so fast that you cannot even see it in the simulator may take several seconds to complete. This can cause all sorts of unexpected problems. The lesson here, test everything on the phone as early as possible.
2) The camera image picker is apparently designed to be used only once then thrown away. The photo library picker (even though they're the same class) doesn't seem to have this limitation.
I put both in tabbed windows, so the user could easily switch images. The user could return to the photo library picker as many times as they wished. However, the camera picker would only take a single picture, then it would only display the last picture taken. There seems to be no way to reset it.
Bottom line, use them as modal views and toss them. Instantiate a new picker the next time you need one.
3) Memory management is hard. Even when I thought I'd been careful, when I tested it in Instruments, I had leaks all over the place.
4) Using Objective-C serialization to save off large collections of objects can be very slow. Encoding the collection into a NSData object, then saving that can vastly improve performance. At least, it did for me.
I'm sure there's more, but that's all I can remember at the moment.
-Rich-
1) Computationally intensive code runs slow on the iPhone. When it comes to raw number crunching, code ran 60 times slower on the iPhone than on my old MacBook Pro. If it takes one second on the simulator, it will need at least a minute on the phone.
Even worse, something that is so fast that you cannot even see it in the simulator may take several seconds to complete. This can cause all sorts of unexpected problems. The lesson here, test everything on the phone as early as possible.
2) The camera image picker is apparently designed to be used only once then thrown away. The photo library picker (even though they're the same class) doesn't seem to have this limitation.
I put both in tabbed windows, so the user could easily switch images. The user could return to the photo library picker as many times as they wished. However, the camera picker would only take a single picture, then it would only display the last picture taken. There seems to be no way to reset it.
Bottom line, use them as modal views and toss them. Instantiate a new picker the next time you need one.
3) Memory management is hard. Even when I thought I'd been careful, when I tested it in Instruments, I had leaks all over the place.
4) Using Objective-C serialization to save off large collections of objects can be very slow. Encoding the collection into a NSData object, then saving that can vastly improve performance. At least, it did for me.
I'm sure there's more, but that's all I can remember at the moment.
-Rich-
Subscribe to:
Posts (Atom)
