Announcing Trigger.io v2.0 | Hacker News Reader

Announcing Trigger.io v2.0

trigger.io

74 pointsamirnathoo12 comments

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.

Totally agree

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.

Reload is awesome... beyond that ??

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.

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 ?

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

Thanks, very helpful. Congratulations on shipping 2.0 !

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!

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!

Thanks for clarifying! Makes sense.

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

Reply on news.ycombinator.com