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:
Amazon continues to change the game with the launch of the new Kindle tablet. I’ve posted further about this over at Good Screens Media.
The technical details of the new Silk browser are fascinating. Silk is a custom webkit browser that routes page requests through an Amazon proxy server. Pages get optimized within the proxy server. Information gets cached on EC2 servers to speed up DNS lookups and file downloads such as images, CSS, and JavaScript. EC2 will keep permanent connections open to popular sites like Facebook and Google to reduce latency.
Going still further, Amazon will monitor a user’s web traffic and intelligently pre-load pages on their actual device if it’s likely the user will soon visit that page. And like the Android world (and unlike the crazy world of iOS), Flash is supported.
At the Internet protocol level, the new browser improves performance further through the use of SPDY, short for “speedy”, that was developed by Google to enhance HTTP internet speeds through a combination of compression, optimization, and request prediction.
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.
The Nerdiacs report great success using Marmalade to port games to Android and iPhone. They say:
“When we started development on our first title, the first thing as usual was to find our needs and select an engine in accordance to them. After considerable debate, we knew what we really needed was a cross-platform engine for mobile phones which should have solid 3D apis and support as many platforms as possible. This hunt coupled with our naivety as it was our first title, led to us the EdgeLib Engine. Our experiences with it was scarring to say the least, but definitely a huge learning experience which we will leave at that for a post in the future. This made us hunt for a new stronger solution, that we can call our base, our motherland, and that is exactly what we found with Airplay SDK now called Marmalade.”
Marmalade’s strength is in taking iOS games to Android. They allow the use of full-featured C++ and support both Microsoft Visual C++ and Mac XCode.
Marmalade is fully owned by Ideaworks3D Limited. Learn more on their website.
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.
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
The folks at ReadWriteWeb are running a poll on mobile enterprise. Lots of new announcements recently, including Zenprise and news about Motorola and SAP.
Keep track of the poll here.
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.
