Dianne Hackborn rocked my world

I’ve been involved with HTML5 for a while, but heading into my last major project, I was on a team that was convinced that the mobile-verse was at a point where an HTML5 project could be implemented as a cross-platform approach for an app targeting both the iPhone Safari and the Android Webkit browser. Not that much of a “far out” line of thinking considering this is 2011 and smartphones are quite the pieces of hardware. Our surprise that this wasn’t the case, quickly turned to fear upon the grim discovery that while Android Webkit supported the HTML5 spec, the actual performance of its implementation is a totally different story.

Most of the Android developer community seems to be fully aware of the various performance problems of Android, but it feels like the “slowly simmering” feeling has started to reach a boiling point.

Dianne Hackborn penned a very descriptive G+ post as an attempt to separate the myths and truths behind Android’s rendering issues. However, instead of clearing the air, what ensued in the (highly interesting) comments is the voice of the Android developer community pushing for some real changes to the very architecture of the OS.

While Dianne makes several detailed points, the basic premise of her viewpoint is that “Android as-is is A-OK”. I can understand defending your work because you’ve been so close to it for so long, but I find this attitude is a little bit troubling.

As an aside to this interesting (and extremely technical) post, Dianne is a true heroine. Seriously.

Andrew Munn for the followup

To throw some kerosene into the mix, Andrew Munn, an ex-Google intern who is now working at Microsoft (huh?), publicly disagreed with a few of Dianne’s points and put together his own G+ post on the issue to explain his own view why the rendering performance on Android is laggy based upon his own Google experience.

Perhaps Andrew didn’t realize his post would go so viral within the community.

The original post of his is still up, but the community (along with Dianne herself) has responded with enough clarification to dispute several of Andrew’s explanations. While it was welcome to read his attitude of trying to “acknowledge” some deficiencies with the Android core design, and trying to spur discussion within the Android community, it really can’t be ignored that he’s moving to Microsoft. Probably to work on Windows Phone 7.5 and beyond.

Again, all very interesting and all pointing to realization that the current Android design has enough red flags to cause a lot of concern to its core developer supporters.

The Real Story – The community wants to help but is demanding change

Better and newer hardware equipped with Android 4.0 (aka Ice Cream Sandwich) has only begun to highlight the performance flaws instead of suppressing them. Perhaps some devices in the very near future will actually be amazing. Perhaps more CPU cores and / or memory will sweep under the rug the core architecture problems behind Android OS.

Perhaps not.

THEN there’s the problem with every Carrier who won’t provide OS updates to customers…but that’s another post.

Let’s focus now on how to break out of your shell in 2012 and / or explode out of the gate. I have planned lots of things of my own, but let’s pull in some help right now to get your mind thinking about it.

1. Chris Guillebeau has put together ‘The Tower’ : a manifesto on URGENCY and LEGACY to help you focus your precious time on developing what really matters to you. It’s free and will help set you on a path to change your life.

2. Dave Navarro, a long time successfull internet marketer, has put one of his best work’s up for sale this month: “How to launch the **** out of your ebook”.

Yes, ebooks are still popular, and yes they can still be quite successfull for you for getting a bit of money in the door while executing your vision. I’ve bought it myself, along with quite a few other “Dave” products, and it’s good.
Forget the “pie in the sky” type of marketing or advice, Dave brings a grounded plan to help you maximize your success.

3. Absorb as much Seth Godin as possible, if you’re not already doing so.

4. Head over to Chris Garrett’s website and grab his two, high quality, free ebooks. Chris’s material (excellent stuff) will help you figure out how to create better content than you do now, which is needed for nearly every web venture these days. To help you sell your creative products or goods, you have to find and resonate with the audience that will support you. Chris’s materials will help you out here.

5. Increase the activities that will help you, decrease the ones that won’t: Buy your spouse more flowers, talk to him / her more than you do now, spend less time on endless time sinks (of the “Lost” category) and more time with your kids. Instead of filling every moment of your time with social media, try to schedule mental vacations that are havens from technology itself. Trust me. By shifting around some of your perspective (even slightly), you can re-focus on your creative pursuits and goals with renewed energy.

To quote Jean-Claude Van Damme from Hard Target, “Work smarter not harder”.

6. Bonus tip : STOP BEING AFRAID TO ASK FOR MONEY – Most people I know when they first start on the path of selling their goods or services online, are afraid to ask for money. They are in business and trying to survive (maybe even make a tiny bit of profit), but somehow worry that by asking your audience for money your precious readers / audience will vaporize. They won’t.. As long as you take care of your people, as long as you treat every relationship as precious, people will stay and help support you.

Don’t get me wrong here. HARD WORK IS STILL REQUIRED, but focused hard work is more productive and will help you achieve the goals you want to set for 2012.

Plant your flag and build your empire

Depending on your specific development focus, these choices shouldn’t come as any surprise to you. Even though I’ve put this list together to help you choose the package or engine that is right for your project, it is by no means complete. For every commercial engine out there, there are thousands of hobby enthusiasts that have devoted their time to making their own mark on the world of game engines.

Please note: These are not “ranked” in any order or preference or even market viability (eg. how much you’ll make in return). They have all been used by game developers around the world to not only create games for sale, but for just plain having fun.

Update: Removed the Kanji Engine, as it’s been defunct and taken offline. Thanks to @Ken_Paulson for that.

Game Engines, Frameworks, Toolkits and Packages

• HTML5

  • ImpactJS
    
  • Construct2
    
  • LimeJS
    
  • EaselJS
    
  • Akihabara
    

• Flash / AS3

  • Flixel
    
  • FlashPunk
    
  • Push Button Engine
    
  • Sandy3D
    
  • Away3D
    

• Cross-Platform PC/Mac

  • BlitzMax
    
  • Torque3D
    
  • Torque2D
    
  • RPG Maker VX
    
  • Ogre
    
  • Irrlicht
    
  • C4 Engine
    
  • Unity3D
    
  • Truevision 3D
    
  • Haaf’s Game Engine
    
  • Simple DirectMedia Layer
    
  • XNA
    
  • Playground SDK
    
  • ShiVa 3D
    

Lately, I’ve been exploring a lot of work on the mobile platform, investigating some popular toolkits and UI libraries to see what can be accomplished.

A quick glance at the competition in this space, reveals a lot of interesting libraries. Because of my JQuery background, the first toolkit I gravitated towards is JQuery Mobile. I’ve been using since the early beta days, but recently the JQM team have announced the official 1.0 release.

The JQuery Mobile Approach

I’ve noticed that the mobile toolkits that are out there, take one of two approaches: they either work with existing page markup, or they take the opposite approach and work entirely within javascript. If you’re coming from a background of “typical” web application development, then I think you’ll find that working with JQuery Mobile is an easy fit.

JQuery Mobile operates by working with your page markup to convert / translate it into a “native looking” mobile application. You still use regular HTML5 markup, then JQM will rest on top of this to create the mobile-friendly app.

The basic page – Hello World

We’re just getting introduced to JQM, so let’s create a “Hello World” app. The common HTML5 application approach is to define all of our layout / pages within a single index.html.

<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
<meta name="MobileOptimized" content="width" >
<meta name="HandheldFriendly" content="true" >
<meta name="viewport" content="width=device-width, user-scalable=no, initial-scale=1.0, maximum-scale=1.0, minimum-scale=1.0">
<meta name="apple-mobile-web-app-capable" content="yes" />
<meta name="apple-mobile-web-app-status-bar-style" content="default" />

I don’t want to get into too many details on the META tags I’m using here at this time. I’ll go through them in the next post where I can provide more details. For getting this Hello World to work, the most important one is the viewport.

After META – load the CSS and javascript

After defining our META keyworks, we want to link to our JQM css and load up our JQuery and JQuery Mobile script libraries. The order of execution here is fairly important, as noted in the JQM documentation.

<link rel="stylesheet" href="http://code.jquery.com/mobile/1.0/jquery.mobile-1.0.min.css" />
<script src="http://code.jquery.com/jquery-1.6.4.min.js"></script>
<script src="http://code.jquery.com/mobile/1.0/jquery.mobile-1.0.min.js"></script>

Note: according to the JQM team, the 1.0 release is tailored / geared towards the use of JQuery 1.6.4. The JQM team haven’t had time to work with the newer 1.7 release, so keep that in mind if you should need some support from the community.

Next comes the Page markup

Finally now that we’ve loaded up our required CSS and Javascript library files, we can define the markup for our first application.

JQM relies on the use of the data-role keyword to define how a page should behave within JQM.

Our landing “page” for the mobile application is defined in the markup with data-role=”page”. If you have a multi-page application (as most mobile apps are), then JQM will automatically try to use the very first page as the landing content for the app.

<body>
<div id="home" data-role="page">

Now that we have our “page” defined in the markup, JQM allows us to seperate the structure into 3 sections: the header, the content and the footer. The Header section is our banner area at the top of our page. More often than not, this contains either a descriptive word or two for the page, or even some navigational elements such as buttons. For this basic app, we will just display Hello World.

<div data-role="header">
<h4>Hello World</h4>
</div>

Next we have our Content section of our page. Obviously, this contains whatever we want our application to do / show to the user; eg. the “meat and potatoes”.

<div data-role="content">
<p>Hi, this is the landing page of our mobile application! This is
in our content section.</p>
</div>

Finally in our Footer section of the page, we can again either display some navigational elements for the app, site taglines, etc. In this case, we’ll keep it simple and just display a basic copyright notice.

<div data-role="footer">
copyright 2011 erikyuzwa.com
</div>
</div>
</body>
</html>

And that’s all it takes to get started with JQuery Mobile 1.0. Enjoy!

See it in action

Point your mobile browser to http://www.erikyuzwa.com/demos/jqm1.0/hello-world/ or aim your QR Code reader:

• iUIiUI is a framework consisting of a JavaScript library, CSS, and images for developing advanced mobile webapps for iPhone and comparable/compatible devices. This is a popular lightweight toolkit for making your smartphone app look “iPhone-y”
  
• Sencha Touch – Sencha Touch allows you to develop mobile web apps that look and feel native on iPhone, Android, and BlackBerry touch devices.
  
• xui – xui is the smallest framework that works across all of the devices in the mobile landscape. it does not try and dictate a page structure or widget paradigm. instead, it uses the dom and since most mobile applications consist of lists and buttons, we feel, html and css do a fine job of rendering.
  
• jo – For iOS, Android, webOS, BlackBerry, Chrome OS & anything else with HTML5 Widgets, lists and scrolling goodness using JavaScript & CSS3 Make native mobile apps or web apps with the same code Works great with PhoneGap
  
• JQuery Mobile – A unified, HTML5-based user interface system for all popular mobile device platforms, built on the rock-solid jQuery and jQuery UI foundation. Its lightweight code is built with progressive enhancement, and has a flexible, easily themeable design.
  
• jqTouch – a JQuery plugin for mobile web development on the iPhone, Android, iPod Touch, and other forward-thinking devices.
  

There you have it. While this is a brief overview of the available possibilities that I’ve come across in projects, I’m sure there’s many out there that I haven’t seen yet.

Got a favorite? Tell me about it!

this is the minefield you're supporting

the image used in this post is from http://www.jessekunze.com

I came across this post by Red3 Software which discusses some of the frustrations behind developing an HTML5 based application on the Android webkit browser.

As I’ve stated in another (popular) post, the Android browser lies like a spider poised malevolently in its web, waiting for its next snack. DON’T LET YOURSELF BECOME THE NEXT MEAL.

Red3 brings up some fantastic discussion points which are worth any team debating before the decision is made to target Android browser for application development. Since they are summarized so succinctly, I’m just going to drop them in here..

• Reality check #1: The current Android browser is not Mobile Chrome. Remember – Google bought Android, they didn’t make it. It may pass the HTML5 compliance tests, but that does not mean to say it does it well. My experience with the Android browser is that it’s glitchy, inconsistent across devices and rough around the edges. For example, it’s rendering of CSS3 rounded corners is noticeably jaggy, and positioning of elements is often off by a pixel creating gaps where there should be none. (My suspicion is that Google are frantically re-implementing the Android browser to become the Mobile Chrome many think it is.)
• Reality check #2: All Androids (and their browsers) are NOT created equal. Manufacturers tweak the browser code too for their own purposes.
• Reality check #3: There are also certain commercial, political and legal reasons why things are different on different Android devices. Don’t believe me? Load up Google maps in the Android browser and try doing pinch to zoom on a 2.x HTC phone. Now try the same on a Samsung phone. The difference? HTC does not want to impinge on multi-touch patents, hence no pinch to zoom in the browser. (Samsung supports pinch-to-zoom. But they had to withdraw some devices in some countries because of patent infringement. Could there be a link?)
• Reality check #4: Just because it’s got it, doesn’t mean to say it flaunts it. Android devices have some of the most impressive hardware specs around. Multi-core processors, GPUs & gobs of memory. However, try panning Bing Map in the Android browser. Then try it on an iPhone. The difference: Android does not implement hardware acceleration in the browser rendering of elements, and it shows.
• Reality check #5: Even though it’s in the best interests of Google to improve Android fast (to live up to the expectations of its customers and become a truly viable competitor), this does nothing to rectify the myriad of broken/deficient devices that are already out there. And even when they do fix the Android reference build, how will they enforce standards on an ‘open’ community who will continue to tweak the core to meet their own agendas?

Well summarized. I would add that as more teams embark on HTML5 development on Android, they will quickly be forced to eat the time spent and back pedal to either a native solution or to just target iOS for HTML5.

If Google doesn’t step in and begin to enforce standards to the manufacturer, it’s own brand will suffer the consequences as more and more Android units of various quality floods towards the unsuspecting consumer.

What are your thoughts?

I’ve been doing a lot of work recently with an HTML5 application targeting the Android webkit browser, and I’ve come up with a few reasons why this was the best possible move that Adobe could have made even with the warning that the journey ahead will be difficult for both Adobe and HTML5 app developers.

1. Android support is a nightmare – The initial “selling point” of Android is its’ greatest weakness. Without having any control over the vendors, there are a ton of Android units shipping which are completely sub-par and a ripoff to the consumer. Then there’s other devices which support certain features quite well, and others at only a mediocre level.
2. Android Webkit cannot be trusted – Because of our first point, there is no control over the Android webkit browser implemented provided by each vendor. I discovered quite quickly that “standard” webkit CSS isn’t nearly the same from device to device and/or vendor to vendor. This situation makes it impossible to develop for.
3. Cheap Android units combined with broken webkit – The situation created by Android has created a complete Black Hole for any browser plugin developer. With a lot of subpar Android units flooding the market, combined with a browser using a wide mix of spotty support for webkit would decimate Adobe’s support staff as they try to handle the massive load of consumers screaming for help
4. HTML5 is rock solid on iPhone Safari – If we take a step back for a minute from the whirlpool of Android, I can say with real experience behind me, that HTML5 support on iPhone Safari is quite simply amazing. Perhaps I may one day come across some CSS / HTML markup which will misbehave on Safari, but I haven’t yet. Being able to get onto the iPhone / iPad will definitely help boost Adobe.
5. Windows Phone 7.5 – Yes this point is pure speculation, however, there is a lot of (growing) evidence out there that HTML5 support on the Windows Phone 7.5 is just as amazing as the Safari experience on the iPhone.

Now some of you might be thinking that I’m an Apple Fanboi or “Anti” Android. Not true at all. Based on my experiences with the platform, if I needed to develop an Android solution, it would be 100% Native. I would never touch the Android browser, and I’m writing these ideas to help others from making that painful journey.

What are your thoughts?