Looking forward to seeing how this works. From their website:
“We set out to make this framework easy for developers to get up and running fast, with a minimal learning curve. Less technical folks can configure the framework with just HTML markup, but we maintain the full power of jQuery and a robust event and plugin system under the hood for developers who want to deeply extend the framework. By using tools like PhoneGap, jQuery Mobile code can be transformed into apps to be distributed through all popular app stores.”
This is pretty neat. Use an online dashboard to create a nice looking mobile theme, and export the css.
Make your own here, it’s easy.
I just tried the new Phonegap online service, and it’s pretty impressive. I already had a mobile html website handy, so all I had to do was upload it as a zip file. Within minutes, I was running it on my Android phone. It had also built iPhone, Android, WebOS, and Symbian apps. It would have completed one for Blackberry too but it found some compatibility errors which it kindly pointed out to me.
Here are screenshots:
From joshy.org, some good principles about how to optimize HTML5 canvas for mobile devices.
Quoted verbatim here:
- Now, let’s talk about mobile devices and optimization. There is no mobile version of canvas, there’s just canvas. It’s the same API on desktop and mobile devices. Mobile devices are sometimes missing features, however, and are usually slower; but the same could be true on older desktops and browsers. So whenever you are making a canvas app it’s important to consider performance and different ways to optimize your code.
- The general mantra for performance is draw less.
- Don’t draw hidden things. If you have four screens of information but only one is visible at a time, then don’t draw the others.
- Use images instead of shapes. If you have some graphic that won’t ever change or be scaled, then consider drawing it into an image at compile time using something like photoshop. In general images can be drawn much faster to the screen than vector artwork. This is especially true if you have some graphic that will be repainted over and over again like a sprite in a game.
- Cache using offscreen canvases. You can create new instance of the canvas object at runtime that aren’t visible on screen. You can use these offscreen canvasas as a cache. When your app starts draw graphics into the offscreen canvas then just copy that over and over again to draw it. This gives you the same speed as using images over shapes, but you are generating these images at runtime and could potentially change them if needed.
- Image stretching. Since we are using images for lots of things already, consider stretching them for effects. Most canvas implementations have highly optimized code for scaling and cropping images so it should be quite fast. There are also several versions of drawImage that let you draw subsections of an image. With these apis you can do clever things like caching a bunch of sprites into a single image, or wildly stretching images for funky effects. [screenshots]
- Only redraw the part of the screen you need. Depending on your app it may be possible to just redraw part of the screen. For example, if I have a ball bouncing around I don’t need to erase and redraw the entire background. Instead I just need to redraw where the ball is and where it was on the previous frame. For some apps this could be a huge speedup.
- Draw fewer frames Now that you are drawing as little per frame as possible try to draw fewer frames. To get smooth animation you might want to draw 100fps, but most computers max out at a 60fps screen refresh rate. There’s no point in drawing more frames because the user will never see them. So how do you sync up with the screen refresh? Mozilla and WebKit have experimental apis to request that the browser call your code on the next screen refresh. This will replace your call to setInterval or setTimeout. Now the browser is in charge of giving you a consistent framerate, and it will ensure you don’t go over 60fps. It can also do smart things like lowering the framerate if the user switches to a different tab. Mobile browsers are starting to implement this as well so background apps will be throttled back, saving on battery life.
- The best way to draw less is to not draw it at all. If you have a static background then move it out of canvas and draw it with just an image in the browser. You can make the background of a canvas transparent so that a background image will show through. If you have large images to move around you may find they move faster and smoother by using CSS transitions rather than doing it with javascript in the canvas. In general CSS transitions will be faster because they are implemented in C rather than JS, but your mileage may vary, so test test test. Speaking of which: Chrome and Mozilla have great tools to help you debug and test your JavaScript. [names? examples?]
- Pixel aligned images. One final tip, in some implementations images and shapes will draw faster if they are draw on pixel boundaries. Some tests show a 2 to 3x speedup [verify] on the ipad canvas impl if you pixel align your sprites. http://jsperf.com/drawimage-whole-pixels http://sebleedelisle.com/2011/02/html5-canvas-sprite-optimisation/
This is just the mobile section, read the full article at
joshy.org.
If you’re looking for a good review of HTML5 for mobile, Chris Toswill at EngineYard has done your homework for you. He covers website sizing (viewport), caching, JQuery templates, local storage, and other good stuff about HTML support on mobile devices.
Here’s an excerpt on Viewport:
“When you visit a website not designed for mobile browsers, it first appears very zoomed out. This is done intentionally by the mobile browsers to make the website viewable. They set the default viewport width to between 800 and 980 pixels (depending on the browser). This allows the user to view the whole website and then zoom in as needed. However, if you are crafting a website specifically for mobile, it make sense to set the initial viewport for the mobile device. This is accomplished with the viewport meta tag.”
Read more at EngineYard.
The team at FunctionSource got an in-depth interview with the development team who designed the HTML5 experience. Here’s an excerpt:
While HTML is a great platform fit for Netflix, it’s not the platform they originally started out with for their device UIs. The initial platform was a mixture of Flash Lite and C++, which Andy characterized as a real integration challenge. They wanted to try a different approach. He explains, “About a year and a half ago, the team sat down and we realized that devices were getting faster quickly. At the same time, WebKit was starting to pick up steam as a great embeddable Web runtime. YouYou combine that with the huge breadth of HTML talent at Netflix, and we saw an opportunity to leverage that talent across all our devices. We decided the time was right to take a dive into the HTML pool.”
The Netflix team realized almost immediately that if they chose HTML for their mobile applications, they’d have to provide their own WebKit runtime to power it. This became apparent as they evaluated using the browser engines third-party device manufacturers provided. “We found that verifying a third-party browser engine against our current and future needs was nearly impossible,” Andy said. And when gaps in such are identified, there’s the issue of cadence to consider. “We’re Web guys. We release new versions nearly every two weeks. Our entire business is based on this flexibility. But device manufacturers work on much longer timelines as they are dealing with hardware. We didn’t want to lose our ability to work rapidly.”
Netflix selected a webkit framework created by QT and built some additional features on top to better handle rapid graphics processing. Then they sent this proprietary webkit version as an SDK to their device partners, and put them through a certification process before they can go live. An exception is Apple, where they had to do their own integration into iOS webkit.
Overall, an impressive HTML5 project.
During 2010 we heard a lot about HTML5 and its possibilities and capabilities. The new updated version of the web standard HTML was at the spotlight and everyone was pretty interested in learning more about its features and techniques. HTML5 has lots of new and interesting tags that allow you to easily incorporate videos, use drag and drop and do hundreds of cool effects and interactions. Here we will show a list with 20 examples of websites using HTML5 and their developers. Almost all examples are developers/designers pages, what show us that several professionals are already adepts of this new trend.
We also checked how are the websites reacting in mobile versions, we tested the iPhone and Android (G1) environment. The Android was tested via emulator, so maybe some results are not 100% accurate.
Beautiful background image and hover effects.
Designer/developer: Cameron Moll.
iPhone performance: everything looks good, the video from the header was removed at the mobile version.
Android performance: everything looking good, even the video.
Simple and elegant layout with nice hover effects.
iPhone performance: text look good and centralized but the background looks a bit out of place.
Android performance: everything ok
Super clean and beautiful layout.
Designer/developer: Jeroen Homan.
iPhone performance: main content and images are ok, footer is not loading properly.
Android performance: everything looking good.
Nice image transitions and subtle menu hover effects.
Designer/developer: Keyzo IT Solutions.
iPhone performance: works fine but could make more use of media queries instead of loading a static version to adjust the screen size.
Android performance: looks good.
Clean and minimal layout with beautiful hover effects.
Designer/developer: Rui Mollar.
iPhone performance: also looks good but loads in the static size of the screen.
Android performance: ok
Subtle shadow when hovering menus and a nice image showcase and transitions.
Designer/developer: Superhug.
iPhone performance: looks good and works fine.
Android performance: looks fine.
Nice effect on header’s menu and framed links with hover effects.
Designer/developer: Ricardo Saavedra.
iPhone performance: looks good, also adjusted to fit the screen.
Android performance: everything working.
Designer/developer: Yellowhammer Creative.
iPhone performance: perfect!
Android performance: also perfect!
Nice header and search box fade effect. Also nice text shadows.
Designer/developer: TheFella.
iPhone performance: great!
Android performance: also great!
Great colors, design, navigation, images disposition and simplicity.
Designer/developer: Cazinc Web Development.
iPhone performance: perfect!
Android performance: yeah, perfect here too!
Beautiful header background images and hover effect on menus.
Designer/developer: Planetperki.
iPhone performance: looks and works good, even the background transitions.
Android performance: also good.
Really nice and smooth image transitions and hover effects.
Designer/developer: Planetperki.
iPhone performance: looks and works good, even the background transitions.
Android performance: same here.
Nice single page layout with vertical slider navigation, cool hover effects and images disposition.
Designer/developer: Michael Acevedo.
iPhone performance: perfect!
Android performance: also perfect!
Awesome user interaction at navigation. Attention to details and beautiful interface.
Designer/developer: Nerd Communications.
iPhone performance: great!
Android performance: not working at all, probably because it’s an iPhone / iPod Touch app. 
Really nice transitions and background effects.
Designer/developer: Julien Etienne.
iPhone performance: not loading properly, broken background and text.
Android performance: apparently everything works fine.
Single page design with nice vertical slider navigation and effects. Good user interaction.
Designer/developer: Vision 18.
iPhone performance: perfect!
Android performance: also perfect!
All HTML5 game.
Designer/developer: Michiel Van den Anker.
iPhone performance: not working.
Android performance: not working.
Really nice shadow effects and image/information boxes.
Designer/developer: ZingChart.
iPhone performance: works good, the only effect missing is the shadows, everything else is ok.
Android performance: works fine.
Another HTML5 game.
Designer/developer: Kate.
iPhone performance: not working.
Android performance: not working.
Clean and elegant layout where we hover around to check browser readiness for HTML5 & CSS3 features. Really nice interaction and effects.
Designer/developer: Paul Irish and Divya Manian.
iPhone performance: not working. The site loads broken and you can’t navigate it properly.
Android performance: looks good but doesn’t have the same interaction and effects.
Source:
HTML5 Gallery
101 Best HTML5 Sites
Is TechCrunch loosening their editorial standards now that they part of AOL? Their recent comparison of HTML5 and native apps manages to evade any useful information while filling us with keywords and inflammatory language (that is, if you are a mobile developer).
Here’s an example:
Let’s be honest: right now, most HTML-based mobile apps are a joke when compared to their native counterparts. It’s not even remotely close. In fact, you could argue that the discrepancy isn’t much smaller than it was three years ago. And considering that the App Store was only on the verge of launching at that point, in many ways, the discrepancy is even bigger. Just look at mobile games now, for example.
It’s not technically inaccurate, just misleading. Read it for entertainment only.
A new report from eLance provides some metrics about how quickly the demand for mobile developers is rising:
Demand for experts in mobile technologies continues to grow at an impressive pace with demand for iPad programmers growing 15% quarter-over-quarter, and iPhone programmers growing 10%. However, Android developers experienced even higher growth in Q4 thanks to a 20% rise in demand quarter-over-quarter. Demand for iOS and Android programmers is unlikely to slow down anytime soon, as Verizon and other carriers start selling Apple products, and a flurry of new Android devices announced at this year’s Consumer Electronics Show hit the market.
As the technology “wars” continue to rage onward, some underlying trends remain the same: With a huge 48% growth quarter-over-quarter, demand for HTML5 programmers continues to skyrocket as businesses look to not only revamp existing websites, but also create a presence on increasingly popular tablet and mobile devices. On the other hand, despite showing no significant growth in Q4, Flash continues to hold steady as a sought-after skill, indicating that businesses are not dropping the proprietary technology anytime soon.
Read the full report on eLance.
LimeJS launched a new platform for building HTML5 games. The examples they show work well but are fairly simple puzzle like games. You can see them here:
Roundball
Zlizer
