Otherwise I don’t come across as a dedicated iPhone developer right?
Well it is exciting, and it’s one sexy piece of hardware that I’d love to have that’s for sure. It really suits one of my game design ideas, well, as much as the iPhone did as well, but now it would be much bigger and even cooler looking so that’s exciting. I’m slightly concerned about the extra cost involved in creating multiple sets of art should I continue to develop my own games. The screen is 1024×768 which is nice, but it’s going to take a lot more art to fill up that space and that’s an area I simply can’t do on my own being a non-artsy type.
I didn’t see much for speakers on the iPad. I really hope it’s not relying on the same little tiny grills at the bottom of the frame like the iPhone. Even upsized these definitely wouldn’t put out any kind of quality I’d want to listen to on my lap goofing around in my living room, and who wants to wear headphones all the time, especially in your own living room? Not me. But for it to be all slim and lightweight I guess you have to make some cuts even to important things (to me) like audio quality.
Version 3.2 of the iPhone SDK is out with support for the device, I’ll set that up today, but I haven’t got time to dig into the accompanying programming guides just yet. I need to get well into the Android side of things I’ve been working on first, and then I can come back and figure out what to do about this iPad thing.
I’m going to develop experience with the Android OS so that I can offer my services for porting iPhone apps to the device, or for developing apps capable of running on both systems. We want to port Prescriber’s Letter to the Android as well, so it will be great to jump right in and get some hands on experience as well.
I ordered the development device 2 (which is basically an unlocked HTC Magic) last week, and UPS is showing it should arrive today. I’ll be snooping around in the samples, but my primary goal will be to discover the APIs I will need to use to duplicate the functionality of the iPhone version of Prescriber’s Letter using the Android SDK. I’ll need to learn about the Android equivalents to UITableView, UICustomTableViewCell, UIWebView. I’m betting their XML libraries are probably much easier to use than NSXMLParser. I’m betting I will likely need to write my own equivalents to ASIHTTPRequest as well as ZipArchive so that I can do all the authentication and downloading and unzipping of content bundles. That’s ok though, those aren’t hard tasks. I’ll search around though, it would be nice to find existing implementations for that stuff.
If anyone can recommend any books on Android development that they found useful and not just repeats of SDK docs I’d appreciate any recommendations you may have.
We found a crash in Prescriber’s Letter where the app would load and hang displaying the Default.png for about 20 seconds, and then immediately shut down back to the iPhone OS. Looking at the crash logs I noticed that at the time of the crash the main thread was in some internal Apple SDK functions for DNS queries after a call to SCNetworkReachabilityGetFlags().
After investigating it seems what was happening is for whatever reason the app was taking too long to resolve the DNS for the host I use to test for network reachability via the Apple Reachability class sample. I was calling isHostReachable: for the host, and the process was taking so long the iPhone OS watchdog timer for applicationDidFinishLaunching: timed out and shut down the app. To solve the problem I had to move my first network reachability test out of applicationDidFinishLaunching: and I now have it in the viewDidLoad for the root view controller.
As promised, the following is a description of the process I went through to develop Prescriber’s Letter, the app I developed for Therapeutic Research Center, the client I’ve been talking about for the last few months. This would qualify as an extremely large blog post, so only continue reading if you’re very interested in the technical details of iPhone app development.
Therapeutic Research Center (TRC) publishes Prescriber’s Letter, an online newsletter focused on developments in the pharmaceutical industry read by doctors and other medical professionals. Originally they approached me looking to build an iPhone app that would essentially “cache” their site on the phone so their customers would be able to read the newsletter content even while offline (for example, while in a hospital where communication hardware is prohibited). They ended up revising their needs and provided me with a more detailed design document. The new app they wanted to build would allow them to duplicate the content of the site without simply cacheing HTML content. Rather the content would be displayed in more native looking iPhone screens. Their design called for an app capable of downloading and displaying their content in a completely flexible manner, with the ability to update everything in the app (text on GUI elements, graphics, hierarchy of information, etc..). Their content consists of articles, issues (collections of articles), detail documents (detailed information pertaining to an article), quiz questions, and miscellaneous HTML content. I prepared a second proposal which detailed how I would approach the problem, they liked what they saw and so we got down to work.
Well my contract is all complete. As soon as I get a chance I’m going to write up a post mortem for it so I can share everything I learned from the project and show it off a little.
To keep me busy in the meantime I’m helping a friend at Aveon Productions to update their app The Oracle of Aveon. It’s a wacky “media experience” I guess is how I would categorize it. I’m helping them localize it for French and Japanese, as well as adding some small features to it. Check it out, the price is down from their crazy starting price, skip a coffee and help out these fellow small guys.
Well I’ve got all the features crammed into this app. Man adding the ability to restore the user’s last screen when they relaunch the app was quite the experience. I know there’s that Facebook set of classes that supposedly is quite good at this but that news came to me too late to integrate into this project. It wasn’t too bad to incorporate into the system I decided to use (I used the Composite pattern from Design Patterns for my menu structure). The complexity was just making sure there were no assumptions or previous states that needed to be reproduced in the executing environment for the screens to work properly. Once all those little niggly bits were located and cleaned up it went quite smoothly. Those are good things to clean up anyways I say, the app is now much more guarded and “safe”, i.e. each view controller is quite self contained and capable of displaying its stuff from pretty much anywhere it’s pushed onto the navigation controller stack.
Early next week will be spent doing the memory analysis for the app, making sure there’s no memory leaks and that everything’s as tight as I can get it. Followed by a great deal of testing before I deliver the product to my client ready to upload. Exciting!
