iQuit

I purchased these three e-books online.  I came across them while asking questions on the Android beginners Google group.  Their author, Mark Murphy is very active on this group answering newb’s questions on a regular basis with detailed and helpful answers.  You can even get a full chapter sample to check it out and see whether the writing style jives with your style of learning.

I do recommend a book of some sort for starting out with Android.  Without a book you’re sort of left to your own devices.  You have to sniff around the Internet at every stage:  “How do I use the Android database classes?”, “How do layouts work?”, you can spend a lot of time googling and following time wasting paths through pages that don’t give the answers you’re looking for.  I was doing a lot of this and these books have cut down on that time drastically.

The Android project is coming along well.  I’m spending a lot of time just thinking about how to best solve problems the Android way, a lesson I learned on the iPhone, to make sure I don’t back myself into bad corners that are hard to get out of.

Well vacation’s over, and while I was away my last client has decided to go ahead with porting Prescriber’s Letter to the Android.  So I’ve got a lot of work to do on that in the coming months.  Should be interesting, and hopefully I’ll have some good stuff to post here in regards to the challenges you can run into porting iPhone apps to the Android.

The weather in Mexico wasn’t always as good as this picture, but here’s what the beach was like where I was staying:

I’ve spent the last week adding changes to the Prescriber’s Letter app.  One of the changes was to add support for browsing all the content in landscape mode.  Supporting landscape and portrait orientations quickly exposes any shortcuts you’ve taken in the design and implementation of your views.  Not to say that I took lots of shortcuts, actually most of my stuff just worked, but there were a few points where I could have saved myself sometime if I’d planned for landscape support from the beginning.  One of those was how I initially chose to do the login screen.  I knew when I was doing it that I should create the login screen as its own view controller and then present it modally.  It was more efficient at the time though to just add the login screen as another view to the root view controller and slide it in and out myself (since the whole screen is generated by code).  Once it came to adding landscape support we didn’t want to have the login screen rotate to landscape.  Now I was in trouble.  There’s no way to “force” a UIViewController to rotate to one direction or another.  You can screw around with writing your own code to perform matrix transformations on your view, but in my opinion that’s just a hack waiting to bite you in the ass.  Really you need to redesign your system so that the view is reloaded, and currently in the latest SDK  reloading (or loading) the view guarantees that the return value of shouldAutorotateToInterfaceOrientation: is respected.  So I converted everything for the login screen over to its own view controller that returns NO to any orientation but portrait, and then present it modally.  No matter what orientation the root view controller is in this brings up the login screen in portrait mode.

I’m off to Mexico now for a well deserved vacation with my wife (who deserves it more than me), away until February 26th!  Lucky me.

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.

Continue reading »

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!

My contract’s final milestone is due January 6th.  It’s going quite well.  I’m slightly ahead of schedule which should leave me lots of time to test the heck out of it and hopefully deliver a very solid app.  I’d very much like the submission process to go smoothly.  Once I’ve completed the project I’ll check with the client and hopefully I can post details about the app here and on the stormtap website.  This will be up to them in the end.

I need to approach the other client I have waiting in the wings and let them know I’m on schedule and we’ll see whether I can lock that contract down too.

I’m currently quite optimistic about the coming year.  If I can continue to have good luck, and find the right blend of contract work and time to work on my own projects I think I will be well on the way to building a sustainable business that will be as exciting, interesting, and fun as this past year has been.  It’s tough to continue with uncertainty, but the goal is so worthwhile I need to keep giving it my all.