Well, it turns out that the built-in Xcode PNG compression tool kinda lacks in the compression department. There’s a great case study about the Tweetbot app over on the ImageOptimum site:

Disabling Xcode conversion and simply using ImageOptim instead was enough to reduce the application size by almost 30% (33.4MB down to 23.8MB) and halve initial display time.

Manually optimizing images with ImageAlpha reduced entire application size by more than a half (33.4MB down to 16.3MB). Images alone were 65% smaller and were displayed 2.5 times quicker than Xcode-optimized ones.

Now that’s awesome. If a few clicks can save you megabytes why not?

It turns out that Xcode creates a CgBI PNG varient optimized for loading speed using 32-bit BGRA. Jeff LaMarche has a great technical explanation of what’s going on, explaining that Xcode basically optimizes for loading speed by swapping bytes in the image and “corrupting” the PNG format.

During the build, Xcode basically screws up your PNG image, turning it into something that’s technically no longer a PNG image. Xcode doesn’t change your original file, but when it copies it to the Resources folder of your application bundle, what it does is it byte-swaps the red and blue octets and also “premultiplies the alpha” … The PNG specification does not support either of these changes

The other downside is that sometimes this manipulation results in a larger file size than you would have with a normally optimized PNG.

To disable Xcode’s built in image compression, go to your target’s build settings, filter for “Compress PNG Files” and select NO.

However, be cautious if you choose to disable Xcode’s built-in PNG optimization and do the optimization yourself with a tool like ImageOptimum. Disabling Xcode’s optimization will mean your iDevice will do the equivalent optimization on-the-fly at run-time, adding additional processing and memory overhead. You should to take this into consideration and optimize your code to share and reuse image resources where possible.

modernizer.js

If you’re working with HTML5 and CSS3–and you should be–you’re probably wasting a lot of time if you’re not using Modernizer. Modernizer gives you a quick and easy way to check exactly what browser or device features your visitors use using. I’d suggest reading Taking Advantage of HTML5 and CSS3 with Modernizr or How to use Modernizr and the check out the documentation.

respond.js

Respond provides faster css3 media queries for internet explorer 6+. This will help you out when you’re following your mobile first responsive design techniques (you’re doing that too right? right?). Get the source here on GitHub and then check out the documentation.

yepnope.js

yepnope is a nice little script loader but I’d only recommend using it if you have a lot of scripts and each one is rarely used. A much better idea is to combine all your JavaScript’s into one compressed file so that you only need one http request to download everything (especially on mobile devices).

impress.js

While impress may not help improve your site, this CSS3 powered interactive presentation tool will definitely help make client pitches rock. But, what about (Prezi)[prezi.com] you say? Go try the impress demo. You’ll understand why it’s called “impress” (though I have a soft spot for kinetic typography). For another example and some excellent reading check out What The Heck Is Responsive Web Design.

spin.js

Now here’s a great idea. How often do you need a nice little “spinner” loading animation? Gifs are so last decade so try this configurable, cross-browser JavaScript spinner with no images! Set a few properties and you’ll be loading in no time.

video.js

Again with the HTML5 scripts but now focused on video. You may or may not agree with thoughts on flash but you’ll probably like this impressive HTML5 video player. Drop it into your simple html5 video markup and you’ll get a nice cross-browser ui–with a fallback to Flash just in case.

zip.js

A JavaScript library to zip and unzip files. Now you can confuse non-savvy computer users right in teh browser!

psd.js

Parse the Adobe Photoshop PSD files right in your browser. NOt sure what I’d do with it but it’s pretty neat. Drop a psd on the demo page and you’ll get a lit of all the layers in the file.

zoom.js

zoom.js is a just an early experiment that allow you to quickly zoom in on DOM elements or points on a page. For example, click on any element on the demo page to zoom in.

jQuery Plugins

Here’s a few more that are great but also require jQuery.

scrollorama.js

Scrollorama is a fun plugin that helps you with “scrolly stuff” as the web site says. Scroll down the demo page to see various example of transitions, pinning, parallax and more. But, remember, use this responsibly. Don’t make scrolling the <blink> tag of 2012.

lettering.js

I’m a bit of a typophile (yes, I know the current iteration of this blog design needs work) and I love tools that make web typography easier. Lettering provides fine grained control for properties like kerning, layout and more. The gallery on the site is better seen than described so after you’re impressed check out the documentation here.

After several attempts of trial and error I believe the following is a foolproof solution for setting the correct orientation of the startup view for an iPad app (assuming the default view was design in portrait orientation). I thought I’d share it here for anyone else who is having a similar problem.

First, in application:didFinishLaunchingWithOptions: add the following:

- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {    

    [[UIDevice currentDevice] beginGeneratingDeviceOrientationNotifications];

   // The rest of your code...

}

then, on the view you want to rotate, check both interface and device orientation to properly position the view in all four orientations (plus laying flat on a table).

-(void)updateOrientation {

    UIInterfaceOrientation iOrientation = [UIApplication sharedApplication].statusBarOrientation;
    UIDeviceOrientation dOrientation = [UIDevice currentDevice].orientation;

    bool landscape;

    if (dOrientation == UIDeviceOrientationUnknown || dOrientation == UIDeviceOrientationFaceUp || dOrientation == UIDeviceOrientationFaceDown) {
        // If the device is laying down, use the UIInterfaceOrientation based on the status bar.
        landscape = UIInterfaceOrientationIsLandscape(iOrientation);
    } else {
        // If the device is not laying down, use UIDeviceOrientation.
        landscape = UIDeviceOrientationIsLandscape(dOrientation);

        // There's a bug in iOS!!!! http://openradar.appspot.com/7216046
        // So values needs to be reversed for landscape!
        if (dOrientation == UIDeviceOrientationLandscapeLeft) iOrientation = UIInterfaceOrientationLandscapeRight;
        else if (dOrientation == UIDeviceOrientationLandscapeRight) iOrientation = UIInterfaceOrientationLandscapeLeft;

        else if (dOrientation == UIDeviceOrientationPortrait) iOrientation = UIInterfaceOrientationPortrait;
        else if (dOrientation == UIDeviceOrientationPortraitUpsideDown) iOrientation = UIInterfaceOrientationPortraitUpsideDown;
    }

    if (landscape) {
        // Do stuff for landscape mode.
    } else {
        // Do stuff for portrait mode.
    }

    // Now manually rotate the view if needed.
    switch (iOrientation) 
    {
        case UIInterfaceOrientationPortraitUpsideDown:
            [self rotate:180.0f];
            break;
        case UIInterfaceOrientationLandscapeRight:
            [self rotate:90.0f];
            break;
        case UIInterfaceOrientationLandscapeLeft:
            [self rotate:-90.0f];
            break;
        case UIInterfaceOrientationPortrait:
            break; //do nothing because it's fine
        default:
            break;
    }

    // Set the status bar to the right spot just in case
    [[UIApplication sharedApplication] setStatusBarOrientation:iOrientation];

}

Enjoy. If you found it useful or have an improvement, let me know.

Like the iPhone, the iPad has only one primary button on the front of the device and a few buttons on the sides (for volume and on/off). The logistics of a kiosk mean people shouldn’t be allowed to randomly quit the app so you have to disable the iPad buttons by jailbreaking—and installing the appropriate software—or by disabling them physically (by covering them up). For physical barriers, there are a number of existing products such as the nice looking Beyond Kiosks, the more portable iBracket or simple DIY projects like this wooden kiosk stand. I’m not sure how the wooden kiosk stand would hold up to abuse but, hardware aside, it comes down to the software problems.

To run successfully as a kiosk, the kiosk app needs to be the only app running on the device without the ability to exit the app in any way (at least without removing the iPad from its enclosure). The iPad doesn’t offer an easy way to force an app to stay open but you can be sneaky and do things like launching the app again whenever it happens to close:

-(void)applicationWillTerminate:(UIApplication *)application {
    [application openURL:[NSURL URLWithString:@"mykioskapp://"]];
}

Note: Doing this would probably get an app rejected from the App Store.

Care must also be taken not to include any way for a user to accidentally jump into another application, such as the web browser or the email app. If someone gets out of the kiosk application they’ll probably be confused but, more importantly, they’ll be stuck with no way to get back because the only buttons that would return them to the kiosk application have been disabled or covered up.

The other software problem is dealing with the Apple App Store submission process. Running in a kiosk could initially be great since a kiosk app probably isn’t going to be distributed through the app store. Instead, it will be easily loaded on each kiosk directly. Both a development distribution or an over-the-air Ad-Hoc distribution would work but each come with their own problems. Anyone who has dealt with Ad-Hoc or development distributions knows that the certificate process isn’t fun and just when you think you have it sorted out, the provisioning profiles on the devices expire and you have to repeat the process. It would be great to bypass the burden of the Apple App Store rules and regulations but to do so someone will need to be on-site to update the app on a regular (monthly) basis as the development or Ad-Hoc distributions expire or the app itself needs updates.

The idea of an iPad kiosk is obviously possible and there are a few existing companies already using it for things such as ticket sales or product information. If I get any further into the project I’ll post some updates and let you know how it goes.

One of the biggest hurdles with UiTextInput is that you don’t get the benefit of the great UI work that Apple has put in their core iPhone text inputs. There’s no text selection, magnification loops, copy/paste or any of those other things we take for granted when we use the default inputs. If you want advanced editing features you have to implement them all yourself—and it’s a lot harder than it looks.

Text selection, for example, is something that you’re probably familiar with if you’ve used an iPhone or iPad but have you ever stopped to actually look what’s going on? The subtleties of the touch interaction are very intuitive but may not be what you expect when you think about it. For example, here are few things you may not have noticed when editing text in something like the default notepad.

• When you quickly single tap, the carat is placed in the text where you tapped but it’s position is based on word boundaries. A mouse click in a word processor places the carat at the point where you clicked but a tap in iPhone OS places it in front of or after the word, depending on which end of the word was nearest the tap.

• Holding on a word will reveal a magnifying loop that gives you fine grained control over the selection. This is the only way you can place the carat within a word.

• The select/select all/paste menu will appear if you long-tap. As a result it will always appear after the loop is shown but could also appear if you touch and release just before the loop shows (of course you’ll be selecting and pasting on a word boundary in the latter case).

• The “select” option in the menu always starts by selecting a full word. Which word depends on where the carat is placed. If the carat is in a word then that word will be selected. If the carat is at the beginning of a word, between the space and the first letter, then the word following the carat is selected. If the carat is at the end of a word, before the following space, then the word preceding the carat is selected.

• Double tapping a word will immediately select it. If you hold and drag on the second tap you can select a larger range based on where you drag. Interestingly, the range selection also has a magnifying loop—but with a different shape—so you can have fine grained control at the end of the selection.

These are just a few of the subtle interactions that most iPhone users just do without thinking about. If you’re going to implement your own UITextInput be sure to closely look at the existing text inputs and how you typically interact with them as you’ll need to implement yours the way users will expect it to work.

Now all I have to do is call setFitTextToBox(true) on the TextFitTextView after allocation. Enjoy!

public class TextFitTextView extends TextView {

    static final String TAG = "TextFitTextView";
    boolean fit = false;

    public TextFitTextView(Context context) {
        super(context);
    }

    public TextFitTextView(Context context, AttributeSet attrs) {
        super(context, attrs);
    }

    public TextFitTextView(Context context, AttributeSet attrs, int defStyle) {
        super(context, attrs, defStyle);
    }

    public void setFitTextToBox( Boolean fit ) {
        this.fit = fit;
    }

    protected void onDraw (Canvas canvas) {
        super.onDraw(canvas);
        if (fit) _shrinkToFit();
    }

    protected void _shrinkToFit() {

        int height = this.getHeight();
        int lines = this.getLineCount();
        Rect r = new Rect();
        int y1 = this.getLineBounds(0, r);
        int y2 = this.getLineBounds(lines-1, r);

        float size = this.getTextSize();
        if (y2 > height && size >= 8.0f) {
            this.setTextSize(size - 2.0f);
            _shrinkToFit();
        }

    }
}

Sounds interesting but based on the video below I’m not really impressed. First, the comparison to typing on the iPhone isn’t that great. Following along on my iPhone I could easily punch out the message just as fast as the Swyping user. Secondly, there seems to be a lot of pausing in the output on the Swyping display. I can see this leading to situations where you stop to think and end up forgetting where you were in a word or loosing your train of thought. I could also see a lot of situations where you’re back “swyping” to edit what was entered a few words ago since it guessed wrong (though the iPhone isn’t much better in that regard).

I haven’t tried it myself so maybe it’ll surprise me but at the moment it just looks awkward. See for yourself: