Catching Android’s Back Button in PhoneGap

This little bit of code is going to be useful to those of you developing a “singe page” app inside of PhoneGap. This applies to Sencha Touch (big fan), but doesn’t as much to jQuery mobile and jQTouch, as it’s a multi-page/navigation based event framework (it uses the app’s url string to do things like move around to different link anchors). This is really important on these single page apps because the Android hardware back button will send the PhoneGap app to the background. You need some way to intercept it so you can start building your own history management mechanism. Sounds fun, right? It’s actually not that hard.

On app initialization, add an event listener for Android’s back button, and the callback to handle it. PhoneGap takes care of the interface between Android and your app.

document.addEventListener("backbutton", backKeyDown, true); 
function backKeyDown() { 
     // Call my back key code here.
 	alert('go back!');
}

That’s enough to get you started, and it should be pretty apparent if it works or not.

How about history management? It will depend on the app and what makes sense, BUT you’ll probably want to create a history array, and pop off some value that directs the app each time you hit the hardware back button. Here’s another idea: change the destination of the back button depending on the view. I personally like the idea of the latter because apps built on Sencha Touch are going to have easy tie-ins through predefined listeners JS Objects that define screen elements like buttons.

Mobile Platform Detection on the web

I had a use case recently where I need to determine whether the client browser was a desktop/laptop/etc or a mobile device that supports tap events in JS. This will be useful to people who are dynamically binding different events to elements.

var tmpElem = document.createElement('div');
tmpElem.setAttribute('tap', 'return;');
clickEvent = (typeof tmpElem.tap == "undefined") ? 'click' : 'tap' ;

You would use it like this

$('.showDetails').bind(clickEvent,function(e){
      display(e, $(this).attr('info'));
      console.log( clickEvent + " " + $(this).attr('info'));
      //would look like "Click fooBar"
 });

Tell your Mac to say “Anything” (and record it)

I don’t quite have the voice acting skills that people care to listen to on a pre-recorded message, so I was faced with a challenge when I decided I wanted one for our hosted virtual phone system over at PhoneBooth. I had a vague recollection that Apple provided recordable speech synthesis / text-to-speech (TTS) capabilities in the command line, so I went searching. Bingo. The app is called say.

This tutorial will show you how to use a Mac’s TTS capabilities to record text to an audio file, and then convert it to an MP3 for use with PhoneBooth, or any other application you might want to use.

Try this out from the command line (open Applications > Utilities > Terminal )

say "Hello world."

To save it to a file:

say "Hello world." -o greetings.aiff

Or to read the text from a file,

say -f script.txt -o greetings.aiff

PhoneBooth requires either wave or mp3 for its auto attendant scripts (e.g., “Press 1 for sales, 2 for billing,” etc.). Some voices support exports to wave (see the say documentation: man say), but the default in 10.6 doesn’t seem to – it creates an audio file, but produces no sound. The next step involves using lame to convert the file to a mono mp3. You will need to install lame using Fink or Mac Ports first. If you don’t have lame installed you can also use iTunes to do the conversion for you, but your tutorial more or less stops here without lame.

lame -m m greetings.aiff greetings.mp3

Finally, upload greetings.mp3 to PhoneBooth. Finished. For the curious, the -m m option tells lame to encode the mp3 to mono.

For the super-efficient folks out there, put it all into one line (and open when finished):

say -f script.txt -o greetings.aiff; lame -m m greetings.aiff greeting.mp3; open greetings.mp3

NB: If you wish to make your spoken text flow more naturally you can add [[slnc 300]] between sentences, increasing or decreasing the number for longer or shorter pauses. Apple has much more detailed documentation for the brave.

If your site goes down, does it make a noise?

I don’t go to my brochure site very often. It’s there for the curious client who needs the reassurance that I know what I’m doing. Considering I haven’t made any significant changes in quite some time, I had no reason to go back, but apparently I should have. At some point my .htaccess file went missing, which was pretty good to foil even the best attempts to view pages other than the home page. I have two questions: 1) How long were all these links broken – that I didn’t even notice it, and 2) Nobody said anything – why?

Regardless, everything is fixed now. Typing my name into Google or Bing will fetch either this blog or the brochure site in the top 2-3 positions. If you haven’t been yet, check out archive.mistercameron.com .

Cue deriding comments.

Cocoa Zombies – NSZombie

Found this great little debugging tip over at MarkJ.net. The short of it: You can use NSZombie tracking to debug memory crashes in your code. Great find – this whole time I was kinda under the impression that there was a lot of educated guessing involved based on where your fingers last touched code. I’m so naïve.

Compiling PHP5.3.x on Snow Leopard

I like to wait quite a while before upgrading Mac OS X to the newest release because, for me, it often requires quite a bit of work. I had hopes that Snow Leopard would be different because Apple finally installed current versions of the whole LAMP stack, but I wanted to wait regardless… just in case.

Why the wait?

I do dev work that require custom libraries in my PHP installation – vanilla PHP from Apple doesn’t have what I need. To do that I’ve relied pretty heavily on the Fink package manager. Too many times I’ve upgraded to the new OS and some of the libraries haven’t yet been updated to work properly on the new system. Usually after a couple months either the libraries get fixed or Google will give me enough results and clues that I can fix the issue myself.

First things first

I went ahead and compiled  Apache from scratch. It’s easy enough and you’ll need the 64bit support for PHP. MySQL was much easier – download the intel x86_64 installer for Mac OS X 10.5 (yes, even for Snow Leopard). Side note – MySQL finally got around to recompiling the System Prefs Pane to 64bit.

Installing Fink

I’ll save you some time. First, compile fink from source. When you set up the app, do the 64bit-only packages (you’ll know – it’ll prompt you to pick 32bit or 64bit). I tried the 64bit and PHP wouldn’t install. You can always do a separate mixed architecture install later (see here for details on mixed fink arch installs).

Compiling PHP (with GD)

I need GD. This tutorial did the trick – once I had figured out the 64bit fink issue(s). Follow it and the companion standard PHP / Snow Leopard compile tutorial, linked in that article. Take a look at my compile flags, if you’re interested:
export MACOSX_DEPLOYMENT_TARGET=10.6
CFLAGS="-arch x86_64"
CXXFLAGS="-arch x86_64"


./configure --prefix=/Library/PHP5
--mandir=/usr/share/man
--infodir=/usr/share/info
--sysconfdir=/etc
--with-config-file-path=/etc/php.ini
--with-zlib
--with-zlib-dir=/usr
--with-openssl
--enable-zip
--enable-exif
--enable-ftp
--enable-mbstring
--enable-mbregex
--enable-soap
--enable-sockets
--with-curl
--with-curlwrappers
--disable-cgi
--with-iconv=/sw
--with-gd
--with-jpeg-dir=/usr/local/lib
--with-png-dir=/usr/X11R6
--with-freetype-dir=/usr/X11R6
--with-xpm-dir=/usr/X11R6
--with-apxs2=/Library/Apache2/bin/apxs
--with-mysql=/usr/local/mysql
--with-mysqli=/usr/local/mysql/bin/mysql_config
--with-pdo-mysql=/usr/local/mysql

Two things: First, my PHP is installed into /Library/PHP5/. Second, my Apache is located at /Library/Apache2/. Nothin to it. Too bad it took me all day to figure this out. At least now I can move on with my life!

Trends and Trajectory

As 2009 comes to a close I’m sitting in a nice, comfy coffee shop, working on some code for an iPhone app I wanted to release a couple weeks ago. I’m not going to be hard on myself. The Holiday season came upon us and there became more important things like family, friends, and feasts. This evening I’ve spent some time reflecting on my journeys over the last 12 months and begin figuring out where 2010 might take me.

I’ve pretty much immersed myself in mobile development the last couple months as some exciting new projects have hit the desk. It’s changed my view of computing. I don’t think much is new, but the added perspective is certainly important. For the sake of pointing them out, something needs to be said about the tremendous growth in a few trends – the ones that will continue explosive growth well into the future.

Web

It’s no surprise that SaaS (software as a service / “pay for play”) has made it pretty big, especially with companies like 37Signals leading the way in team collaboration. Tons of companies are copying the business plan because it can work tremendously well. SaaS is quite a game changer over the old boxed software model. The ubiquity of the net makes it easy for customers to connect to a service, do what they need to do, and leave without ever thinking about all the dirty parts of actually maintaining a computer. There are tons of other great benefits to SaaS, but I’ll just have to save it for later.

UI

It’s no surprise that we’re finally arriving at the Renaissance of user interface design. Tools and information have become improved enough that instead of spending a ton of time writing code, and more time designing appealing interfaces. We see this in both desktop apps and the web.

Platforms

Mobile is big. It’s not going away. This is not about that. Apple’s iPhone has revolutionized our concept of the application development model. It has shown us how apps that do one or two things, but do them well, have taken the place of monolithic apps that try to do everything, but only sort-of well. I don’t think the iPhone can actually take credit for this, but it is probably among the largest driving factors in this mentality shift . We also see similar shifts in online tools (37Signals with their collaboration suite) and desktop apps (Compare the beautiful Billings.app from MarketCircle to Intuit’s Quicken and Quickbooks).

Beyond

I never promised anything revolutionary, but when you look at the horizon it’s pretty clear to see where the current trends will continue to expand into meaningful user experiences.

Case in Point: Orbital iPhone App

Check out this article in TUAW about how an iPhone app, Orbital, isn’t really making it for the developer after less than (nearly?) 100,000 units sold. The article suggests it’s just a case of bad luck. True? I’m not so sure. Here’s why.

Saturation

It seems to me that the App Store is pretty saturated. To clarify – the iPhone App market feels pretty saturated. I don’t mean that good apps don’t come along from time to time, however the sheer volume is daunting. I searched the App Store for “Camera” and came up with about 1200 matching apps.

Marketing

Face it, you can’t rely solely on the App Store to do all your marketing. Get into the top lists and you’re got a pretty good shot of doing well your first couple days. If you don’t, good luck with getting potential customers to find your app out of the thousands that accompany it in the store. It’s time to get involved with good ol-fashioned marketing – just like every other product in this world. Pretty soon developing profitable iPhone apps looks a lot like developing the boxed apps, but without the boxes and retail chain.

I think I’m done blogging about this for a while. Nothing like beating a dead horse.

Thoughts for the App Store

With regards to last night’s post on App Store pricing itself into an unprofitable wasteland, I thought of something.

What if there were two versions of the App Store? One for inexpensive, useless, or just plain bad apps, and another for apps that met certain price, quality, or other criteria?

For those wishing to make iPhone development their business, the current version of the App Store isn’t the ideal marketplace. Finding apps can be challenging – either your searches aren’t quite coming up with what you’re looking for, or you have to wade through pages and pages of apps that don’t interest you. The other problem is the pricing competition with people who may not have similar economic goals as you do.

App Couture

Apple could offer different development tiers. Break the App Store down into groups indicative of where developers enroll. Keep the $99 price point for individuals. After that, add one or two more tiers for the ambitious or the corporate developers – maybe at $499 and $999. I don’t think Apple needs to add additional features. The benefit from joining the higher tiers is that you get placed in the App Store Premium. It’s App Store Couture. Could you also maintain a category for ad-free apps? Never mind the small advertising on the info/about page. I’m talking about those annoying little pop-ups at the bottom of your screen.

With those benefits are going to be some pitfalls. Just because somebody pays several hundred dollars for the premium listing does not ensure a quality product. And what with the fees you pay, will Apple do with it? It’s not up to me, but if it were – how about using some of that extra cash to improve the approval process?

App Graveyards

Let’s take this another route –  take old apps behind the barn, à la Old Yeller. Ok – maybe a bit extreme. Why not make an app graveyard where old apps go to die. By placing certain requirements on how often apps must be updated, Apple could, in theory, keep the App store fresh by keeping new and newly updated apps, while throwing the abandoned ones to the App Store Graveyard. In all likelihood you’re probably not interested in using many of the apps first developed when the iPhone was released. It’s not too big a task for developers to make small, incremental changes on a regular basis. It’s a sticky place to be in. On one hand you’ve spent a lot of time (money) on developing an application, and now you have to spend more refreshing it every so often. The updates might not drive new sales – money wasted, so to speak. Could that problem be solved by simply having to re-submit apps once a year? Uncertain. Surely it would produce some undue burden on the app approval team for apps they’ve already approved before.

Indies

Who wouldn’t like Apple to open up the distribution channels to third parties? I could see this open the possibility for independent virtual storefronts where retailers have the ability to pick and choose the apps they feature through their store. This approach has two possibilities that I think could work. First – Apple could open the iTunes AppStore to an affiliate program: App Store Indies. Online retailers could list apps on their website, but the whole thing link back to iTunes, as it does now. The second scenario would be the ability to distribute apps outside of iTunes, but still retain that special Apple-certified seal of approval that is required already. The apps, registered and digitally signed through Apple, could be available for download, or even boxed up and sold in block-and-mortar stores. There would have to be an economic incentive to Apple and the retailers to make this work. Because Apple owns the only distribution channel, I don’t see any reason why they would want to change unless it meant more dollars for them. That could easily be achieved through higher-priced premium apps. As a consumer, I like the idea of multiple outlets because I come to know and trust certain retailers and go back to them repeatedly. The cream will rise to the top – those retailers selling good apps will succeed, but at least they have the incentive to not bend to the price wars.

Am I biased? You betcha. As a developer, I want to make sure that I can make a living out of what I do. I can’t afford to spend hundreds of hours on projects for the chance of making one or two thousand dollars, 99¢ at a time. The App Store may have become a popularity game, but that doesn’t mean it should do so at the cost of making a living – especially if the iPhone platform is going to continue to be a profitable platform for the developers. If the money leaves, so will they.

Hey there! Come check out all-new content at my new mistercameron.com!