Home screen splash images in iOS5

It seems that Apple slipped-in a resolution to the bemoaned lack of high resolution splash screens for webapps added to the home screen for phones with retina displays. However, there are a couple of gotcha's that you might want to be aware of.

First some background. Here are some examples of how you make you web page capable of providing a home screen icon and splash image with iOS devices:

With iOS5 there are now a few scenarios you need to handle:
iOS < 5 - Retina splash not supported - image must be exactly 320 x 460
iOS >= 5 - Retina splash supported - will not use lo-rez splash - image must be 640x920
iOS >= 5 - on non-retina phone - retina splash not supported Retina splash not supported - image must be 320 x 460

There are basically two techniques that should work here to determine the right image to use: CSS media queries and Javascript injection.
CSS media queries
It seems that CSS media queries are not fully supported on older phones. I found that when adding several directives with different media queries that things stopped working as expected on some devices. Older iPhones on older versions of iOS were either ignoring the media query or somehow parsing them wrong.
Javascript injection
I found the best path to sanity was to use javascript to inject the right directive into a script tag in the header:



Make sure your image file is still small
The image you will be transferring is four times larger than before, and I've observed that if it's too large it may not show up on the first load. Our client's splash screen art was quite detailed, which doesn't compress well. My initial hi-rez image as a PNG was 400K. In one test, I thought that something in my markup was wrong until after about the tenth time starting the app from the home page, the loading image finally appeared. Obviously my file was too large to transfer quickly...

Consider JPEG
It's not common knowledge that the splash screen image format can be PNG, GIF or JPEG. Most of us have got used to using PNG, but if your PNG is too large try a JPEG, tweaking the settings until you get a good compromise between image size and quality. I found that just by saving it out to JPEG with 90% compression setting cut my image file size by 75% without losing too much noticeable detail.

References:
http://miniapps.co.uk/blog/post/ios-startup-images-using-css-media-queries/
http://paulofierro.com/archives/568/

Application Craft Impressions

Application Craft (AC) is a very ambitious attempt to put modern HTML5 development, including mobile, onto the cloud.
The premise is this:
Sign up, sign on, start developing. All for free.
And you really can. It sports a WYSIWYG drag'n'drop form designer, a comprehensive smorgasbord of droppable widgets with property sheets, including layout containers and integrated jQuery Mobile UI components, and an embedded Javascript IDE within the browser. (It really reminds me of an online Visual Studio-like IDE for HTML5 and Javascript mobile apps.)
The big advantage of all this is that you can develop and deploy in your favorite HTML5 browser without the need for a web server to host on.
And what's more, they claim to support desktop, tablet and phone all from the same app, using in-built adaptive layout strategies.
The widgets can even be bound to a datasource, either inherent to the Application Craft framework, or linked to a SQL database on a different server.
Application Craft does have a monetizing model based on number of developer accounts, data storage and bandwidth.
New features are server-side javascript modules and file-based data sources.

My Take
One of the things that impressed me about this framework is that it has the potential to get prototypes and proof of concept apps up and running at virtually no cost.
I have a couple of pet projects I'm working on that are well suited to this. One is completely green-field and the other is a mobile version of an existing web site with its own database backend.
I found the online documentation quite comprehensive, if a little thin, and the many short video tutorials are very helpful to get you started, but are really just feature explanations with examples. A real step by step tutorial would be very helpful.
The online forums are worth using. The AC team is very responsive and will often offer to diagnose an app that you're having problems with if you're willing to share your password with them, or seem more than willing to do a Skype session with you to talk you through an issue. It's obvious they care about their product. However, I do wonder if it takes off, whether they will be able to keep this level of customer care up. For now, though, it's fresh air for early adopters.

It's clear that the AC team has covered their bases - there are ways to preview populated forms instantly in the IDE, run your app in Live mode on the desktop. There are plenty of hints and tips in the documentation on how to test out your app in desktop phone simulators and to set it up for debugging.
And because this is all hosted, if you happen to have an iPhone or iPad laying around, it's easy to test it out on the real thing.
AC also support wrapping with PhoneGap as a service if you really want your warez on the App Store or Google Play (the store formerly known as the Android Market).

All of this may seem too good to be true. Well, I can assure you it's all true, but it's an ambitious product, and there are definitely some rough edges. After playing with it for a couple of weeks, here's the good, the bad and the wish list:

The Good

• The Javascript IDE is almost as good as day-to-day coding in Eclipse. It has themes, a level of context sensitivity
• It's built on jQuery and jQuery Mobile, and so both of these libraries are available for your use if you know how to use them.
• The layout containers make it really easy to construct a well-behaved UI. Combined with the adaptive layout rules, you really can make a one size fits all UI, if you have the patience.
• An impressive set of UI widgets with the ability to add custom widgets of your own make or from third parties.
• Ability to create multiple apps within your console and have them up and running on your own application craft sub-domain in no time.
• Being a hosted end-to-end IDE, you can develop on one PC and pick up where you left using any other.
• A built in security model to ensure your developments stay private until you're ready to release them to the world.

The Bad

• Many web developers are used to tweaking styles and CSS to adjust the look of their apps. AC all but alienates you from that. Not good.
• Application Craft's data storage is a good idea but really badly implemented. It's cumbersome and too complicated for anything but the very simplest of apps. I got the feeling that this was just an experiment that went wrong. Try to build out a data model using the AC system and you'll soon be tearing your hair out wondering where the productivity gain is. AC would do much better to recommend that users find a free database hosting service and link it up to the AC front end, instead of implying that they have a fully integrated solution.
• I'm still not really sure how customizable AC is, unless you're game to create custom widgets to fit into their framework. I get the impression that if you step outside the walled garden, you're going to wish you hadn't strayed.

The Wish List

• The AC API has quite a bit to be desired. It's quirky and overloaded, and has some annoying idiosyncrasies and inconsistencies. It could really do with a clean up by someone who has, well, developed an API intended to be used by other developers. It is a high level API and pretty powerful. However, when AC says you'll be programming in javascript, you'll really be programming in their version of event driven javascript, with a few lines of jQuery for the informed.
• True fixed headers and scrollable panels. The true fixed headers are promised with a near future integration with jQuery Mobile's updated widget set. The absence scrollable panels is more obvious when you upsize your app from phone-size to more complex pad-sized layouts.
• It would be nice to develop AC apps on iPad and iPhone devices on the go. Unfortunately the advanced AC IDE tools only seem to run inside modern desktop browsers.
  

Conclusion
I was able to get things done in AC, but not without several failed experiments and lots of property tweaking. Without a good understanding of HTML I'm not sure if I'd have made it without giving up. I'm not sure that it's really quite ready for prime-time just yet, but for getting a free hosted prototype hooked up to an online database it definitely has some merits.
Application Craft holds a lot of potential in its hands. I wish them good luck in reaching it as they round out and refine out the service.

Apple announces iPad 3, 1080p Apple TV, iOS 5.1

Apple is bring Siri to the Japanese in iPhone iOS 5.1
Apple TV is now 1080p interface and movies, with updated UI and photo streaming.
iPad 3 (not iPad HD as some had speculated):

• Retina display is 2048x1536 pixels. Over 3 million pixels.
• Dual-core A5X chip & new Quad-core GPU (claimed 3x faster than NVidia Tegra 3)
  
• 5MP Camera full-HD 1080p video
• Voice recognition & dictation (not SIRI)
  
• LTE hi-speed digital wireless (Verizon and AT&T in US; Rogers, Telus & Bell in Canada)
  
• Same pricing as iPad2

Biggest surprize is that a full-blown SIRI experience is NOT part of the initial iPad 3 launch. It will probably turn up in a future update.

Neither is any space-age haptic feedback feature...
Rumours were flying, but it seems that April 1st came early this year!

iOS is king... of HTML5!

Backs up what I have observed. Android has similar hardware specs, but is lagging terribly behind in its browser implementation:
HTML5 Game Performance: iOS Performs 3x Faster Than Android
(Thanks to my work colleague for sharing.)

Some advantages of HTML5

I just posted this on the jQuery Mobile forum. My motive to inform people on there that it's not all about performance. (And the sole purpose of this is to concentrate on the advantages. Before you flame me for being one sided, I recognize there are disadvantages and that there are many reasons to NOT go HTML5.)

"One of the primary drivers for adopting JQuery Mobile was flexibility in an uncertain world.
Todd, we realize there are many who are under the delusion that native simulation is achievable with HTML5, and I respect the reality check.


However, there are other major advantages of HTML5 adoption - let's not get hung up on the pure 'performance is king' topic. Please bear the following in mind, and don't lose sight of the fact that users of HTML5 frameworks will EXPECT to host them in native wrappers. I'm glad that you cited that it is a secondary aim of jQM to support the Hybrid model of deployment.


1. Flexibility
1a. Adaptability
2. Consistent looks across platforms
3. True cross-platform "write once run anywhere" potential
4. Future proofing
5. Fast track adoption of new platforms


1. Flexibility
Building in HTML5 gives them the option to deploy as a web app, support HTML5 off-site installation (i.e. install to home screen) or use a native wrapper solution to get into the app stores. There may be many reasons that a solution builder may not already know their deployment strategy, not least because they are unsure that they will be pass compliance with an app store's ever changing policies.
(My personal situation is a case in point - we deploy our HTML5 app on Android as a Hybrid but were unable to reach agreement with the AppStore, and so deploy for iPhone on a web server with the option to install as an HTML5 application.)


1a. Adaptability
Another strong potential has been mentioned above. The potential to reach across formats with one adaptable solution is a very strong one, even if it is not front and center of people's minds at the present time. Frameworks like jQM have the potential to change the face of tradition site design by adopting and supporting a unified, adpatable interface across phones, tablets, netbooks, laptops and desktops. The advent of touch gestures and interfaces has revolutionized even the way people now expect to use their mouse.


2. Consistent look across platforms
Whereas the platform providers recommend certain style guidelines for apps built for their platform, some companies also have their own standards of usage and l&f. HTML5 apps can be styled to the unified standards of the company, not the platform provider.


3. True cross-platform "write once run anywhere" potential
By doing an HTML5 app, I am writing to a cross-platform standard. I have one code base, and have the potential to reach many platforms. My alternative? Invest in teams to develop the same app multiple times, or make a decision that only certain platforms are important to me, and shun the others. 

4. Future proofing
So I have an HTML5 app. It doesn't work well on platform X. The trend towards HTML5 standard compliance means that someday it will work on that platform (and someday after that it may even work well!)


5. Fast-track adoption of new platforms
Getting my existing HTML5 app working on a new or future platform will be far less work than re-writing it in their proprietary native language. And if new providers are not on the HTML5 train, they might as well not be in the game.


I hope that the jQM team will realize that these are valid and achievable goals for HTML5 mobile developers, and decide not to leave anyone behind. We're passionate because we care!"

Overthrow - an attempt to repair scrolling regions on mobiles

The guys over at the jQuery Mobile project recently made me aware of the Overthrow initiative at Filament Group (the main guys behind jQuery) to resolve the internal scrolling issues being experienced on so many mobile devices:

Here's the blog post, which links to the project page: Overthrow project

I'm looking forward to the slaying of this dragon!

jQuery Mobile 1.1 fixed headers and footers

In general, jQuery Mobile's fixed headers and footers are a nice solution. Mobile browsers are getting better at supporting it properly with no visual artifacts, but they're still not all the way there.

Here's the jQuery Mobile 1.1 RC1 test page to try out your mobile devices:

http://jquerymobile.com/demos/1.1.0-rc1/docs/toolbars/bars-fixed.html

(Note that jQuery Mobile has disabled page zooming on pages with fixed headers and footers to suppress some crazy behaviour!)

Their solution is based on this suite of test pages by Brad Frost: http://bradfrostweb.com/demo/fixed/index.html

You can comment below if you find anything weird.

To my surprise, three Android 2.3 devices do very well, (Hallelujah!) and our iOS5 device supports it very nicely - well, that is until you allow the user to pinch-to-zoom the browser page content! (Controlled by an HTML header page directive.) Then some very weird things start to happen. On Android 2.3 it seems to forget that it knows how to do fixed positioning, and on iOS5 it's even more entertaining: the fixed header will move at a different rate to the page content, and when you hit the right extent of the page, the header actually moves in the opposite direction to the page text! Who knew the iPhone supported parallax scrolling effects!!!

And here's the really bad news, if you're still on iOS 4 (or earlier). Since this platform doesn't support fixed positioning well, the jQuery team decided to 'degrade gracefully'. Unfortunately they put the emphasis more on degrade than gracefully, and now iOS 4 doesn't support any type of fixed header and footer at all without putting the onus on the developer. The previous solution was to have the header and footer fade out during the page scrolling (since it would move with the page content during the scroll) and then fade back in when the scrolling was done (since the browser would correct the position of the fixed position elements once the user lifted their finger).

I pointed out to the jQuery Mobile team that their new degradation strategy was biased toward web pages and not web apps, since now iOS 4 users could not have toolbars at the bottom of the screen, only at the bottom of their content. What a bad user experience that is! It's now virtually impossible to position a navbar at the bottom of the screen, which to me defeats the object entirely.

It appears that they see my point and we will at least have a way of falling back to the 'old way' soon, even if it is through a plugin or extension library.

I actually think there's an even better option for iOS 4, and that's using a javascript scroller div like the iScroll component. We already use a scroller in our mobile app and it works just fine on iPhone, (with the exception of textarea controls which grab the swipe event overriding the scroller). It was Android that was the problem. (See previous posts.)