Live data from Hacker News

Why Trigger.io doesn’t use PhoneGap – 5x faster native bridge

trigger.io

1–10 of 67 posts

Re: Why Trigger.io doesn’t use PhoneGap – 5x faster native bridge

#2
This is an awesome read. I've made an HTML5-based app (overview at http://taxono.my for the curious), but have been stuck using Appcelerator, because I need to use the hooks to run code in the background- AFAIK PhoneGap and the like do not have the ability to do this unless you make an Objective-C plugin.

But the bridge between the webview and the Appcelerator code is painfully slow. I had it pinging over current location coordinates more than once per second- it worked fine in the simulator but utterly crippled the app when run on a device. For now all I can do minimize the number of calls I make, but that's hardly a great solution.

Re: Why Trigger.io doesn’t use PhoneGap – 5x faster native bridge

#3
post #2

This is an awesome read. I've made an HTML5-based app (overview at http://taxono.my for the curious), but have been stuck using Appcelerator, because I need to use the hooks to run code in the background- AFAIK PhoneGap and the like do not have the ability to do this unless you make an Objective-C plugin. But the bridge between the webview and the Appcelerator code is painfully slow. I had it pinging over current loc…

Thanks, we'll do comparisons against other native bridges in the future also.

Cool app by the way thanks for sharing... though I wish I could try it on my Android ;-)

Re: Why Trigger.io doesn’t use PhoneGap – 5x faster native bridge

#4
post #2

This is an awesome read. I've made an HTML5-based app (overview at http://taxono.my for the curious), but have been stuck using Appcelerator, because I need to use the hooks to run code in the background- AFAIK PhoneGap and the like do not have the ability to do this unless you make an Objective-C plugin. But the bridge between the webview and the Appcelerator code is painfully slow. I had it pinging over current loc…

Thanks, we'll do comparisons against other native bridges in the future also. Cool app by the way thanks for sharing... though I wish I could try it on my Android ;-)

Thanks! The app was developed for an NYC app making competition (http://2011.nycbigapps.com) and so, with a deadline- so the Android version ended up not being finished in time.

Rest assured, the Android version is on the way. In fact, this app-crippling native webview communication is what has taken up all my time and stopped me from developing the Android version.

Looking forward to the day you guys have a solution for background processing- the Appcelerator JS/native hybrid is a mess I'd love to see the back of.

Re: Why Trigger.io doesn’t use PhoneGap – 5x faster native bridge

#6
It would have been great to see these improvements contributed back to PhoneGap/Cordova, which has an extremely permissive license and whose code is open-source. As it is, trigger.io comes with a restrictive license, I have to create an account to use it, I can't see the code, and they mandate that I include their branding with any free use of their product. Yay.

Re: Why Trigger.io doesn’t use PhoneGap – 5x faster native bridge

#7
post #5

Would be curious to know why Trigger didn't use the URL interception method in Android. Is that significantly slower?

I'm not quite sure I understand what you mean (so if this is the wrong answer let us know). But if you mean why do we use a different method on Android compared to iOS: we can communicate directly from Javascript to Java as part of the WebView in Android, which is very fast. The URL interception method is actually the slowest part of iOS but there is no way around it.

Re: Why Trigger.io doesn’t use PhoneGap – 5x faster native bridge

#9
Anyone have experiences of moving from PhoneGap to Trigger.io? Sounds like the tooling is a bit simpler to use (you can avoid XCode): http://www.quora.com/How-is-Trigger-io-better-than-PhoneGap-... But otherwise I can't see many inducements to using Trigger.io's commercial service over open-source PhoneGap.

Re: Why Trigger.io doesn’t use PhoneGap – 5x faster native bridge

#10
facepalm. First, it is generally better to apply performance improvements to the existing framework than to create a new one.

Second, different is not always better. This will increase call performance, but will incur a (de)serialization penalty, limit parameter types (likely to scalars and read-only hashmaps), and make debugging more difficult. And beware of telling the OS that you implement this protocol, or you will have created an XSS attack vector on your native app.

Whenever you break new ground, don't fool yourself into thinking that you're the first person who has had an idea, and make sure that you sanity check your work.

Post reply on HN