My friend Scott McWhirter, who heads up the Vancouver Perl Monger’s group, asked me yesterday to give a last-minute talk on anything in particular at tonight’s Vancouver.pm meeting. He wasn’t exactly begging, but I know he’s short on speakers this month, and he wanted something interesting to show.

So I decided I’d talk about building and testing Perl-based projects using Hudson. I’ve been planning on writing a blog post on the subject for the past month, but haven’t found the time to finish off the post properly. So if you’re interested in the topic, and you don’t want to wait for me to get around to writing about it online, please feel free to drop by tonight!

Just like most of the men at my office, I’m participating in Movember this year, largely due to the razzing I got last year when I didn’t participate. Yes, I’ve succumbed to peer pressure…what would my mom say? At least it’s for a good cause. Of course, the first question I asked is “What’s Movember?” It’s a fundraising event for prostate cancer where men grow mustaches during the month of November.

While I can grow a mustache fairly well, I really don’t look good with one. So hopefully I won’t have too many pictures taken of me this month. And if you want me to feel better about it all so I don’t feel like it was a total waste, please head on over to my Movember profile page and donate a few bucks, or more.

As you can see, it’s a few days and it’s at a respectable and not-yet-annoying length. If you contribute, you get a vote on what style my mustache should be. I figure of I’m going to have nasty facial hair, I might as well go for it wholeheartedly. So donate to a good cause, frustrate my wife, and get a few good laughs in.

Plenty of times in applications, especially on mobile devices, you just need to tell your users to hold their horses and wait while your application processes something in the background.  Maybe you need to query some data from a remote server, save a file to disk, or maybe you just need to do some number crunching.  Whatever the reason, you don’t want your user to think the program has crashed if you don’t give them some sort of visual feedback that you’re busy and they just have to wait a few seconds.

PhoneGap provides a few methods to handle just this task. There’s four methods within the Notification class that are of interest.

1. navigator.notification.loadingStart()
2. navigator.notification.loadingStop()
3. navigator.notification.activityStart()
4. navigator.notification.activityStop()

Modal loading messages

Modal loading indicator

The easiest approach to take when making your users wait is to show a modal loading dialog, one that doesn’t let the user interact with the application until you’re done.  There’s a lot less for you, as a developer, to manage when the user isn’t allowed to poke around on buttons when you’re updating the display.  Asynchronous operations are a lot simpler when you’re in control.

The loadingStart() and loadingStop() methods do just this.  They put up a modal semi-transparent layer over top of your application, with a “Loading..” spinner message. You simply call the first method when your application is about to do something, and when it finishes you call the second.

Here’s an example of how to use it.  This will load a remote HTML document and place its contents into a node in your PhoneGap application.

Not only does this make it easier to integrate external content into your PhoneGap application, but it guarantees your user is informed that it’s actively working. As a final bonus, if your external web site doesn’t respond, or if the user doesn’t have an Internet connection, the modal loading screen will close after a timeout.

Asynchronous loading messages

Asyncronous activity loading indicator

Sometimes you want to tell your user that the application is busy, but you still want to continue using the app anyway.  If your app doesn’t turn off the top statusbar (where the time, reception, and battery status is displayed), you can control the busy indicator from within PhoneGap.  Just like the above example, you just have to call the appropriate PhoneGap JavaScript methods.  In this case, just update the above example with these messages:

navigator.notification.activityStart();
// Do something that might take a while...
navigator.notification.activityStop();

PhoneGap's custom alert notification is nicely customizable

An important part to any application is issuing a simple alert to your user. Whether it’s to tell them about an error that just occurred, or if you need to ask them a simple question, giving a message to your user is about the most basic part of any app.

Sadly, when you try to rely on the ever faithful “alert()” function in JavaScript inside a PhoneGap application, you’ll notice the alert box it shows is titled with a very unprofessional “index.html” across the top. Not only does it make it obvious that the app they’re interacting with is actually HTML-based, but you can’t convey the importance of one message or another with a title. Most people only ever read the title anyway, so in order to provide this capability to your application, PhoneGap has an answer for this problem.

Inside PhoneGap there’s a class called “Notification” which is used for, well, sending notifications to your user. And, by calling:

navigator.notification.alert(
  message,
  title,
  buttons...,
  options);

Everything, except for the message, is optional. The more arguments you provide, the more you can customize the alert box. For instance, if you don’t supply a button label, one single “OK” button will be created. Want to ask a Yes/No question? Simply pass two labels for their respective button names.

Like other functions in PhoneGap, the alert notification can be passed an “options” object that allows you to give it more information, such as an onClick callback.

That example shows how to ask your user what to do in the event of an Internet connection problem.  You’ll notice that I’ve decided to pass two button labels.  In the onClick callback function I supplied in my options argument, I’m checking the “buttonIndex” variable it passes.  This tells your function which button was pressed.  If you want more than 2 buttons, just list multiple labels and it will show as many as can fit on the screen.

A very simple function, but invaluable as a developer resource.  And, more importantly, a very easy and professional way to get feedback from your user.

One of the integral features of the next application I’m releasing (I’ll write a post about it soon, honest) is the capability of saving a copy of the user’s work in my app to their Photo Library. For a while now I’ve been wanting to be able to save screenshots from within PhoneGap for two main reasons:

1. Be able to export the user’s work and allow them to email it, import it into other applications, etc.
2. Save a screenshot to their splash-screen image, that way when the application restarts it shows their previous state while they wait (for example, the Notes application on the iPhone).

I’ve implemented #1 right now, meaning with a simple non-blocking call you can save the current view to the photo library. In the future I’ll add another three options: Save to the default splash-screen image, save to a file, and save and upload to a remote location.

Check out the check-in I’ve made and if you have any comments, please let me know!

The ActionSheet is a handy control on the iPhone, and is a very intuitive way of getting a multiple-choice answer from a user in a modal but unobtrusive way.

Using it in PhoneGap makes interacting with your user easy, while keeping the display responsive. And as an added bonus, you don’t need to update any HTML or CSS to get the buttons to look right. The native iPhone codebase handles it for you.

So the question is, how do you use it effectively? As most Web2.0-style developers are aware, the only sensible way to develop flexible applications that don’t bog down the browser is to make your applications behave asynchronously, and make use of callback functions to get feedback from external systems (HTTP requests, users, etc). The ActionSheet on PhoneGap is no different.

The ActionSheet is grouped into the PhoneGap “Dialog” class, and is called like so:

dialog.openButtonDialog(title, buttons..., options);

The title property lets you specify the label to show at the top of the ActionSheet. If you don’t want a title, then simply pass in a null value.

The list of buttons is specified as a series of objects, which I’ll describe below.

Finally, the options let you customize how the ActionSheet is displayed (via the “style” property) and lets you set an onClick handler for the entire ActionSheet.

The example above illustrates several options of the ActionSheet PhoneGap control.

1. On a per-button basis you can specify your own onClick callback which will be run when that button is pressed.
2. A global onClick handler can be specified in the openButtonDialog options argument, which will get called no matter what button is pressed.
3. You can choose what the appearance of the dialog should be (currently only “opaque” and “translucent” are supported)
4. A button requires a label property, but you can optionally specify a “type” property (can be “normal”, “cancel” or “destroy”).

The callback functions are simply called with two arguments, the index of the button being clicked, and the label of the button the user clicked on.  So if it’s easier for you to work with array indexes, or with text labels, you can easily find out which button was pressed and when.

So go ahead and try out the ActionSheet control.  Either you can use my latest release in my branch of PhoneGap, or you can use these more advanced features once my changes have been merged in with the official branch.

Finally, what we’ve all been waiting for.   Apple just announced that they’re allowing In-App purchases for free apps, and not just paid apps. This means, as an app developer, I can develop a single app for the app store for free, but can allow my users to upgrade to the full paid version without having to split it up into a “Lite” and “Full” version.

I can’t wait to apply this to my apps!

As any iPhone application developer who’s released at least a single app to the App Store will tell you, releasing your app is a terrible pain in the…well, it’s not a fun experience.  After your second or third app you start to get the hang of things, but there’s still pain and suffering involved.  Managing certificates, getting settings configured properly, and iterating between development, AdHoc beta builds, and the final App Store release builds, all make the process seem tediously manual and prone to human error.

In professional software development shops, you would use a Continuous Integration server to monitor your source control repository, check out changes as they’re submitted, compile, test and package up builds, and notify developers of the build’s health via emails and a web-based “Dashboard”.  I missed having this while developing my PhoneGap-based iPhone applications, so I decided to once and for all bring good development practices to my iPhone work.

Why do I need to configure automated builds anyway?

I get this a lot from people when I’m trying to convince them of the need for automated builds.  I personally find it hard to imagine people getting by without them in a single-developer project, let alone when multiple developers contribute to a project.

Monitoring the health of an application

Lets face it, we’re human, and we make mistakes.  It’s alright to break code from time to time, but what really sucks is when you find out far too late.  Did your recent changes accidentally eliminate your Entitlements.plist file, thus breaking distribution or release builds?  Do you have a file or library you forgot to check in, meaning when you delete the project from your working directory all those changes will just vanish?

Instead of having to remember to check each of those things manually (which, lets face it, you’ll forget at least half of the things you’re supposed to do inevitably), why not have an automated system tell you every time you make a change?  And if you’re in a multi-developer project, you’ll be able to see who broke the build and what change specifically broke it.

Always be ready for distributing your application

Many times in the natural course of development you’ll break code.  You’ve gotta break something in order to improve it.  But sometimes someone (your wife, a client, a beta tester) will want to try out your application before you have an opportunity to finish off your recent changes.  Instead of spending ages back-tracking your work to get your application to compile, why not rely on your automated build system to keep archives of previously successful builds?

Release what you test

Since you want to test an application before you release it to the App Store, you’ll probably create an Ad-Hoc distribution build to give to friends, family, or official beta testers before you bundle your application up to send to the App Store.  Maybe your testers will find bugs, maybe they won’t.  But at the end of the day that compiled app bundle you just created isn’t actually what you submit to Apple.  You need to compile a completely different app bundle with very different files stored in a Zip file, and if you’re not careful you could potentially be releasing something different than what you tested.

Why not have your automated build system create both your Ad-Hoc distribution build as well as an App Store release build every time?  That way you’re not only always ready to release something to the App Store, but you can be guaranteed that you’re submitting to Apple the exact code that your testers evaluated.

More benefits than I can list

If you’re really serious about best practices, you’ll probably want to write unit tests for your code and have those run after your code has been compiled, but before your build is packaged and archived.  Just because your code compiles doesn’t mean that it will behave correctly.  And lets face it, if you have a lot of tests, you’ll never wait for all of them to run throughout the course of your work.  So by running your tests as a prerequisite to a build succeeding, you’re guaranteed that you’ve got a safety net.

There’s plenty of other best practices that having an automated build system can help with, so what I’m discussing here will just cover the tip of the iceberg.  If I’ve convinced you that automating your builds, read on.

Getting started with Hudson

After evaluating a few solutions, I ended up settling on Hudson for my build server.  It’s Open Source, is built in Java so it runs almost anywhere, and it supports Slave build agents which is a must-have for compiling iPhone applications.  You can most likely use anything you want, though the amount of work you’ll need to do to make it work will vary.

Your first step will be to download and run Hudson itself.  It’s a self-contained Jar file, so the installation procedure is very simple.  You might want to run it inside its own user account on your computer, but you can decide where and how you want it run.  I have a Linux server that runs my email, websites and contains my source code repository, so I decided to run Hudson there.  I use Hudson to build not only iPhone apps, but my Perl-based webapps and its dependencies, so having it in a central location makes life easier for me.

After you get it up and running, you might want to install a few plugins to help you connect to your source code repository, or to enable you to do different styles of notification (for instance, my build sends me an instant message on GTalk when I break a build).  Play with its configuration options and see what it can provide.

Create your build job

Of course for your first step you’ll actually need to build your project is to create a build job.  Go to the dashboard and click “New Job”.  Give it a name, and tell it that you want to create a “Freestyle software project”.  This means it will simply run a shell script that describes how your build should be done.

Tell the job how to find your source code by pointing it at the proper source code control repository.  It has support for Git, Subversion, Perforce and even CVS.  Most of the defaults for which branch to build from should be fine, but you’re the best judge of what options to pass to the job.

Once you give it information about where to find your source code, you need to tell it what to do with it.  Under the “Build” section, click on “Add build step” and select “Execute shell”.  This will allow you to enter the name of a script to execute.  Just type in:

"$WORKSPACE/build/build.sh"

Hudson will check your code out into a directory where it will be built, and the $WORKSPACE variable will be set to the full path where that directory exists.  There are other variables it defines for you, which are described on the job’s configure page.  By telling the job to run the above command, it will run the “build.sh” script that you’ll add to your project’s source code repository.  This way the way you build your project can be versioned alongside your actual code.

Create your build script

Of course you actually need a script that will call all the necessary commands to build your application.  Luckily Apple provides a command-line tool called “xcodebuild” which is used to build applications.  In fact, this is the exact command that XCode calls when you click the “Build” button in the GUI.
This is the full version of my build script, which might not work well for you.  This is almost a drop-in script for PhoneGap apps though, and supports packaging up Release and Distribution builds automatically.  Along with this build script (which can be reused for different iPhone projects), you create a per-project build configuration file that looks like so:

This way you can specify the specific certificates each build uses, and which builds you want to create and archive.  The build script will package up the certificate for Distribution builds (that way your beta testers can add the .mobileprovision file to iTunes) and will package up the app’s icon file with the Release build (so the zip file can just be submitted as-is to Apple).

One of the steps in the build script above is to specify a custom build version number at build-time, based on the Hudson build number.  This means, as a developer, you don’t have to manually increment version numbers in order for your test application to install through iTunes. I followed these instructions on auto-incrementing XCode build version numbers, and altered them to suit my build script.  All the guesswork and human-error is avoided.

Slave and remote builds

Screenshot of Hudson's Add Slave screen

One of the limitations of building iPhone applications is that they must be compiled on a Mac with the XCode developer tools installed.  This means in my environment, where Hudson is running on a Linux server, I have to perform my builds on a remote computer.  Luckily at home I have an iMac running in a DMZ of my home firewall, both of which are always running.  So for my builds I configure my iMac to be a slave build server.  I enter its hostname, username and password, and Hudson automatically SSH’s into my home computer, SFTPs the appropriate Jar files down, and spawns the processes remotely.

At that point you can configure a job to use a specific build machine, or you can tag a set of machines with certain keywords and can bind a job to those tags.

Publishing build artifacts

One of the configuration options I specify within my Hudson jobs is I tell it to publish my successful build artifacts (the packaged Zip files for my application releases) over SCP to my web site into a password-protected directory.  From here I can give my beta testers a password to log into my website and to download the latest build, simplifying the beta test cycle.  I just point my testers at a URL and let them test to their heart’s content.  This is especially useful since a lot of mail servers block iPhone app bundles, thinking they’re malware or spam of some kind.

Automatically start builds from your version control system

The final step needed before you can fully automate your builds is to tie Hudson into your version control system.  The way you tie scripts into your version control system depends on what you use, but for Git, you simply create the following script somewhere in your user’s account and invoke it from your post-receive hook.

Next Steps

As I improve my build infrastructure more, I have plans to support pushing releases straight to Apple’s iTunes Connect interface for me.  My plan is to run a “Parameterized Build”, where I can supply options to a build, indicating that I would like to issue a full release.

I also have plans to improve my testing infrastructure, and would even like to try to run tests of my application by interactively controlling the iPhone Simulator.  If anyone has suggestions or experience on doing this, please let me know.

Its been a while since I’ve made an update to my blog, and I figured it’s far overdue for a new post. My life over the past little while has been divided up into 4 chunks: my family, my work, my weekend consulting, and my own personal application development. Somewhere around the second half of that list is sprinkled a bit of PhoneGap development.

PhoneGap vs Apple, resolved

First, I’d like to announce that I’ve made headway with my interactions with Apple. They were convinced by my argument that PhoneGap-based apps, just like any other apps developed by users who have access to a rich API, should be judged by their own merits and not prejudged based on what tools were used to built them. This is fantastic news, and means that apps submitted to the App Store will not be rejected solely because they’re built on PhoneGap. Now, if the application is buggy or if a developer tries to do something underhanded with it (for instance, changing the behavior of the app after Apple approves it) that is still cause for a rejection or worse consequences, but the same goes for any application released to the App Store.

Apple did have some requests though. To ensure that apps are released with a “Known Good” version of PhoneGap that they can trust as not having a fundamentally bad design, they wanted to have a version number that would be considered stable and acceptable. Additionally, they would like to have some way of easily identifying the version of PhoneGap used, so they can easily check that little box that says “Don’t reject it just because of its framework.”

I had a meeting with the good folks at Nitobi over a few beer, and ended up updating the version number to 0.8.0, and added a version tag that is added at build-time to the compiled iPhone application bundle. This will make it quicker for Apple to approve your apps, as well as remove any guesswork on their end about whether or not to trust your application.

The catch…

As with all good things in life, there is a catch. Since Apple doesn’t have any idea what version of PhoneGap any apps already submitted to the App Store for approval may be running on – and as a result has no idea whether it’s a safe version of PhoneGap or not – they’ll have to reject all the PhoneGap applications in their queue, and kindly request that you resubmit your apps once you’ve updated to the newer version of PhoneGap.

I want to stress that they’re rejecting these apps only to ensure they’re running the first Apple-approved PhoneGap version, and not for any other reason. Once you update and re-submit your apps, they’ll reenter the queue and will be reviewed just like any other iPhone application. This doesn’t mean they won’t reject your app for some other reason, but at least PhoneGap won’t be a blocker anymore.

I have some additional announcements and general thoughts on PhoneGap and my use of it to post, but since this news is so big, and since I’ve been too busy lately to update my blog in a while, I thought I’d open with this post first.  I’ll hopefully resume my regular blog posting soon, so please check back later.

Update: For more information about the origins of my conversations with Apple, see my posts titled Updates on Apple / PhoneGap and Open letter to Apple iPhone Developer Support.

Things have been busy over the past few days, which is the reason why I haven’t had a chance to post about this until now. But for the PhoneGap community, I have some good news and some bad news.  First, the good news: I got a phone call from the Apple app reviewer that was reviewing my test app.  And before I go any further, I want to say a few things.

When I crafted my original letter to Apple, I was very cautious how I wrote it, because I don’t want to give anyone the wrong impression. I don’t have any problems with Apple or the fact that they have an app review process. I actually think the strict regulations Apple has with its review process is a good thing for users. If left to their own devices, app developers would release anything and everything whether it had merit or not, in the hopes of earning even a tiny bit of a buck.

That’s not to say that I have nothing but a big warm and fuzzy feeling for the review process, just that it’s like going to the dentist. It’s painful, but you’ll thank them later in life when your teeth would otherwise be falling out – or, in the case of the App Store review process, when the app store would otherwise be overrun with endless seas of buggy and non-functional crap.

Most developers out there seem to vilify the app reviewers, making them out to be legions of sadistic bureaucrats who like nothing more than to waste developer’s time. I’ve never been comfortable with that, because people simply don’t work that way. The app reviewers don’t have an easy job.  They’re not developers, they don’t know how to write apps, they just review them to ensure they meet the guidelines Apple sets forth.

So when they reject your app, it’s not because they’re out to get you, they’re just enforcing policy.  If they make some assumption about your app, perhaps you’re not giving enough information to help them along?  There’s a comments field that you can use to help the reviewer of your app do their job, instead of throwing an app over the fence and saying “Here, take that”.  They don’t owe you anything, and are simply making sure that they cover their asses.  Could you imagine how bad it looked on the guy who reviewed the “Shaking Baby” app? I’m not sure if he lost his job, or just got seriously reprimanded, but this is the sort of thing these guys are trying to prevent.  But because of the black-box nature of the whole process, it’s easy to jump to conclusions.

Finally, before I dig into the meat of my conversation with my App Store app reviewer, I want to point out a few things that many developers seem to have forgotten in their haste to get their apps released:

1.    The app store is a voluntary process; you don’t want to play by their rules, you don’t have to.
2.    All developers signed an agreement that states Apple can choose to reject any apps they want based on their own reasons. There’s no human right’s violations committed when Apple decides that your app isn’t fit for the store for some reason.
3.    Apple is a business, whose goals are to advance their stock and market position for their investors. While some of Apple’s decisions may seem confusing from outside the black box, keep in mind that they are prone to keeping secrets until they throw down their big announcements at whatever annual conference they’re attending. So there are sometimes more reasons why they wouldn’t want some feature leveraged by app developers if they plan to do something much the same themselves. Is it fair? No. Is this what they’re doing? I have no idea, this is speculation on my part.

Now that I have that out of the way, I’d like to relate to you my conversation with Steve from the App Store.

My test app, aCookie Fortunes, was released to the app store ages ago, back when I was still learning how to use PhoneGap (and before I even started to extend and improve it). It is full of bugs, and is badly in need of an update. I made my PhoneGap improvements, and subsequently made a bug fix release. At that point, it sat in Apple’s queue since March 18th.  I sent a few emails asking where things were with it, but never got anything more than the boilerplate responses.

So I suppose the app store reviewers were just chewing through their back-log of apps.  They’re basically a support department, and they do the best they can.  So when Steve got around to my app, he looked at the notes, saw the words “PhoneGap” in it, and was about to click the reject button.  But since it had been sitting in the queue for so long, he thought he’d do the right thing and picked up the phone to call me.

Let me pause here for dramatic effect.  This is awesome customer service, in my books.  He certainly didn’t have to do this, and it shows great initiative on his part, as well as wonderful diligence.  All he had to do was click “Reject”, and carry on with his day.  It’s so easy in this day and age to dehumanize the person on the other end of the computer screen.  To some people I was an entry in a FileMaker-Pro database.  Instead of treating me like a number, he called me on my cell.

I was at work at the time, but took the call anyway – hey, this was big news, and I’d been waiting for over 3 months.  Over an hour later (1:15 to be exact) I quickly sent out a message to Twitter and got back to work.  We’d covered a lot of ground in that conversation, but what it basically boils down to is this:

Apple has an unfounded hate-on for PhoneGap.  Most likely their misconceptions are based on early releases of PhoneGap, and they haven’t taken a second look since then.  Perhaps a few bad-apples ruined it for the rest of us (pun totally intended).  But these impressions are difficult to change.

Steve and I went through the list of every problem PhoneGap was perceived to have, and went through every single point of every single one of the Apple app guidelines that were listed as things that PhoneGap violated. It took a long time, but he would read out each problem, and I would explain to him why they were just flat out wrong.  Some of the problems included the misconception that we were linking to and including a custom-compiled version of WebKit, that we had our own code interpreter built-in, and that we were using private and unpublished APIs on the phone.

I pointed Steve at my Github source, at my blog, and at the PhoneGap mailing list.  He’s of course busy with his job too, so he didn’t have the time to read through the glut of articles that have been posted everywhere, but I did mention that I’d issued an open letter to Apple regarding this, and that it had been picked up by a number of sites around the ‘web.

He asked if there was a way to write my app using something other than PhoneGap, so I could just get it released easier.  Certainly, there are alternatives, and since it’s just code, anything is possible.  But after explaining to him that the goal of PhoneGap is to write cross-platform apps in a Rapid Application Development fashion, there’s little to no point in creating some of these apps in the traditional way.

And largely, my persistence in this matter is more than for my own benefit.  I’m trying to help out the community at large, and want to make sure that all the PhoneGap developers can use it to build great apps, and not have to worry (any more than usual) about Apple rejecting their apps.

So Steve and I came to an arrangement.  He’d agreed to do his best to work with his superiors to try and reverse their impression of PhoneGap, or at the very least evaluate each PhoneGap-based app on its own merits.  I have no problems with Apple rejecting a crappy PhoneGap app, nor do I have a problem with Apple permanently banning a developer from the App Store if they try and do something subversive, like change the behaviour of an app remotely after an app has been released to the store.  But those are things that any developer can do, whether based on PhoneGap or not.  And if Apple comes back with a list of things that are problems still, then we can fix them.  As I put it, “I can can fix almost anything with it.  I have a hammer, I just need to see where the nail is so I can hit it.”

I’ll post more about this later, after I talk with Steve next.  I have a few experiments I’m going to run, and Steve will keep an eye on the apps I release over the next few weeks, to see what happens with them as the percolate through the app review process.  He’ll also be filling me in later if he was able to make any progress with his superiors.

Before I finish up this post, I’d like to say a big thank you to Steve.  If any of his supervisors are reading this, I want to let you know just how great he is.  He treated me with courtesy, listened to my problems, and didn’t prejudge me or my app based on any preconceived notions about PhoneGap or app developers as a whole.  He listened to what I had to say, and went above and beyond the call of duty to help me get my app released, and to help me in getting PhoneGap acceptable to the developer community at large.  These are all things he didn’t have to do, and his day would undoubtedly have been easier had he just clicked the “Reject” button.

And in the end, he actually thanked me for being so friendly and willing to help him through getting my app released.  Steve, right back at you, and I look forward to working with you again.