Tutorials (51)


Quiet the Console – PhoneGap / iOS

I have a confession – I’m a console logging junkie. I just like to see what’s going on. While that may be great for development, at some point you’ll have to quiet the logging down for production. Really – doing enough logging will slow everything down each time you’ve inserted a console.log() into your code.

Silencing the output to XCode’s debugging console wasn’t immediately obvious. Overriding console.log() in JS by setting it to an empty function worked in the browser for development, but as soon as I loaded the app onto the actual simulator, we were back to square one. Enter the PhoneGap DebugConsole prototype. Override it.

Insert this anywhere after your phonegap.js file loads. It’ll keep things quiet as long as DEBUG = true…

There you have it




PhoneGap + XCode4

There’s been a bit of confusion surrounding changes to XCode4 and PhoneGap. Right now the big ones are 1) Where did my PhoneGap user templates go!? and 2) How do I submit my PhoneGap-based app to Apple? Let me help you.

1) You want to create a new PG project, but you’re not seeing the XCode templates when you go through the new project menus. Check out Shazron’s blog @ Nitobi for a command-line script to get you a new project up and running. It’s not as sexy as the XCode template, but it will do.

2) You can’t compile your app for submission to Apple? That was a little more tricky to track down. See this thread on the Apple Dev Forums for a bit of an abstract view of what’s going on. I’ll save you the details. Follow these steps to XCode bliss.

  1. Select the PhoneGapLib.xcodeproj entry in your files list:
  2. Make sure the “All” tab is selected:
  3. Look for the “Deployment” section and scroll down until you see the “Skip Install” parameter. Set Skip Install to YES:
  4. EDIT: Make sure to verify your target device…
    Make sure you have the “iOS Device” option selected in the schemes drop-down:
  5. Go over to the “Product > Archive” menu. XCode will do its compile magic. Open the Organizer to see the app and the listed archives when the compile is complete. At this point, make sure you are ready to upload the app to iTunes Connect. Bonus: we get to skip the Application Loader app from now on!
  6. Select the archive and click the “Submit” button. XCode will ask for your credentials. Log in and select the appropriate app and distribution profile from the list. Submit. If all goes to plan, you’ll get a message of approval. Finished.

That was easy. Now you can navigate the XCode4 waters with PhoneGap.




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 )

To save it to a file:

Or to read the text from a file,

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.

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):

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 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!




Installing PEAR Libraries Locally

[I started this post quite a while ago and forgot about it. Here it is finished. Hopefully you find something useful here]

I’ve had a few projects already where I could really use some PEAR libraries but not sufficient enough access to the server so I could install them in the system-wide PEAR include directory. I went searching for an easy to manage way to package specific PEAR libs along with apps I was building and installing for clients – something that would work without access to system-wide PHP/PEAR setup, and even in rare cases where I couldn’t write outside the document root.

First place to at least read through is the documentation. I’m going to assume you already know the basics of PEAR.

This summary will discuss the FTP method, as it seems applicable to more situations. For me – I keep my sites under version control so I need to be able to perform a local install that I can commit to the repository and either export or update on my various server environments.

Tools:
* Terminal or command-line (CLI)
* CLI version of PHP
* CLI version of PEAR

Steps (code follows)

  1. Create a directory where you want the PEAR libs installed. Note: PEAR will create a directory named pear in the location you specify.
  2. CD into that directory.
  3. Create your config file for your local environment (probably won’t be needed on external servers unless you plan on installing from there, in which case you should create a separate config file for each site).
  4. Install and update packages.
  5. Update your app’s include paths.

The Code:

  1. Create your config file in the PEAR directory from step 1, above. Absolute paths, absolutely!

    The first path is the location where you want the files. The second path is the location where the pearrc file is located. I usually put the PEAR files in an includes directory within the site’s document root, just in case a host or client I’m dealing with doesn’t have write access in higher-level directories. It’s best to keep the pearrc file outside of the webroot, or deny access to the file via Apache’s Allow/Deny directives.
  2. To run PEAR commands on your local install, you will need to use the following format

    (otherwise you’re likely working on system-wide changes – doesn’t help you when it’s time to deploy to the server). An example,
    %> pear -c /path/to/setup/pearrc install File_CSV_DataSource
  3. Set your app’s includes path to search in the PEAR directory:

    Change as needed.

That should do it. It’s a basic introduction, but if you already know how to use PEAR, you’re already 95% of the way there.

 




Using Pinch Media Analytics in PhoneGap

Getting close to finishing up an app for a client in the coming weeks, my business partner and I decided it would be a good idea to include some analytics code so we could track how people are using our application. We ended up using Pinch Media’s Analytics to do our tracking. It came down to this: their code is REALLY easy to implement, and they provide us with just enough information to satisfy our curiosity. I think one of the biggest draws is that it records information regardless of the user’s online status – meaning offline app usage information is stored to a small database and then uploaded once the user reconnects. Had we used a web-based solution, which would have been natural given the nature of PhoneGap (the underpinning of our application) being UIWebView, we would have missed out on some details without considerable work-arounds to cache data as Pinch Analytics does.

Because PhoneGap is essentially a single view application that displays web pages, you are a bit limited with the extent that you can integrate Pinch Analytics out of the box… unless you use javascript callbacks to Objective-C within PhoneGap. That’s not the point of this post. The point is that you just need to follow Pinch’s instructions and you will have analytics data reported back to you within a few hours.

Moving forward, I’m likely to investigate some of the finer points of creating my own PhoneGap callback functions so I can embed Pinch Analytics Beacon methods, which are nice little ways to record information about discreet actions taken within your app – recording leader board views, for example.




PhoneGap Up To Speed

I recently ran across some major performance problems with a jQTouch app running in PhoneGap. Some of the symptoms included long pauses on touch events, non-responsiveness, and laggy transitions.

Brian LeRoux (Nitobi/PhoneGap), Jesse McFayden (Nitobi/PhoneGap), and David Kaneda (jQTouch) were the stars looking into this issue. Ends up Jesse found where the Accelerometer was taking a 40Hz sample rate and sending the data to a callback. The solution is to just disable Accelerometer use – either in the plist or, as I did, comment-out all the accelerometer bits. Likewise, I removed location functionality, as this app in particular doesn’t need it.

You can read Jesse McFayden’s post here. And if you’ll excuse me, I have an app to finish…




ReadOnly Form Elements

Here’s a quick note for the frustrated:
When setting the readonly parameter on a form element via javascript, make sure you use a capital “O” as follows:
elem = document.getElementById('myInputElement');
elem.readOnly = true;

Why it took me so long to find that out, I have no idea why. Most forums threads by others seem to think the disabled parameter is the best way to go. Actually, the sheer number of people suggesting that makes me think it’s a bad idea – just following the crowd. This is why readOnly might be the right option: You’re still allowed to post the form value, but the user isn’t able to change what’s inside the box. When using disabled *nothing* gets posted from that element. So if all you want to do is prevent a user from editing the value of a form element, use readOnly. If you don’t want that value posted, then go ahead and use disabled.

Enjoy!