You’ve possibly seen bézier curves used in desktop publishing and graphics packages. So let’s take another trip to WolframMathWorld to look at the equations.
I’m sure you understood that but I’m feeling a little nauseous.
In the last post, we saw how quadratic curves have a start point (P0), end point (P2) and a single control point (P1) which determines the curvature. In the case of canvas, a bézier curve has a start (P0), end (P3) and two control points — one for each end of the line (P1 and P2). Thanks again to Wikipedia for a great illustration.
Béziers give far more control over the shape. Because the initial part of the curve follows its control path, we can generate curves which reverse direction or wrap on themselves. They are ideal for creating a Visio-like flow diagram where you need to join two shapes by a connector.
On to the code!
Like before, we require a few lines of JavaScript to get the canvas context and set the default widths and colors:
Version 1.0 of Alex Sexton’s yepnope.js script loader was released last week, so I figured it would be a great time to show you how you can combine Yepnope with Modernizr to make use of HTML5 features without incurring extra downloads for users with up-to-scratch browsers.
What is Regressive Enhancement?
You’re probably already familiar with the concept of progressive enhancement: designing a baseline version of a feature that works in all browsers, then adding features for more capable browsers.
The “polyfill” or “regressive enhancement” technique just means that you go ahead and use the new features, then use JavaScript to emulate native behavior in older browsers. So, instead of using a script to give you drop shadows on all browsers, you just write your CSS with the box-shadow property, and then include a script that transparently takes that property and uses the values you specify to create a drop shadow in JavaScript.
What is Modernizr?
For those of you who aren’t familiar with it, Modernizr is a small (3.7KB gzipped) JavaScript library that detects the presence of HTML5 and CSS3 features in the browser. Raena made use of it in her recent tutorial on creating a progressively enhanced image gallery, and Kevin interviewed Paul Irish, one of the library’s creators, in a recent episode of the SitePoint pocast.
Modernizr is ideally suited to regressive enhancement, because it allows you to know when you can rely on browser functionality, and when you need to fall back on JavaScript or alternate styling.
There are two main ways of using Modernizr. The most common way is to rely on the HTML classes it adds to your html tag. When viewing a page with Modernizr in the latest Firefox 4 beta, here’s what I see in the opening <html> tag:
All those classes tell me which features are available in the browser. For example, I have @font-face, web workers, and CSS3 box-shadow, text-shadow, and border-image, but I don’t have websockets or 3D CSS transforms. So, in my CSS, I can do something like this:
.borderradius .box {
-moz-border-radius: 5px;
-webkit-border-radius: 5px;
border-radius: 5px;
}
.no-borderradius .box {
// fallback code providing an alternate styling to browsers that don't support border-radius
}
That’s simple enough. The cool bit is that Modernizr also provides you with a JavaScript API that can tell you whether or not a feature is available, including a few features that don’t show up in the <html> tag classes. For example, let’s say I have some JavaScript code that provides placeholder values for input elements. I don’t need to run this code if the browser supports the placeholder attribute, so I can use Modernizr to check for that before executing my snippet:
This way, my code will only run if there’s no built-in browser support for placeholder text.
The Problem
There’s still a slight problem here, though. If a browser does support the placeholder attribute, I’m still requiring it to download a bunch of code that does nothing but emulate that attribute’s behavior. I’m sure you’ll agree this is a little wasteful! Enter yepnope.js. Yepnope loads scripts if certain conditions are met. The best part is that it integrates beautifully with Modernizr, so everything just snaps into place.
The simplest example, from the library’s website, looks like this:
If the browser supports geolocation, that snippet will load the normal.js file from the server; otherwise, it’ll load both polyfill.js and wrapper.js.
A Practical Example
Now that you know how all the parts work, let’s put them together into a real-world example. Let’s say you have a simple signup form, consisting of fields for a username, password, and email address. Here’s the markup:
The form uses a number of HTML5 features: the required attribute, the placeholder attribute, and the pattern attribute. In a supporting browser, such as Firefox 4 beta, this provides placeholder text and some basic client-side validation:
The placeholder attribute provides placeholder text
The email input type provides built-in format validation
The pattern attribute provides regular expression based validation
In a non-supporting browser, however, you get big fat nothing. Let’s fix this using a JavaScript-based polyfill along with Modernizr, and Yepnope to load it only when it’s required.
Step 1: Download Modernizr and Yepnope
The new custom Modernizr builder allows you to bundle yepnope right into Modernizr, so let’s do that. Head over to http://modernizr.github.com/Modernizr/2.0-beta/. In this case all we need to detect are the form attributes and input types, so click those two checkboxes, leaving the HTML5 Shim and Modernizr.load (yepnope.js) boxes ticked.
Click Generate, and then Download Build to grab your custom Modernizr library.
Step 2: Include Modernizr in Your Page
Because Modernizr needs to determine if other scripts should be run, and adds classes that might be required by your CSS, it should go at the top of your HTML, rather than at the bottom as is usually recommended:
<script src="modernizr.custom.02401.js"></script>
(Remember to replace the custom build number with your own.)
Step 3: Test for Feature Support
Now we want to test to see if the browser supports the new input types and attributes:
We’re loading the H5F library by Ryan Seddon, which emulates all the new input types and attributes we’re using in this example. In this case we have one polyfill script that covers a bunch of different features, so we’re checking for all of them at once and loading the polyfill if even one of them is unsupported. This is not always ideal, but we’re keeping things simple for the sake of illustration.
You’ll also notice we’re not using a “yep” in this yepnope call. That’s fine: in the event all the features we’re detecting for are present, Yepnope won’t do anything at all, which is what we want.
Step 4: Execute Callback Code
You might be tempted to just call your newly included library on the next line of code, but this won’t work. Yepnope.js loads scripts asynchronously, so the browser won’t wait for the script to be finished loading before moving on to the next line in your code. That means that if you try to use the features you’ve just told Yepnope to load, you’ll likely get an error.
Instead, Yepnope allows you to set a callback function for each script you load, to be run once that script has finished downloading. Here’s how that works:
The function you specify as a callback will be called each time a script is loaded. This means that if you’ve specified both a yep and a nope, the callback will be called twice. Fortunately, the callback is passed three useful parameters: url is the URL of the result that was loaded, result is a Boolean value representing whether or not your test passed, and key is a way of referring to specific resources using keys (you don’t need to worry about this for now).
In the above example, I’m only loading a script on nope. As a result, the callback will only be called once anyway, and only if the test fails, so I don’t need to worry about the parameters.
Step 5: You’re Done!
Believe it or not, you’re done. With the above code in place, browsers that support the new form features will use their built-in functionality, while older browsers will load a JavaScript fallback. The JavaScript will only be loaded in those non-supporting browsers, so you’re rewarding modern browsers with snappier load times. Even better, because the polyfill hooks onto the new attributes and doesn’t require any extra classes, the solution is future-proof. Fewer and fewer visitors over time will download the polyfill, until eventually none of them do.
What’s Next?
I’ve only covered the simplest use cases of yepnope,js. For such a tiny library, it packs a lot of functionality, so you should definitely have a read through the project’s page to see some more advanced usage examples. Even if you’re not using it for HTML5 or CSS3 polyfills, there are potential performance gains to be had from loading your scripts asynchronously and on demand, so Yepnope is still worth looking into.
Now, all you have to do is start putting new HTML5 and CSS3 features to use on your website, safe in the knowledge that you can provide a full-featured fallback to users of older browsers without impacting the experience of your more up-to-date visitors.
jCanvaScript is a JavaScript library that comes with methods to controlling HTML5 canvas in a less-complicated way.
The library is completely object-oriented and besides the canvas context, it provides access to mouse/keyboard events, drag 'n' drop and object animation.
Creating new objects is very straightforward with various built-in objects like .circle(), .rect(), .image(), and much more.
Also, there is a huge set of functions that can complete almost any possible action within a single line.
jCanvaScript is very well documented and comes with examples for every feature.
The Mobile App Trends Series is sponsored by Sourcebits, a leading product developer for mobile platforms. Sourcebits offers design and development services for iOS, Android, Mobile and Web platforms. Follow Sourcebits on Twitter for recent news and updates.
As the mobile application space continues to explode, developers are increasingly using HTML5, JavaScript and CSS3 to aid in the creation of web apps and native mobile apps. This process is especially useful when dealing with cross-platform development or when working with content that already exists in some form on the web.
We’re going to take a look at how some of the best HTML5-centric, cross-platform mobile frameworks are being used to help developers deliver native app experiences on a variety of devices.
Why HTML5
Given the hype and buzz surrounding HTML5, it would be easy to believe that it is a technology that will do your laundry, mow the lawn and make you dinner. In truth, HTML5 isn’t the second coming, and it isn’t an officially ratified standard — yet. The spec continues to edge closer to completion, however, and when combined with JavaScript and CSS3, HTML5 can do some really incredible things.
This is particularly true for mobile devices. A de facto requirement for any modern mobile operating system is the inclusion of a modern HTML5-compliant web browser. The leading modern mobile platforms — iOS and Android — both use WebKit as their bases. Likewise, BlackBerry and HP/Palm are also using WebKit and Microsoft is going to release a mobile version of Internet Explorer 9 for Windows Phone 7.
What this means is that out of the box, modern smartphones and tablets support the bells and whistles that make HTML5 so special. It also means that developers can feel free to use those technologies when creating their applications and not have to worry that the device itself won’t support a particular function.
It also means that developers that choose to create HTML5 web apps for the desktop — like for the Google Chrome Web Store — can often use the same code when crafting an app for the iPad or for other tablets.
Because ScrollMotion has built its underlying app platform in HTML5, porting the content to a non-iOS device, like the Chrome browser, required very little work.
Platforms
Choosing what mobile platforms to support continues to be a vexing problem for developers both big and small. Supporting one platform can be difficult enough, but now developers not only have multiple operating systems to consider, but multiple device types as well. iPhone and iPad apps can be packaged together, but both require separate experiences and views.
Likewise, Android developers that want to target the upcoming wave of Honeycomb tablets will need to create variations of their apps for the different device types. Add in the BlackBerry PlayBook, HP’s TouchPad and the future devices from Nokia and Microsoft, and it’s not difficult for even a large development team to become overwhelmed.
Fortunately, this problem has created a microcosm of cross-platform mobile development tools. We’ve covered a number of these platforms and frameworks in the past, but we want to highlight a few that specifically target HTML5 and JavaScript.
Appcelerator’s Titanium platform was designed from the offset to help web developers create mobile and tablet applications with ease. Over the last year, the platform has seen tremendous growth, and new features and devices are added at a fast pace.
Appcelerator recently acquired Aptana, which should ensure that the tools for building its apps continue to improve and evolve over time.
Some of the apps that have been built with Appcelerator include GetGlue for iPhone, iPad and Android and ScoutMob’s excellent iPhone app.
PhoneGap is an HTML5 app platform that lets developers build native apps using HTML5, CSS3 and JavaScript. What really sets PhoneGap apart is that it lets developers create a full-functioning mobile web app but place that app in a native wrapper, so that it can use native device APIs and get submitted to the App Store or Android Market.
In essence, it enables mobile developers to create an app just as if they were targeting the mobile browser but with the benefit of being able to get into the App Store.
PhoneGap Build is a new service (still in beta) that lets developers quickly and easily create app-store ready versions of their apps for various platforms. It does all the work of compiling the code for various platforms and gives the developer a final build suitable for submission to the app market of their choice.
Ars Technica used PhoneGap to build its iPad app. This is a great example of using web standards to deliver an app that presents existing content in a customized view and experience. Clint Ecker’s post about how the app was built is worth a read.
Rhodes is a Ruby-based framework designed to help developers create native apps for a wide range of devices and platforms. The reason we included Rhodes in this roundup — despite being a Ruby tool — is that it uses HTML, CSS and JavaScript in its views. That means that HTML can be used for the interface aspect of the app — even if Ruby is what is powering the work on the backend.
The Unify Project is a set of tools designed to make it easier for developers to create smartphone apps using HTML5, CSS3 and JavaScript. Sponsored by Deutsche Telekom, Unify is published under a dual open source license (MIT and Apache version 2.0) and it uses PhoneGap, Adobe Air, Sass and the quooxdoo JavaScript framework.
Additional Tools
Using various mobile web frameworks alongside an HTML5 platform is a common approach to mobile app development.
Developer Pete Freitag recently gave a presentation on building mobile apps using jQuery Mobile and PhoneGap. Freitag made the slides available on his website and the presentation offers a nice overview of how to use two emerging web frameworks together.
Feitag’s tracking and reimbursement app Mileage Pad was built using PhoneGap and jQuery Mobile.
Other web frameworks that can be used alongside PhoneGap or Rhodes include Sencha Touch and SproutCore.
Or Just Make an HTML5 App
Of course, an increasingly viable option for mobile developers is to just use HTML5 to create a mobile web app.
As HTML5 gets better and browser support of HTML5 improves, the differences between running an HTML5 app in a native wrapper, a la PhoneGap, and accessing an HTML5 web app from an app shortcut on your home screen is going to continue to disappear.
Lots of companies — including Facebook — are looking at HTML5 as the future platform for their apps that target next generation devices.
Earlier this month, 37signals decided to forego building a platform-specific mobile app for its Basecamp product and instead created Basecamp Mobile. This decision initially drew some criticism, with members of the developer community questioning the company’s decision to just use HTML5.
With the recent Readability kerfuffle, it’s possible that more developers will start considering a mobile web approach for their applications. Readability’s Rich Ziade and Dan Benjamin discuss the issue in length, including what it means for mobile developers, on “The Daily Edition.”
The Future is Bright
Whether it’s through a framework, via an application wrapper or as the basis for a mobile web app, HTML5 is going to continue to be an important driving force for mobile application development.
In fact, as the technology evolves, we wouldn’t be surprised to see more HTML5 elements popping up in native desktop applications as well.
Are you using HTML5 when building mobile apps? Let us know.
Series Supported by Sourcebits
The Mobile App Trends Series is sponsored by Sourcebits, a leading developer of applications and games for all major mobile platforms. Sourcebits has engineered over 200 apps to date, with plenty more to come. Sourcebits offers design and development services for iPhone, Android and more. Please feel free to get in touch with us to find out how we can help your app stand apart in a crowded marketplace. Follow Sourcebits on Twitter and Facebook for recent news and updates.