- (void)webViewDidFinishLoad:(UIWebView *)webView is slow. “You’re running an interpreter (JavaScript runtime) on top of a device with a small CPU and small memory. Go figure.”
The JavaScript bridge does not appear to block the main thread. This is a good/bad thing. You can invoke JavaScript code within the WebKit via your native Objective-C code.
The JavaScript bridge is one directional. From Objective-C/UIKit you can invoke JavaScript upon the WebKit and henceforth do wonderful things
Multiple languages in one project. Whilst we mainly just wanted to take a static HTML file, and dynamically update various elements with application data (e.g. the surf and weather conditions in the example above), we needed to do that via JavaScript.
Why you may want to do it
WebKit for rapid prototyping: WebKit exists and it is awesome at rendering HTML and CSS, with access to the powerful CSS3 transformations and webkit-specific bonus features.
It is highly likely that your designer can make something beautiful looking in Photoshop and cut it up into HTML + CSS. Comparatively, its highly unlikely they can cut it up into native Objective-C code.
WebKit isn’t the holy grail for non-Objective-C developers, but if your grand-poobar level skills are in JavaScript and HTML, and your Objective-C/iPhone skills are still catching up, then its a wonderful prototyping platform. Especially for static, complicated displays of data. Especially if that data includes HTML content from an external feed which needs to be rendered.
For Oakley’s Surf Report app, Anthony is toying with replacing some of the WebKit usage with native UI elements (normal UITableView with custom UITableViewCells) so that we can get back those precious seconds and give them to the user as a Christmas present.
However, Mozilla has also provided an emulator for folks to run Fennec on their desktop machine and are soliciting feedback from the community especially on the browser UI but also on other aspects of the browser as well.
Fennec (Mobile Firefox) has reached milestone 9, which is also our first alpha! We’re calling this release the User Experience alpha.
As with the previous milestones, M9 is targeted at the Nokia N800/N810 (Maemo) Internet tablet. Yes, we have made great progress on Windows Mobile, but no milestone releases yet. However, in addition to the native Maemo release, we are also releasing desktop versions of Fennec. That’s right, you can install Fennec on your Windows, OS X or Linux desktop too! We want you to be able to experiment, provide feedback, write add-ons and generally get involved with the Mozilla Mobile project, even if you don’t have a device.
I am so happy that the NDA mess is over! Clancy has written about how you can have your iPhone Web app run in full screen and has a demo app that shows it off:
Ben Putman has put together a nice iPhone Safari 3D navigation menu example that shows off the transforms and events available on the latest mobile Safari.
Ben told us:
In thinking of an interesting test, I've created a menu that you can rotate across a fixed y-axis with touch, allowing you to spin the menu around and see the depth and back of elements. There are also some examples of how animations can be used as you click and the menu unfolds. I also added a lightbox to examine how one might view some photos although it's not really practical in this form.
Open up the demo in your iPhone / Touch and also take a peak at the source to see what is going on, with snippets like this:
Dylan Schiemann wrote about how disappointing it was that the iPhone didn't support SVG:
Safari on the iPhone does not currently have support for SVG. Safari 3 beta on Mac and Windows is currently the best browser on the planet for SVG performance, so this is a somewhat disappointing omission. We are hopeful that by the end of the year, the iPhone will receive the Safari 3 upgrade, and along with that native support for SVG. For now, we’ll have to wait on dynamic charting and drawing tools due to no SVG and the lack of mousemove event handlers.
It appears that if you point your iPhone 2.1 browser to SVG content and tests it now works!
iPhone apps get a lot of attention and press and understandably so. For a lot of iPhone app developers, these tiny apps can turn into a tremendous cash cow making development for the phone platform invaluable. But considering that the iPhone is running Safari on it, it's surprising that we haven't seen a whole lot more buzz surrounding the use of the new Webkit functionality available to the browser.
So I wasn’t content with the things I’ve tried doing in Safari, and recently began digging through the documentation of the iPhone SDK and the actual CSS Transforms spec.
I was a bit skeptical when I first read about all the cool functions that work in Webkit iPhone, but nowhere else, because there was little documentation, and literally nothing done by other developers, no demos, no tests. I thought, surely, some students with too much free time must have jumped on that immediately?
Seems like Paul was on the right track as finding information on taking advantage of there features for the iPhone was scarce. So by using a iPhone simulator, Paul was able to start hacking at some of the built-in Webkit features, especially the 2D CSS Transforms.
Here comes the cool stuff: The perspective function seems to define how the other primitive functions behave.
Let’s have a look at a practical example: Take a look at the following three functions:
* rotateX - Rotates the element on the X axis.
* rotateY - Rotates the element on the Y axis.
* rotateZ - Rotates the element on the Z axis (By default, same as “rotate”)
Try these out - all three will give you flat, 2d animations, although they are, in fact, functions that use a 3D matrix. However, now change the -webkit-perspective property to 200, and try again. Now, you established virtual depth, and all three functions will give you incredible results.
The end result of Paul's tinkering is a very cool flip effect that is handled within the iPhone's browser and similar to that found in typical iPhone applications. While only a small demo, this opens up possibilities in how browser-based applications can react within the iPhone and what can be presented to mobile web users.
To see the demo, you will need an iPhone or an iPhone simulator.
What about iPhone limits though? David Golightly tests the limits on the iPhone with a script that keeps downloading tiles until it can no longer do so:
After downloading about 210 images, the iPhone simply stops downloading new ones. This is probably due to hitting the hard 30MB same-page resource limit.
Matthew Congrove took some time to play with the iPhone SDK, but it wasn't his bag, so he decided to go back to building a Web application for the iPhone, and was pleasantly surprised with the updates to Safari that enabled new things:
In the midst of all my research for help I stumbled across something that I, like most, had completely forgotten about; the iPhone update wasn't just for native third-party applications, but it also upgraded the existing applications. Yes, that includes Safari. The upgrade for the iPhone's on-board browser added in support for CSS animations and transitions, a JavaScript accessible database, a few new DOM selectors and more. For me this meant that the myDailyPhoto web application could look and feel more like it was a native Cocoa Touch enabled experience. As soon as the idea crossed my mind I sat down to churn out this little test app.
To get the flick effect Matthew wrote the following CSS:
It has been a busy week for Mozilla. We have seen news across the board of their technology.
First we have the news that Firefox 3 should be available to download on June 17th. They are having a download party to kick things off.
Stuart Parmenter had a proxy post that delves into the world of fonts and text:
When Mozilla developers decided to incorporate the Cairo subsystem and build a new graphics layer from scratch, they also decided to completely rework the system that renders text in the browser.
Text is an incredibly important part of the Web. While graphics, audio, and video are increasingly common, we still spend the majority of our time on the Web just reading stuff. All the words you read in a web browser are rendered using a font which contains a set of glyphs used to form individual letters. For more simple written languages there may be a straightforward one-to-one mapping of characters to glyphs, but for more complex languages, one glyph may represent multiple characters.
Ben is a huge fan (a.k.a. anal) of this type of thing. Fonts and rendering can make a big difference, and the post goes into detail on what is going on in the new Firefox 3 engine. It discusses kerning, ligatures, hinting, font smoothing, anti-aliasing, and more. After reading this post you may want to watch Helvetica the movie!
Then we go to the mobile side, where Aza Raskin has posted concept video on the new touch screen interface that they will be building for Fennec. There is a ton of detail in Aza's writeup including design principles:
Touch. This concept prototype for Firefox mobile (code name Fennec) is being designed for a touch screen. Why not multitouch? Because Firefox should be able to run on the least common denominator of touch devices. Especially for touch-enabled interfaces direct manipulation is key. Along that line of thought, the interface should be operable with a finger. Switching between input methods is time-consuming and annoying, so the user shouldn’t have to switch to a stylus or other secondary form of input. Firefox will work on non-touchscreen devices, but that’s out of scope for this demo.
Large targets are good. The same fingertip that controls the interface takes up between 1/5th to 1/10th of the vertical/horizontal height/width of the mobile touch-screen. In other words, fingers are fat: hitting small targets is like trying to touch-type with your elbow. All actions should be represented by targets that are large enough to be fast, easy, and (at the very least) not aggravating to hit.
Visual Momentum and Physics are compelling. Nothing shouts “sexy!†like pretty animations and a physics engine. Beyond marketing appeal, there is a strong argument that such physicality helps the user build a mental model of the interface, and that interface physics yields consistency. We are wired to track the movement of things and to be able to remember where they’ve gone, as long as they don’t appear and disappear, which doesn’t happen in the real world. Of course, copying every physical metaphors blindly gets you interfaces like the multi-million dollar blunder that was Microsoft Bob, so we need to select our metaphors carefully.
Typing is difficult. This means we want to minimize the amount of keystrokes required to get anywhere or do anything.
Content is king. With restricted screen size, every pixel counts. As much of the screen as possible should always be dedicated to content, not controls or cruft.
Then we move to the server side with a Weave status update that should be shipping with Firefox 3. It includes new features around data types, bookmark sharing, and a Web client view. Check out the Wiki for more details.
It gets going by trying to show you the magnitude of mobile (3.3 billion in perspective), tells us that mobile has cried wolf for 15 years, but the time has come.
Finally, they go into detail on the results from the CloudFour mobile browser test that we posted on awhile back. Well worth a quick flip through the deck.
Jason Grigsby of Cloud Four has created a research project that needs our help.
He has created a mobile browser concurrency test to "query the number of concurrent connections your phone makes. Your phone’s browser will need to display images for the test to work.
We’ve also set up a SMS keyword to make it easier to get to the test url. You can simply text MOBILETEST to 41411 on your phone, and you will receive back instructions on how to test your phone.
With mobile devices, the speed of web pages is even more important given bandwidth, processor and memory constraints. Yet, for those trying to take advantage of the techniques promoted by Yahoo’s Best Practices for Speeding Up Your Web Site, it is nearly impossible to find how mobile browsers differ from desktop browsers.
When the results are in, they will be published under creative commons so we can all learn from then. It is interesting to see how the test itself works:
How Does the Test Work?
Designing the concurrency test was a difficult challenge. In order to have the test work for as many mobile browsers as possible, we needed to support XHTML-MP 1.0 (WAP 2.0). XHTML-MP does not support javascript which meant that all of the testing needed to occur on the server.
The basic test works by delivering a XHTML-MP page containing 64 images distributed equally across 4 domains. When the first image is requested by the browser, the server opens a connection and holds it open without delivering the image. It waits 15 seconds to see if any other image requests come in. As each image request comes in, the counter for the appropriate domain is incremented.
If this works well, maybe we can move to other browser factors. With the huge number of devices, operating systems, and mobile browsers, it will be interesting to get data on the diversity.
