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
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.
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!
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.
12 comments
[ 4.7 ms ] story [ 37.4 ms ] threadHow is this better / different than frameworks such as Phonegap and Titanium ?
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
Congratulations on 2.0, regardless!
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!
I'm trying to figure out what benefit Trigger gives you over phonegap/cordova.