Use Trigger.io and Mozilla’s PDF.js to build a PDF viewer for your Android app

one.png

While iOS has had a native PDF viewer baked into the WebView component for as long as I can remember the Android WebView is still unable to open PDF files for viewing.

Usually this problem is solved in one of two ways, neither of which are ideal:

1. Show the PDF file via the online view capabilities of the Google Doc Viewer.

  • Requires that the user sign into their Google Account before they can view the file.
  • It’s not immediately clear to the user how they should navigate back to your app.

2. Download the file locally and open it via an external Android app.

  • Complex to implement.
  • May fail if the user’s Android device does not have a PDF viewer installed.
  • It’s not immediately clear to the user how they should navigate back to your app.

In this tech note we’re going to explore a third option which uses Mozilla’s PDF.js library to seamlessly display PDF files in your app and does not suffer from any of the drawbacks above.

Introducing PDF.js

PDF.js is a HTML5 Portable Document Format (PDF) viewer built by Mozilla Labs. that can faithfully and efficiently render PDF files without native code assistance.

It provides excellent document rendering quality and is easy to integrate into an app to provide a workable solution to the problem of rendering PDF documents for your Android users.

You can find out more about the project on the GitHub page:

https://github.com/mozilla/pdf.js

Using PDF.js in your Trigger.io App

Step 0: Create an application

Create a new app and add the following modules to it:

  • file – unless you are viewing PDF files which are local to your app or can set CORS headers on the remote server you will need to use forge.file.cacheURL to obtain a local copy of the file.
  • tabs – you may wish to continue using the tabs module to display PDF’s on iOS

Step 1: Obtain the PDF.js library

While there are instructions for building the PDF.js library from source on the GitHub page we’ll be making our lives easier by using the bower package manager to obtain a copy of the library:

What this will do is add a subdirectory called bower_components to your app containing the following files:

If you don’t already have bower installed on your system you can head over to bower.io for installation instructions and documentation.

Step 2: Load the PDF.js library in your app

Open your app’s src/index.html file and add the library includes to the other content in your page’s <head> section:

Step 3: Create a custom PDFViewer

A huge advantage of using a HTML5-based PDF Viewer is you get a lot of control over how to represent the reader to your users.

Not only can the viewer itself be customized by modifying bower_components/pdfjs-dist/web/pdf_viewer.css but you also get complete control over how it will be hosted within your app.

For the purposes of this tutorial we’re going to replicate the look & feel of opening a PDF using forge.tabs on iOS to give us something like this:

Android PDF Viewer

Let’s open our app’s src/js/main.js file and implement a simple PDF viewer based on PDF.js:

Step 4: Test it!

Open up your app’s src/index.html file and add some code to test your viewer:

In Conclusion

In this short tutorial we walked you through the process of using Mozilla’s PDF.js library to build a simple PDF viewer you can use inside your Trigger.io app.

You can obtain copies of the full src/index.html and src/js/main.js files used for this demo here:

GitHub Gist

We hope you enjoyed it and are looking forward to hearing from you at support@trigger.io if you have any feedback or questions!

How to use Android AAR libraries with your Trigger.io Native Modules

aar.png

Third-party native libraries for Android are increasingly starting to appear only in AAR form.

This is wonderful if you’re using Gradle and/or Android Studio but the Trigger.io native module build system uses ant for build automation!

Fortunately, it’s relatively simple to convert an AAR library into a format you can use with your Trigger.io native modules.

If you were to unpack an AAR library you’d find that it is really just a standard Android library project which has been zipped up into a single file:

To import an unzipped AAR library into a Trigger.io module you would have to take the following steps:

  1. Convert any entries in AndroidManifest.xml to module/android/build_steps.json
  2. Copy classes.jar to module/android/libs
  3. Merge res/ with module/android/res
  4. Copy any jar files in libs/ to module/android/libs
  5. Copy any JNI libraries in jni/<abi>/ to module/android/libs/<abi>
  6. Create any entries in proguard.txt to module/android/build_steps.json

This can be a little overwhelming so we’ve written a small python script called import_aar.py which largely automates the process.

You can grab yourself a copy from here: import_aar.py

In the next section we’ll walk through an example of using it to import an AAR library for use by your native module.

Step 0. Backup your module directory!

Either commit the current state to source control or make a copy of your module/android directory so you are able to restore it to its original state if anything goes wrong during this process!

Step 1. Switch to at least Platform v2.2.11

To support JNI libraries we had to make some small changes to the Forge platform so you may need to update your module/manifest.json file’s platform_version to at least v2.2.11:

Step 2. Import aar libraries

Copy the import_aar.py script to your local machine and run it as follows on each of the aar files you wish to import:

Example

For the purposes of this tech note we’re going to walk through a simple module that uses the Google Play Services Maps .aar library to add support for the native Google Maps UI to your app.

First, start the Android SDK manager and make sure you have the latest version of the Google Play services package installed:

playservices.png

Next, copy the following aar libraries from your Android SDK directory into a temporary location:

Now you can impor the AAR library into your module as follows:

To use Google Play Services SDK you’ll also require a few additional entries in your app’s AndroidManifest.xml, so let’s add those to module/android/build_steps.json.

Google Play Version

Google Maps API key

You’ll need to replace the key below with your own key:

See https://developers.google.com/maps/documentation/android/start for instructions on how to get your own key.

Step 3. Update the Android inspector in the toolkit and write some code

Once you’ve imported the AAR libraries you’d like to use you can simply click the Update Android button in the Toolkit to refresh the Android Inspector project with the imported AAR library content.

Example

To test it, let’s add support for the Google Play Services Maps library we imported.

Open up the Android Inspector in Eclipse and create a new class called MapFragment in the ForgeModule project:

Next, you’ll need to add an entry to your app’s AndroidManifest.xml file for the MapFragment class. Do this by adding the following step to module/android/build_steps.json:

(Remember to update your inspector after making any changes to the files in your module’s module directory!)

Finally, edit API.java and add the following API method to your module which will instantiate the MapFragment class you created above:

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:

screenshot1.png

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!

Connect Everything to Everything Else With Trigger.io and PubNub

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.

iot.jpg

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.

Although realtime web technologies have been around for some time it’s only quite recently they’ve started to pervade everyday activities, such as hailing a taxi, keeping track of sports scores, bidding in an online auction or even opening the door to the garage.

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.

iot.jpg

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.

Their wide range of robust, friendly APIs merge seamlessly with Trigger.io’s fast, effective hybrid mobile runtime, bringing realtime technology to mobile.

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

2.png

Create a new app in the Trigger Toolkit.

Step 2

3.png

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

4.png

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:

5.png

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:

Step 5

Click here to go to PubNub’s 10chat demo page:

box.png

…now copy the 10chat javascript code from the code box into your app’s index.html file:

Step 6

Save the file, go back to the Trigger Toolkit and run the app again.

Now if you open the 10chat page in a web browser you’ll be able to chat back and forth between the two!

8.png

Learn More

We hope you enjoyed this short introduction.

For more in-depth tutorials on PubNub, please visit the PubNub Data Stream Tutorial page.

If you’re interested in learning more about using PubNub with Trigger.io please give us a ping at support@trigger.io, we’d love to hear from you!

Setting Up Google Play Services for a Trigger.IO Native Module

Google Play Services Logo

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:

  1. Add the Google Play Services Jar file to your module.
  2. Add the Google Play Services resource directory to your module.
  3. Add a meta-data tag for the app’s AndroidManifest.xml file
  4. Add Proguard rules to allow Google Play Services to use reflection.
  5. 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:

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 2: Add Google Play Resources

To include the external resources used by the Google Play Services library you will need to copy them into the module/android/res folder.

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:

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:

Step 5: Update Inspector

The final step just requires you to update your module’s inspector project by navigating to your module in the Trigger Toolkit and hitting the “Update Inspector” button.

Please give us a shout at support@trigger.io if you have any questions.

Solving Android Fragmentation with Trigger.IO Forge and Intel’s Crosswalk

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.

source: https://developer.android.com/about/dashboards/index.html

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:

HTML5TEST 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

For Javascript performance we evaluated the same set of devices against the Octane 2.0 Benchmark:

Octane 2.0 Results

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:

  1. Open your application’s src/config.json file in an editor and set the platform_version key’s value as follows:
  2. Run your app from the Toolkit using the Crosswalk button or from the command-line with:

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!

To track release information you can go to: Forge Beta Release Notes

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.

Happy hacking everyone!

Another splendid year at Trigger.io

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.
  • Released our entire catalogue of native modules as open source.
  • Began building a community of contributors to our open source modules. Thank you for everyone who sent in a push request or three, you know who you are!
  • Introduced you to the future of hybrid app UI’s with our introduction to Famo.us with sloths
  • 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: Thisthis, 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!

 – Antoine

Wrapping Famo.us with Trigger.io for Silky Smooth UI Animations at 60fps

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:

And this:

Answer the prompts truthfully and then you can go:

Or, if you prefer:

Which should give you something like:

Problems?

Want Moar?

Keep an eye on @triggercorp for our upcoming Famo.us Trigger.io tutorial covering the ins and outs of using Forge native modules with Famo.us.

In the meantime, you can check out our sample app built with Trigger.io and Famo.us here: https://github.com/trigger-corp/tutorial-famous/

image

What’s a generator anyway?

When you did this:

…you invoked a generator that creates a seed app configured with all the bits and bobs needed to use Famo.us within a Trigger.io app.

Generators are built using a really cool tool called Yeoman which also allows you to create seed projects for many other kinds of JS frameworks and projects.

You can check the famous-triggerio generator out here: https://github.com/trigger-corp/generator-famous-triggerio/

We’re currently working on creating Trigger.io generators for a number of other frameworks, let us know if there’s a framework you’d like to see us support!

What do hybrid apps have in common with sloths?

Hint: It’s not velocity

Ridiculously fast Trigger.io app development with Forge Live

Today we released v2.1.7 of the Forge platform and with it, a major new feature we’re really excited about: Forge Live

 

Forge Live shows you the effect of your code changes in real-time on an emulator or device making the the mobile build / deploy / test cycle faster than even the web (you don’t need to refresh!).

See it in action now:

Background

It’s almost halfway through 2014 and there’s never been a better time to be hybrid app developer.

Frameworks such as AngularJS, Ionic and React promise an order of magnitude improvement in developer productivity. Coming up we can also look forward to technologies such as Famo.us, WebGL and Apple’s Nitro JavaScript engine. Technologies which promise a level of performance that will open up a whole new class of applications that could previously only be tackled by native developers.

That said, one thing that doesn’t seem to be receiving much love is mobile app development workflow.

Frankly, writing apps for iOS or Android feels much like desktop app development did in the early 90’s!

  • Write some code
  • Compile your app
  • Deploy to device
  • Run app
  • Wash. Rinse. Repeat.

While this model is not without its advantages  it’s a shame to be bound by limitations inherent to compiled languages such as Java and Objective-C when hybrid app development is built on the same dynamic languages that make web development as easy as:

  • Write some code
  • Hit Refresh

In fact, using tools such as grunt-contrib-watch to detect changes to your files and then automatically trigger a browser reload the entire cycle can be reduced to a single step.

That’s why we created Forge Live!

Using Forge Live

Note:

If you are developing for Android please note that Forge Live is only supported on devices running Android KitKat (4.4.x) or higher.

Step 1: Install Node.js

Before you can start using Forge Live you will first need to install Node.js on your machine. You can either use your favourite package manager or download an installer from: http://nodejs.org/download/

Note:

On newer versions of Ubuntu the packaged node binary has been renamed to nodejs due to a conflict with another package. Unfortunately this has the side-effect of breaking grunt.

The workaround is to install the nodejs-legacy package as follows:

Step 2: Check your Platform Version

If you’ve just created a new app you won’t need to do anything here.

If you want to use Forge Live with an existing app you will first need to check that your app is compiled with Forge 2.1.7 or higher.

You can do this from within the Trigger Toolkit:

Or in your src/config.json file:

Step 3: Start your app

Once your app is on the latest stable platform version you are ready to start your app up in Forge Live mode.

To do this, simply navigate to the Forge Actions page and click on the platform you’d like to work with:

Or with the command-line tools:

Followed by:

Any changes you make to your source code will now be instantly reflected in your running app. It’s that easy!

If you’d like more information about using Forge Live you can also look at the documentation.

We’d love to hear what you think about Forge Live so please feel free to contact us on support@trigger.io with any questions or feedback.

A new year with Trigger.io

Ho Trigger Corps!

It’s now been just over two months since I took over the role of day-to-day management at Trigger.io and it’s time to take stock of what we’ve accomplished during this time.

This year I’ve had a chance to meet many of you for the first time and I’m pleased to report that we’ve been able to keep the promise we made to maintain the high bar Trigger.io sets for customer support. It’s been 75 days and during this time you’ve opened 420 support tickets and we, in turn, have resolved 425 support cases.

That said, despite all odds, life at Trigger.io hasn’t just been about support.

We’ve also managed to keep product development ticking over with 2 minor platform updates, 2 new native module releases and more than 10 updates to our existing native module line-up.

After open-sourcing our modules in December last year we’ve noticed a steadily increasing stream of pull requests coming in to the repositories that benefit our entire Trigger.io community.As a result it is largely due to your effort that we’ve been able to keep Trigger.io development moving.

Thank you Trigger Corps, You rock.

-Antoine

 

New Native Modules

 

Native Module Updates

  • forge.notification v2.3 New method: getBadgeNumber
  • forge.launchimage v2.4 New option: background-size: cover, iOS7 fixes
  • forge.file v2.3 New method: file.info()
  • forge.parse v2.3 New methods: setBadgeNumber, getBadgeNumber, registerForNotifications, Added support for Google Cloud Messaging, Update to latest Parse SDK
  • forge.flurry v2.4 New option: debug, Update to latest Flurry SDK
  • forge.facebook v2.3 Update to latest Facebook SDK
  • forge.media v2.2 Fix for mute switch position being ignored. (Thanks @mnaughton !)
  • forge.request v2.5 Fix HTTP method and contentType settings being ignored for file uploads
  • forge.contact v2.3 Fix a crash when selecting all contacts on Android

Read the full changelog here

 

Core Platform Updates

We’ve pushed out two minor updates to the core platform which brings us up to v2.1.2.

These updates fixed a number of annoying bugs, made some progress towards a better code signing experience for our Windows customers, brought our Android native API support up to android-19 and added Chrome DevTools remote debugging support for Android KitKat devices.

If you’re not already on 2.1.2 do consider updating your projects today!

Read the full changelog here

New Hires

I’m really pleased to announce our new team member, Gaelin Meyer, who has been doing a great job managing Accounts and Marketing for us here at Trigger.

Gaelin has been working in an advisory capacity with several Internet Startups here in Cape Town since 2005, holds a degree in Psychology from the University of South Africa and is busy raising two beautiful children.

Her primary responsibility is to know what you need from us at Trigger.io, so expect to hear more from her in the upcoming months!