Welcome to the second part of our new monthly blog series, “Shipping Code”!

In the previous instalment we took a look at the various strategies available for developing your mobile app. We covered Mobile Web Apps, Native Apps and Hybrid Apps.

For the remainder of the series we’ll be leaving Web & Native Apps behind to focus purely on Hybrid App development because that’s what we do here at Trigger.io!

How should I structure the architecture of my Hybrid app?

Now that you’ve decided on a Hybrid App for your development strategy the next question you’ll face is how to structure your code.

There are a variety of architectural patterns in common use and the approach you decide on will depend largely on the type of application you are developing.

In general terms we can break the patterns down into the following broad categories:

Single Page: The “Single Page” architecture is the most common pattern found with hybrid apps. This architecture takes the form of a single index.html page which serves as the containing document for the app. Content and resources are then dynamically loaded into this page via Javascript.

Static Site: The “Static Site” architecture is similar to a traditional web site. The app consists of multiple HTML pages which are linked together via hyperlinks.

Hosted Iframe: In the “Hosted Iframe” architecture the app takes the form of a single index.html page with an embedded <iframe/> tag which contains a remote web site.

Let’s take a closer look at each of these patterns:

Option 1: Single Page

The trend over the last ten years has been towards so-called “Single Page” apps which move responsibility for rendering the application UI from the server towards client-side HTML and Javascript.

This approach brings a number of advantages, most importantly:

Speed: With traditional server-side architecture there is a significant delay after each user interaction as a request first has to be sent to the server and any UI updates have to be returned to the user.

Simplicity: Rather than managing complex application and UI state on the server for each user, that state can now be maintained locally on the user’s device.

See the Wikipedia page for a thorough discussion on Single Page applications.

While the entire app is hosted on a single page local to the device the backend web server still plays a role. Most commonly, a RESTful JSON interface will be exposed on the web server which provides the following services to your app:

Implementing application logic for the data endpoints used by the application.

Retrieval and persistence of application state.

User authentication and authorisation.

The components of a Single Page App

The exact structure of your Single Page app will depend largely on whether you are using vanilla HTML/Javascript/CSS or one of the many Third-party Single Page app frameworks to implement your app.

That said, most Single Page apps will contain some combination of the following elements:

A src/index.html file containing:

The basic app layout

Imports for your Javascript code.

Imports for your CSS code.

Imports for any Third-party Javascript & CSS libraries.

One or more src/templates/*.html files containing:

Templates for your views

Templates for your UI components

One or more src/js/*.js files containing:

Your application logic.

Third-party libraries and frameworks.

One or more src/css/*.css files containing:

Rules for the look & feel of your application.

Third-party CSS frameworks.

Binary resources such as images, audio or video.

Third party Single Page App Frameworks

There are a large number of Third-party Single Page libraries and frameworks available that simplify the task of structuring and developing your Single Page app.

While the borders aren’t always clear-cut, we can divide Single Page app Frameworks into two broad categories:

Pros for Single Page Architecture

It’s much easier to develop complex Single Page apps than traditional server-based applications.

There is a huge selection of high-quality Third-party Single Page app frameworks available.

You can access all forge.* API’s from your app.

Users can still use your app even if they are not connected to the Internet.

Cons for Single Page Architecture

If you have not developed Single Page apps before you’ll have to go through a mild learning curve to get comfortable with the concepts.

If you want to use functionality from your existing website you may need to implement a RESTful JSON interface for transferring data between your app and backend services.

Option 2: Static Site

This approach can work well with simple apps that require interaction with native device features and consist primarily of statically served web pages, images and other resources.

The components of a Single Page App

Structured in the same way as a website serving static content, your hybrid app contains a separate HTML file for each page in the site.

While it’s tempting to think you could take any existing website and easily convert it to a web app in this way it’s worth remembering that this will only work with the very simplest of sites as you will no longer be able to rely on the server for processing user interaction or other forms dynamic processing.

Pros for Static Site Architecture

It can be the easiest way to transfer content from an existing site to mobile.

You can access all forge.* API’s from your app.

Users can still use your app even if they are not connected to the Internet.

Cons for Static Site Architecture

Maintaining a complex application as a set of HTML pages can quickly become overwhelming.

If your existing site features complex server interactions you will have to rewrite those as client-side Javascript and expose a RESTful JSON interface on your server.

Option 3: Hosted Iframe

If you have an existing web app which does not require complex interactions with native device features or functionality you can simply “host” it inside a hybrid app by using an <iframe /> HTML tag inside your app’s main page.

An important factor to bear in mind is that you cannot directly access forge.* API’s from the remote site’s pages.

If you would like to make use of native device features you will need to bridge the calls from the remote page to your app’s src/index.html page by using the window.postMessage() and window.addEventListener() API’s to marshall communication between the hosted site and the parent hybrid app.

Pros for Hosted Iframe Architecture

You can decide which portions of your app will be implemented locally and which portions will re-use existing site functionality.

Cons for Hosted Iframe Architecture

You will need to apply responsive design to your remote content or it may look odd on mobile devices.

Accessing device functionality through the forge.* API’s is more complex as function calls will need to be marshalled through the iframe’s parent window.

Users may not be able to use your app unless they are connected to the Internet.

Conclusion

All of the above options are supported by Trigger.io Forge but we will be spending the bulk of our time in this series focusing on the Single Page App Architecture (Option 1) as it has emerged as the most practical and popular pattern for hybrid app development.

In the next instalment of this series we’ll be taking a closer look at some Single Page app frameworks and the problems they solve.

Until then, if you have any questions about the material we’ve covered so far, we’d love to hear from you at support@trigger.io!

Introduction

Google’s beta release of their API Client Library for Javascript promises to make life easier for developers who want to integrate their apps with Google services (Calendar, Contacts, Analytics, etc.)

While Google provide some documentation for using their library with web applications accessed via a standard browser there are some gotchas involved when trying to make us of it in a Hybrid app environment.

Specifically:

Athentication & Authorization flow differs slightly as Hybrid apps do not support the creation of popup windows.

Google make use of a small shim library which bootstraps the rest of the library source code from their remote servers. This library has a bug which causes it to fail silently when included from a page which has been served by a protocol other than http:, https: or file:. Unfortunately, Trigger.io app assets are served via the content: protocol on Android!

In this technote I’m going to show you how to use the GoogleJS Client Library and walk through solutions to both of these issues.

Application Configuration

To follow this tech note and use the Google Javascript client library, you’ll first need to configure your application as follows:

Step 1: Platform Version

Make sure your app is running on platform version v2.2.15 (or higher)

Step 2: Modules

Add the following three modules to your app:

tabs – We’re going to use a forge tab to open the OAuth authorization dialog and obtain the user’s auth token for your app.

httpd – This is a new, experimental, module which serves your app content via the http: protocol rather than file: (iOS) or content: (Android).

OAuth 2.0 Authentication & Authorization

To access any private data belonging to the user your application will need to work with Google’s OAuth 2.0 mechanism.

While Google provide a simple convenience method in the form of gapi.auth.authorize() it is not suitable for use in a Hybrid application as it will attempt to open a browser popup window to handle user login.

Series overview

Part of what attracts developers to hybrid apps is the freedom of choice we get from building on open standards supported by the community of our fellow developers but this very freedom can also be intimidating at times!

To help make sense of the wild and wooly landscape out there we’d like to introduce our new monthly blog series: “Shipping Code”

Our “Shipping Code” series will be running over the next year and will cover the entire hybrid app development cycle from beginning to end.

The process of shipping a new mobile app from scratch is complex and you’ll run into many different questions on your journey.

What we will try and do is to fit those questions (and some answers!) into a cohesive picture which, we hope, will assist both new hybrid developers and even old hands to locate themselves in the happy chaos of modern mobile app development.

Introduction: The Three Mobile App Strategies

As a developer you have three broad strategies available to you if you want to develop an app which runs on a mobile device:

Mobile Web App

Native App

Hybrid App

We’ll be kicking off our series on hybrid app development by examining some of the pros and cons of each approach.

Strategy 1: Mobile Web App

The easiest solution for getting your application onto a mobile device is to simply develop it as a web application.

Mobile web apps are hosted on a remote server and built using identical technologies to desktop web apps: HTML5, JavaScript and CSS

The primary difference is that it will be accessed via mobile device’s built-in web browser which may require you to apply responsive web design principles to ensure that the user experience is not degraded by the limited screen size on mobile.

There are a number of limitations to this approach but the biggest is that you will only have limited access to device API’s, features and integration with other apps on the user’s device.

Pros:

Few, if any, technological differences from any other web site or web application.

Maintain a single version of your app for both mobile and desktop versions.

You can easily ship new versions of your app by updating the remote server.

Cons:

The cost of applying responsive design principles to an existing website may be a significant fraction of developing a mobile app.

Your app will not be available on mobile app stores which may make it hard for users to find it.

Mobile device browsers have historically lagged behind their desktop counterparts, this can create compatibility issues on mobile devices with parts of your app not behaving as required.

Limited access to device features.

Strategy 2: Native App

Native Apps exist on the other extreme of the scale. They are developed using the device’s native SDK’s.

On Android this usually means writing your code in Java using Google’s Android SDK libraries. On iOS you’d be working in Objective-C or Swift using Apple’s iOS SDK libraries.

This is unquestionably the most powerful approach as you are able to access all features of the device and make use of the native UI components of the device.

The biggest downside is that you’re going to need engineers with the skills required to maintain two separate platform versions of your app, one for each device you want to support.

Pros:

Access to all device API’s, features and inter-app integration.

Full control over the user experience allowing for complex experiences such as gaming or content creation.

Your app will match the native look & feel of the device without requiring a 3rd-party UI library.

Your app will be available on App stores.

Cons:

Development costs are high and can take orders of magnitude longer to ship due to the low-level nature of the device SDK’s.

You need to write and maintain a separate version of your app for each device you want to support.

Developers need to learn multiple different programming languages and API’s with steep learning curves for each version of the same app.

Slower development time.

Bugs are more likely to crash your app (or even the device!)

Harder to debug errors & crashes

Shipping updates can be slow due to the app store approval processes.

Strategy 3: Hybrid App

Hybrid apps occupy the space in the middle of the previous two extremes. They enable you to use standard web technologies to develop your app whilst, simultaneously, having access to the native API’s and features of the device.

While they have somewhat of a reputation for not being competitive against their native counterparts the present reality is that we continue to see more and more world-class apps that shipped with a Hybrid App strategy.

There are many more good reasons to choose a Hybrid App for your project but there’s one factor which stands out above all else:

Shipping and maintaining a Native App on both Android & iOS is going to cost you, at the very least, twice as much as a Hybrid App.

…and this is assuming that you and/or your team are already well versed in Java, Objective-C, Swift and the Android & iOS SDK’s!

Pros:

You can use most of the same technologies and tools used for web development to create a mobile app.

Maintain a single codebase for both iOS and Android versions of your app.

Now, if everything goes to plan you should be able to run the ForgeInspector project on your mobile device, select the showMap method, hit “Run!” and see:

Closing thoughts

Android AAR libraries may seem complex at first but, in reality, they make integration of 3rd-party libraries much easier with your app.

Instead of wrestling with the individual pieces of a library, developers are now able to use a single integrated bundle which makes it possible to import library classes, resources, AndroidManifest.xml entries, proguard rules and JNI libraries into your app with a single step.

We hope you enjoyed this TechNote and look forward to hearing from you at support@trigger.io if you have any comments or questions!

It’s a fascinating time to be a developer. As early as 2008 the number of things connected to the internet surpassed the number of people alive on earth, and some well informed people think the number could be as high as 50 billion by 2020.

Users have been exposed to the type of user experience that realtime web technology provides, and expect those types of experiences in the apps they use.

Keep talking

Massive social platforms now represent one of the main ways that we communicate with each other. It’s realtime technologies that power the interactivity that make the experience so rewarding. Given the comprehensive toolsets provided by PubNub, implementing full-featured, massively scalable messaging has never been easier.

IoT and Really Big Numbers™

Talk about the Internet of Things (IoT) brings up numbers that can get anyone sweaty!

The global market is estimated to be worth $7.1 trillion by by 2020, or $14.4 trillion, according to Cisco. Less than 1% of things that could be connected to the Internet currently are, which means 10 billion things out of the 1.5 trillion that exist globally are currently connected. That’s a big gap, and a big opportunity.

Time-to-market has never been more key, nor a mature and well-developed technology stack.

PubNub

PubNub started life as a provider of APIs allowing publishers and developers to integrate messaging and social services on apps and websites.

Since then their product offering has evolved into The PubNub Data Stream Network, a PAAS which allows rapid development of real-time apps and communication for web, mobile and IoT apps.

PubSub

In software architecture, publish–subscribe is a messaging pattern where senders of messages, called publishers, do not program the messages to be sent directly to specific receivers, called subscribers. Instead, published messages are characterized into classes, without knowledge of what, if any, subscribers there may be. Similarly, subscribers express interest in one or more classes, and only receive messages that are of interest, without knowledge of what, if any, publishers there are.

Pub/sub is a sibling of the message queue paradigm, and is typically one part of a larger message-oriented middleware system.

This pattern provides greater network scalability and a more dynamic network topology, with a resulting decreased flexibility to modify the Publisher and its structure of the data published.

Using PubNub with Trigger.io

To demonstrate Pubnub’s ease of use I’m going to show you how to run PubNub’s 10chat 10-line Javascript chat sample inside a Trigger.io app.

Step 1

Create a new app in the Trigger Toolkit.

Step 2

Under Config / Tools, specify whether you want the app to run on a specific device or emulator, and specify the path to the appropriate SDK

Step 3

Now let’s give it a test run! Under Forge, click either Android or iOS to run it on the appropriate platform, or click Web to run it in a browser window.

You should now see something like this:

Step 4

So far so good, now let’s make it do something!

Find the index.html file in the src/ folder of your app, open it in the text editor of your choice and remove the template code between the <body></body> tags to leave you with something like this:

Adding support for the Google Play Services library when building an Android custom native module is a little more complex than most and we’ve had a number of requests for detailed information on how to do it.

While Google provide detailed documentation, it’s not always clear how that maps to the Trigger.IO native module SDK.

The process boils down to these five basic steps:

Add the Google Play Services Jar file to your module.

Add the Google Play Services resource directory to your module.

Add a meta-data tag for the app’s AndroidManifest.xml file

Add Proguard rules to allow Google Play Services to use reflection.

Update your module’s inspector project with the changes from the previous steps.

Let’s walk through these steps in detail…

Step 0: Increase Eclipse memory limits (optional)

If you run into issues here where Eclipse crashes out on after adding the Google Play Services library to your module you’ll need to edit your eclipse.ini configuration file and increase the memory limits:

1

2

3

4

5

6

7

Linux:/etc/eclipse.ini

Mac:/Applications/eclipse/Eclipse.app/Contents/MacOS/eclipse.ini

-XX:MaxPermSize=512m

-Xms512m

-Xmx1024m

Step 1: Add Google Play Library

To include external libraries you need to copy them into the module/android/libs folder in your module:

Step 3: Setup AndroidManifest.xml

Google Play services require you to specify the version of Google Play Services your app is working with in your app’s AndroidManifest.xml file.

To do this open your app’s module/android/build_steps.json file and make sure it looks as follows:

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

[

{

"do":{

"android_add_to_application_manifest":{

"element":{

"tag":"meta-data",

"attributes":{

"android:name":"com.google.android.gms.version",

"android:value":"@integer/google_play_services_version"

}

}

}

}

}

]

Step 4: Add Proguard rules

As part of the final compilation step, the Android compiler will use ProGuard to obfusticate the bytecode passed to it. This can cause problems with some libraries which rely on reflection to look up class and method information at runtime.

To prevent Proguard from obfusticating the Google Play Services library add the following to your module/android/build_steps.json file:

The State of the Hurt

Anyone developing for Android will be all too familiar with the compatibility issues that come up when trying to run apps on older Android devices. Historically, even the act of porting an app from a desktop browser environment to Android has been fraught with issues as the Android WebView lacked many basic HTML5 features and suffered from implementation problems.

While Google did much to rectify this after they started shipping a Chrome based WebView with Android 4.4 the reality is that, at the time of writing, Android 4.4 or higher devices still only account for 44.2% of the marketplace.

The remainder is made up of 7.3% devices still running Android 2.x while a massive 48.5% of devices are still running some version of Android v4.x with various non-Chrome versions of the Android WebView.

Image from: https://developer.android.com/about/dashboards/index.html

Finally, if you thought it couldn’t get any worse… even if we assume that at some point in the future we have a majority of devices running 4.4 or higher there is STILL no guarantee that your app will run smoothly across Android versions as it is entirely up to the vendor whether a given device will be receiving regular updates of the System WebView!

Against this background it therefore gives me great pleasure to announce that we have integrated Intel’s Crosswalk technology with Trigger.IO.

Starting from today your Forge apps only have to target a single web runtime for Android which covers 92.7% of all Android devices while retaining full access to all of our Forge API’s.

What is the “Crosswalk” Forge target?

Android versions before v4.4 shipped with a proprietary System WebView which lacked many basic HTML5 features, performed poorly and suffered from compatibility issues.

Android versions higher than v4.4 use a Chrome-based System WebView which, in turn, is based on the open-source Chromium code base which closely tracks HTML5 implementation standards.

Up till now, developing hybrid apps under Android meant that your app would be hosted by whichever System WebView shipped with the device forcing developers to take a “lowest-common-denominator” approach and spend an inordinate amount of effort to ensure rendering compatibility.

What the Forge crosswalk target does is to embed a build of the latest versions of the open-source Chromium WebView directly within your Forge application, allowing your app to execute in a uniform environment irrespective of the System WebView shipped with a particular device.

This means your app will behave exactly the same no matter which Android device it is running on!

How well does Crosswalk perform?

Apart from the tangible benefits that come from being able to target a uniform WebView, the Forge crosswalk target also provides significant performance improvements over all versions of the Android WebView, even those based on Chrome.

HTML5 Conformance

We checked a variety of Android devices against the HTML5TEST Benchmark for HTML5 conformance and found some interesting results:

VERSIONS OF ANDROID OLDER THAN v4.4

The older devices showed the most significant improvements over the default System WebView, in all cases exceeding even the iOS System WebView in compatibility scores.

VERSIONS OF ANDROID FROM v4.4 AND UP

Our biggest surprise from HTML5 conformance testing was the marked improvement we saw even for devices that shipped with a Chrome-based System WebView. Even the latest Chrome-based System WebView scored a couple points lower than Crosswalk. We attribute this to the fact that Crosswalk are able to more rapidly integrate and ship improvements from the upstream Chromium project.

CROSSWALK SCORE VARIATIONS

Something else we noticed was that there was some variation in crosswalk scores between devices. Closer investigation showed that, in all cases, the variation came down to the following HTML5 features which required hardware support:

WebAudio is only available on ARM devices that support NEON optimizations which were introduced with the ARM Cortex-A8 processor.

Newer Video Codecs require specific hardware support for decoding which is not present in some older Android devices. Our recommendation is that if you are in doubt, use H. 264 as support is a requirement for all Android devices on the market.

Support for the universally loathed DRM and Media Source extensions are tied to Video Codec support and may therefore not be available on some devices.

Javascript Performance

The impact of Chromium’s use of Google’s V8 Javascript engine is clearly visible in these results with older devices showing as much as a 60% improvement in execution speed.

Again, the advantages of crosswalk are evident even on newer devices where we see an 8% improvement on identical Nexus 7 hardware between the older Chrome-based WebView on Android 4.4.3 vs Android 5.0.2.

How do I use it?

Crosswalk is currently in Open Beta and can be accessed by changing your App’s platform_version to v2.3.1beta-3 and using the crosswalk target rather than android:

Open your application’s src/config.json file in an editor and set the platform_version key’s value as follows:

1

"platform_version":"v2.3.1beta-3",

Run your app from the Toolkit using the Crosswalk button or from the command-line with:

1

2

forge build crosswalk

forge run crosswalk

This is a Beta release so please don’t be dismayed if you run into issues. We’ll be standing by at support@trigger.io to answer any questions you may have!

When will it enter the stable platform branch?

The Crosswalk target is the biggest change we’ve implemented since the release of Android 4.x and the Crosswalk project itself is still under heavy development so we’re going to be holding off a bit on pushing it to the stable v2.2.x release stream until everyone’s had a chance to try and break it!

How much will it cost?

Integrating Crosswalk into Trigger.IO Forge has been a major engineering challenge which we’ve invested a lot of time, money and resources into.

Because of this, we did toy with the idea of making access to crosswalk exclusive to our Go Pro or higher customers as a way of recouping our development cost.

That said, our philosophy has always been to provide all of our customers with access to the best tools for Hybrid App development.

Our experience with Crosswalk is that it falls into that category of game-changing technology which everyone should have access to.

Therefore, we made the decision to make Crosswalk available, at no extra charge, to all of our customers irrespective of the plan they are on.

What about my custom modules?

We’ve been able to maintain binary compatibility with the vast majority of Forge modules and it is likely your modules will continue working “as is”.

If you have a custom module which is behaving strangely under Crosswalk please contact us at support@trigger.io and we’ll be happy to assist you with any changes that may be required.

In conclusion

By using the Forge Crosswalk target to build your apps you are now able to take advantage of a unified HTML5 runtime with significant Javascript performance improvements.

Crosswalk also offers a more rapid release cycle than the Android System WebView and continues to bring new HTML5 features and performance improvements to your app even on devices which are no longer supported by vendor updates.

With Crosswalk you are now also able to take advantage of many new HTML5 standards and features which, in the past, had to be avoided due to compatibility concerns, including:

3D CSS Transforms

WebGL

Date/Time input types

Multiple file selection

Raw Sockets

WebRTC

We feel that the integration of Crosswalk marks the beginning of a new era for our Forge standards-based Hybrid App Runtime and look forward to making the new capabilities developed by the W3C over the last few years available to all of our users.

Hi Trigger Folk,

Following a turbulent start at the beginning of the year our team have had the time of their lives delivering ongoing product development and world class support for your favourite hybrid app platform.

And what a twelve months it has been… over the course of this year we:

Resolved 1787 support tickets.

Released 80 module updates including support for major SDK updates from Facebook, Parse, Flurry, UrbanAirship and Apptentive.

Released 17 platform updates including support for iOS 8 and Android 5.0

Released Forge Live and sped up everyone’s development workflow by an order of magnitude.

Worked with the great folk at PushWoosh to bring you another option for Push Notifications on Android and iOS.

I’d like to say a special thank you to so many of our customers who have been incredibly supportive, patient and just plain awesome during this time. Without you it would never have been possible to successfully transition Trigger.io to become independent, profitable and able to remain this way!

The team will be taking a well-deserved break starting from this Monday, 22 December till Wednesday, the 7th of January 2015. We will however be responding to any critical issues that may come up during this time.

This email wouldn’t be complete without a hint at some goodies Santa has in store for us in 2015 so I’ll just say: This, this, some of this and definitely more of this.

All my thanks to our customers, business partners, StackOverflow contributors, module authors, GitHub contributors, contractors and everyone (past and present!) at Trigger. We wish you all a peaceful holidays and a truly satisfying new year!

Unless you’ve been living under a rock for the last few months you’ve probably heard some buzz on the interwebs about a new Javascript UI Framework called Famo.us that promises to change all the things!

Given the rate at which JS frameworks proliferate these days this could be a somewhat outrageous claim to make unless, in fact, it can and does.

I’ve been following their progress for some time now but rather than giving you my opinion I’ll ask you a few questions and then give you the opportunity to find out for yourself:

Would you like your app to feature silky smooth UI animations & transitions running @ 60fps without having to write native code?

Would you like the ability to create gorgeous custom user interface components that can compete with anything we’ve seen in native apps?

Would you like to easily populate a scrolling list view containing more than ten items without reducing your mobile device to a superheated vapour?

Would you like to do all of the above in Javascript without having to fight HTML & CSS every step of the way?

(Can you tell that I’m excited yet?)

If your answer to even one of these questions is “Hell Yeah!” then pop open a terminal window and do this: