For posterity, I’ve copied Mark’s explanation here. For his full explanation and his code example, follow the link above.

My favorite way to explain how delegates work involves animals.

Let’s say you are going to create a particular bird. You start with a predefined class definition of a bird (provided in the existing framework as, say, CFBird). The existing framework class assumes all birds have certain things in common — they hatch and grow the same, poop the same, fly the same, and lay eggs the same way, etc. (tee hee, I said poop.  ) But different birds look different, are different sizes, chirp differently, eat different things, and may mate differently.

So let’s say Apple provided you with the basic bird class (with hatching, growing, pooping, flying and egg-laying behavior already built in).

Here now in this more advanced age of object-oriented design, there’s a concept (design pattern) called “delegation” and it’s a cool way to easily implement custom classes, assuming ahead of time that you’ll likely never need to worry about anything else about creating birds other than specifying how they differ from each other — how they look (size and color) and how they chirp, eat and mate.

So, the people who designed the CFBird class have set up a “protocol” which specifies the “delegate methods” (kinda like “callbacks” in C) which is all your new class will need to implement to create your custom bird, and you’re done! Basically the class is going to call into your code when your particular bird is drawn, when it chirps, eats and mates. These tasks are “delegated” to you in your subclass of CFBird.

Everything else is handled for you, and you only need to concern yourself with what is different about your bird, and forget about what is the same amongst all birds, simplifying your life and making things more consistent.

In your code, when you specify your new class of bird, in the @implementation you’ll make reference to a <protocol>, and by doing so you are telling the system that you agree to implement the methods specified in that protocol which will detail exactly how your particular bird is going to look, chirp, eat, and mate. Done and done.

The subclassing comes first, and the possible delegate methods follow if you specify a protocol to follow.

In one of the tab’s views I had a standard button with a Touch Up Inside event that I had connected to a buttonClicked method in the view’s controller.  For some reason, when I tapped that button the app would crash.  This was not happening when I built the same stuff in a single view app.

I went searching and was happy to find that the problem was well described and solved in the developer forums of MacNN.  It turns out that when you have have multiple view controllers for separate .xib files being controlled by a Tab Bar Controller you need to take an extra step of setting the Class Identity for that particular view. Here’s how:

1. Open up MainWindow.xib in Interface Builder
2. Expand the Tab Bar Controller item. (Your views are displayed)
3. Single-click the controller containing your button.
4. Hit ⌘-4 to bring up the Properties Inspector.
5. Under Class Identity at the top, you’ll see the Class is set to UIViewController.  You need to use the dropdown to select the controller for that particular view.  In my case it was called SounderViewController, but it should match the name of the controller where your button clicked method is.

Voila.  Hope that helped you. If it did, please leave a comment. If it didn’t, please leave a comment.  Follow me on Twitter for iOS, music and life musings: @jetsetter.

I’m pumped to announce availability of Rock Show 2.0.  This is the first version of Rock Show that works on the iPad and both the iPhone and iPod Touch.  A lot of fixes and tweaks are in this version of the application, along with some new posters as well!

Two articles are up about the release, Padgadget is hosting one item and a second can be found at IntoMobile.  For a full low-down and updated info on the app, visit its page: http://www.rockshow.fm

Apple doesn’t give much guidance on this important chunk of text. “Write your Application Description with a focus on what makes the functionality or design of your app unique.” was a tip from this past June from the App Store Tips blog.

We know that 4000 characters is the limit.  And App descriptions are made up of simple text, including unicode symbols like checkboxes (✔) and more (♣☢☂).  Apple takes your unicode text and formats it for display on the web via Web Preview, in iTunes and on the iOS devices themselves (the app store).

Since you probably have very specific points you want to get across, and users have a very short attention span, you need to pay attention to how Apple will format what you write.  In this entry I discuss how to create app descriptions that look great everywhere Apple publishes your app description.

Word Wrap and the Fold

Word wrap occurs in app descriptions when enough characters fill up a line.  Each line has a maximum number of characters and when a word goes over that, it is bumped to the next line.  This is important because one word of word wrap can waste an entire line of potential ad copy.  This is important: the length of your lines in your app description affects the placement of the fold.

The fold is the point where iTunes, Web Preview or the iPad App Store app decide to make the user click or tap the More… button.  Everything below the fold is out of sight, out of mind.  Without the data to prove it, my hunch is that at least half the time, users are not bothering to click More… before deciding whether they are installing an app or not.

All this means is that you must use the space above the fold as effectively as possible.

All app purchase vectors limit the top of fold line display to three lines.  Two important rules here:

1. Blank lines count as lines.
2. Lines over 120 characters in length will lead to word wrap and the use of an additional line above the fold line.

App Description Formatting on iTunes and Web Preview

Web Preview and iTunes behave in a similar way, Web Preview is just that, a summary of your app description and screenshots along with a link to view the app in iTunes.  The final step on a computer is to have iTunes open to the page where the user clicks purchase to download the app.  A history of Web Preview and SEO implications may be found here.

Both iTunes and Web Preview show the same number of lines from your app description before the “break” point.  A break point is where all text is hidden below the fold, and the user must click the More… link to display the rest.

Let’s look at some examples. The following three shots were taken from Web Preview.  iTunes displays the same amount of information as Web Preview, however only Web Preview has fixed width.  Resize the iTunes app window, allows longer word-wrapping lines but ultimately the same amount of information above the fold as Web Preview.

Note: Click any images to see the full size.

Here the app publisher has chosen to highlight two specific sentences and put a line of space between them for readibility.  Note that if the first line was longer than 120 characters, top of fold would be a complete and a partial line (due to the wrap) and the third would simply be a blank space.

Here the app publisher has one long line of text with no carriage returns.  This means that all three allowable lines of text are the result of one word wrapped line.  This is the maximum amount of information you can cram into the top of fold, but it does not read very well here.  Wait until you see how ad copy like this looks in the iPhone’s App Store.  For your reference, this one line of text is about 343 characters in length.

Looking at the devices

Currently there are two different sizes in the iOS hardware family.  The long one, (iPhone and iPod Touch devices), and the wide one, (iPad devices).  In addition, there are three types of binaries, iPhone only apps, iPad only apps and Universal apps, which work on both iPhone (iPod Touch too) and iPad.

If your app is only for iPhone you need to focus on how it is displayed in the iPhone’s app store.  If it is only for iPad, you need to look at it there.  In either case you also need to look at how Apple’s relatively new Web Preview page displays your app description too.

App Description Formatting on the iPhone

Often users install apps directly on their device, rather than using iTunes and syncing a purchase.  It is certainly less clunky and you have instant satisfaction of getting to run the app right away.  That means your app description marketing copy should be influenced by how the lines of text look when displayed on each of these devices.

Here are some screenshots of how word wrapping of text affects readability on the iPhone App Store app.  Note that the iPhone app store app only supports portrait orientation.

Interestingly, a long line of text looks like a nice paragraph on the iPhone.  Also, Apple uses the bullet character to bullet features.

Note here that the long lines make the display of this text awkward and difficult to read.  (I use it anyhow!)

Note a few things here:

1. The first and third lines are used so Web Preview and iTunes display both lines top of fold.
2. The bulleted lists do not word wrap, (the max char per line is 45).
3. Unicode goodness makes it look crisp.
4. Attention goes to lines 17 and 18 in the app description.  They are the final ones before the user would scroll down to see the screen shots.

Here’s Rock Show’s Web Preview:

App Description Formatting on the iPad

The iPad app store app supports both landscape and portrait modes.  It also brings back the idea of the fold and its exposing link, “More…”  In this way, the iPad’s app store application is formated more like iTunes’ traditional display.  See for yourself by comparing iBooks Web Preview with the landscape view of the iPad App Store app. iBooks also happens to have a fancy custom background that 3rd party developers generally won’t have access to:

Conclusion

There isn’t an easy way to preview how your app’s text will look in all these different store fronts until after it is published , but you can at least know what you’re up against.

Experiment with your language and line length.  Every opportunity for a new installation of your software on an iOS device holds not only immediate, but residual value.  Since potential users may view your value proposition from a few different angles, pay attention to the quirks and write accordingly.

Aaron Fechter the President of Creative Engineering, Inc has been reprogramming a working animatronic bear-band set up.  It looks like the company created it for a line of restraunts similar to Chuck E. Cheese.  He’s currently taking cash bids to do syncing or “choreography” for the band members.

The way the performance is filmed and presented are awesome.  Shakey prolonged shots, quick pulls outward.  The overall video quality is low and the colors look a bit washed out.  Everything is blurry and the bear with the guitar has a spooky shadow.   Great media.

One solution to this problem would be to create image files containing stylized text and then rasterize them and allow the user to page through them.  The problem with this is that you can’t have tappable URLs or links embedded in the text.

David Peixotto, coding ninja and my business partner for Neutrinos, suggested we look at using a Webview or HTML view and put an imageview in the background.  The trick is telling the iPhone to display a UIWebView with a transparent background.  I looked around for the solution to this and came across this helpful post in the iPhone Developer SDK forums.

Step one of getting a transparent web view in interface builder is to create HTML in the controller.m for the view containing the webview that contains the CSS line: <body style=”background-color:transparent”> Inside the <head> </head> sections of the html.

Step two is to set the background color of the webview to clear or transparent:  myWebView.backgroundColor = [UIColor clearColor];

Step three is to make sure that the “Opaque” box on the inspector of properties of the WebView is unchecked.

That should be all you need to do.  Drop a UIImageView behind the newly transparented web view object and you should be able to use a scrollable rich text with hyperlinks.  Horray.

If this helped you or confused you more, please post in the comments!  We do have it working on 3.0 much to the happiness of our client.

Dynamically built webpages, (especially applications), require time to load and visual feedback that something is happening.  The most famous example is the gmail loading page:

Gmail uses a more sophisticated progress bar to represent the loading of the webpage.  I found an article on yensDesign that gives some great advice on how to do this, if you want to get really fancy.

If you have a dynamically built page that you’d like to give a loading message to that doesn’t require a full progress bar, I recommend simply displaying a message and an animated gif.

The Method

The trick to accomplishing this is a small mix of JavaScript and CSS.  You don’t have to be using <div>’s to display your content, but you should.  My example uses <div>’s.

Let’s begin by assuming you have the majority of your page’s content within a series of nested DIV’s, where the outermost DIV is called “container.”

 <div id="container">
    <div id="heading">
       ...heading content...
     </div>
     <div id="body">
       ...body content...
     </div>
  </div>

Normally, the dynamic content in your container would be rendered by the browser after it has downloaded and performed the main JavaScript routines.  What we want to do is hide the container when the page is first loaded and instead display a DIV that contains a waiting message and a little animated gif icon.

Begin by using the CSS display property to hide the container DIV like so:

  <div id="container" style="display:none">

Next, you need to add a new DIV that contains your “Please Wait, loading…” message.  I chose to include an animated gif icon of a twirling circle, which I easily created using the AjaxLoad.info, a site created by Catherine Roman.   If you want to download my animated loading gif, you can get it here.

Here is an additional set of nested DIV’s that contain the loading content.  This should be placed outside the container DIV:

      <div id='siteLoader'> 
        <div id='siteDetailLoader'> 
        <img src='/path/to/your/animated/gif/loading.gif' border='0'> 
        Please wait while the page loads...<br /> <br /> 
        </div> 
      </div> 

You’ll note that the display property is not set on siteLoader because it is visible by default.  This is what we want.  The trick now is to make the siteLoader DIV dissappear once the dynamic page content is done loading while simultaneously displaying the container DIV with the real page content.

This is handled using the global event handler onLoad.  There a few ways to make use of the onLoad event, I recommend including an external JavaScript file.  Do this by saving a new text file called actions.js in the same directory as the page you’re changing.  Just after your <title> tag on your document include this external JavaScript  file using:

<script src=”actions.js” type=”text/javascript”></script>

Inside actions.js, you need to include a function based on window.onload as follows:

window.onload = function() {
   document.getElementById("siteLoader").style.display = "none";
   document.getElementById("container").style.display = "block";
}

What this is doing is saying to the browser, “as soon as you’re done loading the webpage, you should hide the ‘please wait’ stuff and show the meat and potatos of my webpage.”

To view all of this in action, have a look at my recently updated online portfolio which of course, talks up what a great person I am.  I hope this has been helpful, as always–please post your comments!

For further reading on busy indicators and the important visual feedback and attention cueing needed to be successful with the display of heavy dynamic webpages, have a look at the article series on SAP Design Guild by Gerd Waloszek called “Waiting at the Computer: Busy Indicators and System Feedback.”   There is a wonderful table giving guidelines on the type of feedback that should be displayed based on user wait time.

I was just doing a ShareThis icon for a client I’m working with and found that how to properly style the button is poorly documented.  In order to replace the whole icon and text, you are supposed to use the developer API.

I only wanted to style the text, so I was hunting for some CSS to style the text and could not find the right classes to call.  Some hunting turned up the following:

.stbuttontext – This class will allow you to change the look of the text, ShareThis.  You can style it with any normal styling like color or font-family but text-decoration does not seem to work. :p

.stico_default – This class allows you to style the icon itself.  An example on how to replace the ShareThis icon with your own site’s favicon webmonkey is: 

{
	background: transparent url(http://www.banagale.com/favicon.ico) no-repeat scroll 0px 0px !important;
}

I’m interested in any other css that can be used to style the ShareThis button without requiring API calls (if there are any).   if you know of additional classes, or this helped you please post a reply.

Follow me on Twitter

Salesforce does not explain how its clients should go about crafting a quality Contact Us web page.

What is a quality Contact Us web page?  

Generally you’ll find the same type of fields on Contact Us pages across the web.  You are asked for your first and last name, job title, complete address and something specific about your query, like Where did you hear about us? Or What model Range Rover are you interested in?

 What’s the use of having their name if you don’t have their phone number?  Usually, a company will want to set specific form fields to required. Checking whether a potential customer has filled out a required answer is called form validation.

An Overview of Form Validation

There are two ways to validate form data, client side and server side.  While doing both client and server side validation may be a best practice, my experience is that only one method is chosen.

In general, Javascript is used to validate forms on the client side (in browser).  When a potential customer forgets to enter their phone number, javacript pops a small dialog box reminding them they screwed up.  The user fixes their error and tries submitting again.

Server side validation occurs when the potential customer submits a form and a new page loads, typically with a warning in red saying what information they forgot to enter.  The user then clicks back to return and complete the form.

Limitations of Data Validation on Salesforce Powered Contact Us Forms

Salesforce does not allow server-side data verification.  My understanding is that all users of Salesforce submit form data to the same encrypted URL: https://www.salesforce.com/servlet/servlet.WebToLead?encoding=UTF-8

A unique customer ID accompanies all data posted to Salesforce which routes it into your personal silo of the great CRM cloud in the sky.  Since you don’t control this servlet page on salesforce.com, you can’t do anything once the form is submitted.

This means that a client side check, using javascript, is your only real alternative for validating forms used to feed data into Salesforce.

Implementation

There are many examples on the web of how perform simple form validation with Javascript.  If you want to get really fancy, here’s the javascript SalesForce uses for validating its own forms.  It includes checking for the email address to be formed properly and if the phone number is valid.  A screenshot of the page the above jscript was taken from is below.

Keeping it simple, you can simply ensure something was typed into individual fields like so:

<script type=”text/javascript”>

function validate_required(field,alerttxt) {

with (field)

{

if (value==null||value==”")

{alert(alerttxt);return false;}

else {return true}

}

}

function validate_form(thisform)

{

with (thisform)

{

if (validate_required(first_name,”Please fill out your first name.”)==false)

  {first_name.focus();return false;}

}

}

</script>

The matching form element would be:

<label for=”first_name”>First Name: *</label>

<input  id=”first_name” maxlength=”40″ name=”first_name” size=”25″ type=”text” /> 

And finally the <form> tag needs to run the javascript:

<form action=”https://www.salesforce.com/servlet/servlet.WebToLead?encoding=UTF-8″ onsubmit=”return validate_form(this)” method=”post”>

Voila.  You have performed client-side data validation.  

Caveats and Other Madness

This example uses the standard Salesforce field “first name” and its associated id, first_name.  If you use custom fields in Salesforce, you’re going to have to deal with weird id’s, like 000004fsx02.  In these cases you will need to construct form elements with different ID and Name values, since the javascript that I used did not accept DOM names that began with numbers.  

My research suggests that this is against convention, but you do what you’ve got to do.  Maybe you can write better javascript that will take these funky salesforce custom field id’s.  If you can, please post your solution here.

I should also mention that occasionally you want to hard code data for passing into custom fields in Salesforce.  In these cases you must still use the form data spit out by web-to-form, only set the only response to what you want and set the item to hidden.

Suggestions for Salesforce

Salesforce disowns anything you do with the HTML that the web to form functionality kicks out for you.  They do not support creation of contact us forms, and provide no advice on technologies or methods to validate data inbound to their CRM.  Asking their customer support staff  if their CRM has the ability to perform server side validation will be met with confusion.

Salesforce needs to provide better support for this important aspect of lead origin into its client’s sales processes.  Undoubtedly, SF likely has elegant methods for working with data using its SDK.  If it is going to actually reach startups and smaller businesses with a $9 per user subscription plans, it needs to better support the most basic functionality of passing data into the system.

If Salesforce does not better address the down market, it will lose against startups like Zoho that offers a similarly priced CRM and a comprehensive set of other web applications and that has a user community willing to create how-to videos for things like Contact Us form creation.

At a minimum an explanatory page should be available in Salesforce’s online help to explain the basic methods for building and validating web form data.

I hope this has been helpful, please post your experience!

Follow me on twitter.

Developers working on emerging software platforms are a flexible bunch.  They’re used to having theirapplications break so long as the platform overall is being improved.  A better platform means more users, which means greater opportunity for 3rd party developers.  One thing developers do not like, however is having their software tools gobbled up an encorporated into the core of the platform.

I wrote about how this was happening in my blog post, Nationalization or Expropriation? Independent Facebook Application Developers Continue to Face Uncertainty.  Something entirely different is happening right now on the Touch platform, however.

It all started with the an application called, “Pull My Finger,” which allowed people to touch illustrated fingers in order to play back audio of flatulence.  You see, Apple, unlike Facebook, will only allow applications to become available to run on the Touch Platform devices (the iPhone and iPod Touch) after they have been reviewed by hand by an Apple employee.

Let’s take a look at the normal application development cycle for getting an application up onto the Apple Touch platform:

Now let’s take a look at the alternate scenerio:

As you can see, the developer has two choices when their application is rejected from the iTunes store.  A redesign scenerio could occur when their application breaks a minor rule.  For instance, early on Apple was rejecting applications that mis-used the vibration function on the iPhone.  A developer could rectify this problem by taming down their application’s vibration and re-submitting.

The give-up scenerio is based on a different type of rejection from Apple.  There have been two well-documented cases of Touch Platform application rejections by Apple because the fundamental basis of applications was rejected.  As mentioned, the Pull My Finger application was rejected because “[Apple] determined that this application is of limited utility to the broad iPhone and iPod touch user community, and will not be published to the App Store.”

More recently another rejection was delivered to someone who had created a podcasting application.  In this case Apple rejected it “since Podcaster assists in the distribution of podcasts, it duplicates the functionality of the Podcast section of iTunes.”

The problem faced by developers is uncertainty.  How can they know what is and what is not ok before investing development time and resources into creating an application.  The problem for Apple is that if they define exactly what the rules are for approval, there will always be exceptions.  Plus, Apple may still not know what their rules are.

Some of the blame lies with developers and their desire to play on the edges of what a reasonable and rational iPhone application idea might be. For instance, designing low-brow flatulence applications or tools that replicate existing functionality does not show a lot of creativity on the developer’s part.

In addition, the I’m Rich application made it past Apple’s application approval group initially, but when it made headlines, it was an embarassment for Apple.  Can we really blame them for being more careful now?

But just as Facebook application developers grew angry over the integration of functionality they had developed into the Facebook core, Touch platform developers deserve great communication from Apple on what is and is not ok, in order to avoid wasted effort.  Developers have indicated that applications that violate non-Apple trademarks have successfully been approved and listed for sale in iTunes.

One developer fed up with Apple’s approval ambiguity has given a number of suggestions for improving the situation, including Apple hiring a a 3rd party developer champion or evangelist, someone who can perform official coaching or pre-approval on application ideas prior to beginning a development effort in earnest.

For now, developers will have to stick to common sense in coming up with ideas for new applications for  the Touch platform.

[Update 9/20/08: I found a more detailed flowchart on the approval process here.  Also, I made a minor edit to  second flowchart to reflect the possibility that the app is approved]