Announcing Trigger.io v2.0
trigger.io
Announcing Trigger.io v2.0
1–10 of 14 posts
Re: Announcing Trigger.io v2.0
#2The 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.
Re: Announcing Trigger.io v2.0
#3I'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 ?
Re: Announcing Trigger.io v2.0
#4I'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
Re: Announcing Trigger.io v2.0
#5I'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…
Thanks, very helpful. Congratulations on shipping 2.0 !
Re: Announcing Trigger.io v2.0
#6Having 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!
Re: Announcing Trigger.io v2.0
#7Having 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!
Re: Announcing Trigger.io v2.0
#8Having 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, stringByEva…
Thanks for clarifying! Makes sense.
Re: Announcing Trigger.io v2.0
#9Trigger 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.
Re: Announcing Trigger.io v2.0
#10Trigger 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