Since iOS devices all run WebKit, they’re all quite advanced when it comes to the CSS they’re able to parse. This includes, as we’ve previously seen, the media declaration in a <link> tag for a CSS file, but also includes CSS3’s @media declaration inside a CSS file. The primary purpose for this would be to adjust for the vastly different widths we have (we can even adjust for varying widths on desktop browsers, too), but we can also use it to do other fun stuff.

Take a peek at one example of changing the display of a site based on width on Simon Collison’s website, Colly. If your viewport is set to ~950px or greater, we have the full-width, four-column layout. However, as you shrink your viewport down, the layout changes to a two-column display, then finally to a one-column display where the single item is slightly larger in width than the single items are in the two- or four-column views. All-in-all, a rather lovely design. And the whole “Celebrated Miscellany” idea produces a fascinating aesthetic. It reminds this writer of an old science journal, like something Darwin or Audubon might have drawn.

So how do we do it? Well, Colly uses a series of @media rules at the very end of his stylesheet. Here’s one of the bits we’re talking about (edited for brevity):
@media (min-device-width:1024px) and (max-width:989px), screen and (max-device-width:480px), (max-device-width:480px) and (orientation:landscape), (min-device-width:481px) and (max-device-width:1024px) and (orientation:portrait) { div#page { width:468px; } .home ul#navigation_pri, .home ul#subnav-b { padding-bottom:30px; } … div#siteinfo p { font-size:14px; } }
So what’s happening there? well, all of the CSS rules for this particular @media query are encapsulated in the query itself. The query is asking a number of different questions to cover quite a few bases, but this particular set of CSS covers the “less than 950px viewport” eventuality. As for mobile devices, this view comes into play if an iPhone is in landscape mode, or if an iPad is in portrait mode.

The second @media query looks like this:
@media (min-device-width:1024px) and (max-width:509px), (max-device-width:480px) and (orientation:portrait) { div#page { padding:30px 0px 10px 0px; width:306px; } … }
It’s considerably simpler, as it doesn’t have to ask as many questions about your viewport or device width. The first part of the query takes care of iPads and desktops alike, while the second handles the smaller display devices.

So there you have it folks, the ability to craft resolution dependent layouts and styles. Now go forth and amaze your clients!

But what about an app that’s primarily useful locally on your device and has no real need to maintain any sort of connection to the internet? A clock, or a to-do application, or a calendar, for example. Using Push Notifications is costly for the developer, as they must maintain a server that allows for always-on connectivity from their users, and if they experience a surge in popularity, those costs could skyrocket. Thankfully, Local Notifications are here to save the day.

The basic principle is to write some code to display these notifications, some code that hooks into the Local Notifications service to release these notifications based on the device’s internal time, and then some code to decide what to do about the notification after it fires. That last piece will likely be dependent on whether or not the app is running.

So that takes you through the whole thought process, but what about examples? Head on over to the Local Notifications article at iCodeBlog for a walkthrough, but make sure you’ve already nailed down some basics.

When it comes to navigation, having that bottom “dock” of icons for your most important bits seems to be the most successful way to offer access to features. Another thing used sometimes, but not seen in this series is a “home page,” showing full screen all the navigation bits. The Facebook app exemplifies this best. When navigating from one section to another, however, the top back and forwards arrow buttons provide the most usefulness. The iPod app offers the best example of this with its multi-colored “Now Playing” button constantly leading back to what you’re doing right now, which is listening to music, and a separate back button appearing when you drill down from the artists or albums view to the songs view.

The Mint.com app shows what’s possible with some creative icon editing, and letting iOS do some of the work for you, as well as showcasing design evolution. For the time being, you can still see the old app design at the iTunes Preview link above and can compare it to the screenshot provided earlier in this series.

The Groceries app shows us that doing a seemingly simple thing, which an iOS device is almost overkill for, and doing it well is a recipe for serious success. Beautiful icons, subtle touches to tie the app into its real-world model, but offering greater organization and ease of use than even pen and paper.

Square demonstrates that while simple, clear app design is crucial, having a physical accessory can sometimes be the killer app, especially when its something as eminently useful as a credit card reader that anyone can apply for and obtain. Their underwriting difficulties notwithstanding, all of their users have raved about Square and bright things are on the horizon for this and other portable payment gateways.

Finally, Tapbot’s Weightbot, Pastebot, Calcbot and Convertbot apps show that having a guiding theme throughout all your apps, and really creating a global brand for your products can inject some true personality into them, giving them almost a life of their own.

As you can see, the main interface has three buttons, and while they are similar to the typical outline-style Apple espouses, they are actually modified versions of the icons you see within the WordPress admin interface, accompanying the top-level navigation elements there. This is quite an excellent tie-in to the main, web-based software. But let’s back up a bit. The setup screen for a WP-powered site attempts to be as simple as possible, only offering a single screen’s worth of options and only really requiring that you answer three questions: your blog URL, username and password. From there, the app can almost always connect; only in rare instances does it have difficulty and ask you for a direct link to the xmlrpc.php file that allows for this sort of remote access.

While you’re in the setup, however, you can make some changes to how many “recent items” are displayed when viewing this site’s items, whether or not geotagging is enabled and whether or not photos are resized to make posting times faster. HTTP authentication is an advanced feature, allowing you to hide your site behind basic authentication, and the WordPress app wants to ensure you can edit these sites as well.

Now that we’ve added our site, we can see our comments, posts and pages, and make a new post or page if we so desire. The comments list shows avatars and can be filtered for pending comments if you have WP’s review features for comments enabled. You can even delete whole swathes of comments if you like by tapping the edit button in the top right. Tapping a comment itself allows you to unapprove it or edit it.

The posts and pages lists are identical in all but what sort of item you’re editing, and as they’re identical in many ways as far as WordPress is concerned, this makes sense. You have access to all the usual fields (title, tags, categories, publish status), and can write plain text or HTML in the content area. There’s currently no way to do any rich text editing without HTML knowledge, but this remains one of the few limitations to content entry. They did make one particularly interesting design choice. When viewing the entry initially, the metadata remains as a header and the content scrolls in the lower half of the screen. Tapping the content, however, enlarges it to full screen, allowing for much easier editing of content.

Along the bottom, the navigation has shifted to offer control of the entry in questions, comments, photos and other settings (such as publish date, for scheduling or pre-dating items), and even the ability to preview the post as it would appear on your blog. The preview features depends on your theme’s compatibility, and occasionally does not work as expected, but it falls back to a basic preview to give you at least some idea of what you’ve created.

All in all, an excellent mobile blogging / editing app for the WordPress software. Best of all, like WordPress itself, it’s free. Enjoy!

This is a great idea, and it really drives home the idea that web apps can augment, or even supercede, native applications in some ways. If you load it up in desktop Safari with the user agent manually set to MobileSafari (via the Developer menu), you can actually see that they’re using jQTouch, which was mentioned in a previous post.

It is worth noting that, true to the “β” (“beta”) character after the name, the site is still very much a work in progress. This is best exemplified by the jerky scrolling, and somewhat jerky animations. This could be due to jQTouch’s work-in-progress nature, or OpenAppMkt’s modifications to the jQTouch code (if any).

Moving on to what the app can do, though: they’ve utilized a very interesting mechanism to enable you to “install” the web apps directly from their interface. When you click install, a new window loads, still at OpenAppMkt, then instructs you to “add to home screen.” When you do that, OpenAppMkt grabs the home screen icon and name of the app you’re trying to “install,” and sets that. Now, when you go to load that app, it briefly heads to OpenAppMkt, then proceeds onward to the actual web app itself. While this does add a layer of abstraction, it increases the visibility of “installing” web apps, if you will, by adding them to the home screen, which is definitely a good thing.

Not only that, but their greater goal seems to be to build a clearinghouse for web apps, similar to Apple’s own Web Apps directory, but with reviews and ratings. Creating this sort of community for these apps only improves their visibility and usefulness. Hopefully OpenAppMkt is here to stay!

While that simulator that came with the device’s SDK can be useful, remember that it’s not a true substitute; it’s meant to test things when they’re in-progress. Once you have a working build, you need to install it on your device and live with your (maybe not so) shiny new app. Use it with two hands, one hand, one hand while walking, in bright light, dim light, in both orientations (if your app will support that), and in any other situation you can think of.

Especially taking into account the one-handed thing, deciding button placement becomes a huge issue. Just a few pixels too close together can change a button from being just right to always being mistakenly triggered.

In addition, with a touch interface, we’ve lost a particular paradigm of mouse and cursor interfaces: hovering. There are no longer any hover states, as there is no pointer to hover. While this has a greater effect on websites and web apps, it can still create trouble if you’re trying to demonstrate to your users which elements are actually UI elements, and which elements are just content.

This sort of thing, of course, is where having a small army of beta testers is most useful. So crack that whip and see what they have to report!

The primary interface for the iPod app, however, is the list. As always with sorted lists on iOS, full-width banners separate the letters of the alphabet and a vertical bar of the alphabet allows you to quickly zoom down to a specific letter by sliding up and down along the far-right side. We have lists of artists, albums, songs, videos, genres, each with their own slight twist. When viewing songs for example, a “Shuffle” list item appears at the top to let you quickly jump into listening to all of your music. Not only that, but each song has, beneath its title in black, bold text, a smaller subtitle informing you of the album the song belongs to. In almost every list, in fact, you can pull down to reveal a search form, letting you quickly filter for what you want. In the artist view, an “All Albums” list item allows you to drill down into the album view, and from there you can continue on by tapping “All Songs” to find yourself in the songs view.

If you select a particular album, you get a small preview of the album art, some metadata about the album (release date, number of songs, length), a big shuffle button and then a zebra-striped list of the songs with their track number and length in a neat table. You can see that a black “Now Playing” button, shaped like a pointer, is present. This remains throughout the app if you are playing a song, even if its been paused, as a way to quickly return to the current track and resume.

The “Now Playing” screen, in fact, has some great features of its own. It has the usual play, previous and next buttons and a volume slider, and in the main area displays album art primarily, but tapping said album art reveals a secondary set of controls. A progress slider appears, allowing you to scrub through the song, but most interestingly of all, once you tap and hold on that slider, an instruction appears stating “Slide your finger down to adjust the scrubbing rate.” You can get some fine-grained control of where you want to go in the song this way—a brilliant addition! These secondary controls also offer you the ability to turn on repetition (of all items in your playlist or just the current item), begin a Genius playlist from this particular item or enable shuffling. Tapping the top right “list” button flips things over to a list of songs on the album in question and allows you to change the star rating of the current song.

All in all, iPod has lots of clever features tucked away behind taps and buttons, but not so far away that you’d never find them, even if by accident. It’s the usual simple elegance and usefulness we’ve come to expect from Apple, but it pays to study it now and again and learn from their example.

Still, the familiarity most developers have with jQuery, combined with the polish of this framework/plugin, makes it a very attractive option for any web developer. Let’s take a peek at what it can do. It uses native WebKit animations, it can preload images, has a variety of themes built in to it (and you can easily make more using SASS), and has not just the usual JS CallbackEvents, but can also respond to a variety of touch events! Now that is very cool.

As an example, here’s how easy it is to replace a standard click with jQTouch’s custom tap event:
$(function(){ $('#tapme').tap( function(e){ console.log('Tapped!'); }); });
Now that is just brilliant. A “swipe” CallbackEvent is also under development. As of now, it appears to be hit-or-miss, but it’s in there.

If you want to explore some of what jQTouch can do, head on over to the demo on your iPhone. Bear in mind that as useful as this is, its definitely still under heavy development; as it is, the most recent commit to the github repository was July 21, so things are definitely still active.

If you want to explore the code, head on over to the aforementioned github repository. Cheers!

• iPhone (aka iPhone 1, iPhone 2G) & iPhone 3G both have a grand total of 128 MB.
• iPhone 3GS has 256 MB
• iPhone 4 has 512 MB

So you can see, we’ve returned to the days before a gigabyte of RAM was commonplace. However, this is total physical memory; once you actually turn the device on and get going, that number plummets. In the case of all of them, the system RAM usage (including the MobilePhone application, which also must always be running) is roughly 64MB. In the case of iPhone and iPhone 3G, that cuts your memory in half. Pretty brutal. Thankfully, the later two devices up the ante considerably, but they are still somewhat constraining.

So what does this mean programmatically? It means you’re going to implement things on an as-needed basis, and kill them off as swiftly as possible. Otherwise, SpringBoard (in the case of iOS) will quite ruthlessly kill your application with an out-of-memory error, and we all know how jarring that can be.

Keeping these sorts of physical / systematic limitations in mind is one of the most important concepts in mobile development. It’s akin to developing for some of the previous generation console gaming systems; you have to get it as solid as possible, using as little memory, with as few bugs as you can, at version 1.0.

Good luck!

So how do we test our apps before we release them? In the case of Android apps, this is quite simple, as installation of non-Market apps is possible by checking the “Unknown sources” checkbox in the “Applications” area of “Settings.” For security reasons, be sure to disable this once you’ve installed the app you’re looking for.

In the case of iOS apps, however, the only distribution method is the App Store. So how do we get our app into testers’ hands? We need to create what’s called Ad Hoc distribution. This is a capability that came along with iPhone 2.0. You’ll need to collect the UUID for each tester’s device(s) and use the Program Portal for your app to create provisioning profiles for all of your testers. You then bundle the profiles into the test version of your app, and then build and distribute to them. You’ll need to supply each tester with a ZIP of the .app bundle and a copy of the Ad Hoc .mobileprovision file that you generated.

More explicit, step-by-step instructions for this can be found in Apple’s Developer documentation, but the easiest to read resource is definitely Craig Hockenberry’s Beta testing on iPhone 2.0 article, which outlines the whole procedure. Things have moved around a bit in Xcode 3, and Xcode 4 promises even greater changes, but the procedure is similar enough.

So go forth, and test your new app with your loyal minions!