Fluid Mobile HTML5 Design and Development

In the world of print publication, laying out a design starts with a canvas that has a known height and width. If an agency is putting together an advertisement for a magazine, and they know that they are (hypothetically) designing for a page that is 8 inches wide and 10 inches high, assuming a standard 300 dpi, a designer can start off by creating a 2400×3000 pixel canvas. That designer can then move on to laying out the advertisement with pixel-perfect accuracy knowing full well that the magazine stands very little chance of changing size or shape after it has been printed. If an image or a block of text needs to be moved to the left by 2 pixels, it is as simple as moving that element over 2 pixels.

The world of mobile development isn’t quite that cut and dry. When an app needs to work on multiple devices and multiple orientations, the variety of screen sizes on the market must to be taken into account. This is especially true for Android and cross-platform apps, where screen sizes and pixel densities vary greatly between devices. First, there’s the physical device resolution to consider. The iPhone 4 and 4S have a “Retina” display with a 480×960 resolution (so named because the pixel density is so high that individual pixels are impossible to see with the naked eye), older iPhones have a 320×480 resolution, the first and second generation iPads are 1024×768, the new iPad has a 2048×1536 retina display. Android device resolutions are all over the place. The Samsung Galaxy 10.1 has a 1280×800 display, and two Android phones we’ve been working with lately (the Sharp Aquos SHI13 and the Kyocera Digno ISW11K) have resolutions of 540×960 and 480×800 respectively. The new Windows 7 Nokia Lumia 900 is 480×800.

Additionally, for the mobile web and for “hybrid” applications built with HTML5/CSS3 using native wrappers like Phonegap, the UI for the application is rendered inside of a Webkit-based webview on iOS and Android and a IE-based webview on Windows Phone. Webviews are designed to support pinching and zooming on mobile devices, so there are actually a few different functional “resolutions” to consider.

For instance, the document layout size (document.documentElement.clientWidth, document.documentElement.clientHeight) and the Screen Size in CSS pixels (window.width, window.height).

Taking the Zoom level into account, the portion of the document shown on the screen is the visual viewport (window.innerWidth, window.innerHeight). As you can see here, while the Document size and the Screen size remain the fixed, the viewport size changes as more and less document pixels are shown within the CSS pixels:

The reason for all these different resolutions is that when the iPhone was first developed, it had a physical resolution of 320×480 pixels, but Apple wanted users to be able to browse regular web sites as if they were sitting at a desktop computer with a much larger screen. They designed the iPhone to render pages in portrait mode as if the screen was 980 pixels wide. This causes it to initially render maximally zoomed out, and users then pinch and scroll around the page as if the phone were a small window to the larger website. By doing this, Apple decoupled the device resolution from the resolution of the CSS page being rendered in the browser. Google and other smart phone manufacturers followed suit. Even though the iPhone device resolution is 640px wide, the web view renders at 320×480 with a pixel ratio of 2 (2 device pixels for every 1 CSS pixel).

While the viewport concept is great for viewing web sites that were originally designed for desktop computers, mobile “hybrid” apps that use HTML5 technologies and mobile web sites are typically developed so that users do not have to (and frequently cannot) zoom and pan around the display. This effect is accomplished by locking the viewport size to the resolution reported by the device as the CSS screen size by using the “viewport” meta tag:

<meta name=“viewport”content=“width=device-width, initial-scale=1.0, maximum-scale=1.0, minimum-scale=1.0, user-scalable=0” />

This is what causes a hybrid or mobile web app to fill the screen, and allows the developer to place a fixed toolbar at the top, a fixed tab bar at the bottom. The end result is that the mobile web can look and function very much like a native app. You can see here in the “content” parameter, the width is set to equal the device width, at a zoom-level (scale) of 1, and the ability for the user to scale/zoom the viewport is disabled by setting “user-scalable” to 0. This special “viewport” meta tag was first introduced by Apple, and has been added to most other browsers, including the Android Webkit browser.

All of this brings us to the need for a fluid, adaptive layout, applying time-honored lessons from traditional web design and development so that the app adapts properly to multiple different screen sizes and ratios. As John Allsopp puts rather eloquently in his oft-referenced article, A Dao of Web Design, “If you are concerned about exactly how a web page appears this is a sign that you are still aren’t thinking about adaptive pages”.

Adaptive Layouts

Developing an adaptive layout for a hybrid mobile app is much the same as developing an adaptive website—after all the base technologies are the same. Instead of specifying sizes and locations in exact pixels, sizes are specified in terms of percentages of the element that contains them, and locations on the screen are specified in relation to other elements or the outer edges of the screen. Additionally, much like a native app, when viewed on different screen sizes, certain elements should scale and others shouldn’t. The tab bar, for instance, should scale horizontally to fill the screen, but should stay the same height regardless of the overall screen size so that more content is able to fill the page.

This makes it more difficult to place items exactly at a given location on a specific device, but it allows the app to resize fluidly on many different devices:

Taking it a Step Further — Responsive Design

But as the iPad example above makes evident, there’s a limit to what can be done by simply scaling items within the display. Scaling an app designed for a phone up to a tablet or desktop computer form factor does a poor job of using the extra screen real estate. For instance, on an iPad in landscape mode, it’s common to implement a Master/Detail view, where a list of data is presented on the left panel (master), and the detail about a selected item is displayed on the right (detail). This example that uses the Force.com Mobile Components to render Contact information in Salesforce.com shows the general idea:

That’s a pretty radical shift in how a view is rendered between a phone and a landscape tablet. Luckily, the HTML5 specification introduced the concept of Media Queries, which allow an HTML developer to specify different CSS style sheets depending on the resolution, orientation, aspect ratio, and even pixel density of the device that is rendering the page.

By specifying different style sheets for various types of devices, like phones, tablets, typical desktop computers, print, and massive displays, it’s possible to create a layout that adapts perfectly to the size of the device being used. I could provide some visual examples, but the MediaQueri.es site already does an excellent job of showing how this works, and the examples there illustrate the benefits quite well. As for how media queries are used, it’s as simple as specifying a media attribute in a <link> tag, and since stylesheets are additive, you can start “Mobile First”, and build your site up from the simplest design to more and more complex designs. That way the smallest devices will only download the CSS files and images meant for them, and other, larger devices can pull down the CSS files intended for them as well. For instance, this series of three CSS links starts by specifying a very basic style sheet that is intended for phones. Tablets in portrait orientation will render the first two CSS links, and desktop/latptop computers and landscape tablets will use the first three. It’s possible to continue this–for example–by specifying a stylesheet for extremely large displays, and a stylesheet for print.

Further Reading

If you’re interested in learning more about responsive web design and media queries, these are some great resources:

• Responsive Web Design by Ethan Marcotte
• The Book of CSS3 by Peter Gasston
• MediaQueri.es
• A Dao of Web Design by John Allsopp
• Mobile First by Luke Wroblewski

Codesign: Re-Signing an IPA between Apple accounts

Since much of the iOS development work we do is for clients who are developing apps to distribute internally with an In House Mobile Provisioning Profile using their Enterprise Distribution Certificates, and not all of them want to share those files outside of their organization, we frequently need a way to send them the IPA file built with our own Apple account, and have them re-sign it to use their own.

This process can also be used, for instance, to test the final App Store Distribution build before sending it to iTunes Connect by resigning a copy of it from an App Store Distribution profile to an Ad Hoc one or to update an .ipa file from an In House profile with a certificate that is about to expire (they expire every year) to a new one without having to rebuild the app from the source.

Licensing Restrictions

If you’re doing this in order to send an app to a client, the first thing to note is that you want to use an Ad Hoc profile on your own account, not an In House profile. On the subject of customers, the license agreement for Enterprise Distribution states that you can:

Allow Your Customers to use Your Internal Use Applications, but only (i) on Your physical premises, or (ii) in other locations, provided all such use is under the direct supervision and physical control of Your Employees (e.g., a sales presentation to a Customer). 

So, sending your client an .ipa signed with your In House provisioning profile is verboten. However, the rules for Ad Hoc distribution are more lax in that they allow for distribution to individuals “who are otherwise affiliated with you”:

Subject to the terms and conditions of this Agreement, You may also distribute Your Applications to individuals within Your company, organization, educational institution, group, or who are otherwise affiliated with You for use solely on a limited number of Registered Devices (as specified on the Program web portal)

Also, it’s just easier to know that you’ve re-signed it correctly if you know that you’re starting with an Ad Hoc profile, since the app will only be able to be installed on the devices specified in your provisioning portal.

Bundle Id

This whole re-signing process will only work if the Bundle Id is the same for both profiles. So, the first thing you’ll need to do is find out what your client wants to use for the bundle id for the app. Let’s say our client, Tom’s Things, wants to use com.tomsthings.bestappever for a bundle id. To set that up, you’ll just need to set up that new bundle id in your provisioning portal (I’m using a wildcard ID here):

Then, you need to set up a new Ad Hoc profile using that bundle id and your distribution certificate, and you’ll probably also want to include a few of your client’s device UDIDs on it, so they’re able to test the app without having to re-sign it every time you send them a build.

Codesign: Re-signing the App

Now comes the fun part (for certain definitions of fun): taking the .ipa file and re-signing it to use a different account’s distribution certificate and profile. Since you’ll need the destination certificate and profile, in the example given above, this would be done by someone at Tom’s Things to use their own Enterprise Certificate and In House mobile provisioning profile. You’ll need to do all of this from the command line, so open up Terminal.app and navigate to the location of your .ipa file. The command line commands are shown here in blue.

• Step 1: Unzip the IPA file (they’re just zip files renamed to .ipa). This will leave you with a folder named “Payload”.

unzip BestAppEver_adhoc.ipa

• Step 2: Delete the _CodeSignature from within the .app bundle.

rm -rf Payload/BestAppEver.app/_CodeSignature

• Step 3: Replace the embedded.mobileprovision file with your In House .mobileprovision profile.

cp ~/Documents/TomsThingsInHouse.mobileprovision Payload/BestAppEver.app/embedded.mobileprovision

• Step 4: Use codesign to replace the existing signature using a certificate in your keychain to sign the app. In this example, I would need to have a certificate named “iPhone Distribution: Tom’s Things, Inc.” in my keychain. When you run this command, you’ll be asked to allow codesign to access this certificate. Choose to “Allow” or “Always Allow”.

/usr/bin/codesign -f -s “iPhone Distribution: Tom’s Things, Inc.” ––resource-rules Payload/BestAppEver.app/ResourceRules.plist Payload/BestAppEver.app

• Step 5: You’re almost done. The last thing you need to do is to zip that Payload folder back into an .ipa file. Do do that, just use the zip command.

zip -r BestAppEver_inhouse.ipa Payload

And that’s it. Now you have an .ipa file signed with your certificate and mobile provisioning profile, ready to be uploaded to your internal app store or sent to your team for testing.