7 ms·

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

136 points by amirnathoo 15y ago

rmurphey3 15y ago
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.
- untog 15y ago
  Is trigger.io a fork of PhoneGap? If not, "contributed back" isn't exactly the right phrase. In any case, I think that anyone is free to do whatever they want with their code- trigger.io are not obliged to liberally license their work. They even describe how they've achieved their performance increase in the blog post- it's more than many would do.
  - amirnathoo 15y ago
    Yep, to be clear - trigger.io is not a fork of PhoneGap or downstream from it.
- amirnathoo 15y ago
  We're trying to optimize the development cycle for web devs. So it's not just about the bridge itself, but also keeping the code around it lean and fit in with our command line tools / cloud build service. All so the build / test cycle is seconds. Also we're a small team so don't have time to do everything we would like, and also contribute to Cordova. Trigger.io's native bridge is not a a fork of PhoneGap or downstream of it.
untog 15y ago
This is an awesome read. I've made an HTML5-based app (overview at http://taxono.my 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.
- amirnathoo 15y ago
  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 ;-)
  - untog 15y ago
    Thanks! The app was developed for an NYC app making competition (http://2011.nycbigapps.com 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.
theoj 15y ago
Would be curious to know why Trigger didn't use the URL interception method in Android. Is that significantly slower?
- Connorhd 15y ago
  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.
  - ynniv 15y ago
    You can call Objective-C from JavaScript on iOS: [ https://developer.apple.com/library/mac/#documentation/AppleApplications/Conceptual/SafariJSProgTopics/Tasks/ObjCFromJavaScript.html https://developer.apple.com/library/mac/#documentation/Apple... ]
    - Connorhd 15y ago
      I believe this is a Mac OS X feature that isn't supported on iOS.
      - deleted 15y ago
        [deleted]
  - theoj 15y ago
    Thanks for the answer. Sorry I wasn't clear... I was referring to this part of the article, in which you describe how the HTML / JavaScript communicates with Objective C on the iPhone: >> We then make a request to a fake URI (forge://…) which we intercept in native code Have you tried doing the same for Android? Do you have any numbers that compare the performance of this method with the JS -> Java bridge?
    - 15y ago
deleted 15y ago
[deleted]
drewda 15y ago
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-or-Appcelerator 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.
- amirnathoo 15y ago
  When thinking about the pricing model, you should compare us to a combination of PhoneGap's cloud build service (which is also fremium and restrictive) and their support packages: http://phonegap.com/support#support-packages http://phonegap.com/support#support-packages The main difference with us is that you do not pay to raise a support tickets: you get direct access to our developers on any plan. And we charge per-app with no restrictions on the number of developers.
  - MattRogish 15y ago
    Is that really the main difference? It seems, from what I can tell, users must go through Trigger.io to do a build to get their app in the store. Their code isn't portable to a non-trigger.io platform, either (mobile web, etc.), and the built binary contains closed-source code (Trigger.io platform stuff). You can run a PhoneGap build locally without going thru the PhoneGap build service. And you get complete and unrestricted access to the source code. If your service disappears or starts charging exorbitant amounts of money, users are SOL. Trigger.io is a commercial entity that is in the business of locking customers into a platform and exploiting it. PhoneGap is the opposite. I place no value judgements on this (I use plenty of licensed code on a daily basis and I work for a commercial entity doing something similar); that may or may not matter to a person, but to me - that seems to be the main difference.
    - lukifer 15y ago
      +1. Even if there is perfect trust with a platform vendor, that doesn't mean they won't come under new management tomorrow that rewrites the rules. That's a scary proposition for the backbone of one's business, since porting to a new platform is almost as much work as writing it in the first place. I can't say I never use closed libraries/platforms/APIs, but when possible, I always choose the option that has a community fork, or some other escape route.
ynniv 15y ago
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.
- Connorhd 15y ago
  We totally agree that when things have a solid foundation it makes sense to build on top of them. The problem we saw with Phonegap was several design decisions we disagreed with (as we described briefly in the blog post). This left us with the option of putting up with it (and ending up with an inferior product), or writing our own bridge, and writing our own bridge made sense. Of course you are right in that writing anything new means you have to work hard to get it to as high a standard as the alternatives, which is why we work hard to test our platform - see http://trigger.io/cross-platform-application-development-blog/2012/01/26/how-forge-works-and-why-were-proud-of-it/ http://trigger.io/cross-platform-application-development-blo.... It's also important to remember that the native bridge is just one part of our product, we also write the code that generates and builds the app, which we want to integrate as tightly as possible. Writing our own bridge makes this a lot easier to do well.
  - spacy 15y ago
    You gotta admit the native bridge is pretty important though, it could be a bottleneck for all the nice bits native code. On that basis the bridge is fundamental to good performance.
alunny 15y ago
(disclaimer: I work for Adobe on a competing service (PhoneGap Build) and have worked with PhoneGap for years) This is a silly benchmark - there is absolutely no reason you would put 1000 calls at once, sequential or parallel, across this sort of bridge in a real app. You probably shouldn't be calling any JavaScript API in a client-side app 1000 times at once. The bridge in PhoneGap Android probably is slower than the one in Forge but 1) that's a tradeoff the PhoneGap devs were willing to make for wider compatibility, support for older devices, and isolation from the bizarre Android WebKit bugs that crop up in every release. 2) synthetic benchmarks aside, there's no indication this would affect the usability of the app. Take the camera example in the article. A PhoneGap call (judging from the graphs) takes about 14ms, a Forge call about 3ms. That's for the entire round trip (JavaScript -> Native -> JavaScript), so divide each in half for each side of the trip. With PhoneGap: * first half of the trip (7ms) * Android presents Camera activity, user picks a photo, Android returns control to original app (say, 500ms, very conservatively) * second half of the trip (7ms) = 514ms With Forge: * first half of the trip (1.5ms) * Android presents Camera activity, user picks a photo, Android returns control to original app (500ms) * second half of the trip (1.5ms) = 503ms This is much closer to a real-world use case - and the calls to native APIs entirely dominate the time spent on the bridge.
- gavingmiller 15y ago
  Totally agree with you on this one. On a side note, are there plans to develop a better set of debugging tools for PhoneGap? It's one of the major pains of the platform. If one is already in development can you point me in the proper direction? Thanks!
  - willtheperson 15y ago
    Ripple (http://ripple.tinyhippos.com/ http://ripple.tinyhippos.com/) does a pretty good job. You can get an extension for Chrome. It will simulate PhoneGap events and extend JS api's to support what iOS and Android should have. Kind of clunky but pretty useful.
  - alunny 15y ago
    Agreed - I'd definitely like to see something like JSFiddle for PhoneGap. We're working on weinre right now - http://phonegap.github.com/weinre/ http://phonegap.github.com/weinre/ - and also recommend Aardowlf - https://github.com/lexandera/Aardwolf https://github.com/lexandera/Aardwolf - and Ripple - http://ripple.tinyhippos.com/ http://ripple.tinyhippos.com/
varelse 15y ago
Naive question: Does Trigger.io allow multiplatform use of WebGL?
- deleted 15y ago
  [deleted]
- alexbell 15y ago
  Multiplatform on mobile? As far as I am aware, no browsers for Android support WebGL. And Safari on iOS certainly doesn't. And as long as you're referring to mobile, why wouldn't you just use OpenGL anyways?
  - AntiRush 15y ago
    Firefox Mobile supports WebGL on Android. With a little work, UIWebviews on iOS (4.2+) support WebGL.[1] [1] http://atnan.com/blog/2011/11/03/enabling-and-using-webgl-on-ios/ http://atnan.com/blog/2011/11/03/enabling-and-using-webgl-on...
    - alexbell 15y ago
      Sweet, I did not know. Is the performance respectable (provided it's a modern device)?
      - varelse 15y ago
        It's not going to match native apps, but it works. Chrome Beta (ICS-only alas) supports WebGL as well
pmuellr 15y ago
re: "This approach is heavier and hackier, but a decision they made in order to sideline a bug in the Android 2.3 simulation. It’s not a bug that affects actual Android 2.3 devices, so we take this to be a bit of overkill." From what I could tell, the bug was shipped starting with some version of Android 2.x (I'm thinking 2.2) where JSC was used as the internal JS engine for WebKit instead of V8. When the Android devs added V8 support, they actually broke JSC support. It's a device manufacturer choice (or was) as to which JS engine to use. Curiously, Android shipped the 2.3 simulator image (guess that was the version) with JSC support, thus, "it was broken". The API in question is `WebView.addJavascriptInterface()`. That method returned successfully, but whenever you accessed the interface from JS, you'd trap. Could be this was only on the simulator, but - I'm thinking folks saw this on devices as well. Maybe those devices are no longer relevant? Presumably Cordova will revert back to using `WebView.addJavascriptInterface()` when it's safe to do. The problem is, it's not clear when it's safe to do so. It's also not clear how you can test your JS environment to see if "it's safe", programmatically. Or maybe you can (eg, throw an Error, check for existence of error.stack), but ... it's wasn't a comfortable situation to be in. Do you have some references that the 'bug' doesn't ship on devices, or that it no longer ships on simulator images? What versions of Android SDK/simulator/devices does Trigger.io support? Presumably you don't support running Android 2.3 on the simulator, as your code would trap?
- jamesbrady 15y ago
  Hey Patrick, we support from v2.0 upwards, although not as heavily tested on 2.0 and 2.1. Our tooling actually sets users up with an AVD, and our docs (http://docs.trigger.io/en/v1.2/android/getting-started.html http://docs.trigger.io/en/v1.2/android/getting-started.html) do say that 2.3 is not supported on the emulator. Although we obviously can't test every device out there, everything so far points at no device ever actually shipping with JSC after 2.2, e.g. see http://code.google.com/p/android/issues/detail?id=12987 http://code.google.com/p/android/issues/detail?id=12987 If we do get requests from our users to change that approach, we'd obviously consider it, but at the moment, we think the significant performance and code cleanliness benefits outweigh the downside.
JRambo 15y ago
This is great. I`m a huge fan of PhoneGap. I'll check out Trigger for sure, hope it's just as easy!
- sahilpjain 15y ago
  Awesome - we'd love to hear what you think after you have a play. Feel free to email me directly at sahil@trigger.io if you have any questions. Simplicity is and has always been of huge importance for us. Developers that use our framework tell us it is much easier to get started with than other offerings out there.
mirsadm 15y ago
Last time we were looking at the web/javascript based cross-platform tools there seemed to be lots of issues with memory handling (running out of memory to be specific). Is this still the case or, even, has this ever been a major issue for big applications? Maybe somebody who has used these tools successfully can provide some more information.
grannyg00se 15y ago
Narrow scope benchmarks are nice. But I wonder how these platforms (phonegap, trigger.io, feedhenry) stack up in real world development scenarios.
yuvipanda 15y ago
Interesting - haven't heard of Trigger.io before (I build a lot of PhoneGap applications). One thing that's going to keep me on PhoneGap for the foreseeable future, despite its issues, is the fact that it is an Open Source project now. I trust ASF + volunteers more than any startup/company.
evanlong 15y ago
Or you could realized language bridges are stupid and just write the Android and iOS code. Seriously, all you do is trade one set of problems for another. Might as well deal with the native platform problems and make an awesome app for that platform.
vlucas 15y ago
How does this compare to other native bridging platforms like Appcelerator Titanium? I see no mention of it anywhere in the blog posts or on the comparison charts on your site, etc.
- amirnathoo 15y ago
  We'll do other articles and comparisons in the future - we haven't yet had a chance to benchmark against Appcelerator. Anecdotally we think a performance comparison of the bridge would be favorable, but actually the main reason people use us over other frameworks is that our development process is designed for web devs. So with us, you don't need to do local compiles or use a particular IDE, and we have a much faster build / test cycle.
spacy 15y ago
I don't want to be a spoil-sport, but it's not rocket science to make native bridges really fast, you have to cheat, it's fiddly and different for each OS type.
denysonique 15y ago
Is there a Trigger.io kitchen sink? I would like to test the UI responsiveness.
bconway 15y ago
Trigger looks to be an interesting technology, unfortunately it also looks like a Gowalla Situation waiting to happen. It would be tough for me to build products for my clients (or a business) on that.

136 points by amirnathoo 15y ago

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.

untog 15y ago
Is trigger.io a fork of PhoneGap? If not, "contributed back" isn't exactly the right phrase. In any case, I think that anyone is free to do whatever they want with their code- trigger.io are not obliged to liberally license their work. They even describe how they've achieved their performance increase in the blog post- it's more than many would do.
- amirnathoo 15y ago
  Yep, to be clear - trigger.io is not a fork of PhoneGap or downstream from it.
amirnathoo 15y ago
We're trying to optimize the development cycle for web devs. So it's not just about the bridge itself, but also keeping the code around it lean and fit in with our command line tools / cloud build service. All so the build / test cycle is seconds. Also we're a small team so don't have time to do everything we would like, and also contribute to Cordova. Trigger.io's native bridge is not a a fork of PhoneGap or downstream of it.

untog 15y ago

This is an awesome read. I've made an HTML5-based app (overview at http://taxono.my 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.

amirnathoo 15y ago
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 ;-)
- untog 15y ago
  Thanks! The app was developed for an NYC app making competition (http://2011.nycbigapps.com 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.

theoj 15y ago

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

Connorhd 15y ago
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.
- ynniv 15y ago
  You can call Objective-C from JavaScript on iOS: [ https://developer.apple.com/library/mac/#documentation/AppleApplications/Conceptual/SafariJSProgTopics/Tasks/ObjCFromJavaScript.html https://developer.apple.com/library/mac/#documentation/Apple... ]
  - Connorhd 15y ago
    I believe this is a Mac OS X feature that isn't supported on iOS.
    - deleted 15y ago
      [deleted]
- theoj 15y ago
  Thanks for the answer. Sorry I wasn't clear... I was referring to this part of the article, in which you describe how the HTML / JavaScript communicates with Objective C on the iPhone: >> We then make a request to a fake URI (forge://…) which we intercept in native code Have you tried doing the same for Android? Do you have any numbers that compare the performance of this method with the JS -> Java bridge?
  - 15y ago

deleted 15y ago

[deleted]

drewda 15y ago

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-or-Appcelerator 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.

amirnathoo 15y ago
When thinking about the pricing model, you should compare us to a combination of PhoneGap's cloud build service (which is also fremium and restrictive) and their support packages: http://phonegap.com/support#support-packages http://phonegap.com/support#support-packages The main difference with us is that you do not pay to raise a support tickets: you get direct access to our developers on any plan. And we charge per-app with no restrictions on the number of developers.
- MattRogish 15y ago
  Is that really the main difference? It seems, from what I can tell, users must go through Trigger.io to do a build to get their app in the store. Their code isn't portable to a non-trigger.io platform, either (mobile web, etc.), and the built binary contains closed-source code (Trigger.io platform stuff). You can run a PhoneGap build locally without going thru the PhoneGap build service. And you get complete and unrestricted access to the source code. If your service disappears or starts charging exorbitant amounts of money, users are SOL. Trigger.io is a commercial entity that is in the business of locking customers into a platform and exploiting it. PhoneGap is the opposite. I place no value judgements on this (I use plenty of licensed code on a daily basis and I work for a commercial entity doing something similar); that may or may not matter to a person, but to me - that seems to be the main difference.
  - lukifer 15y ago
    +1. Even if there is perfect trust with a platform vendor, that doesn't mean they won't come under new management tomorrow that rewrites the rules. That's a scary proposition for the backbone of one's business, since porting to a new platform is almost as much work as writing it in the first place. I can't say I never use closed libraries/platforms/APIs, but when possible, I always choose the option that has a community fork, or some other escape route.

ynniv 15y ago

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.

Connorhd 15y ago
We totally agree that when things have a solid foundation it makes sense to build on top of them. The problem we saw with Phonegap was several design decisions we disagreed with (as we described briefly in the blog post). This left us with the option of putting up with it (and ending up with an inferior product), or writing our own bridge, and writing our own bridge made sense. Of course you are right in that writing anything new means you have to work hard to get it to as high a standard as the alternatives, which is why we work hard to test our platform - see http://trigger.io/cross-platform-application-development-blog/2012/01/26/how-forge-works-and-why-were-proud-of-it/ http://trigger.io/cross-platform-application-development-blo.... It's also important to remember that the native bridge is just one part of our product, we also write the code that generates and builds the app, which we want to integrate as tightly as possible. Writing our own bridge makes this a lot easier to do well.
- spacy 15y ago
  You gotta admit the native bridge is pretty important though, it could be a bottleneck for all the nice bits native code. On that basis the bridge is fundamental to good performance.

alunny 15y ago

(disclaimer: I work for Adobe on a competing service (PhoneGap Build) and have worked with PhoneGap for years) This is a silly benchmark - there is absolutely no reason you would put 1000 calls at once, sequential or parallel, across this sort of bridge in a real app. You probably shouldn't be calling any JavaScript API in a client-side app 1000 times at once. The bridge in PhoneGap Android probably is slower than the one in Forge but 1) that's a tradeoff the PhoneGap devs were willing to make for wider compatibility, support for older devices, and isolation from the bizarre Android WebKit bugs that crop up in every release. 2) synthetic benchmarks aside, there's no indication this would affect the usability of the app. Take the camera example in the article. A PhoneGap call (judging from the graphs) takes about 14ms, a Forge call about 3ms. That's for the entire round trip (JavaScript -> Native -> JavaScript), so divide each in half for each side of the trip. With PhoneGap: * first half of the trip (7ms) * Android presents Camera activity, user picks a photo, Android returns control to original app (say, 500ms, very conservatively) * second half of the trip (7ms) = 514ms With Forge: * first half of the trip (1.5ms) * Android presents Camera activity, user picks a photo, Android returns control to original app (500ms) * second half of the trip (1.5ms) = 503ms This is much closer to a real-world use case - and the calls to native APIs entirely dominate the time spent on the bridge.

gavingmiller 15y ago
Totally agree with you on this one. On a side note, are there plans to develop a better set of debugging tools for PhoneGap? It's one of the major pains of the platform. If one is already in development can you point me in the proper direction? Thanks!
- willtheperson 15y ago
  Ripple (http://ripple.tinyhippos.com/ http://ripple.tinyhippos.com/) does a pretty good job. You can get an extension for Chrome. It will simulate PhoneGap events and extend JS api's to support what iOS and Android should have. Kind of clunky but pretty useful.
- alunny 15y ago
  Agreed - I'd definitely like to see something like JSFiddle for PhoneGap. We're working on weinre right now - http://phonegap.github.com/weinre/ http://phonegap.github.com/weinre/ - and also recommend Aardowlf - https://github.com/lexandera/Aardwolf https://github.com/lexandera/Aardwolf - and Ripple - http://ripple.tinyhippos.com/ http://ripple.tinyhippos.com/

varelse 15y ago

Naive question: Does Trigger.io allow multiplatform use of WebGL?

deleted 15y ago
[deleted]
alexbell 15y ago
Multiplatform on mobile? As far as I am aware, no browsers for Android support WebGL. And Safari on iOS certainly doesn't. And as long as you're referring to mobile, why wouldn't you just use OpenGL anyways?
- AntiRush 15y ago
  Firefox Mobile supports WebGL on Android. With a little work, UIWebviews on iOS (4.2+) support WebGL.[1] [1] http://atnan.com/blog/2011/11/03/enabling-and-using-webgl-on-ios/ http://atnan.com/blog/2011/11/03/enabling-and-using-webgl-on...
  - alexbell 15y ago
    Sweet, I did not know. Is the performance respectable (provided it's a modern device)?
    - varelse 15y ago
      It's not going to match native apps, but it works. Chrome Beta (ICS-only alas) supports WebGL as well

pmuellr 15y ago

re: "This approach is heavier and hackier, but a decision they made in order to sideline a bug in the Android 2.3 simulation. It’s not a bug that affects actual Android 2.3 devices, so we take this to be a bit of overkill." From what I could tell, the bug was shipped starting with some version of Android 2.x (I'm thinking 2.2) where JSC was used as the internal JS engine for WebKit instead of V8. When the Android devs added V8 support, they actually broke JSC support. It's a device manufacturer choice (or was) as to which JS engine to use. Curiously, Android shipped the 2.3 simulator image (guess that was the version) with JSC support, thus, "it was broken". The API in question is `WebView.addJavascriptInterface()`. That method returned successfully, but whenever you accessed the interface from JS, you'd trap. Could be this was only on the simulator, but - I'm thinking folks saw this on devices as well. Maybe those devices are no longer relevant? Presumably Cordova will revert back to using `WebView.addJavascriptInterface()` when it's safe to do. The problem is, it's not clear when it's safe to do so. It's also not clear how you can test your JS environment to see if "it's safe", programmatically. Or maybe you can (eg, throw an Error, check for existence of error.stack), but ... it's wasn't a comfortable situation to be in. Do you have some references that the 'bug' doesn't ship on devices, or that it no longer ships on simulator images? What versions of Android SDK/simulator/devices does Trigger.io support? Presumably you don't support running Android 2.3 on the simulator, as your code would trap?

jamesbrady 15y ago
Hey Patrick, we support from v2.0 upwards, although not as heavily tested on 2.0 and 2.1. Our tooling actually sets users up with an AVD, and our docs (http://docs.trigger.io/en/v1.2/android/getting-started.html http://docs.trigger.io/en/v1.2/android/getting-started.html) do say that 2.3 is not supported on the emulator. Although we obviously can't test every device out there, everything so far points at no device ever actually shipping with JSC after 2.2, e.g. see http://code.google.com/p/android/issues/detail?id=12987 http://code.google.com/p/android/issues/detail?id=12987 If we do get requests from our users to change that approach, we'd obviously consider it, but at the moment, we think the significant performance and code cleanliness benefits outweigh the downside.

JRambo 15y ago

This is great. I`m a huge fan of PhoneGap. I'll check out Trigger for sure, hope it's just as easy!

sahilpjain 15y ago
Awesome - we'd love to hear what you think after you have a play. Feel free to email me directly at sahil@trigger.io if you have any questions. Simplicity is and has always been of huge importance for us. Developers that use our framework tell us it is much easier to get started with than other offerings out there.

mirsadm 15y ago

Last time we were looking at the web/javascript based cross-platform tools there seemed to be lots of issues with memory handling (running out of memory to be specific). Is this still the case or, even, has this ever been a major issue for big applications? Maybe somebody who has used these tools successfully can provide some more information.

grannyg00se 15y ago

Narrow scope benchmarks are nice. But I wonder how these platforms (phonegap, trigger.io, feedhenry) stack up in real world development scenarios.

yuvipanda 15y ago

Interesting - haven't heard of Trigger.io before (I build a lot of PhoneGap applications). One thing that's going to keep me on PhoneGap for the foreseeable future, despite its issues, is the fact that it is an Open Source project now. I trust ASF + volunteers more than any startup/company.

evanlong 15y ago

Or you could realized language bridges are stupid and just write the Android and iOS code. Seriously, all you do is trade one set of problems for another. Might as well deal with the native platform problems and make an awesome app for that platform.

vlucas 15y ago

How does this compare to other native bridging platforms like Appcelerator Titanium? I see no mention of it anywhere in the blog posts or on the comparison charts on your site, etc.

amirnathoo 15y ago
We'll do other articles and comparisons in the future - we haven't yet had a chance to benchmark against Appcelerator. Anecdotally we think a performance comparison of the bridge would be favorable, but actually the main reason people use us over other frameworks is that our development process is designed for web devs. So with us, you don't need to do local compiles or use a particular IDE, and we have a much faster build / test cycle.

spacy 15y ago

I don't want to be a spoil-sport, but it's not rocket science to make native bridges really fast, you have to cheat, it's fiddly and different for each OS type.

denysonique 15y ago

Is there a Trigger.io kitchen sink? I would like to test the UI responsiveness.

bconway 15y ago

Trigger looks to be an interesting technology, unfortunately it also looks like a Gowalla Situation waiting to happen. It would be tough for me to build products for my clients (or a business) on that.