Here, for example, is a way to add my Open in External App icon to links that you capture from a UIWebView to display in Mobile Safari:

a { color:rgb(50, 79, 133); text-decoration:none; padding-left:26px; background-image:url(data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABoAAAARCAYAAADDjbwNAAAAGXRFWHRTb2Z0d2FyZQBBZG9iZSBJbWFnZVJlYWR5ccllPAAAAKZJREFUeNpi+v//PwM9MBMDncDws4jFOKBNF0hfIkGPydkNVWfJ8dEcEvXMIctHQKwOZTMSof4/EOuSaxE/CerBjgEGN9xiYDAywvhANt6g+09JJAMt+Y/PAmSLPhERXLgw0ZZRLXmDLCNkER81LALFFaU+YsSD4ZYgJRDaBB0xlsCS9ycSkvh/tGBiJJSskX10k4jUhZzKLpBbqKaTqCeFHIsAAgwAk2iI07NfUtQAAAAASUVORK5CYII=); background-repeat:no-repeat;
}

• apporacle | iPhone & Mac OS Icon and UI Design - Nicolas Thomsen
  An iPad mock-up of OmniFocus by the very talented Nicolas Thomsen:

  "Since OmniGroup announced their plans to bring their products to the iPad (iPad or bust!) I have been wondering how my most used app, OmniFocus, would look and feel on the platform. I made a quick mockup of how I´d like it to work based on the iPhone app and the Mac OS app."

  (tags: nicolas thomsen, apporacle, ipad, mockup)
• PSD: Apple iPad fully editable template | Icon Design for iPhone and OS X
  Fully editable Apple iPad in PSD format. Every element you see is editable via vector masks. Everything is scaleable.
  (tags: ipad psd ui)

In a nutshell, Twitter requires any new applications that use the Twitter API to use oAuth for authorization if they want to display the source parameter in tweets. The source parameter is the little bit of text and the link to your app that appears at the bottom of tweets (e.g., via Tweetie). It constitutes a very important bit of organic marketing for Twitter apps.

My gripe – as a developer creating a new mobile Twitter app for the iPhone – was that this rule only applies to new applications. Existing application can continue to use basic authentication and display the source parameter. This currently creates an uneven playing field where new desktop and mobile applications cannot compete with existing applications on UX due the following deficiencies with oAuth and/or Twitter's implementation of oAuth:

1. Twitter's lack of a mobile-optimized oAuth screens
2. The trip to the browser is a major context change for the user for desktop and mobile apps. It is not the same as opening a new site within the context of the browser experience.
3. Cumbersome and convoluted UX for setting up multiple accounts in Twitter. Setting up N number of accounts means N number of round trips from the browser, each requiring the user to sign out, then sign in again before approving the new account.
4. The Consumer Secret is stored in a desktop/mobile client and thus is open to reverse engineering and spoofing. This nullifies the argument that oAuth is better for identifying clients when it comes to desktop/mobile apps.
5. oAuth recursive delegation is not a solved problem. How does a mobile Twitter client, for example, sub-delegate the authority it got from the user (in a revokable manner) to a service like TwitPic?

Alongside actively discouraging developers from creating new desktop and mobile apps, this policy also leads to user experience travesties like Echofon asking the user for their credentials before sending them to the browser where they have to sign in again. (All this just so that it can meet the requirement of "using oAuth" and display the source parameter while remaining competitive with existing apps that offer seamless integration with third-party Twitter services.)

As of yesterday, however, a couple of very exciting things have either been implemented or come to light that have almost entirely addressed my concerns with Twitter's oAuth policy (and which give me new hope for the evolution of oAuth on desktop and mobile).

Twitter launches mobile-optimized oAuth screens

A major UX flaw with Twitter's implementation of oAuth was the lack of mobile-optimized oAuth screens. This is how I described the existing user flow in my email to the Twitter Development Talk list recently:

Sending a user to Twitter's oAuth page after having slaved over every pixel in your iPhone app is like giving someone a ride in a Ferrari and then throwing them in a mud puddle before pulling them back in for the remainder of their ride.

I'm happy to report that Twitter addressed this yesterday and has launched mobile-optimized Twitter oAuth screens. This is great news! This new feature means that mobile Twitter clients that currently implement oAuth will get an immediate user experience improvement.

This does not change the fact, however, that the traditional oAuth flow – which requires a major context change on desktop and mobile applications – presents the user with a less-than-stellar user experience.

Since the browser redirection is a UX nightmare for mobile and desktop apps, it has often been circumvented by loading the oAuth authorization screen in a web control. As the Exposure iPhone App example in the previous link shows, this nullifies the advantages of having a trusted third-party application present the page, along with its URL, to the user. This sort of circumvention happens when the UX and practical concerns of one context (desktop/mobile) is not met by a solution that was originally created for a different context (web). It also leaves the user as open to getting phished by a malicious app as a regular credentials request and undermines trust oAuth itself.

I'm happy to report, however, that Twitter has gone several steps further to implement a pragmatic extension to oAuth that radically improves the user experience for desktop and mobile apps.

Twitter fixes oAuth for desktop and mobile with browserless xAuth extension

Twitter has implemented a new flavor of oAuth that I've started calling xAuth due to the x_auth headers that it uses. This is a radically different flow to the traditional oAuth experience that requires a round-trip to the browser.

The xAuth extension to oAuth allows clients to obtain a user's credentials and then exchange those for an oAuth token without a trip to the browser. It appears to be an implementation of the OAuth Access Tokens Using Credentials Internet Draft submitted to the IETF in March of last year.

Twitter's xAuth implementation is not open to the public yet but at least one app, Seesmic Look, is using it. Twitter has not given a timeline for when the feature will be available to other apps, stating that "it will be available publicly soon".

You can't imagine how happy I am to see Twitter implement this. It makes perfect sense for desktop and mobile applications which run in a trusted context (as opposed to web applications that do not).

Have no doubt about it, xAuth is a complete UX win for oAuth that makes it both usable and practical for desktop and mobile applications to implement and I look forward to seeing it become part of the standard.

oAuth Recursive Delegation

oAuth Recursive Delegation – where one client can sub-delegate the authorization it got from the user to another client – is not a solved problem at the problem. There is an Internet Draft on oAuth Recursive Delegation from September of last year but, from what I've been reading on both the oAuth and Twitter lists, no concrete implementation exists at the moment.

Currently, non-oAuth clients simply share the user's username and password with other services like TwitPic. This, of course, is a rather terrible practice but provides a seamless user experience.

Stop-gap solutions for oAuth, like sharing an application's Consumer Secret and Consumer Key, are not much better.

The way I see delegation working in oAuth is actually quite simple. Here's an example for a general-purpose mobile Twitter client (lets call it LoudBird) that uses xAuth:

1. LoudBird asks the user for her username and password
2. LoudBird authenticates the user with Twitter and gets an authorization token allowing it to Read, Write, and Delegate.
3. Since LoudBird uses TwitAwesomePhoto to upload photos, it asks Twitter for a sub-authorization token that delegates its Read and Write (but, in this case, not its Delegate) authorization to TwitAwesomePhoto
4. LoudBird provides this sub-authorization token to TwitAwesomePhoto when making requests and TwitAwesomePhoto uses it to update the user's account.

The advantages of this approach are several:

• The user can, at any time, revoke LoudBird's authorization (for example, because her laptop got stolen).
• The user can, at any time, revoke TwitAwesomePhoto's authorization (for example, if TwitAwesomePhoto is revealed to be a horrible spam machine from the depths of Atlantis).
• At no point does LoudBird share the user's credentials.
• At no point is the user's flow interrupted – the UX is seamless.

I'm going to go over the existing Internet Draft more carefully when I get a moment and – if it's necessary and won't be redundant – I'll flesh out the above flow in more detail.

Pragmatism and UX FTW

There is always a tradeoff between security and user experience. However, where security solutions ignore the practical requirements and needs of users and developers, they will either be ignored or, even worse, circumvented in the worst possible ways as demonstrated by the Exposure, Echofon, and TweetPhoto examples presented here.

Twitter's xAuth implementation is a timely and pragmatic solution that adapts oAuth to the needs of mobile and desktop applications. I applaud Twitter for taking the lead with this. I also encourage anyone with an interest in building good user experiences to do the same and I look forward to seeing xAuth become part of the oAuth standard.

I am giving a talk today at the Twitter Dev Nest in London on Twitterformats and I just got word that we have time for me to a second presentation on the latest oAuth developments at Twitter, including the hugely-exciting xAuth. Come down and say hello. The meeting kicks off at 6PM.

Here are some notes to help you if you're trying to sign in to your Thomson router (BeBox).

Control panel

You access the control panel from 192.168.1.254.

This will prompt you for your sign-in (log-in) details:

Username and password

If you haven't changed it, the username is Administrator and the password is the serial number of your modem.

O2 remotely changed the password of your router to your router's serial number in September of last year in response to a security vulnerability. You can find the serial number under your modem, across from the Thomson name. Enter it in ALL CAPS and do not include the bit at the end in parentheses.

Change the channel to an unused one in your area

If too many WiFi routers are competing on the same channel in your area, you might get reduced performance (or none at all). Finding out the channel of WiFi networks around you, however, is harder than it should be. I found numerous references to two apps, iStumbler and KisMac for doing this and both had UIs created by henchmen of the hounds of hell and I wasn't able to get either to work.

Instead, the easiest option I found that works was to use the command line, as per the instructions in this article. In summary, open up a Terminal window and type the following:

• sudo ln -s /System/Library/PrivateFrameworks/Apple80211.framework/ Versions/Current/Resources/airport /usr/sbin/airport
• airport -s

The first line creates a symbolic link that allows you to simply type “airport” in the terminal window to execute the command. The second line should scan for active WiFi networks around you and display their channel numbers.

Now sign in to your router's control panel and then navigate to Home > Home Network > Interfaces > WLAN: BeBox and click the Configure link at the top-right-hand corner (the Thomson router control panel was designed by the cousins of the henchmen of the hounds of hell) and change the channel there to an unused one.

DNS errors

I would randomly have it so I couldn't connect to some sites even though other people could. Apparently it was because the router was set up with a less-than-stellar DNS server. If you're having the same issues, try this:

First go to http://192.168.1.254/cgi/b/is/?be=0&l0=2&l1=2 in the browser and note whether the heading on that page reads Internet, Static_IP, or Dynamic_IP. Note this down for later.

Next, open up terminal and Telnet to 192.168.1.254:

telnet 192.168.1.254

For the sign in details, use the same ones you used above to sign in to your router's Admin interface.

Once signed in, you should see some snazzy ASCII art.

Finally, enter the following lines, substituting either Internet, Static_UP, or Dynamic_IP for XXX:

:dns server route flush
:dns server route add dns=87.194.255.154 metric=0 intf=XXX
:dns server route add dns=87.194.255.155 metric=1 intf=XXX
:saveall

So, if your connection type is Static_IP, like mine, for instance, you would type:

:dns server route flush
:dns server route add dns=87.194.255.154 metric=0 intf=Static_IP
:dns server route add dns=87.194.255.155 metric=1 intf=Static_IP
:saveall

Many thanks go to drsox and fooby on irc.bethere.co.uk for helping me through this. You guys rock!

Learn to love IRC

The Be folks are very active on IRC (Internet Relay Chat), so grab yourself a copy of Colloquy or some other IRC client and get yourself to irc.bethere.co.uk if you need any help. You can follow the Be Broadband folks on Twitter @bebroadband.

Hope this helps and if you have any other hints or tips, please feel free to add them to the comments.

Unfortunately, I can't say the same thing for the staff at the Waterstone's itself.

This afternoon, I was sipping my cappuccino and working away on my latest iPhone app when one of the Waterstone's staff approached my table and proceeded to tell me off for having my notebook plugged in. Yes, you read that right: a Waterstone's staff entered the Costa and proceeded to publicly reprimand a Costa customer (I can only assume that someone at Costa will be talking to someone at Waterstone's about that little breach of protocol, if nothing else).

She proceeded to tell me that I was using "their electricity" and had I "asked permission" and did I see anything wrong with what I was doing? I politely informed her that, yes, I was aware that I was plugged in and that, in this day and age, I would assume that I could plug my notebook in at a cafe. I've done so many times at other Costas and Starbucks and never had any issues. Nor would I expect to have any.

She left to ask her supervisor and, a few moments later, I was approached by another young lady from Waterstone's who confirmed that yes, indeed, I was not allowed to use their electricity. She proceeded to tell me about their electricity usage targets and how they were having trouble meeting them (no doubt due to my daily patronage of the Costa – a transgression which I will work doubly hard to avoid in the future).

So, today, Costa got my custom for the last time and tomorrow I'm probably going to pop into my local Starbucks because – evil or not – I've never had anyone hassle me there.

I do hope that someone from Costa reads this and has a stern talk with the Waterstone's folks. Of course, I have no idea what their arrangement is but I would be very suprised indeed if it allowed Waterstone's staff to harass Costa's customers, whatever the reason. At the very least it reflects poorly on Costa's brand and, in this case, lost them a regular customer. The correct thing to do would have been for the Waterstone's staff to take the subject up with the Costa staff who could then have relayed the information to me.

Also, since the policy at the Waterstone's Costa in Brighton is that the plugs are off-limits, I expect to see a sign informing customers of this. It might also be an idea to actually cover the plugs up to make this archaic policy even more evident so that future patrons are not hassled for behaving like they actually live in the 21st century.

Finally, since the Waterstone's Costa also doesn't have any WiFi, this probably makes it the most geek-unfriendly place in Brighton. If you have a notebook and want a coffee, look elsewhere.

The following code...

NSUInteger i;
switch (i) { case 0: // Do something break; default: NSString *s = @"something"; s; break;
}

... doesn't compile. Instead, you get the following two errors:

• Expected expression before 'NSString'
• 's' undeclared (first use in this function)

The culprit is the auto-generated code. The following code does compile. Note the curly braces.

NSUInteger i;
switch (i) { case 0: { // Do something break; }
  default: { NSString *s = @"something"; s; break; }
}

The curly brackets are not required for switch statements but when they are absent, a statement must follow the case or default labels. Declarations are not statements in C and thus result in this error.

The following code, which doesn't use curly braces, also compiles.

NSUInteger i;
switch (i) { case 0: // Do something break; default: NSLog(@"Magic? Not really, just a statement."); NSString *s = @"something"; s; break;
}

Hope this helps you in case you encounter this sneaky little gotcha!

Interested in learning iPhone development? Check out my Introduction to iPhone App Development Course.

The symptoms were that the touch-and-hold insertion point magnifying glass would appear and work properly only the first time it was used. It would then add some visual corruption to the text view and refuse to appear on subsequent touch-and-holds. The selection magnifying glass would work and, after using it, the insertion point magnifying glass would also work (but again, just once).

Even with the selection magnifying glass, however, you would get a visual glitch (a small ghost image would remain on the text view.)

At first, I thought I was seeing an identical issue to the issue that affects UITextFields in UITableViews (see the solution to that issue on StackOverflow).

That, however, was a red herring.

Here's the real reason: the UITextView didn't like that I was turning off animations on UIWindow to display the keyboard:

[UIWindow setAnimationsEnabled: NO];
[self.myTextView becomeFirstResponder];

The fix is either to not disable animations, or, if you want to disable them, to renable them afterwards.

Adding a small delay of 0.1 seconds and re-enabling animations did the trick:

- (void)showKeyboardWithoutAnimation
{ [UIWindow setAnimationsEnabled: NO]; [self.myTextView becomeFirstResponder];
  [self performSelector:@selector(keyboardAnimationDidEnd) withObject:nil afterDelay:0.1f ];
}
 
- (void)keyboardAnimationDidEnd
{ // So that we don't screw up the // UITextView's magnifying glasses. [UIWindow setAnimationsEnabled: YES];
}

Smoking pot, for example, nets you a $10 fine whereas having sex in church sets you back $25. You add up the various fines for all the offenses you committed to reach the value of your final fine and publish it publicly (e.g., on Facebook or your blog).

The idea is that the higher your final fine, the naughtier you've been and yet no one knows exactly what you've done so your secrets are safe.

A little harmless fun, surely.

But if the originator of the meme had been less scrupulous or better versed in mathematics (and, more than likely, both), it could have led to a lot of potentially embarrassing admissions. How?

1. Use only prime numbers for the fine amounts (e.g., $3, $5, $7, $19, $43, etc.)
2. Instead of asking people to sum the total, ask them to find the product of their answers (i.e., multiply them).

So, say that smoking pot had a $3 fine and having sex in church set you back $5. If you had engaged in both these offenses, your fine would be $15.

If you posted this publicly, thinking that the aggregate amount hid your true dealings, you would be in for a rude awakening at some point since multiplying two prime numbers results in a composite number that is divisible by those two numbers alone (as well as 1 and itself). So there's only one way that $15 could be read as: you smoked pot and had sex in church.

(It would still be up to people's imaginations, however, if you did both at the same time.)

Similarly, if you had partaken in the $3, $5, and $7 offenses, your total fine would be $105. A seemingly innocent number but one that can only be divided by those three numbers, their various composites, 1, and itself. So publishing that single number would have been essentially the same as owning up to each of the separate offenses publicly in a list.

All this to say that someone could have used this meme, in a slightly altered format, as a widespread social engineering hack to get people to reveal their most personal details while lulled into thinking that they were publishing an aggregate and rather less revealing number.

Thank you for putting people before profits.

It's time for Yahoo! to grow a pair too and for other Western companies to abandon their hypocritical double standards when it comes to respect for human rights and freedom of speech.

(And that means you, Mr. Shareholder, caring about more than just your dividends and making a quick buck.)

I go to bed with a little more hope for the future.

Thank you, Google.

If you don't care for reading my rant at how I arrived at the solution, feel free to simply download the PSD of my UIPickerView skin with transparent selection bar (Photoshop CS3 format, .zip, 94KB) and customize it to your heart's delight and use it in your iPhone apps. Oh, and if I saved you some time, one way of thanking me is to feed my App Store habit with a tip.

(And before you leave, don't forget to check out the Introduction to iPhone App Development course I'm teaching in February in the UK.)

A UIPickerView by any other tint…

So when Apple created the UIPickerView, They decided in Their Infinite Wisdom that no developer would ever want to change its color… apart from the ones who built Apple's own Clock app, of course! (Check out the Timer tab for a gloriously greyscale picker.)

So how does a mere mortal alter the tint of a UIPickerView? Let me tell you… but first, do you have an hour or two to spare?

Hack it, baby!

The hack seems simple enough: Just grab the graphics from a screenshot of the simulator, tint them in Photoshop, then fake it by loading the new graphic into an UIImageView that you place on top of the component. That works for the border, but what about the selection bar?

The problem is that the selection bar graphic you grab is opaque and the selection bar needs to transparent.

Of course, you can just recreate the selection bar. But it would be damn hard to get it perfect.

What if there was a way to copy the opaque bar and recreate it exactly but with transparency?

So, what if there was a way to go from this screen grab, which is 100% opaque:

To this:

While recreating the selection bar exactly.

Well, you can, but it involves a bit of math and quite a bit of patience.

On Alpha blending and pushing pixels

So, when I tweeted asking if someone had an easy tool for doing what I wanted to do, Seb and Mario both responded with helpful suggestions. Mario's link to the Alpha compositing page on Wikipedia was especially useful as that's where I found the following formula for alpha blending:

The value of the resulting color when color Value₁ with an alpha value of α is drawn over an opaque background of color Value₀ is given by:

Value = (1-α)Value₀ + αValue₁

Of course, what I wanted was the opposite of this: I had the pre-blended color values of the selection bar (on a white background/matte) and I needed to know how I could match those colors if the pixels had an amount of transparency. In other words, I know Value (the pre-blended color value; the "resulting color"), I know the background color that it was blended with (Value₀) and I want to know Value₁ (the color) for any given α.

So, turning the equation around, we get:

Value₁ = ( Value - (1-α)Value₀ ) / α

Furthermore, in this case since the background color is white (i.e., 1.0 for all channels), it simplifies down to:

Value₁ = ( Value - 1 + α ) / α

So all that's left (!) is to go through all the pixel values in the opaque image and calculate the color values they'd have at opacity α.

To simplify things, I was trying to create a greyscale version of the bar, so the R, G, and B values were identical.

So, for example, given a grey reading with R=B=G=140 in Photoshop, I would translate that to a 0-1 color value by dividing by 255 and then use the resulting value in the equation. e.g., if I was trying to match the pixel at 50% opacity, I would get:

colorValue = 140/255 = 0.55
Value₁ = ( 0.55 - 1 + 0.5 ) / 0.5
Value₁ = 0.1

0.1 roughly translates to R=G=B=26 in Photoshop.

Here's what this looks like:

So we've managed to take an opaque grey and find the exact same color at 50% opacity when blended with a white background.

Applying it to the selection bar

I initially thought of writing a Photoshop script to iterate over the contents of a selection and create the version of it with transparency automatically. However, one look at the sample scripts that come with Photoshop made me run screaming.

Since the selection bar is a horizontal bar with simple straight gradients, it can be losslessly reduced to a one-pixel wide image. This means that I had about 61 pixels to sample manually, calculate the transparent color values for, and then recreate. I figured it would be simpler to do it manually then to learn the brain-frak that Photoshop scripting appears to be (even though it uses JavaScript – how could they complicate that so much? I blame a lack of good introductory instructional materials.)

So, I created a speadsheet in Numbers with the formula. Next, I proceeded to create a one-pixel grid over the selection bar using guides (since the grid in Photoshop is messed up), and then sampled the 61 pixels, one-by-one, copying the values to the spreadsheet.

I then ran the formula on the pixel values both at 50% and 60% alpha.

The problem with this equation is that not every opaque value can be represented by a color value at any opacity. So you have to make sure that all your pixel values fall between 0 and 1. At 50%, a couple of the pixel values fell below zero so I decided to go with 60% opacity.

I then manually recreated the one-pixel selection bar, pixel-by-pixel using the pencil tool and the calculated pixel color values for the channels and finally set the opacity of the layer to 60%. Eh, voilà, I had my transparent selection bar.

A suggestion for graphics apps

If anyone from the Photoshop team is reading this, I'd love to see this as a feature in Photoshop. How cool would it be if I could select an opaque area of the image, specify an opacity and a matte color (e.g., default to the background color swatch) and get a transparent version that matches the source exactly?

Mario already started playing with something like this for Peacock, and posted a manual color matching filter.

So you don't have to…

So you don't have to go through all this yourself, why not download the PSD of the UIPickerView skin I made (Photoshop CS3 format, .zip, 94KB).

Enjoy, and I hope it saves you some time! (And if it does, feel free to say thank-you by contributing to Aral's App Store Addiction Fund.)

Finally, if you'd like to learn how to develop iPhone apps yourself, you could do far worse than to attend my Introduction to iPhone App Development course in February. It takes place in Brighton in the UK.