Our News RSS
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.”
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 mobile technology company BuiltWith just released stats on the adoption of mobile-specific technologies for websites:
“Of the top 100 sites most visited on the internet5, 71 of them have content specifically designed for mobile devices. The remaining 29 either do not support mobile devices or, depending on the device, prompt the user about a device specific application.”
Contrast this with this Google / Mary Meeker chart of smartphone penetration:
Read the full report from BuiltWith. Read more about Google’s mobile web stats here.
It’s official, HP is dropping WebOS. It was a beautiful OS while it lasted, in many aspects it rivaled the iPhone.
Financially speaking, Elevation Partners may have made the right decision selling to HP, but for consumers, they clearly sold to the wrong partner. If Google had picked up WebOS, maybe Android would have a nicer look to it.
I still remember a meeting with the design team at Palm right before they launched WebOS. It was a spectacular team, picked from all the best companies in Silicon Valley. Sharp, confident people who knew how to build a mobile interface that really worked for people. It felt like a product from the early days of Palm, revolutionary user experience.
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.
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.
Comscore released their report on the 2010 U.S. Digital Year in Review. Lots of good metrics on the mobile market.
Here’s their chart of smartphone market share by OS:
There’s a free download of the report at Comscore.
