If you haven’t seen it yet, app-UI is a collection of reusable “application container” components for building native-like mobile experiences for apps built with web technologies.   It is still in the very early stages of development, and I’m actively working on it… so please let me know if you run into any issues or suggestions.

I scoured through all of my application and framework code, but just couldn’t seem to figure out why/where event listeners were being removed.   What I needed to do was simple, figure out where “removeEventListener” was being invoked.  “removeEventListener” is a native function, so you can’t set a breakpoint to see every instance where it is being invoked, right?

Actually, you can, but you have to look at the problem just a bit differently…

You can’t set a breakpoint on a native function, however, since JavaScript uses prototypal inheritance you can change the prototype of an object to change its behavior and override native functions.  Since you can modify an object prototype, changes to that object’s prototype will be applied to all instances of that object type.   So, you can add some debugging code to override the behavior of HTMLElement’s “removeEventListener” function.

First, make a copy of the original removeEventListener function on the HTMLElement.prototype:

HTMLElement.prototype.originalRemoveEventListener
        = HTMLElement.prototype.removeEventListener

Next, override the original removeEventListener function, add a console.log() statement, and then invoke the original removeEventListener function that you just made a copy of:

HTMLElement.prototype.removeEventListener = function(type, listener, useCapture)
{
    console.log('remove: ' + type);
    this.originalRemoveEventListener(type, listener, useCapture);
};

Now, every time that the HTMLElement’s removeEventListener function is invoked, you will get a console.log() statement.  Not only do you get console debugging, but you can now set a breakpoint inside of the new, overridden, removeEventListener function.   Using the breakpoint, you can use your developer tools to view the call stack and track down where the removeEventListener function is being invoked. Thus, you can track down the root of your issue.  I use the Chrome developer tools, but similar tools are also available in Safari, FireFox, IE, and Opera.

Using the call stack, I was able to track down that I was inadvertently calling jQuery’s remove() function on the view’s DOM element, instead of jQuery’s detach() function.  Both remove() and detach() will remove your elements from the page’s DOM, however remove() also gets rid of any event listeners to prevent memory leaks. When I made the one-line code change from remove() to detach(), everything resumed working as expected. I then removed the debugging code.

Here’s the complete code in one snippet for overriding removeEventListener:

HTMLElement.prototype.originalRemoveEventListener
        = HTMLElement.prototype.removeEventListener;

HTMLElement.prototype.removeEventListener = function(type, listener, useCapture)
{
    console.log('remove: ' + type);
    this.originalRemoveEventListener(type, listener, useCapture);
};

Prototypal inheritance gives you the ability to change the behavior of objects at runtime, and it can be incredibly powerful in building your HTML/JS applications.

Many of the questions were around the roadmap for PhoneGap/Cordova. You can access the PhoneGap/Cordova roadmap at: http://wiki.apache.org/cordova/RoadmapProjects

Feel free to post any additional questions, and stay tuned for the next open session.   If you have any feedback on how we could improve this session, please let us know!

The “Silver Bullet”

First, the “Silver Bullet” argument… I have never seen it stated anywhere that PhoneGap is a “Silver Bullet” that will solve every problem for every application developer.   PhoneGap is a tool for developing applications.  It enables developers to build applications in situations where they may not have otherwise, including:

• No knowledge of native development
• Existing web development skills
• Reuse of assets across platforms or leverage existing code/assets
• Lower barrier of entry in the mobile app world

PhoneGap isn’t a “magical” solution to end all other solutions.  It is a toolset that enables you to build & bundle natively installed applications using web technologies.  For more detail on what exactly PhoneGap is, see this post “PhoneGap Explained Visually“.  If you’d like to understand the motivations behind PhoneGap/Cordova, then look no further than the PhoneGap blog.

If you were building a house, would you use a butter knife to drive nails?  Or, would you use a sledgehammer for finishing touches? If you needed lumber for your house, would you go cut down a tree, cut some beams out of it for use in your house frame?  No, You wouldn’t do any of these.  You would use the right tool for the job, and you would use raw materials that you already have available or are easily accessible.

Chances are, if you are building an app, you would do the same thing.  There are cases where PhoneGap is not the best choice, but that does not mean there aren’t a huge number of cases where PhoneGap is a great choice (if not the best).  It does not make sense to have to rebuild everything from the ground up, or have to learn completely new skills just to build apps for a mobile platform.

Increasing Complexity

The article also makes claim that HTML/JS based apps are more complicated than native apps:

At first things are easy. For simple screens, using a webview might be faster than writing a native implementation. As you add functionality to the webview, the complexity increases until you give up and write everything native.

This is far from the truth.  There are 2 facts that are completely overlooked in this statement:

1. You can write a “bad” or overly-complex application in any langauge.  Native development is not a silver bullet that prevents you from building “Bad” apps.
2. Native applications can also be extremely complicated – they are not inherently more simple.

Regardless of the underlying technology, the more features, views, data models, and components that you have within an application will add to the overall complexity of that application.  This is precisely why people apply model-view-controller (MVC) development paradigms and software design patterns.

PhoneGap and hybrid/web development techniques are no exception to this rule.  You can create really simple apps very quickly without a high degree of computer programming skill, but creating complex applications requires real software development processes.  MVC, abstraction, encapsulation, separation of concerns, etc… all apply.  You can absolutely build complex applications with web technologies, but you must approach them in a structured manner – just as you would approach an enterprise-quality native application. If you do not approach a complex problem with proven software design principles from the beginning, you risk setting yourself up for failure regardless of the underlying technology.

I have significant experience in developing native applications, interactive development, HTML/JS, as well as developing with cross platform technologies.  Based on my own experience, I am far more productive with HTML & JS/PhoneGap than I am with native development, and I can create applications that are just as complex.

That does not mean everyone will be the same as me.   A developer who comes from either the Objective-C or Java worlds and does not know HTML will likely be more productive with native development – once they learn the libraries and paradigms for native mobile development. Likewise, developers who are already proficient with interactive development for the web will be more productive using web technologies.  One cannot make generalizations about a software tool or productivity when the use cases and developer skills are so widely varied.

The Framework Tax

The article makes the claim that you end up paying a “tax” by using frameworks such as PhoneGap:

You could use an open source shell-app framework like PhoneGap, but that leaves you at the mercy of their schedule. If the native platform introduces a new API, or you run into an edge case that requires extending the shell framework, it could be months before you can implement your own app’s functionality.

Again, this is not entirely accurate.  The goal of PhoneGap is not to recreate & mirror every native API on every platform.  Rather, to provide a consistent API for building your applications across multiple platforms, using familiar web development skills, and to push the web forward.   There are certainly APIs on all platforms that it does not support.

Luckily, PhoneGap is built on top of an extensible architecture, so that if you wanted to take advantage of a new API, you can create your own native plugins (yes, in native code) to expose that functionality for use within your PhoneGap applications.  If you do not want to wait on the PhoneGap/Cordova open source initiative, then you can build it yourself without delay.  You do not need to fork the framework for this, rather you extend it within your own projects.   There’s also a good chance that someone has already written a native plugin and posted it on github that you can reuse.

Browser Fragmentation

Well, you have a point there… to a point. There are definite browser fragmentation issues.   Webkit on iOS != Webkit on Android != Webkit on BlackBerry != IE/Trident on Win Phone, etc…  However, this is generally related to presentation styles, not core browser functionality.  It is important to use tools like caniuse.com when you are evaluating your development strategy and modernizr during implementation phases (for graceful degradation).  While there are variations in the browsers, it doesn’t mean that your architectural patterns, your business logic, or your data model are going to be different.

Different browsers on different platforms also have different performance metrics, and you need to build your application experience based on what you are trying to create. Do not try to force a slow browser to be fast; that will never work.

Versioning

The versioning argument in that article sates “hybrid apps allow you to update” is not entirely true:

Shell app let you update content without requiring a full app release by serving your pages off a server. In the process, you lose release atomicity, the assurance that whatever you ship to clients comes in one complete, unchanging bundle.

Yes, you can serve web pages, and if you have native content around the web content, then it could be mismatched.  However, it is important to understand that you can’t create apps with HTML technologies that update their own code withinin the local app bundle on the device based off of code downloaded from a server.

If you build an app that bypasses Apple’s App Store and updates itself automatically, it will get rejected.   You may be able to pull down data/content or images and cache them locally, but a “full app release” is not possible.   The Apple Developer Agreement explicitly says in section 2.7:

“Apps that download code in any way or form will be rejected“

Likewise, “Users may wait weeks or months to update apps” applies to native development as well. If your users don’t update, then they don’t update.  In this case the mobile branding may not match the website branding.  This happens regardless of technology choice.

The Uncanny Valley

There is merit to the uncanny valley argument (html based apps don’t always feel “right”), but that does not mean it is impossible to build native-feeling applications using HTML and JavaScript.  The trick is that you must design these apps to feel like applications, not like web pages.  Here are a few apps that are built using HTML-based technology: Apple Store, Facebook, LinkedIn, Wikipedia, Mafia Wars, US Census Browser, Bit Timer, Untappd, and even the “revolutionary” iAd advertising experience from Apple are all built on top of HTML.  (This is by no means a definitive list of all HTML-based apps either.)

Some of these apps you might already use on a daily basis. The “uncanny valley” argument really comes down to UX design, and giving your HTML application a first-rate experience.  If you do not invest in your user experience, it will not feel right.  Some of these apps show up in Apple’s recommendation lists… would Apple recommend bad apps to us in the “walled garden” that they have worked so hard to curate?

Performance

Again, this is a question of using the right tool for the right job.   You would likely not build a 3D modelling application using HTML/JS, but you could easily build a word game experience, an enterprise data reporting front-end client, or content-centric experience using HTML & JavaScript.  There are things that you need to do to make sure your HTML-based experiences perform well, such as using touch events instead of mouse events (mouse events in web views can have an OS lag up to 3-400 MS, where touch events do not).  Or, using CSS3 translate3D transforms to enable GPU-rendering on DOM content. Perception of an application boils down to creating a proper user experience.  You can absolutely create a great user experience with HTML & related technologies, but I wouldn’t use it for super-computing tasks.

If your app requires intense data crunching for a computationally intensive task, you can always drop down to a PhoneGap native plugin to perform the heavy lifting for you.

Write Once, Run Everywhere

When was the last time you saw a computer or device that could not render HTML content?   I have several devices at my disposal for work: 3 Android devices, 2 iOS devices, 1 Windows Phone, 1 Blackberry, and a Macbook.  None of these devices is incapable of rendering web content.  HTML is the most widely distributed and pervasive means of presenting digital information in a visual manner, and it has been around for decades.

The Right Tool

As mentioned in the original post, use the right tool for the job. Don’t force a solution that doesn’t fit, but also don’t over-generalize your technology decisions based upon incorrect assumptions. I can build a responsive layout with dynamic content far easier in HTML than I can in native Objective-C, but building a triple-A quality game isn’t even close to achievable in HTML. It all depends on context:

• What are you trying to build?
• Who are you building it for?
• What are the UX requirements?
• Who is building it, and what are their skills?
• What is your budget?

There is no doubt or question in my mind – You can absolutely build incredible app experiences that truly feel like apps using web based technologies.

I’ve been focusing on multi-platform HTML-based solutions, especially with the app-UI framework/library.  Shadow has become very handy when testing features on multiple devices.  App-UI is a free & open source collection of reusable “application container” user interface components that may be helpful to web and mobile developers for creating interactive applications using HTML and JavaScript.

Basically, I just point the desktop Chrome browser at the page I want to test on my devices, and all devices will navigate to that particular page.  Quick, easy, and to the point.   Check out the video below where you can see the synchronized browsing experience in action.

In my examples that have browser history integration you can even see that selecting an item in the list causes all devices to navigate to the selected item (starting at 25 seconds into the video).  It does not yet necessarily solve every issue around button clicks and scrolling, but it certainly helps streamline the testing of a single page/experience on multiple devices.

Enjoy!

1. PhoneGap is great for rapid prototyping.
2. Don’t limit yourself to a prototype! PhoneGap is awesome for building real-world production applications targeting multiple platforms!

You can check out my presentation here:

• Rapid Prototyping with PhoneGap.pdf

Some reasons why you might want to use PhoneGap for rapid prototyping:

• It’s easy
• More people know HTML & JS, over native development
• Lower barrier of entry in mobile development
• Integrate seamlessly with HTTP services
• It can cost less & can get done faster
• Reduced developer hours + web designers can build the prototypes
• Less development effort = faster turnaround

Here are the real-world PhoneGap apps that I demonstrated:

Wikipedia Mobile - The official mobile application for wikipedia.

• iOS: http://itunes.apple.com/us/app/wikipedia-mobile/id324715238?mt=8
• Android: https://play.google.com/store/apps/details?id=org.wikipedia&hl=en
• BlackBerry Playbook: http://appworld.blackberry.com/webstore/content/105171

Halo Waypoint – Companion application to the Halo game for Xbox & Xbox Live.

• iOS: http://itunes.apple.com/us/app/halo-waypoint/id468457600?mt=8
• Android: https://play.google.com/store/apps/details?id=com.halo.companion&hl=en

Untappd – Social networking with beer.

• iOS: http://itunes.apple.com/us/app/untappd/id449141888?ls=1&mt=8
• Android: https://play.google.com/store/apps/details?id=com.untappdllc.app

US Census Browser – Visualizing data from the 2010 US Census

• iOS: http://itunes.apple.com/us/app/census-browser/id483201717
• Android: https://play.google.com/store/apps/details?id=com.tricedesigns.CensusBrowser

I covered techniques for making your apps feel like “apps”, not “web pages”.   You can read more about these techniques and useful libraries in my recent post on Multi-Device Best Practices.  Note: That post contains references to both Flex and HTML/JS/CSS tools.  In this presentation I focused only on the HTML/JS/CSS tools.

I also covered techniques for data visualization.   You can read about techniques for visualizing data using web standards technologies, and see serveral HTML/JS data visualization libraries from my recent post on “Data Visualization with Web Standards“.

In this presentation, I covered PhoneGap Build, a cloud-based compilation tool for PhoneGap apps, and debug.phonegap.com for remote application debugging.   I also covered iWebinspector for debugging PhoneGap experiences inside of the iOS Simulator.

Let’s also not forget the real-world companies that have invested in PhoneGap/Apache Cordova, including Wikipedia, Facebook, Salesforce, IBM, and others.  You can read more about these companies from my recent post “Who Uses PhoneGap“.

• Web-Standards-Data-Viz.pdf

Basically, there are 5 general ways to visualize data using web-standards techniques – here is a brief overview with pros & cons:

<img>

You can embed images using the html <img> that have server-rendered data visualizations. This is nothing new… They are very basic, but will certainly work.

• Not interactive
• Requires online & round-trip to server
• No “WOW” factor – let’s face it, they are boring
• Example: Google Image Charts

HTML5 <canvas>

You can use the HTML5 <canvas> element to programmatically render content based upon data in-memory using JavaScript. The HTML5 Canvas provides you with an API for rendering graphical content via moveTo or lineTo instructions, or by setting individual pixel values manually.  Learn more about the HTML5 canvas from the MDN tutorials.

• Can be interactive
• Dynamic – client side rendering with JavaScript
• Hardware accelerated on some platforms
• Can work offline
• Works in newer browsers: http://caniuse.com/#search=canvas

Demos:

• Rgraph – Open source charting library using HTML5 <canvas>
• Examples
• “One Million Points” Scatter Plot – Let the page load, then use the mouse to click and drag regions to “drill into”.   This is a live visualization that shows a scatter plot with a histogram for massive data sets by manipulating individual pixels.
• Demo with 50,000 data points
• Demo with 1,000,000 data points
• Source code
• “Lil Doodle” iOS App.  This is not data visualization, just shows you programmatic drawing using HTML5 Canvas.

Vector Graphics (SVG)

Vector graphics can be used to create visual content in web experiences.

• Client or Server-side rendering
• Can be static or dynamic
• Can be scripted with JS
• Can be manipulated via HTML DOM
• Works in newer browsers (but not on Android 2.x and earlier): http://caniuse.com/#search=SVG

Demos:

• “US Census Browser” – multi-platform PhoneGap application showing enterprise-class data visualization using web standards techniques.
• D3.js data visualization framework
• Raphael.js data visualization framework
• HighCharts data visualization libarary
• Sencha Touch Charts
• Kendo UI DataViz

HTML DOM Elements

Visualizations like simple bar or column charts can be created purely with HTML structures and creative use of CSS styles to control position, visual presentation, etc… You can use CSS positioning to control x/y placement, and percentage-based width/height to display relative values based upon a range of data.   For example, the following bar chart/table is created purely using HTML DIV containers with CSS styles.

WebGL

WebGL is on the “bleeding edge” of interactive graphics & data visualization across the web. WebGL enables hardware-accelerated 3D graphics inside the browser experience. Technically, it is not a standard, and there is varied and/or incomplete support across different browsers (http://caniuse.com/#search=webgl).  There is also considerable debate whether it ever will be a standard; however there are some incredible samples out on the web worth mentioning:

• WebGL Globe
• Global Temperature Anomalies
• Realtime Color Histogram

Feel free to leave a comment with any questions.
Enjoy!

• Multi-Device-Best-Practices.pdf

First, I gave an overview of mobile & multi-platform with AIR and PhoneGap.  See these links for more detail on the platforms:

• What is PhoneGap
• Multi-platform development with AIR
• Why cross-platform development?

Next, I emphasized the differences in user experience, display density, usability, and application style/feel between different platforms and device form factors.  You can read more detail on these topics here:

• Flex/AIR: Device form factor detection
• Device form factor detection in PhoneGap (example project):

I also covered various libraries and techniques for making your creations feel like “native apps” instead of “web pages in a container”, and ways to make your apps look & feel “more native” for a given platform.

Details on Flex/AIR-specific tools & frameworks for native-like app experiences:

• Platform specific styles via CSS media queries
• Eskimo framework for platform specific styles
• Flex Code Samples (FXP)

Frameworks/Libraries for HTML/Web/PhoneGap, for “app-like” experiences:

• Twitter Boostrap
• Zurb Foundation
• iUI
• jQuery Mobile
• jQuery UI
• Sencha Touch
• Kendo UI
• App-UI
• iScroll
• Moobile JS

Feel free to leave a comment with any questions.
Enjoy!

The problem:

I have a horizontal slider (custom HTML/JS) component, and content within a separate HTML <span> should be updated when the slider value changes. The JavaScript seemed to be working properly, I could see console.log output that showed events were being dispatched, but the UI wouldn’t display what I was seeing in the debugging tools. Instead, the UI would update sporadically with a value, but not consistently, and not for every time that I updated the HTML DOM.

The solution:

Set the CSS “display” property on the <span> element to “inline-block”, and everything works properly. This was a really strange issue since I could see the HTML DOM updates, but the actual UI wasn’t being updated.

If my description doesn’t seem to be making any sense, check it out in the video below.   Keep an eye on the HTML DOM structure, as well as the rendered output.

Unfortunately, it took way longer than I would have hoped to fix such a seemingly simple issue.   Hopefully this saves you some time if you run into it too!

Version 2.0 is currently available for:

• Apple iTunes: http://itunes.apple.com/us/app/census-browser/id483201717 (powered by phonegap)
• Android: https://play.google.com/store/apps/details?id=com.tricedesigns.CensusBrowser
• The Web: http://tricedesigns.com/census/  (modern browsers only)

Version 2.0 of the US Census Browser has some substantial changes, including:

• Completely new & redesigned UI layer, using app-UI.  app-UI is an open source framework for application view-navigators that mimic native mobile applications.   Using the app-UI SplitViewNavigator, the US Census Browser now supports both landscape and portrait orientations.
• Switched from Google Maps to Open Street Map using OpenLayers.  Users of the Census Browser maxed out my Google Maps account!  That is 25,000 map loads within a 24 hour period! WOW! I switched to the free Open Street Maps solution, which doesn’t have any usage/bandwidth limitations.  With this change I was also able to add interactive maps.
• Updated to Twitter Bootstrap 2.0.  The app is now using new UI styles and components which are now available in Twitter Bootstrap version 2.0

The source code for the US Census Browser has also been updated on github: https://github.com/triceam/US-Census-Browser

To learn more about app-UI, check out my page here: http://www.tricedesigns.com/2012/04/24/introducing-app-ui/

Enjoy!