En nuestro quinto episodio, abordamos los siguientes temas:

1- Historias destacadas de la semana

a- Adobe Creative Suite (CS6) ya está disponible. Primeras impresiones: descargas rápidas de aplicaciones, instalación sin problemas y versión para PC/Mac.

b- Post: “The New Articulate Storyline iPad App and mLearning” Artículo, demo y 2 videos.

2- La Comunidad de Articulate: la importancia de la asistencia y la colaboración.

3- Articulate Storyline: funcionalidades destacadas (gráficas de personajes, objetos interactivos, capas de diapositivas, estados, grabación de pantalla, adaptación de la presentación de contenidos, posibilidad de crear y traducir proyectos en distintos idiomas, etc) y algunas limitaciones.

4- Articulate Storyline vs. Adobe Captivate.

5- La historia para el aprendizaje móvil que propone Articulate Storyline y desafíos para el futuro (SCORM, seguridad, etc)

In this article, I describe a simple data synchronization strategy that uses the device’s (or browser’s) SQLite database. The implementation currently leverages the Web SQL API (even though the W3C is no longer actively maintaining the spec) because both iOS and Android support it, but they don’t support IndexedDB, the official alternative. However, the API described below — getLastSync(), getChanges(), applyChanges() — defines a generic synchronization contract, and the solution can be expanded and made “pluggable”: You could create different synchronization objects, each providing a different implementation of these methods. You could then choose which object to plug in based on the context and the platform your application is running on.

Try it in the Playground

Before looking at the code, you can try some offline syncing in this a hosted playground:

1. Open the Offline Client Playground in Chrome or Safari (they both support Web SQL).
2. Click the Synchronize button.
3. Look at the log (the textarea in the middle of the screen): Because it’s the first time you use the application, all the employees have been downloaded from the server and inserted in your local SQLite database.
4. Clear the log, click the Synchronize button, and look at the log again: because you now have an up-to-date local version of the data, the server didn’t return any change and your local database remains unchanged.
5. In another tab, open the Server Admin PlayGround.
6. Modify an existing employee and click Save. (Don’t worry, it’s using your own session-based data set).
7. Go back to the Offline Client tab, click Synchronize, and notice that the server returned one change, and that it was applied to your local database.
8. Go back to the Server Admin tab and modify (create, update, delete) other employees. Switch back to the Offline Client tab, click Synchronize, and see how these changes are applied to your local database.
9. You can also use the Resources Tab in the Chrome Developer Tools to inspect your local database.

Server API

The only piece of infrastructure you need at the server side is an API that returns the items that have changed (created, updated, or deleted) since a specific moment in time expressed as a timestamp.

Here is the RESTful API call used in my application:

http://coenraets.org/offline-sync/api/employees?modifiedSince=2012-03-01 10:20:56

The format of the data returned by the server is up to you and is part of the contract between the client and the server. In this application, the server returns the changes as an array of JSON objects. The server-side technology (RoR, PHP, Java, .NET, …) and database system (SQL, NoSQL, …) you use to generate the list of changes is also totally up to you. I provide a simple PHP implementation as part of the source code. That implementation manages a session-based data set that provides an isolated and transient playground. In a real-life application, you’d obviously get the data from some sort of database.

Client API

At the client side, our synchronization API consists of three methods.

getLastSync()

A method that returns a timestamp to be used as the query parameter for the next synchronization request. A common practice is to persist a timestamp after each synchronization request. But things can go wrong and the timestamp itself can get out-of-sync. I prefer to “recalculate” the lastSync timestamp before each synchronization request.

getLastSync: function(callback) {
    this.db.transaction(
        function(tx) {
            var sql = "SELECT MAX(lastModified) as lastSync FROM employee";
            tx.executeSql(sql, this.txErrorHandler,
                function(tx, results) {
                    var lastSync = results.rows.item(0).lastSync;
                    callback(lastSync);
                }
            );
        }
    );
}

getChanges()

This is a wrapper around an Ajax call to the server-side API that returns the items that have changed (created, updated, or deleted) since a specific moment in time defined in the modifiedSince parameter.

getChanges: function(syncURL, modifiedSince, callback) {

    $.ajax({
        url: syncURL,
        data: {modifiedSince: modifiedSince},
        dataType:"json",
        success:function (changes) {
            callback(changes);
        },
        error: function(model, response) {
            alert(response.responseText);
        }
    });

}

applyChanges()

A method that persists the changes in your local data store. Notice that SQLite supports a convenient “INSERT OR REPLACE” statement so that you don’t have to determine if you are dealing with a new or existing employee before persisting it.

applyChanges: function(employees, callback) {
    this.db.transaction(
        function(tx) {
            var l = employees.length;
            var sql =
                "INSERT OR REPLACE INTO employee (id, firstName, lastName, title, officePhone, deleted, lastModified) " +
                "VALUES (?, ?, ?, ?, ?, ?, ?)";
            var e;
            for (var i = 0; i < l; i++) {
                e = employees[i];
                var params = [e.id, e.firstName, e.lastName, e.title, e.officePhone, e.deleted, e.lastModified];
                tx.executeSql(sql, params);
            }
        },
        this.txErrorHandler,
        function(tx) {
            callback();
        }
    );
}

Synchronization Logic

With these server and client APIs in place, you can choreograph a data synchronization process as follows:

sync: function(syncURL, callback) {

    var self = this;
    this.getLastSync(function(lastSync){
        self.getChanges(syncURL, lastSync,
            function (changes) {
                self.applyChanges(changes, callback);
            }
        );
    });

}

Final Notes

• This solution currently supports unidirectional (server to client) data synchronization. It could easily be expanded to support bidirectional synchronization.
• This solution currently implements “logical deletes”: items are not physically deleted from the table, but the value of their “deleted” column is set to true.
• As mentioned above, you could replace the Web SQL implementation with another data access strategy. For example, take a look at Brian Leroux’ Lawnchair for another local persistence solution.

Source Code

The source code is available in this GitHub repository.

The trick is, once you select that option a project is created and opened just fine, but you MUST actually Run the application first to cause the special www folder (specific to PhoneGap projects and containing the main .js file PhoneGap needs to work) to be created in the same folder as the .xcodeproject file just created.

The instructions do mention executing the project and that you will get an error at that point, but don’t make it entirely clear that the important www folder will actually be created at that step. If you’re like me, you might decide to skip that instruction because you know it’s not going to work yet anyway since PhoneGap needs the www folder copied in. Yes, I can admit I did this the first time . Then you will probably try to follow the rest of the instructions to copy that www folder in and find that it’s not there. My personal assumption when I did this the first time is that the www folder was getting created for me when I selected the new Cordova-based Application option. Now that I have more experience, I can see how you may not ALWAYS want that www folder created upon project creation, such as the case where you are copying an existing one in, however I will have to follow-up more on this to see if there are changes coming in this workflow.

To illustrate, after creating your Cordova-based Application in XCode, if you right click on the root of the project in XCode and say Show in Finder, you will see this:

But after you actually Run the project in XCode and receive errors, then stop and right-click again on that root project in XCode to Show in Finder, you will the www folder was in fact created and is ready to copy in to XCode:

If you’re a developer that has run into this yourself (not one of those that always follows specific directions and never makes ANY assumptions ) then I hope this helped you quickly get to the bottom of it .

NOTE: This is specific to creating a brand new project, not porting over an existing www folder that already had the necessary contents where there is no need for a default one to be created.

It has really become very easy to create seamless repeating patterns in Adobe Illustrator CS6.

In this video I will show you how to create a repeating Japanese pattern using just three circles and the new pattern creation tools.

Patterns made like this can then be used in your illustrations, layouts, or even as tiles in the background of your web pages.

Enjoy!

It’s a big change, but one that I’m excited about. Doing it in the spring will align more closely with releases and planning, which is ultimately going to make for a better event. We’ve also completely revamped how we think about content at MAX and as Kevin said, the content is going to focus around 4 major areas:

• Design and creativity
• Web sites, including the latest on HTML5, JavaScript and CSS
• Digital publishing, video, and gaming, including the latest on Flash
• Applications, particularly for mobile platforms

We’re working on getting some awesome speakers and I’m excited to be helping put on what is going to be a world class event for designers and developers creating digital content. Over the next few months I’ll also be talking more about how you can get involved, so stay tuned. And see you in May.

However, I also discovered that starting with PhoneGap 1.5 (release notes), a new key was added to the PhoneGap.plist (now Cordova.plist) called UIWebViewBounce.  It’s set to YES by default (I have no idea why).  If you set it to NO, your app will be anchored in with nails and the bounce removed.

This is also now configurable with PhoneGap Build by setting webviewbounce to false in your config.xml (documented here).

What is it?

The crux of PhoneGap is essentially a big ‘ol .js file (per platform, separate one for iOS vs Android etc) along with some simple native code to enable it to work. In the main JavaScript file (phonegap.js or cordova.js) are a bunch of functions that give you access to native features including the camera, compass, accelerometer, file system, storage access, media capture, audio playback, notifications, contacts and network connection status etc, similar to what Adobe AIR APIs offer, with the addition of a couple more. You write your applications in HTML/JavaScript and use CSS to style them. PhoneGap apps are wrapped in a native web container component, which is why your HTML/JS/CSS work. This also means there is a dependency for your phone’s browser to be based on the WebKit engine. This really isn’t an issue though since WebKit is the default for iOS, Android, BlackBerry Tablet OS and webOS currently. A great overview of commonly asked questions about PhoneGap can be found on my teammate Andy Trice’s blog, as well as a bunch of other great PhoneGap posts, so definitely check out his blog for heaps of good content.

How Does it Work?

The API functions in the phonegap.js (or most recently cordova.js) files call native plugin/extension code to provide the access to the native features through JavaScript exec calls. If you’re an AIR developer, it’s similar to the AIR Native Extensions model, except in PhoneGap they’re called plugins, and the set of APIs listed above (notifications, compass etc) are included and set up for you by default in the PhoneGap download. There are a bunch of other open source plugins available too which can easily be added to your project, or if you don’t find one you need, they’re easy to write. Here you can find instructions on how to write one for Android, and here for iOS. You can see that the JavaScript exec calls for iOS use .h/.m files for the actual native implementation, and .java for Android.

When you’re ready to use one of the APIs in your application, it’s very straightforward and easy to use. Here’s an example of adding a notification to your application:

Code Example

...
    function showAlert() {
        navigator.notification.alert(
            'You are the winner!',  // message
            alertDismissed,         // callback
            'Game Over',            // title
            'Done'                  // buttonName
        );
    }
...

Here’s the result:

You will find that all of the APIs are accessed through a navigator variable (declared in the phonegap.js file). To see examples of how to use all of them, check out the nicely done API reference docs.

If you’re curious of how this works underneath, here’s the notification code snippet straight out of the cordova.js file (NOTE: remember phonegap and cordova are currently the same library, so if you download it now you may find that your main API files are named cordova.js file instead of phonegap.js):

phonegap.js Source for Notifications

...
/**
 * Open a native alert dialog, with a customizable title and button text.
 *
 * @param {String} message              Message to print in the body of the alert
 * @param {Function} completeCallback   The callback that is called when user clicks on a button.
 * @param {String} title                Title of the alert dialog (default: Alert)
 * @param {String} buttonLabel          Label of the close button (default: OK)
 */
Notification.prototype.alert = function(message, completeCallback, title, buttonLabel) {
    var _title = title;
    if (title == null || typeof title === 'undefined') {
        _title = "Alert";
    }
    var _buttonLabel = (buttonLabel || "OK");
    <strong>Cordova.exec(completeCallback, null, "org.apache.cordova.notification", "alert", [message,{ "title": _title, "buttonLabel": _buttonLabel}]);</strong>
};

The above code shows the notification alert function definition to use for performing a native alert notification on iOS. The important line there is the Cordova.exec(…) call, which will use the native plugin code for iOS or Java to perform the notification. If you’re extra curious and want to see what the native code looks like for this, you can open the Notification.java or CDVNotification.m files such as shown (note: you need to download the actual cordova/phonegap project source from github here to view the source files for the core plugins. This is only necessary if you wish to view them or want to make your own custom changes to them, typically you would just install from here). I pasted a couple snippets from the native code files below to give an idea:

Java Source for Notifications

public PluginResult execute(String action, JSONArray args, String callbackId) {
    PluginResult.Status status = PluginResult.Status.OK;
    String result = "";   

    try {
      ...
      else if (action.equals("alert")) {
        this.alert(args.getString(0),args.getString(1),args.getString(2), callbackId);
        PluginResult r = new PluginResult(PluginResult.Status.NO_RESULT);
        r.setKeepCallback(true);
        return r;
      }
...

Objective-C Source for Notifications

...
- (void) alert:(NSMutableArray*)arguments withDict:(NSMutableDictionary*)options
{
    int argc = [arguments count];

	NSString* callbackId = argc > 0? [arguments objectAtIndex:0] : nil;
	NSString* message = argc > 1? [arguments objectAtIndex:1] : nil;
	NSString* title   = argc > 2? [arguments objectAtIndex:2] : nil;
	NSString* buttons = argc > 3? [arguments objectAtIndex:3] : nil;

	if (!title) {
        title = NSLocalizedString(@"Alert", @"Alert");
    }
	if (!buttons) {
        buttons = NSLocalizedString(@"OK", @"OK");
    }

	CDVAlertView *alertView = [[CDVAlertView alloc]
							  initWithTitle:title
							  message:message
							  delegate:self
							  cancelButtonTitle:nil
							  otherButtonTitles:nil];

	alertView.callbackId = callbackId;

	NSArray* labels = [buttons componentsSeparatedByString:@","];
	int count = [labels count];

	for(int n = 0; n < count; n++)
	{
		[alertView addButtonWithTitle:[labels objectAtIndex:n]];
	}

	[alertView show];
	[alertView release];
}
...

Common Questions

• What kind of UI Components does PhoneGap offer? PhoneGap does not offer UI Components, they leave that implementation up to you with your choice of HTML/JS/CSS or some other UI frameworks available like Twitter Bootstrap, jQuery Mobile, Kendo UI etc…
• How can I consume data in a PhoneGap app? The same way you consume data from a web application – REST, JSON, SOAP etc.
• What’s the difference between PhoneGap and Cordova? Cordova is the Apache Open Source project behind PhoneGap. If this is confusing to you, please read this post!
• What kind of development environment do I need? You can develop in your editor of choice on any platform. There are some workflow tips I can provide and will do so in the next post with my choices for editing, debugging etc. Once you have created your app in your platform of choice, you can just upload the source directly from your source control system or via zip file to PhoneGap Build as the screenshot below shows and it will create a ready to install package for all of the different platforms.

More Resources

Don't get me wrong. I love PhoneGap Build.  I love not having to open multiple IDEs to work on mobile apps. I love working on HTML apps in HTML tools - but you lose a few things in the trade. You lose being able to click one button and have your work available on your device.  You miss being able to click and get a pop up that says your work is ready to view on the device.

These things seem small, but having tried to build actual projects in PhoneGap Build, I found them critical.  I would go kick off a build, and then have to wait for the build to be complete.  I'd open a browser windows while I waited. 20 minutes later, I would cycle through my Chrome windows and remember that I was waiting for a build to complete.  

A few months back I tried my hand and solving this and came up with a shell script that handled this for Android.  Over the past few weeks, I've added to, improved, and modified it. I now have a solution in ANT that does the following:

• Uploads files to PhoneGap Build triggering a rebuild
• Polls for IOS and Android to be finished
• Downloads ipa and apk files when ready
• Installs them onto connected iOS and Android devices
• Uses the "say" command to let you know when things are done.

It takes the form of an ANT build file, some properties, and 2 shell scripts. I've posted the whole thing as PhoneGap Starter Productivity on github. As far as I know this will only work on OS X, which I hope isn't a huge problem for anyone, and I'm willing to collaborate with someone to make them more cross platform friendly.

Also I feel it's important to note, that while these scripts mean you don't have to use the IDE to accomplish these tasks, you still have to have Xcode and the Android SDK on your machine to use them. 

We just announced that we will move Adobe MAX from the end of the year to spring. So the next Adobe MAX will be on May 4-8 in Los Angeles. I for one I am excited with this move and I can’t wait for Adobe MAX 2013. You can find more about this in Kevin Lynch’s post.

Welcome episode #5 of our new podcast entitled “This Week in mLearning.” In case you missed previous episodes, you can find them HERE.

Great news, our Podcast is now live on iTunes and you can subscribe HERE. Please let us know your comments by leaving a comment here and thank you in advance for listening and for helping us spread the word about this Podcast on Mobile Learning.

Below is a summary of topics we discussed this week.

1- Highlights of the week

a- Adobe Creative Suite (CS6) went live. First impressions: fast downloads, seamless installation and PC/Mac version.

b- RIM´s BlackBerry World 2012: Public preview of BlackBerry 10 and BlackBerry Mobile Fusion,  an enterprise mobility solution and RIM’s entry into the multi-platform Mobile Device Management (MDM) marketplace. Among the management capabilities BlackBerry Mobile Fusion will provide, security is one of the highlights.

c- Big companies start to think about their mobile strategy: The Financial Times moves away from its native app over HTML5, Facebook doesn’t know what to do with mobile users and LinkedIn makes use of a hybrid app.

d- Google+ iPhone app

e- Great excitement about mLearning at ASTD 2012 International Conference & Exposition

f- The eLearning Guild Research: “Mobile Learning: The Time is Now” by Clark Quinn

g- Book release and blog book tour: “The Gamification of Learning and Instruction: Game-Based Methods and Strategies for Training and Education” by Karl Kapp

h- Pebble: an example of the power of crowdsourcing. Pebble is a customizable e-paper watch, promoted by Kickstarter, a funding platform.

2- Articulate Storyline: killer features and performance limitations.
3- Articulate Community
4- Articulate Storyline´s mobile story and challenges for the future (SCORM support, security, etc)
5- Articulate Storyline compared with Adobe Captivate.
6- Apps of the week: Wolfenstein 3D (free game) and Zite (personalized magazine).

Last week, I tried a variation of this at a Tampa meetup with an audience of about 100 people and it worked really well.  Late  Friday night, I created Phraffle (phone + raffle = Phraffle!) — http://phraffle.com.  It’s obviously a very simple and somewhat silly app, but it was fun to build.  It was also my first use of TypeKit (font used in the logo).  The spinning effect is based on a blog post I found by Saurabh Odhyan.  He basically pans an image across a div using JQuery.spritely.  Once the speed increases, the image is switched to a blurred version.   I loved the effect so I took his example and made some modifications until I had the right look and feel.

Let me know if you have any ideas on how to improve this or if you have seen other interesting ways of handling raffles.  I might create a tiny app for phones/tablets for off-line use-cases.  It all depends on how bored I get next weekend.

Mayra Aixa Villar:

As Instructional Designers, every day, we look for that spark of inspiration that can help us design our next eLearning project. We strongly believe in simple but still engaging designs, and for that reason, we’re always trying to find creative ideas to present learning content in order to get our message across. By reading about different techniques, trying different tools and exploring mobile apps, it’s amazing how much new insight one can gain. Our main goal is to transform any piece of information into an endearing, meaningful learning experience.

This is why I agree with Kasper Spiro as he makes a case for finding a new metaphor for eLearning:

I’m convinced that we have to find a new metaphor for e-Learning in order to bring e-Learning to the next level. The old book-metaphor with chapters and pages is well suited for linear courses, but it doesn’t work for more flexible individual approaches of e-Learning.

via A new methaphor for e-Learning – Challenge to learn.

In my opinion, the need to look for new metaphors for learning becomes even more crucial if we seek to make a successful transition from eLearning to mobile learning (mLearning).

Because of that constant pursuit of new ideas, metaphors and new tools, what started as a simple project in order to try out the shiny new Articulate Storyline product, ended up being an interesting demo that includes plenty in the way of interactivity. Easy-to-use triggers, powerful interactive objects as well as slide layers allowed me to create an interactive infographic with a software application that as Tom Kuhlmann describes it, democratizes eLearning.

Rapid elearning played a role in the evolution of elearning mostly because it took course creation out of the hands of a few programmers and placed it into the hands of anyone who wanted to create a course.

I see this as the democratization of elearning. And it runs parallel to how digital media’s empowered people all over the world to create and deliver content using a host of online tools and social media applications.

via The Next Generation of E-Learning » The Rapid eLearning Blog.

RJ Jacquez:

I continue to be very impressed with the new Articulate Storyline product. I’m especially impressed with how straightforward it is to publish any project for consumption on the iPad using the new Articulate Mobile Player iPad app. During my last year at Adobe, one of the questions I heard over and over, was how could eLearning developers enable learners to consume learning content on their iPads. I believe Articulate has been able to address this need with the launch of Storyline and their iPad app. Obviously mobile means much more than the iPad, and much work needs to be done beyond an iPad app, but I think having an iPad strategy is an excellent start and I expect that Articulate will continue to strengthen their mobile learning story in future versions of Storyline and Studio.

The other challenge we have as we continue to embrace mobile learning is thinking outside the eLearning box. I have written before that it’s human nature to bring existing principals we feel comfortable with, as we face new paradigm shifts. In eLearning and mLearning terms, this means that as we transition to mLearning, it might seem obvious to try and apply what has traditionally worked in eLearning into the smaller screen, but I would advice against that. Instead we need to figure out new ways of engaging the next generation of mobile learners. This is why I liked the interactive infographic project that Mayra shared with me because it shows that she’s starting to think outside the eLearning box, as she looks for new ways to present content. I also found it very interesting just how much one can do using very few slides in Storyline. I have been looking for an opportunity to do a screencast on some of the features I really like about Storyline and also demo the ease with which one can publish a project for consumption on the iPad using the Articulate Mobile Player app.

Below are two screencasts I recorded using this infographic project. The first is an overview of Articulate Storyline based on my experience with Adobe Captivate, and the second is a demo of how to publish for iPad and, what it’s like to interact with the content using the app.

In closing, if you have an iPad and want to try this infographic project yourself click the button below using your iPad’s mobile safari browser. I recommend you watch the videos first in order to better understand the entire process:

Please check them out and let us know what you think.

Invokes a specified method in a CFC file to generate the message that has to be published. Used in scenarios where you have raw data (that needs to be processed) to create a message.

• The websocket channel.
• CFC name. This is dot notation and NOT a relative path. This is crucial! Remember in my Application.cfc where I made a root CF mapping? I did that because I have to use a mapping to refer to my CFC. So imagine I want to hit chat.cfc in the same folder. Instead of simply using "chat", which the docs seem to imply would work, I must use "root.chat".
• CFC method.
• Array of arguments for the CFC. Not a structure, but an array. You will want to ensure you nicely list out your arguments in the method. This is optional.
• A structure of custom headers. Almost all your WebSocket operations allow for custom headers. This can include a selector as well as anything else you want to send along the wire.

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.

RAVE AI is an upcoming artificial intelligence framework for Flash/AS3 by Tomas Vymazal from Brno, Czech Republic. The main purpose of this framework are 2D/3D first person shooter games and other sort of games that require agent simulation. It supports JSON finite state machine definition, so you can predefine the behavior of agents. Next to that it supports 2D/3D terrain, bridges, very optimized pathfinding, sight/raycasting/shooting and there is a very impressive yet internal roadmap as well.

You can look forward to it later this year, the performance is amazing and Tomas is also planning to add support for ActionScript Workers for background processing later when available.

See it in action / rendering via Minko engine:

Get in touch with Tomas at twitter @myownclone.

Stay tuned for more.

Gamua released a much awaited version – Starling Framework 1.1 a couple of days ago! Clearly, a lot of improvements have gone into it. Here are some of the areas of improvement -

• I would say, first and foremost is the performance boost for the iPad 1.
• Introduction of Blend Modes for images for wonderful effects.
• A very handy component built-in to show statistics – frame rate, memory, etc.
• The most seriously useful feature – Multi-resolution development with support for multi-resolution textures.

I hope to cover some of these in my upcoming episodes of Starting with Starling. So, don’t wait more… Start with the new Starling 1.1!

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!

I'll be talking about Using PhoneGap Build to simplify your mobile development life. One of the great things about PhoneGap is that it allows you to use HTML JS and CSS to build your applications, but you still have to use native tools to build your apps. PhoneGap Build helps immensely with this, but you make some productivity sacrifices. This session will show you how to maximize your work, and touch as little of the IDE as possible. 

First time for me at this conference, but from what I understand it's a great conference that tackles a specific topic: getting development and design to work together better. Great goal, really looking forward to it.

D2WC
May 16-18
Kansas City Marriott Country Club Plaza
4445 Main Street
Kansas City, Missouri 64111
USA

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.

If you plan to write an app for iOS or Android, you will save time and create a better product if you stick to Objective-C and Java, respectively.

Which I agree with in principle, but I also found some of his arguments deeply flawed. He spends a lot of time talking about the cross-platform problem of trying to build a web-experience that looks native on iOS and native on Android. Specifically he calls out differences on iOS and Android:

The harder problems are inconsistencies in platform conventions. The iPhone uses Helvetica as its system font, while Android uses Roboto. iOS transitions between views by sliding new views in from the right, while Android uses a zoom effect.
You could recreate each platform in HTML5, but that requires a lot of work. You could design everything around an iOS look, and settle for things looking weird on Android. You could create a platform agnostic design language, making things equally weird for everyone. In a web view, it’s an uphill battle for consistency, whereas going native provides consistency for free.

Put aside the fact that if you’re doing native development you’re writing two different versions anyway (I’m not sure why that would be a knock against an HTML-centric solution), why do you have to design around an iOS or Android specific look?

The Native Component Question

I know it’s harder, and potentially more expensive, and requires more design sense, but why should developers of HTML-centric apps for mobile devices be locked into the specific UI look and feel of that platform? I’m not talking about UI paradigms (eg, soft back buttons on iOS, menu buttons on Android), but the specific look of apps. Instead of skinning your application to look like an iOS app and then try to make it look like an Android app, do a design that looks unique and polished that would translate well across both platforms. Then as you start to get into the specific differences (he brings up a good point about transitions) you can implement those device/platform-specific patterns. To me one of the beautiful things about the HTML/JS/CSS stack is the freedom with which we can develop. Bringing that to mobile applications, and letting some great CSS/HTML designers loose on that platform is a great thing. And it’s one of the reasons I love PhoneGap.

There are definitely some performance implications by going with a shell app/HTML-centric app approach. And as your application gets more complex, those will pop up more and more. So it’s something to be very aware of. Benjamin quotes some of the reasons he sees for people choosing HTML-centric apps: “we need to release faster”, “write once, run anywhere”, “HTML is easier”. I’m not sure any of those are great reasons to choose HTML-centric apps. Instead I see the primary benefits of the HTML approach as not being locked into a specific platform or deployment model. With HTML you can repurpose code for mobile web and you can target new platforms as they come (no device is not going to support HTML). But maybe most importantly, with HTML you can easily create custom app experiences. There are some great designers out there who can do amazing things with HTML and choosing something like PhoneGap lets you use those skills to create a unique web-like experience with all of the device features users expect from native apps.

Is it a silver bullet? Definitely not. But I think dismissing HTML-centric apps as being done because they’re cheaper/faster/easier doesn’t do them justice. For some kinds of apps, the HTML-centric approach is just better. There’s an amazing community of people that know HTML/JS/CSS, the web is the ultimate platform for reach and flexibility, and shell-apps bring those two elements to the native app world. That’s something to celebrate.

Another month, another Adobe WebUp (#5) has come :) (May 31st in our office). You should know this by now! For the first time there will be more external speakers than Adobe speakers – in total five sessions. If you live in Bucharest or close make sure you go here and register. Here are the five topics:

• Advanced CSS Layout Techniques – Dan Popa/Adobe
• Take your web apps offline with Application Cache – Ionut Margelatu/Adobe
• Introduction to HTML5 History API – Cosmin Nicula
• Common mistakes in Mobile Web Apps – David Emanuel Oprea
• From development to evolution – Andrei Epure

See you there on May 31st and if you want to be a speaker at one of the future events, drop me an email!

Register for the event here! Event hashtag #AdobeWebUp5 and Twitter @AdobeWebUp.

En Nuestro cuarto episodio, abordamos los siguientes temas:

1- Historias destacadas de la semana

a- Adobe Creative Suite (CS6) y Adobe Creative Cloud. Un lanzamiento exitoso, nuevas características, la importancia de estas características así como también la importancia de la nube para el aprendizaje móvil y algunas desventajas. Puedes encontrar más información en este post: “The New Adobe Creative Suite (CS6) is a Sign of the Mobile Times” (RJ Jacquez).

También, algunas aplicaciones como Adobe Photoshop Touch, Adobe Proto, Adobe Collage, Adobe Kuler y comentarios acerca de la ausencia de Adobe Captivate de la Adobe Creative Suite.

b- Google Drive: un servicio de almacenamiento en la nube y sincronización de archivos que puede utilizarse a través de distintos dispositivos.

2- La revolución del video: algunas estadísticas
3- Mejores prácticas y el uso actual de videos en el aprendizaje móvil
4- SceneChat: videos más interactivos. Puedes encontrar un ejemplo de la implementación de esta tecnología aquí: #eLearnChat 44
5- Khan Academy, el aula al revés (the Flipped classroom) y las lecciones de TED-ed: educación basada en videos
6- Aplicaciones de la Semana: iA Writer.

The web is moving forward. And it is so great to see this. I know it sounds a bit dramatic but this is exactly what happened before with two CSS proposals (CSS Regions and CSS Exclusions).

As a result of the past six months or so of work between Adobe and the other parties involved in the process the specs were updated this very month (May 2012) and new working drafts have been published.

If you want to read more about these proposals or to understand how the standardization process works read here.