Announcing Trigger.io v2.0

74 points by amirnathoo 12 years ago | 12 comments

lukifer 12 years ago |

Trigger looks really cool, but the thing still holding me back is the lack of an escape route. If PhoneGap goes belly-up, I've got the source, no big deal. If the same happens to Trigger, I'm stuck having to rewrite major portions of the app from scratch.

taylorRichie 12 years ago | |

If Adobe decided to discontinue PhoneGap, you could just go straight Cordova :D

I'm trying to figure out what benefit Trigger gives you over phonegap/cordova.

taylorRichie 12 years ago | | |

Reload is awesome... beyond that ??

eclipxe 12 years ago | |

Totally agree

explorak 12 years ago |

The Fetchnotes team is really excited about this new approach to native mobile modules! We have a whole suite of them we'll be publishing in the coming weeks and months - it's great we can share them so easily now. Awesome job guys.

Bjoern 12 years ago |

I'm not really an expert on this, so this might be a silly question.

How is this better / different than frameworks such as Phonegap and Titanium ?

amirnathoo 12 years ago | |

It's a reasonably common question and we think we have some quite good answers - you can see a summary on our homepage.

Our customers tell us they choose us vs alternatives for: - the efficiency of our build / test cycle - the broader API out of the box including native UI components and integrations with 3rd party SDKs like Facebook, Flurry and Parse - the ability to push updates to the app without going through the App Store approval process using our Reload feature: https://trigger.io/reload

Bjoern 12 years ago | | |

Thanks, very helpful. Congratulations on shipping 2.0 !

ggoodale 12 years ago |

Having spent a fair amount of time in PhoneGap, I recall one of the tricky bits of using stringByEvaluatingJavaScriptFromString to call into JS land was that it could block, leading Apple to impose a 5 second timeout on that particular API call. Is that still the case? I recall that making loading large objects created/fetched via native code more complicated.

Congratulations on 2.0, regardless!

restelettedo 12 years ago | |

stringByEvaluatingJavaScriptFromString calls are still capped, at 10MB and 10 seconds - that might be up from the 5 seconds you experienced.

Our approach to that is two-fold:

We try not to send big chunks of data through the bridge (we pass file around by reference, for example): in our initial prototypes a couple of years ago we passed image data base64 encoded and that definitely didn't scale!

Secondly, stringByEvaluatingJavaScriptFromString just gets data into the JS engine's scope - the processing of those received messages is done in a separate thread of execution. By that I mean started by an event, not true multi-threading of course!

ggoodale 12 years ago | | |

Thanks for clarifying! Makes sense.

Raphael 12 years ago |

So you're making it easier to make Android apps that look like iOS apps. Great...