Techniques to Optimize Memory Use in CocoonJS Canvas+ Environment

Memory is a critical resource in HTML5/JavaScript game development, especially on mobile devices. In a desktop environment you can load tons of textures but on some low-end mobile devices you can reach the maximum RAM limit quickly. Although JavaScript encourages automatic memory management by using a garbage collection mechanism, you shouldn’t ignore effective memory management techniques. HTML5/JavaScript applications can suffer the same memory related problems as native applications, such as memory leaks, out of memory issues and they must also deal with garbage collection pauses. 

This post will give you some general advice on memory optimization for HTML5 games and some CocoonJS Canvas+ specific tips.

Effective asset loading

Preloading all the assets at the start is the easiest and quickest way to manage the memory but it only works for small games where all the assets fit into the available memory. You shouldn’t preload everything on a heavy game, only the assets that you need each time, and dispose of the unneeded assets as soon as possible. Your game memory usage depends highly on your game engine (some of them do a better job than others). Don’t expect that the browser or the garbage collector will fix all your problems and that you can stop worrying about effective memory management.

Texture packer

Javascript images and canvas objects are backed into OpenGL textures and FBOs, usually using RGBA format, 32 bits per pixel. Think about it, for example a 2048×2048 image eats 16MB of memory!  Some GPUs require POT (Power Of Two) textures for the best performance, so keep in mind that some images could use more memory than their real size and use 2^n size textures whenever you can.

We recommend that you pack all your textures using one of the Sprite Packer tools out there. That way you’ll waste less memory and improve performance (by avoiding the number of context switchings) and loading times. Some HTML5 engines are able to pack all your textures at runtime, others don’t, so please check your engine features first.

Garbage Collection

JavaScript automatically frees objects when it detects that they are not used anymore, this process is called garbage collection. During a collection the execution on your page can be suspended for a moment. If your game creates too many JavaScript objects in each frame it can lead to noticeable pause issues. This is another example that proves that it is a mistake to forget about memory management on JavaScript. You should reuse javascript objects whenever possible.

The dispose method

Image and Canvas objects are disposed when the garbage collector detects that they are not reachable in the JS code. The disposal is not immediate, it may take some seconds depending on the heuristic rules of the JavaScript virtual machine. Using a WebGL context the developer has more precise control over the WebGL texture and buffers disposal but that’s not the case when using a 2d context or when dealing with Image and Canvas objects.

CocoonJS’ Canvas+ environment exposes a method called “dispose” on canvas, image and audio objects. This method immediately frees the associated texture or internal buffer, which is very useful for games with heavy textures or for games that need a greater control over the memory.

Using this CocoonJS Canvas+ exclusive feature is very easy. Imagine we have an image object represented by the “myImage” variable.

myImage.dispose && myImage.dispose(); // The same for canvas and audio objects.

The memory warning event

iOS and Android native applications are able to receive a memory warning notification from the system. The default implementation in Canvas+ and WebView+ environments is to perform a garbage collection and free as many internal cached data objects as possible.

From CocoonJS Canvas +2.1, the environment exposes the “memorywarning“ notification as a window listener. It is strongly recommended that you implement this method and free up as much memory as possible by disposing of cached data objects, images on canvases that can be recreated.

Cocoon.on(“memorywarning”, function() {
  // dispose of cached images and canvases that can be recreated
});

Texture reducer

Texture reducer is a CocoonJS Canvas+ exclusive feature. When your game targets all resolutions you need huge textures for iPad retina like devices and small textures for small mobile devices. A game developer has many ways to handle this:

  1. Create different asset packages, HD and normal. Good solution but bigger app size.
  2. Scale down HD resources. Excessive memory usage and performance impact on small devices.
  3. Create smaller asset packages on runtime rendering to a canvas/texture. Good solution but some JavaScript engines don’t support this.

The CocoonJS Canvas+ texture reducer feature can transparently do the job for you. It uses the third approach and it is highly customizable (for example, you can only apply it to certain resources). Check out the complete API documentation to see how to set it up.

As the texture reduction lowers the quality of the final images to be displayed, an interesting approach that we have recommended to some customers is to apply it only for certain device models, leaving higher resolution for some others (you can use the “navigator.userAgent” property to identify the device model). This, of course, it is not an easy task on Android due to the big number of device types, but on iOS is definitively an interesting option, specially for older devices such as the iPhone4 or the iPad Mini 1st generation.

Max Memory Threshold

This new CocoonJS Canvas+ exclusive feature available from version 2.1 and higher, exposes the “setMaxMemory” utility method. When the max memory threshold is set, CocoonJS checks the total amount of texture sizes (images and canvases). When the runtime memory size reaches the max memory threshold, CocoonJS disposes of the least recently used textures until the memory fits the threshold. It disposes of textures used for JS Image objects (which can be reloaded later if needed or are drawn again). It doesn’t dispose of canvas objects because they cannot be reconstructed if they are used again in a render operation. This extension is designed to be used in 2D contexts, because in WebGL contexts the developer is the one responsible for memory disposal.

Check out the API documentation.

Lazy Loading

Another CocoonJS Canvas+ exclusive feature available on version 2.1 and higher we have added the “cocoonLazyLoad” boolean property to Image objects (we have also added a duplicate called “idtkLoadDisposed” for retro compatibility with Construct2). When the property is set to true, the image is not loaded until it’s used in a render operation. Engines that load all the assets at startup can benefit from this property. But do not forget to purge the textures when they are not needed again, for example, using the dispose mechanism described earlier!

NPOT Textures

Canvas+ uses POT (Power Of Two) textures by default in 2d contexts. This is very useful for performance improvements, especially on mobiles with old GPUs. But it can waste memory on games that don’t use packed or 2^n textures. In CocoonJS Canvas+ version 2.1 you can allow NPOT textures in Canvas2D contexts (they were already supported in WebGL).

Check out the API documentation.

Conclusion

We have covered some basics of memory management in HTML5 games and exposed Canvas+ specific tips and tools.  We are always open to your suggestions. Remember that if you have some problem with memory usage in Canvas+ and you think that the problem is on our side you can send us a testcase and we’ll be glad to help you.

Additional Notes about Ludei’s Canvas+ Environment

CocoonJS’ Canvas+ is not a full browser, but a highly optimized JavaScript Virtual Machine for Canvas 2D and WebGL environments. Comparing it to a full fetched browser is not recommended as browsers include “a lot of magic tricks” (and that is why sometimes they are big and slow). For example, a browser might be able to handle a 5000 by 5000 pixels image but that does not mean that the underlying device is able to do it, just that the browser is handling some things internally for you either lowering the quality of the image (downscaling it) or subdividing it. Very few native technologies (C++ game engines) allow this kind of features as the developers should know how to handle this situations correctly (do not use 5000×5000 textures in the first place). Here at Ludei we never intended to create a new browser, but provide a highly specialized runtime environment so HTML5 developers can be closer to the native side without ever leaving JavaScript and the great HTML5 APIs.

CocoonJS Enables Android Wear HTML5 App Development

Google announced Android Wear this year, a new Android OS version suitable for wearable devices (Google Glass and smartwatches for now). Of course, Ludei right away started to wonder what kind of HTML5 execution capabilities will be available in such interesting devices. A couple of weeks ago, we purchased several Android Wear watches and begin to perform some tests over them. The first thing that we noticed was that at least this initial version of Android Wear does not come with a system WebView. It kind of makes sense as it is a very constrained environment and webviews are very resource demanding. Every attempt to execute a full fetched web environment on Android Wear Smartwatches has shown really low performance. Still, we wanted to see HTML5 running on a Smartwatch and how a good of a fit our highly optimized Canvas+ technology could be for Android wear. Our results were really encouraging as Canvas+ works amazingly well on these devices. Check out the following video that shows some HTML5 canvas apps and games running on Android Wear!

Of course, some minor modifications had to be done both to the technology and our cloud compiler, but we are more than happy to announce that we have enabled a new compilation target inside the CocoonJS Cloud Compilation System so any developer inside our community can test it. As far as we know, CocoonJS is the only technology that allows to deploy hybrid HTML5 applications for Android Wear even supporting WebGL! This is just an initial testing environment that allows you to build Android Wear applications but there are some initial limitations:

  • Do not add ad services. These services use the system webview to show ads and as we mentioned, Android Wear does not have a system webview.
  • Although you will be able to install the resulting APK on your smartwatch, we need to work on ways to better integrate the Android and Android Wear experiences. Please, use this initial builds for testing purposes.

If you want to test it, you need to make sure your app works on our Canvas+ environment. You can test it using the CocoonJS Launcher for iOS on iTunes, GooglePlay or Amazon. Then, just go to the CocoonJS cloud compiler, create or select an existing project, go to “Compile Project” and you should see the new target “Android Wear”.

Screen Shot 2014-10-23 at 12.44.03

Once you select the target, as it happens with any other CocoonJS compilation, a simple APK will be built in our cloud service, similar to the GooglePlay, OUYA or Amazon APKs, and it will be sent to your email account, but this one completely prepared to be executed on a Android Wear device. Connecting to Android Wear devices is similar to any other Android device as you will need to activate the developer options in the device and allow USB debugging. 

Enjoy testing your games and apps on an Android Smartwatch!

CocoonJS Latest Releases

New versions of some components of CocoonJS are ready. Please, share with us your comments about these releases. Your feedback is important to find bugs and determine next improvements. Enjoy!

Core v2.1

All platforms

  • Implemented custom Keyboard handling so users can enter text directly into the app, without popping up a dialog.
  • Cordova support is now always available for all platforms and environments in CocoonJS.

iOS

  • Added the new CocoonJS WebView+ for iOS 8 based on the new WKWebView (Only for 32-bit devices at the moment).
  • Fixed iOS 8 orientation and layout issues.
  • Drop iOS 5 support.
  • Updated the following third-party services
    • FacebookSDK.framework (3.19).
    • Google Play Services (3.0).
  • Fixed bug where reloading with an open websocket made the app crash.
  • Fixed bug where sending a score to GameCenter could cause a crash in poor-quality networks.
  • Fixed bug where after a reload, the system WV was being loaded instead of the WebView+.

Android

  • Added the option to compile Canvas+ projects for Android Wear.
  • Added support for the new ART Java virtual machine.
  • Fixed bug where making a webview call forwarding replaced the HTML body with the returned value in some Android versions.
  • Alert dialogs buttons behavior was not consistent across Android versions. Fixed.
  • Fixed rare case where the webview was being added twice.
  • Fixed negative values as notification ids.
  • Fixed case where webview would remain black after load.

Services

  • Updated the following third-party services
    • Google Play Services (5.0.89)
    • MoPub (3.1.0)
    • AdColony (2.2.4)
    • AdMob (6.12.0)
    • Chartboost (5.0.1)
    • Greystripe (4.3)
    • InMobi (4.5.1)
    • MillenialMedia (5.4.1)
    • Parse (Android: 1.6.0, iOS: 1.4.0)
    • iAd
  • Fixed rare crash when using local notifications.
  • Fixed type cast error showing in the console when sending a push notification.

Canvas+ v2.1

  • Added 8 WebGL extensions:
    • WebGLVertexArrayObjectOES
    • WebGLCompressedTextureS3TC
    • WebGLCompressedTexturePVRTC
    • WebGLTextureFloat
    • WebGLTextureHalfFloat
    • WebGLTextureFloatLinear
    • WebGLTextureHalfFloatLinear
    • WebGLTextureFilterAnisotropic
  • Fixed ambiguity when getting the window.location.port value.
  • Added NPOT texture support for Canvas2D.
  • Added a mechanism to discard seldom-used textures when the app receives a memory warning, to keep Canvas+ working even if the app loads more images than fit in memory.
  • Added a lazy-loading mechanism so images can be loaded on first use instead of when the src attribute is set.
  • Fixed rarely-occurring deadlock when pausing audios.
  • Fixed issue with the audio system not being ended correctly if the audio thread was locked.

WebView+ for Android v2.2.0

  • Updated to Chromium 36.0.1985.143.
  • Fixed unnecessary creation of shell additional instance.
  • Fixed cache mode.

See on github.

Plugins v3.0.4

See on github.

Launcher v2.1

  • New UI for both Android and iOS versions.
  • Added filename/URL search mechanism.
  • Added Favorites panel.
  • The Android Launcher now allows navigation through the whole device file system and loads not only .zip files but entire folders too.
  • Improvements to the debug service usability. Also, new error/warning reporting icons.
  • Restructured settings dialog.
  • More stable architecture. The launcher will keep working even if CocoonJS has a runtime problem.
  • Fixed several problems on Android 2.3.
  • Android launcher now allows canceling the app load process.

CLI v1.0.0-0.5.0

  • CocoonJS serve now has livereload enabled by default.

Known issues:

  • Livereload feature not work in system webviews with no websockets support.

See on github.

The End Of The Wrappers? I Don’t Think So!

It’s official: HTML5 is hot once again. For the past year, many of the wishes that all HTML5 developers have been waiting for have finally come true. All major browsing technologies support the main HTML5 features that make this technology a great option to develop beautiful desktop sites and compelling mobile apps. The latest addition to the list of iOS 8 with its official support for WebGL and improved webview called WKWebView with Nitro JIT acceleration, has been widely applauded by the community. And there are plenty of other reasons to be happy if you are an HTML5 developer, as the runtime environment that will run your app or game is a major issue that has been holding back the widespreading of the web as a major development platform (specially on mobile) for the last years.

There are many articles out there around performance benchmarks of the current browsers. Chromium based solutions for Android, Internet Explorer supporting the main HTML5 specifications (and auto updating itself quite regularly), plenty of great app development frameworks, … the list of good news is long. And here at Ludei, we are glad that, finally, all the pieces are starting to come together. But (there is always a but ;)), we have been reading much about a concept we do not agree with, and is the apocaliptic calling to “the end of the wrapping technologies” for mobile web applications. Ludei has been providing great tools and technology for HTML5 developers for the last couple of years.

Ludei’s developer community has grown strong to 50,000 developers and more than 4,500 apps published on mobile markets. We are going to continue to provide a great development experience and the best tools and runtimes as long as they continue to come out to the market. But there is a reality we still know about: building compelling mobile web apps is not simple. And we are not just talking about developing the app itself. Some frameworks are getting mature, some are starting to show their potential, but there is a detail worth mentioning: the mobile space is not the same as desktop web app development.

  1. First of all, mobile users are used to and feel comfortable with app stores, so they want apps. Building an app is not a major issue, but still, lots of web developers do not want to face all the hassle of installing native SDKs, compile applications and moreover, update multiple tools to be able to create their final mobile apps.
  2. But not only this, successful apps need access to native SDKs and mobile features that may vary from one platform to the other, or even from one store to the other. We are talking about in-app payments, ad networks, push notifications, social network SDK integrations, etc.
  3. Additionally (and sadly), there is still not one runtime environment solution that fits all and not plenty of good tools to test and debug apps on mobile. At Ludei, we have developed our own HTML5 runtime environments (Canvas+ and WebView+) and we also provide access to use the system web browsing technologies. This way, developers can choose what works best for them depending on their app. Even our canvas only technology, Canvas+, has plenty of advantages that some other technologies do not have for some type of apps (mainly games): low footprint, advanced memory management, extensions, accelerated physics, full control over the runtime (crucial for some customers), etc.

All these features are what wrapping technologies like Ludei’s CocoonJS or Apache Cordova provide: A productive way of testing, creating and monetizing HTML5 mobile apps. The bottom line is, that we are far from a mobile browser only app and game market. App stores on mobile will continue to exist, and actually, that’s the beauty of HTML5, your product can exist in both environments (as a browser based discoverable app and a mobile app store app). Mobile web app development is here to stay and grow and wrapping technologies are far from being at their end, moreover, in our opinion, they are at their infancy.

iOS 8 support added to the CocoonJS Cloud Compiler

After the official iOS8 release on September 17, 2014, we are proud to announce that the iOS 8 support integration is now completed and ready to use in the CocoonJS Cloud compiler for both CocoonJS and Cordova compilations.

iOS8 support is available for all the supported CocoonJS versions at 2.0.1 and all the available Cordova versions. We are removing CocoonJS 2.0.0 support after this update.

Regarding the CocoonJS Launcher, an iOS 8 ready version is under review by Apple and will be available in the AppStore in the next weeks. In the meanwhile, remember that you can still use a Custom CocoonJS Launcher.

So you can start compiling and uploading your apps and games to the Apple AppStore with iOS8 support now!

New CocoonJS Plugins are here!

We have been working hard on improving the CocoonJS plugins. The new plugins for CocoonJS are finally ready and we have been focused on making them easier to handle. By the way, we have also revamped and improved the documentation with more examples and useful links.

 

plugins-docs

To begin with, the main namespace for all the plugins has changed from CocoonJS to just Cocoon. Secondly, there is a new namespace organization and some plugin functionalities that before were included inside the App namespace, are now distributed among them. This is a more detailed list of the new namespaces:

  • Cocoon.Camera: It represents the CocoonJS camera plugin API.
  • Cocoon.Device: All functions related to the device.
  • Cocoon.Dialog: Dialog functions (prompt / confirm).
  • Cocoon.Motion: All functions related to the Accelerometer and Gyroscope.
  • Cocoon.Proxify: It proxies different functions of the WebView environment, like Audio objects and XHR.
  • Cocoon.Touch: It holds some functions to handle the touch events in both surfaces (Cocoon & WebView).
  • Cocoon.Widget: It holds the WebDialog widget, which essentially shows a Webview on top of the CocoonJS layer.
  • Cocoon.Utils: It holds some different utilities.

Additionally, note that Construct 2 plugin will be updated in order to use these new plugins.

Another important change from the old extensions is the new event handling system, based on signal events.

Below there are several examples about how to use the new plugins:

Cocoon.Camera:

Cocoon.Camera.start({
  success : function(stream){
    ctx.fillRect(0, 0, w, h);
    ctx.drawImage(stream, 0, 0, w, h);
  },
  error : function(){
    console.log("Error", arguments);
  }
});

Cocoon.Widget.WebDialog:

var dialog = new Cocoon.Widget.WebDialog();
dialog.show("http://www.ludei.com");
//This dialog will close after 15 seconds.
setTimeout(function(){
  dialog.close();
}, 15000);

Cocoon.App: On application suspended event.

Cocoon.App.on("suspended", function(){
  console.log("The application has been suspended");
});

The new CocoonJS Plugins can be found at Github and, in order to improve them faster and to receive important feedback from our users, everyone can contribute to a better documentation by doing a pull request.

The new CocoonJS Plugins are published in beta and the old ones are in a deprecated state. Consequently, we will stop developing them.

We really hope you will benefit from this new structure of the plugins and the improved documentation.

CocoonJS Updates For Construct 2 Developers

Ludei has been for several years now serving as a game native hybrid HTML5 app building system for many Construct 2 (and other frameworks) users. A big number from our more than 42,000 developer community have used CocoonJS successfully to release final products to the stores, hundreds of them made with Construct 2. We have provided a good platform for many, but we also understand CocoonJS might not have worked as expected in some situations. We would like to clarify this and help the Construct 2 and other game and app development platform communities to grow and be successful.

First of all, CocoonJS has evolved in the last months. We started focusing just on HTML5 games, where we saw the biggest needs, about 3 years ago. The HTML5 Canvas component was available in mobile browsers and native hybrid technologies (WebViews), but it was slow, fragmented and lacking many advanced features (and still does). We developed Canvas+, a cross-platform technology for iOS and Android that solved many of these problems. But this technology has been built from the ground up by Ludei (yeah, we built a subset of a browser from scratch!) and it wanted to fulfill only one purpose: render HTML5 Canvas 2D and WebGL applications on mobile. It did and does not render any DOM elements apart from Canvas. It lacks many features. We have added some over time (basic HTML parsing, XHR, WebSockets, gamepad, …) but still, it is not a complete HTML5 execution environment. We understand that it can be a hard environment to work with (specially at the beginning) as it limits the HTML5 APIs that can be used. But despite these limitations, it has been used by all our games and by thousands of projects from our developer community that have been successfully published to the Apple AppStore, GooglePlay, Amazon, Tizen, OUYA, etc. Big companies like Disney, Nickelodeon and others have used it too to accelerate and publish their games.

About a year ago we realized that a new trend of HTML5 execution environments were about to be launched. The iOS WebView was getting better in every aspect, even on the Canvas execution (still lacking WebGL until iOS 8, released last week). Google released the source code for the Chromium Project for Android and was announcing a possible inclusion of the runtime inside every new Android. The Cordova community also grew and it has become the de facto standard for native hybrid app compilation. We went back to the roots and tried to include these technologies and as a result, WebView+, the System WebView execution environments and the CocoonJS Cordova Command Line Interface were added to CocoonJS.

Now CocoonJS is not just Canvas+, a HTML5 Canvas 2D and WebGL execution environment, it is a complete set of technologies that developers can test and use in order to select the one that best fits their needs. We have also contributed the WebView+ (Chrome based) to the Cordova community with the CocoonJS Cordova Command Line Interface so anyone can build their Android and iOS (WebView based) projects on their own. Our Cloud Compilation System also provides the option to compile the Cordova project for you, so you do not need to install nor update any SDKs locally.

Additionally, we made all of our CocoonJS Extensions available in any of these new environments (WebView+, WebView) too and of course, if you choose to use Cordova compilations, you can use any Cordova plugins.

Regarding the Construct 2 community specifically, as Scirra has hidden the CocoonJS export option from the latest release, and as we know there is a big part of the Construct 2 community that might still want to use our service, we are providing different solutions:

  1. The latest versions of Construct 2 hides anything related to CocoonJS by default. If you want to still get access to these features, you can do so by specifying to “show deprecated exports/plugins” by right clicking in both the Construct 2 export options and the Construct 2 plugins respectively.

image_02

image_00

  1. A couple of months ago we announced that CocoonJS Canvas+ was compatible with the regular Construct 2 HTML5 Web export option. This means that if you export to the HTML5 Web and still be able to test and deploy Canvas+ based projects. There might no be fullscreen mode when WebGL is enabled in this type of export but if you disable WebGL in Canvas+ and use it’s fast Canvas 2D acceleration, your game should be correctly adapt to the whole screen. Although we recommend option 1, we are also mentioning this possibility for all those developers that do not have the export to CocoonJS option.

image_03

image_01

  1. Remember that CocoonJS is a platform that provides different runtime environments. If you want a phonegap like experience, but still use an improved WebView on Android, you can use our WebView and WebView+ options and compile your Construct 2 HTML5 Web export using both the CocoonJS Cordova Command Line or the CocoonJS Cordova Cloud compiler.

All these runtime environments are available to be tested using the CocoonJS Launcher application for iOS, GooglePlay and Amazon, a great testing tool for your projects.

And we are still working on improving our platform and these are some of the features that will soon be available.

  • We are working hard to be even more Cordova compliant and provide a seamless integration of all our runtime environments in a simple to use cloud compilation service.
  • The cloud compiler will be exposed through a REST API so third party development frameworks can easily access it and provide a unified experience for their developers.
  • A new version of the Construct 2 plugin will be available soon with a new plugin id.
  • A new iOS runtime environment option will be available: WebView+, based on the new WKWebView iOS 8 component. We are experimenting with it right now.

We fully respect Scirra’s decision to hide the CocoonJS related options. Still, we think we need to remember and correctly communicate that CocoonJS is no longer just a Canvas+ execution environment and that still can provide a great final product native hybrid app compilation for many developers (even using Canvas+, used by many!) from Construct 2 or any other HTML5 development framework. We hope to see more and more WebView and WebView+ projects being compiled using CocoonJS!

The future of the CocoonJS Cordova Command Line Interface (CLI)

A couple of months ago we published our CocoonJS Command Line Interface (CLI) that let’s you compile Cordova based projects, which benefit from the Webview+ runtime. Today we want to share with you an approximation of what’s coming to the CocoonJS CLI in the following months.

One of the main tasks we are currently developing is the integration of the command line with our cloud. This will allow you to download projects locally and upload them back to Ludei’s cloud compiler, so the compilations you make with the CLI use all the project data you already have stored in the cloud compiler (e.g., your Facebook tokens, MoPub ad units…).

Another exciting change coming to the command line is the possibility of using Crosswalk as an alternative runtime environment. Crosswalk will join the current Webview+ and Canvas+ as another execution environment for applications made with Cordova/CocoonJS. The main benefit of using Crosswalk is that it has Android binaries for x86, so Android devices running Android 4.x x86 enjoy all the features of a modern browser specifically suited for the underlying CPU.

We will also update the HelloWorldApp/DeviceReady demo that is created when you make a project using “$ CocoonJS create”, so that this new sample app will use different features of the Webview+/Crosswalk to demonstrate the potential of these runtimes.

But remember that you can already benefit from the following features with the current version of CocoonJS CLI.

Already available features of the CocoonJS Cordova CLI

  • The CocoonJS-CLI is agnostic to a specific cordova 3.x version.
  • The Webview+ provides a chromium-based environment for your HTML5 hybrid apps. It will deliver all the power of Chrome and the same look and feel across every Android device on the market. As we promised, Android fragmentation is over!
  • Remote debugging

At this point, these are the tasks that are already in development and you’ll be able to use in the following months.

Roadmap for the upcoming months

  1. Integration with the Ludei’s file system API. (which let’s the user upload it’s local project and compile it in the cloud). No more hassle of setting up and updating the Cordova environment locally.
  2. Different execution environments support (either Canvas+, WebView+, Crosswalk or whatever environment may come in the future) thanks to the compilation in the cloud.
  3. Cloud project management from the command line.
  4. Live reload. This is a great feature that will allow that by just saving a source code file on the server, let the CocoonJS client be aware of the change and update itself “automagically”,  saving tons of time during development.

It seems that the CocoonJS Cordova Command Line Interface will bring many brand new features to our platform, what do you think?

CocoonJS 2.0.2 is live!

The new version 2.0.2 of CocoonJS is live! You can read the full changelog here but take a look to the highlights.

75d29906-c26e-4e89-9077-847c99fb632f

Canvas+

  • Fixed the crash on Tegra-based Android devices like the Samsung Galaxy Tab 10.
  • Fixed texture corruption bug that affects Phaser based games using WebGL.
  • Other improvements in audio, DOM node management, camera speed, computeStyle, etc.
  • More

WebView+

  • Updated the WebView+ to the latest stable Chromium version. Fixes some crashes, improves WebGL support, etc.
  • Other stability bugs fixed.
  • More

CocoonJS Launcher

  • Fixed the support for Android 2.3.
  • Settings are more homogeneous both on iOS and Android and are correctly stored between sessions.
  • Improved URL handling. The final slash is no longer necessary for URLs to a folder (a more browser-like behaviour).
  • The URL history button on Android shows all your URLs.
  • More

Extensions

  • Added a new native share functionality. CocoonJS.App.share() inside CocoonJS_App.js.
  • The CocoonJS Extension repository now provides branches for previous CocoonJS versions.
  • Fixed several bugs and updated the SDKs in the ad extension for MoPub and AdMob.
  • Fixed bugs on social, notification and multiplayer extensions.
  • More

Download the launcher from App Store, Google Play and Amazon App Store. The version with 2.0.2 has been submited to Google Play and Amazon and are waiting for review. Enjoy!

Introducing the CocoonJS Command Line interface and webview+ plugin for cordova

The main improvement of CocoonJS 2 was providing cordova compatibility to Ludei’s cloud compiler. With the cordova compiler, we also released the webview+, a chromium-based webview for android 4 and higher. You can use it directly from our cloud compiler.

The webview+ provides a chromium-based environment for your HTML5 hybrid apps. It will deliver same look’n feel across every android device on the market. As we promised, Android fragmentation is over!

The great news is that we want to share this development with the HTML5 and cordova community, so we are doing a public release of the main tools of our cloud compiler: the webview+ plugin for cordova and CocoonJS Command Line Interface.

The webview+ plugin for cordova enables your cordova-based apps to include a webview+ to run as the execution environment for your app. This plugin can be included in your current cordova android projects. What does this plugin provide?

  • Implements the cordova plugin API, so it interacts seamlessly with any cordova app
  • Webview+ provides remote debug for any cordova project. JS instrumentalization and live code changes, dynamic breakpoints, and all the power of the chrome developer tools
  • WebGL support for any android device running android 4 and higher.

Interested? You can get more info here. The project is hosted in our github here.

Other contribution we want to share with the community is the CocoonJS Command Line Interface. Standing on the shoulder of giants (cordova-cli), we’ve developed a Command Line Tool that eases the process of dealing with webview+ in Cordova projects. But, why another fork from cordova? Why another open source command line interface?

  1. Currently, installing webview+ manually is a bit tricky and the cocoonjs-cli eases the process, apart from reporting more meaningful error logs
  2. Cocoonjs-cli is cordova compliant, so the only difference you’ll notice is the command name, moving from cordova to cocoonjs
  3. The cocoonjs-cli also will be one of the remote interfaces for the cloud compiler. The cloud compiler enpoints are currently under development. We want to empower our users with tools that eases the process of managing their cloud projects
  4. Because we use extensively open source software and it’s time to give this love back to the community

Get more info abut the Cocoonjs-cli here. The source code is hosted in our github.

We encourage every HTML5 developer to download it, install, use, test and find bugs. We really would like to create a big community around these new projects.

Hail to open source!