Team changes at Trigger.io

Trigger.io is now nearly 3 years old and publicly available since January 2012. We’re delighted with how it has grown from a useful product — 10,000 developers signed up, and millions of app builds — to become a profitable business as of September this year.

We’re proud of the self-sustaining community that has built up around Trigger.io, with several people making their livelihood building apps for clients on our platform, and contributions from the community on StackOverflow. Last week we open-sourced our native modules and can already see developers begin to contribute.

At this point, James and I have made the decision to step back from day-to-day work on Trigger.io, and for the company to bring in new blood. Antoine van Gelder, whom many of you already know, will take over day-to-day management and new development.

We’re delighted to have Antoine take this on and anticipate only positive changes for current and new customers — there is no change to the availability of the Trigger.io service, support or plans for new development. James and I will continue to be involved as directors working with Antoine to improve the company and product, although you’ll see less of us in day-to-day communications.

Antoine

 

We’ve worked with Antoine for almost as long as Trigger.io has been around. He was instrumental in getting the product to launch, working across our entire stack from the client SDKs, Toolkit, server-side logic and compile servers. In addition to his development work, he has also interacted with many customers through support and through the maintenance of our legacy browser add-on platform.

Not only that, but Antoine has broad experience running all aspects of software companies having built his own startup and run consulting companies in the past. He’s a keen advocate of standards, open source and creating great products that benefit with the world. All that — combined with his technical expertise, knowledge of the Trigger.io stack, and product philosophy — means we are supremely confident that he is the right person to take Trigger.io from here.

With our v2.1 release we felt the company and product are in great shape and could benefit from new inspiration, so the time is right to pull the trigger (pun intended). Anyone who has worked on the same product for several years will know that it can often benefit from a new perspective, so we’re confident that the plan we’ve put together with Antoine is a win all around.

The future

James and I delight in creating new products and businesses which is why we started Trigger.io. We love what we’ve built with Trigger.io but over the past year have also become excited about other projects.

Specifically — based on many shared interests — James, Tim, Connor, and I have decided to join Square. We’re super excited about Square’s prospects, their team, and the new projects that we can impact there. Making commerce easy — Square’s mission — is inspiring and has many facets. We hope to iterate fast and be able to share more of what we’re working on soon.

We’re delighted at being able to make this team change while having the Trigger.io product continue to improve and grow sustainably. It’s a situation that few startups are able to reach, and we owe it all to our amazing customers: thank you!

Please do reach out by emailing support@trigger.io with your questions.

New feature roundup: iOS 7 and Android 4.4 support, new accelerometer and Apptentive modules

As well as a host of minor improvements and fixes which are documented in our module changelog, we’ve been hard at work on some big items.

Namely, support for new iOS and Android platform versions and two new modules: one developed by us, another by a 3rd party which we’re delighted to be able to offer.

Here are the details:

Apptentive: in-app feedback from your users

Apptentive provide SDKs for iOS and Android that enable you to get in-app feedback from your users.

Interacting with your users inside your app is immensely important to boost ratings – create conversations rather than critics and intercept negative feedback. So we’re really excited that they’ve created a Trigger.io module so you can use their SDK in your Trigger.io app:

forge.apptentive.showMessageCenter(
    {},
    function(error) {
        forge.logging.info("Error: " + error.message);
    }
);

This example shows how Apptentive can be used to solicit feedback. In addition, the Apptentive module provides:

  • App Store rating flow
  • Surveys
  • Custom user information tracking
  • Custom device data tracking

We’re excited for future updates by Apptentive and other SDK developers who integrate with Trigger.io.

Accelerometer module

By popular demand, we’ve created an accelerometer module. Here’s an example of how it can be used to detect whether the phone is laying flat:

// Alert the user the first time they put their device on a flat surface
forge.accelerometer.onChange.addListener(function (data) {
	if (data.z > 9 && data.z < 11) {
		forge.accelerometer.clearWatchInterval();
		alert("Phone is flat");
	}
});
forge.accelerometer.setWatchInterval(1);

iOS 7 and Android 4.4 support

We released support for iOS 7 in September as part of our v2.0.1 platform version, with several new module versions. You can read details of the changes here.

More recently, we were very excited about Android 4.4 (KitKat) which was released last week. Especially since this new version of Android will have its WebView powered by Chromium. That’s great news for developers since it means that, in Trigger.io apps built for Android 4.4, you can use:

To start building for Android 4.4, you will need to:

  1. Rebuild with our latest platform version – 2.0.4
  2. Update tabs module to 2.5
  3. Update ui module to 2.1

What’s next?

Follow us on Twitter or Facebook to see our latest news and updates.

Sign up now to take advantage of these new features or get in touch with us at anytime at support@trigger.io.

Guest post – how CardSmith build for mobile using Trigger.io

This guest blog post was written by Scott McClure, developer at CardSmith, currently building the mobile version of their access, tracking, and verification application using Trigger.io. He also manages the build and release processes for the company. 

About the app

PockeTracker is a mobile application that allows users to verify admittance to facilities and events, take payments on location, and track attendance. It supports an offline mode and the ability to scan ID cards with magstripe, barcode, or contactless card readers. Version 3.0 of the application was redesigned from the ground up using Trigger.io.

Why Trigger.io?

We had several specific requirements for the tools needed to build the next generation of our mobile application.

  1. We wanted to write the majority of the code in a language everyone on the development team was familiar with.
  2. We needed to be able to target both iOS and Android platforms.
  3. If we were going to use a hybrid model approach we would still need direct access to the underlying OS. Direct access was particularly important because the application needed to integrate with several different magstripe, barcode, and contactless card scanners, and keyboard emulation would be insufficient to accomplish this. Also, we were going to need to support an offline mode with large amounts of data being cached locally. We felt for performance reasons that this should be implemented natively.
  4. Any tools required for building and packaging the application needed to integrate seamlessly into our current build process.

Trigger.io fit all of these requirements and we have been very pleased with the final results.

I’d like to share with you how we accomplished the last requirement to integrate with our current build process.

Build Process

For all of our applications, we rely on Subversion for source control and TeamCity for build management. With PockeTracker, we now also use the standalone build API provided by Trigger.io. Source code check-ins are automatically detected by TeamCity, then checked out by the build agent and sent via HTTP to the Trigger.io standalone build service.

We could have just as easily used the Trigger.io command line tools instead of the standalone API, but using the API gave us one less build agent dependency to maintain.

Currently, our build tasks include:

  1. Check out the latest source from the trunk
  2. Run our JavaScript modules through the Require.js optimizer
  3. Update the build number in the config.json file
  4. Zip the source folder
  5. Send the zip to the Trigger build service
  6. Monitor the build for a success or failure
  7. If successful, download the package and publish it

Checking out

This isn’t really a post about how to set up a TeamCity build configuration, but TeamCity makes it very easy to monitor a Subversion repository for changes and check out the updated source onto a build agent. It simply requires you point TeamCity to your repository, add your login information, and create a build process trigger.

Updating the build number

Once a change is detected and the source downloaded, we need to update the version number found in the config.json configuration file. Using a custom C# build runner plugin, and taking advantage of the JavaScriptSerializer class we are able to accomplish this fairly easily:

const string PATH = @"%teamcity.build.checkoutDir%/src/config.json";

JavaScriptSerializer serializer = new JavaScriptSerializer();
var jsonObject = serializer.DeserializeObject(File.ReadAllText(PATH)) as Dictionary;
jsonObject["version"] = "%MajorBuildNum%.%MinorBuildNum%.%RevisionBuildNum%";
File.WriteAllText(PATH, serializer.Serialize(jsonObject));

Zipping the source

Once the build number is updated, we use the NAnt runner to zip the contents of the ‘src’ folder:

<?xml version="1.0" encoding="utf-8"?>
<project name="RapIDTrack 3 Client" default="build" basedir=".">
  <target name="zipME">
    <zip zipfile="%system.teamcity.build.checkoutDir%\src.zip">
      <fileset basedir="%system.teamcity.build.checkoutDir%\src">
        <include name="**.*" />
      </fileset>
    </zip>
  </target>
</project>

Push, monitor, and download

Out last steps are to push the zip file to the Trigger standalone build service, monitor for a successful build, and download the package. Again, we used the C# build runner.

To push the zip file along with some configuration settings, we prepare a web request. Since we are currently only building for Android, we only need to include the required email, password, and ‘and_*’ fields.

const string boundary = "---------------------------AaB03x";
const string url = "https://trigger.io/standalone/package";
const string email = EMAILADDRESS
const string password = PASSWORD;
const int MAXTRIES = 500;
const String DLDIR = @"%teamcity.build.checkoutDir%";
const String BUILDNUM = @"%build.number%";

Dictionary<String, String> nameValues = new Dictionary<string, string>();
Dictionary<String, String> namePaths = new Dictionary<string, string>();

nameValues.Add("email", email);
nameValues.Add("password", password);
nameValues.Add("and_keypass", ANDROIDKEYPASS);
nameValues.Add("and_storepass", ANDROIDSTOREPASS);
nameValues.Add("and_keyalias", ANDROIDKEYALIAS);
namePaths.Add("src_zip", @"%teamcity.build.checkoutDir%\src.zip");
namePaths.Add("and_keystore", @"%teamcity.build.checkoutDir%\ + ANDROIDKEYSTORENAME");

HttpWebRequest req = (HttpWebRequest)WebRequest.CreateHttp(url);
req.Timeout = 300000;
req.Method = "POST";

req.Accept = "application/json";
req.ContentType = String.Format("multipart/form-data; boundary={0}", boundary);

StringBuilder body = new StringBuilder();
using (System.IO.Stream s = req.GetRequestStream())
{
	foreach (String name in nameValues.Keys)
	{
		String line = String.Format("--{0}\r\nContent-Disposition: form-data; name=\"{1}\"\r\n\r\n{2}\r\n", boundary, name, nameValues[name]);
		byte[] buff = Encoding.UTF8.GetBytes(line);
		s.Write(buff, 0, buff.Length);
	}

	foreach (String name in namePaths.Keys)
	{
		String line1 = String.Format("--{0}\r\nContent-Disposition: form-data; name=\"{1}\";filename=\"{2}\"\r\nContent-Type: application/base64\r\n\r\n", boundary, name, Path.GetFileName(namePaths[name]));

		//stream the description
		byte[] buff = Encoding.UTF8.GetBytes(line1);
		s.Write(buff, 0, buff.Length);
		//stream the file
		buff = File.ReadAllBytes(namePaths[name]);
		s.Write(buff, 0, buff.Length);
		//stream end
		buff = Encoding.UTF8.GetBytes(Environment.NewLine);
		s.Write(buff, 0, buff.Length);
	}

	//end our form data
	String endLine = String.Format("--{0}--", boundary);
	byte[] endBuff = Encoding.UTF8.GetBytes(endLine);
	s.Write(endBuff, 0, endBuff.Length);
}
...

Next we send the POST request and get the response:

using (HttpWebResponse resp = (HttpWebResponse)req.GetResponse()) {
	if (resp.StatusCode == HttpStatusCode.OK)
	{
		//GOOD response should be in the form of:
		//{"id": "SOME GUID HERE", "result": "ok"}
		//BAD response will be:
		//{"errors" { JSON ARRAY OF ERRORS } }

		StringBuilder sb = new StringBuilder();
		using (StreamReader r = new StreamReader(resp.GetResponseStream()))
		{
			while (!r.EndOfStream)
				sb.Append(r.ReadLine());
		}//end using
		String response = sb.ToString();

		JavaScriptSerializer jsSerializer = new JavaScriptSerializer();
		var pushResult = jsSerializer.DeserializeObject(response) as Dictionary<string, object>;
		if (pushResult.ContainsKey("result") && String.Compare(pushResult["result"].ToString(), "ok", true) == 0)
    ...

If the response is OK, we periodically call the service with the ID that was supplied to monitor the build progress:

String id = pushResult["id"].ToString();
Console.WriteLine(String.Format("Response Success, ID is: {0}", id));
Console.WriteLine("Monitoring Build...");

//monitor the build by periodically asking if the build is complete, using id
String askURL = String.Format("https://trigger.io/standalone/track/package/{0}?email={1}&password={2}", id, email, password);
int count = 0;
while (count < MAXTRIES)
{
	HttpWebRequest askReq = WebRequest.CreateHttp(askURL);
	askReq.Method = "GET";
	using (HttpWebResponse askResponse = (HttpWebResponse)askReq.GetResponse())
	{
		sb = new StringBuilder();
		using (StreamReader r = new StreamReader(askResponse.GetResponseStream()))
		{
			while (!r.EndOfStream)
			  sb.Append(r.ReadLine());
		}//end using

		String askResponseBody = sb.ToString();
		var monitorResult = jsSerializer.DeserializeObject(askResponseBody) as Dictionary<string, object>;
		String state = monitorResult.ContainsKey("state") ? monitorResult["state"].ToString() : null;
		if (String.Compare(state, "success", true) == 0)
		{
            //DOWNLOAD THE FILE
            //...
		}
    else if (String.Compare(state, "failure", true) == 0)
		{
			Console.WriteLine("Response Is FAILURE");
			Console.WriteLine(askResponseBody);
			count = MAXTRIES;
		}
		else
			Console.WriteLine(String.Format("Something went wrong. Response Is: {0}", askResponseBody));
	}//end using

    count++;
}//end while

If the service returns a “SUCCESS” message, then we just grab the package URL and download it. Otherwise, we write the return message out to the console so the build log will show the reason for the failure:

//get our Android package download url
//should be in form {"info": {"files": {"android": "ADDRESS"} ...
var info = monitorResult["info"] as Dictionary<string, object>;
var files = info["files"] as Dictionary<string, object>;
String dlURL = files["android"].ToString();
Console.WriteLine(String.Format("Download URL: {0}", dlURL));
Console.WriteLine("Downloading File...");

//download our file
HttpWebRequest dlReq = WebRequest.CreateHttp(dlURL);
dlReq.Timeout = 600000;
using (HttpWebResponse dlResp = (HttpWebResponse)dlReq.GetResponse())
{
	//stream to dl directory
	using (Stream r = dlResp.GetResponseStream())
	using (FileStream fs = new FileStream(String.Format(@"{0}\PockeTracker_{1}.apk", DLDIR, BUILDNUM), FileMode.Create))
	{
		byte[] buff = new byte[2048];
		int bytesRead = 0, totalBytesRead = 0;
		while ((bytesRead = r.Read(buff, 0, buff.Length)) > 0)
		{
			fs.Write(buff, 0, bytesRead);
			totalBytesRead += bytesRead;
		}//end while
		Console.WriteLine(String.Format("Downloaded {0} bytes", totalBytesRead));

		success = true;
		Console.WriteLine("Downloading Complete!");
	}//end using
}//end using

The downloaded package is then published internally for acceptance testing.’

Closing thoughts

Of course, there are many improvements we would like to make to the process. Automating our QUnit tests for the main application and JUnit tests for each Android native module will be our next priority. Another priority will be to add in support for our iOS native modules once those are completed. I hope that this example of our experience with the Trigger.io standalone build API will help you with your own build processes.

Sign-up for Trigger.io now to get started with your mobile app. Questions? Email support@trigger.io anytime.

Introducing OpenForge: an open-source cross-platform browser add-on framework

Trigger.io makes it simple for web developers to create native mobile apps for iOS and Android using JavaScript. But early on in our company’s history we also created a cross-platform browser add-on framework for Chrome, Firefox, Safari and Internet Explorer.

We are now open-sourcing that codebase, calling it OpenForge.

This codebase will be far from stale – development of the browser add-on framework will continue with a full-time maintainer who will also provide support. In open-sourcing the framework we have also provided the ability to build locally without reliance on Trigger.io infrastructure.

This will benefit customers that have already been building using our browser add-on tools, and make it possible for others to see, use and contribute to the codebase.

Codebase, docs and support

You can see the browser add-on platform code and tooling to build in this repo:
https://github.com/trigger-corp/browser-extensions

The README instructions give information on how to setup for local builds. The codebase is released under the BSD 3-part license which allows for unlimited commercial use. API docs are available here in Trigger.io’s legacy docs. In the future they may be hosted elsewhere but will be linked to from the README.

It is possible to get started using the framework for free, but as you get more serious you may want to get professional support to make sure your questions and issues are resolved, and any modifications you need are handled quickly. Antoine van Gelder at 7degrees is available to be contracted for this.

The history of OpenForge

OpenForge came out of the work that James Brady and I did with WebMynd where we built browser add-ons for search personalization that were downloaded more than 1.5M times.

We built a set of libraries for our own use to abstract away cross platform differences and realized that they could be useful to other developers. At the same time we saw the growth in Android and the problems that web developers faced in building for both that and iOS, and so Trigger.io was born.

The focus of Trigger.io has been on mobile platforms for a long time now, but at the start we also invested significantly in making our internal browser add-on libraries useful to others, and many of our team members contributed to that.

Initially our libraries were for Chrome, Firefox and Safari. Antoine van Gelder came on board and wrote the Internet Explorer SDK from scratch. At the same time in summer 2011 Connor Dunn and James Brady re-wrote much of the Chrome and Firefox code to tidy up and improve what we’d used ourselves to be ready for more public release. I then brought the Safari SDK up to speed.

Since then Tim Monks has improved the tooling, with Connor and especially Antoine continuing to update the SDKs.

What’s next?

With this announcement, Trigger.io’s browser add-on business is now completely separate from mobile. On the mobile side, with the Forge v2 platform release, we’ve been able to iterate native modules faster and faster.

You can expect more new modules, improvements to existing ones and our build tooling soon. As always we’re eager to hear from you either about OpenForge for browser add-ons or Forge for native iOS, Android and mobile web. Just contact support@trigger.io with your feedback or questions.

Trigger.io v2.0 – create and re-use native mobile components

Trigger.io makes it simple for web developers to create native mobile apps for iOS and Android by using JavaScript to compose different native features.

Today we release our v2 platform which enables developers to create and re-use native modules provided by 3rd parties.

 

In the past if you wanted to add a native feature to your app that was not supported by existing Trigger.io Forge APIs, you would have to dive down into native code yourself or hire a contractor to do that. Trigger.io v2.0 is a big deal since developers can now make the native modules they’ve built on top of Trigger.io available for re-use.

Ultimately this means you’ll be able to select from a much broader range of native features – both the core APIs built by our team and others contributed by 3rd parties – and combine them with the best of HTML5.

You can see some examples on modules page right now:

We’ll be publishing several more in the coming weeks. If you have already built a Trigger.io plugin and would be interested in making it available to others as a module, please get in touch, we’d love to hear from you.

The journey and v1 product

We launched Trigger.io last year because of the huge shift to mobile and our desire to help web developers navigate that. Our core community of developers grew fast. They told us that they loved our platform because of the super fast build / test cycle, fast native bridge, and rich API which includes native UI components and integrations with cloud services which is much broader than alternatives.

All of that is enabled by our Toolkit UI, command-line tools and unique Forge build technology.

Later Reload made the proposition to web developers even more compelling: update your app at web speed without needing to go through the App Store approval process. On top of the ROI benefits to being able to reuse web code and skills when you first build your app, Reload makes a Trigger.io-style hybrid mobile app better for the long-haul when you update your apps and manage their lifecycle.

But what if you need a native mobile feature that the Trigger.io Forge APIs don’t support? We want you to have the best possible development process without compromising on your your app features, so we enabled extensibility through plugins. Now we’ve taken that extensibility to another level.

What Trigger.io v2.0 means for developers

Our v2.0 platform is a big step forward, but if you’re already familiar with our platform, you’ll see our commitment to speed in the build process, native wrapper, and the broad range of APIs remains the same – our module ecosystem is an addition, not a major change to what you’re already using.

But now, web developers who are building mobile apps with Trigger.io will be able to access to a broader range of APIs including cloud service integrations and native UI components sooner. Because you’ll be able to use 3rd party developed modules as well as those built by our team here at Trigger.io.

Instead of contracting for services whenever you want a new new feature for your native app, you’ll be able to pick-up and integrate re-usable components.

For developers who are able to build natively, you can make re-usable components available through our platform so you don’t need to repeat your work for each new client engagement. While you can’t charge for individual modules right now, you can use our platform to get more customers for your services and support contracts. And in the future we’ll enable a rev-share so you can earn a passive income from your work.

What’s next?

If you’re building, or thinking about build mobile apps, you’re concerned about which platforms you should be supporting, the upcoming iOS7 release and figuring out the set of features you’ll need – we’re there for you. Please get in touch at support@trigger.io so we can try to help.

Our plan is to continue to focus on improving our tooling and making the build / test cycle as simple as possible. While building a high quality module ecosystem that gives you the broad range of features that you can compose in new and interesting ways.

Mobile development should be a pleasure. Right now it isn’t. We’re further along the path and are determined to help web developers get there.

 

New feature roundup: native confirm, loader and Android toasts UI, audio playback and new foreground camera module

You asked for more native UIs and we’ve delivered!

On top of that we’ve expanded on our native APIs by enhancing the media module for audio playback and adding a new foreground camera module for use with older Android versions where the file.getImage API doesn’t suffice.

We’ve had a much broader range of APIs in our core product than other hybrid platforms for a while – it’s not just about native features, but also UI components and cloud SDK integrations, as you can see from our features summary.

Here are the details:

Native confirm, loader and toast UIs

 

Available on both iOS and Android, we’ve added new native UI components in the notification module.

You can show and hide a native loader using forge.notification.showLoading and forge.notification.hideLoading:

forge.notification.showLoading("Please wait", "Video is loading...", function() {
    //Success callback
}, function() {
    //Error callback
});

You can prompt the user for confirmation using a customizable confirm UI with forge.notification.confirm:

forge.notification.confirm("Confirm your action", "Are you sure you to delete this item?", "Yes", "No",
    function (userClickedYes) {
      if (userClickedYes) {
        // ... implement logic for when user clicked "Y"
      } else {
        // ... implement logic for when user clicked "N"
      }
});

“Toasts” are small temporary popups which are great for giving your user unobtrusive feedback as they use your app. We’re pleased to now offer a toast API for Android and iOS: forge.notification.toast.

These features make it easier than ever to make your Trigger.io look and feel native since you can use actual native UI components rather than working on mimicking them in HTML5.

Audio playback

Our media module has had a native video playback API for a while.

And although it’s possible to achieve audio playback using HTML5 <audio> or <video> tags we’ve had many requests for more control over the audio player than HTML5 on its own can offer. So we’ve introduced native audio player controls with the forge.media.createAudioPlayer API.

forge.file.getLocal("music.mp3", function (file) {
  forge.media.createAudioPlayer(file, function (player) {
    player.play();
  });
});

As well as the basic “play” method, the audio player has the usual “stop” and “pause” controls plus APIs to get the “duration”, “seek” a particular position in the track and listen for playback position changes with “positionChanged.addListener”.

Foreground camera module

Older Android versions can struggle with the memory requirements of the forge.file.getImage API which provides native camera access. To handle that, we’ve added a new foreground camera module to be used on Android only.

Unlike the file module this module displays the camera as part of your app. Although this means that the user will not have the option to select an image from the gallery, or perform advanced options such as zooming or changing other camera settings, on low memory devices this is a more reliable method of capturing a photo – it tends to be snappier too!

What’s next?

Follow us on Twitter or Facebook to see our latest news and updates.

Sign up now to take advantage of these new features or get in touch with us at anytime at support@trigger.io.

Webinar: learn how to build native plugins for Android

Join James Brady, Trigger.io CTO on Tuesday, May 14 at 10am (Pacific time) for our second webinar covering native plugins. This webinar is open to all Trigger.io customers and free trial users.

Build native plugins for Android

Join us for a Webinar on May 14

Space is limited. Reserve your Webinar seat now at:
https://www1.gotomeeting.com/register/854875241

Details

Trigger.io co-founder and CTO, James Brady, demonstrates how to get started building a native plugin for Android.

There will be an opportunity to ask questions about your specific app, and the best one will earn the asker an exclusive Trigger.io t-shirt!

Title: Trigger.io Webinar: build native plugins for Android
Date: Tuesday, May 14, 2013
Time: 10:00 AM – 10:45 AM PDT
After registering you will receive a confirmation email containing information about joining the Webinar.

System Requirements

PC-based attendees
Required: Windows® 7, Vista, XP or 2003 Server

Macintosh®-based attendees
Required: Mac OS® X 10.5 or newer
Mobile attendees
Required: iPhone®/iPad®/Android™ smartphone or tablet

Trigger.io named to Facebook’s Technology Partners Program

Social features in your mobile app have never been easier with Trigger.io

We’re excited to announce that Trigger.io has been named to Facebook’s Technology Partners Program.

See the integration in action with this short screencast showing how fast you can get started with our demo app and tutorial:

Trigger.io makes it simple to create amazing mobile apps using the best of HTML5 and native. You write your code in the JavaScript using our APIs and can build native apps for iOS and Android in seconds. Sign-up now to try it for yourself.

We’ve integrated the Facebook SDKs for iOS and Android into Trigger.io so you can now access native Facebook SDK features through our JavaScript API. Check out the Facebook module documentation.

When it comes to social and sharing, Facebook is a ‘must have’ for your mobile app.,

Customers are already using it – check out PumpUp

Many of our customers such as PumpUp are already taking advantage of the integration.

PumpUp is a new mobile app that provides you with personalized workout sessions based on your fitness and goals. Check it out in the App Store.

They’ve used our integration with Facebook to handle user login, and let users publish their workouts to their stream to get motivated. Here’s what the co-founder of PumpUp said about Trigger.io and the integration with the Facebook SDK:

Trigger made it dead simple for us to integrate with the native Facebook SDK and implement push notifications as well. Their Reload feature also lets us push test builds to my debug users as well as do A/B testing with live users. I can’t believe how much Trigger has accelerated our development — we’d be nowhere near where we are today without it! I’d recommend Trigger as the superior alternative ”

How to get started with our demo app

We’ve created a simple demo app to get you started – you can see it in action in the screencast above and the code is here.

Simply follow the instructions in the README to start building. It explains the simple steps to setup Trigger.io and the Facebook configuration to get started.

Dive into the code to see how you can use the Trigger.io Forge API to interact with the native topbar UI element and get fine geolocation using GPS:

forge.topbar.show();
forge.topbar.setTitle('Scrumptious');
forge.geolocation.getCurrentPosition( {
  enableHighAccuracy: true
}, function(location) {

});

 

And see how simple it is to enable Login with Facebook and Open Graph calls:

forge.facebook.authorize(['publish_actions'], function(token_information) {
  logResponse(token_information);
  window.location.hash = '#menu';
});

 

forge.facebook.api("/me/trigger-scrumptious:eat",
  "POST",
  params,
  function (response) {
    logResponse(response);
    if (!response || response.error) {
      errorHandler(response.error);
    } else {
      handleOGSuccess(response);
    }
  }
});

 

What’s next

If you’re building mobile apps incorporating social features, we’d love to hear from you – get in touch with us at support@trigger.io and sign-up to get started now.

With the Technology Partners Program, Facebook is committed to providing the best tools for you to be successful building social apps and we’re delighted to partner with them for mobile.

Expect more integrations and tutorials down the line showing how you can use Trigger.io’s tools in conjunction with Facebook and other cloud services

One year on: the numbers, the product, the future

We launched our Forge platform in January last year. We’re immensely proud of it. Nevertheless, many things have changed since then as we’ve iterated fast with new releases week after week.

Our goal is the same: to provide web developers with the best framework for developing mobile apps across multiple platforms.

There’s a huge shift to mobile underway right now and we’re really only at the start. Ranking #1 for a search for “phonegap done right” and #4 for “mobile development platform” with our article on how to understand mobile platforms we want to enable web developers to make the transition with helpful content as well as our platform.

If you haven’t already check out Trigger.io Forge to see how it can accelerate your app plans by letting you re-use your HTML / CSS / JS skills and code for your mobile apps for iPhone, iPad, Android or mobile web.

The numbers

It’s been a while since I updated you on our build stats – you can see how they looked last summer. Compare that to now:

We’re pretty happy with that strong growth – 10x since March last year. More developers are more engaged than ever in our platform – you can see examples of what they’ve created on our site.

Our customers range from companies building apps for themselves, through contract web developers and studios to product companies that are building many templated apps for industry verticals.

The product

With a stable core team of developers, we’ve been getting more and more productive at responding to your feedback and improving our product. At launch we were confident that our build / test cycle was far faster and simpler than the main hybrid app alternatives – PhoneGap and Appcelerator.

With the improvements we’ve made over the year, we’re now not only confident that our platform is the fastest and simplest to develop with, but it also allows you to achieve the best results. Basically it is the best mobile app platform out there. Don’t take our word for it, try it for yourself.

Reload

A huge part of that is Reload – the ability to push updates to your app contents and logic without needing to resubmit to the App Store.

We kicked off this feature during our away trip in Barcelona, and since launching it’s become one of the main reasons devs choose Trigger.io.

This is a unique feature amongst mobile platforms. It’s not possible to download and execute remote code with natively developed apps. Other hybrid mobile platforms let you reference remote HTML / CSS / JS but that doesn’t help if the user is offline and you’d have to write your own caching and synching logic.

Reload productizes all of that and gives you both offline performance and fast updates when network is available.

Native UI components

Using pure HTML5 for your front-end and Forge APIs to access native features is great for many cases, especially with emerging UI libraries like Lungo making this simpler than ever when used with Trigger.io.

But on mobile there’s sometimes no good substitute for real native UI. Can you have the best of both worlds? We think so and we have made native UI components available starting with the native topbar and tabbar:

Still no need to code Java or Objective-C to use those with Trigger.io Forge, it’s all controlled from JavaScript!

We continued with native alert and confirm dialogs, including Android toasts, in our notification module and native date / time pickers. More are on their way.

Standalone build API

For our customers who build large numbers of apps, sometimes based off common templates, having a slick update process and native UI isn’t enough: automation is a must.

You wanted to be able automate your builds, testing, parameterize your apps, and even let your end-users create their own apps on your site.

To deliver the best mobile platform for these requirements we launched a standalone build API so you can automatically trigger builds directly without going through our Toolkit.

We didn’t stop there – pre and post build hooks together with our parameters module enable further automation.

Native plugins

While our customer value the ability to build native apps without needing to write native code, some of the time there’s no option but to drop down into native code to get that last 10% of differentiation, quality and functionality.

To that end we’ve made the platform plug-able and launched our native plugins beta last year.

Plugin development is now enabled by default on all of our plans and we expect to take the ‘beta’ label off soon.

What’s next?

In summary: Trigger 2.0!

Breadth of APIs is our #1 priority right now so you can access a wide variety of device features to differentiate your app. To that end we went to Berlin on an away trip in February and hammered out a major set of changes to enable that. You’ll see the results of that work in the product soon.

Don’t worry though – we’re concerned about backwards compatibility and Trigger 2.0 is not a re-write or pivot, it will build on the existing product. Some of our customers have called Trigger.io “PhoneGap done right”. We hope you’ll be able to think of Trigger 2.0 as “Trigger.io as we know it, but now even more awesome”.

As always stay in touch with us at support@trigger.io, we’re eager to hear from you.

Build content-rich mobile apps with Trigger.io and the Rackspace Open Cloud

We’re excited to announce a partnership with Rackspace to make building content-rich mobile apps simple in the Open Cloud.

 

Read more about Rackspace’s mobile developer ecosystem launch today. We’re delighted to be part of it.

Building mobile apps, which include large photo and video content, but still perform and download fast is usually challenging. But by integrating Trigger.io Reload and Rackspace Cloud Files, it’s possible to achieve fast performance by storing media locally within the app, while also allowing fast updates from the cloud.

Learn the technical details of the integration in our docs, and see it in action with our demo app in this screencast:

Challenges of large content in mobile apps

The initial user experience is so important to attract and retain users for your mobile app. But to keep their attention you also need to provide fresh new content all the time.

This means you have to overcome the following challenges to build a great content-rich mobile app. Your app must:

  • Be small to allow for fast download onto the device
  • Have content local to the app for fast performance and a great offline experience
  • Be able to access new content to keep the user engaged

Achieving all three requirements at the same time is challenging. You must package some content locally while also having a mechanism to pull down new, remotely hosted content in the background.

Using Trigger.io Reload with Rackspace Cloud Files

You can overcome the challenges of using large content in mobile apps by using Trigger.io Reload with Rackspace Cloud Files.

Rackspace Cloud Files provides a scalable, high-performance CDN that’s perfect for your web apps, and now, with the integration with Trigger.io Reload, ideal for your mobile apps as well. Trigger.io Reload makes it simple to update the content of your mobile app in the background.

You can see how to use the two together in our docs. Sign-up for Trigger.io and the Rackspace Open Cloud now to follow along yourself.

What’s next?

Expect more integrations and tutorials down the line showing how you can use Trigger.io’s tools in conjunction with Rackspace’s cloud service to create amazing mobile apps using the best of HTML5 and native.

Rackspace is committed to supporting mobile app development by providing open hybrid cloud services in all categories so we’re delighted to announce this initial integration and partnership.

If you’re building content–rich mobile apps, we’d love to hear from you, get in touch with us at support@trigger.io and sign-up to get started now.