Tuesday, 20 March 2012
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
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.
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...
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.
Monday, 19 March 2012
The premise is this:
Sign up, sign on, start developing. All for free.
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.
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:
- 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.
- 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.
- 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.
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.
Wednesday, 7 March 2012
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!
Tuesday, 6 March 2012
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.)
"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.
2. Consistent looks across platforms
3. True cross-platform "write once run anywhere" potential
4. Future proofing
5. Fast track adoption of new platforms
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.)
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!"