tag:blogger.com,1999:blog-36941363.post5536393093502065870..comments2023-08-21T08:53:36.415-07:00Comments on Ganor's Blog: Thoughts on Flash (the Eclipse way)Roy Ganorhttp://www.blogger.com/profile/10470159818677369634noreply@blogger.comBlogger6125tag:blogger.com,1999:blog-36941363.post-25187624163024662982010-05-02T22:05:30.995-07:002010-05-02T22:05:30.995-07:00It really is a shame that Adobe didn't step up...It really is a shame that Adobe didn't step up and provide a Flash container for SWT. They use Eclipse as a base for their products and it is in their interest to promote Flash usage. <br /><br />I also agree with Boris. I did several dialog boxes using HTML (no Flash) and it worked fine. I also managed to avoid starting an HTTP server instance, which is easier on performance in general.Zviki Cohenhttps://www.blogger.com/profile/05628815129329714900noreply@blogger.comtag:blogger.com,1999:blog-36941363.post-59020299694071033512010-05-02T15:50:33.394-07:002010-05-02T15:50:33.394-07:00I agree with Boris - JS/flash is a default integra...I agree with Boris - JS/flash is a default integration solution. There is no need to bridge them - you can access Flash objects directly from JS. http://www.adobe.com/devnet/flash/javascript_api.htmlSeva (Wsevolod) Lapshahttps://www.blogger.com/profile/15288661468099585692noreply@blogger.comtag:blogger.com,1999:blog-36941363.post-1380105611678145192010-05-02T13:22:48.199-07:002010-05-02T13:22:48.199-07:00@Boris "Or implement a XHR-style API ... this...@Boris "Or implement a XHR-style API ... this can help you avoid the platform-specific issues with ports you described" <br />This is exactly what we came up with at the end...<br /><br />Thanks for your feedback!Roy Ganorhttps://www.blogger.com/profile/10470159818677369634noreply@blogger.comtag:blogger.com,1999:blog-36941363.post-3233542879108955422010-05-02T12:38:49.212-07:002010-05-02T12:38:49.212-07:00@Roy - as always, it depends: different technologi...@Roy - as always, it depends: different technologies have different tradeoffs. For example, the Java/JavaScript bridge is synchronous (i.e. on the UI thread). This can sometimes make things easier, and sometimes more deadlock-prone ;-). One thing you could try is setting up a simple RPC-style API that allows you to talk between Java and ActionScript without having to touch the JavaScript parts. Or implement a XHR-style API to replace your current approach with minimal effort, perhaps this can help you avoid the platform-specific issues with ports you described.Boris Bokowskihttps://www.blogger.com/profile/06344587055927544695noreply@blogger.comtag:blogger.com,1999:blog-36941363.post-22214859703021340512010-05-02T03:55:58.294-07:002010-05-02T03:55:58.294-07:00@boris interesting one, but then we should have al...@boris interesting one, but then we should have also bridge JavaScript and Flash which is another layer. Don't you think it's more complciated than direct http req./res.?Roy Ganorhttps://www.blogger.com/profile/10470159818677369634noreply@blogger.comtag:blogger.com,1999:blog-36941363.post-45366134388207665042010-05-02T03:26:13.710-07:002010-05-02T03:26:13.710-07:00Why did you not use the JavaScript/Java bridge API...Why did you not use the JavaScript/Java bridge API of the SWT Browser widget for the communication between your Flash application and the Eclipse side? Using Browser#evaluate, you can call JavaScript from the Java side, and using new BrowserFunction(browser), you can make functionality implemented in Java available as functions on the JavaScript side. This API is available in Eclipse 3.5 and later.Boris Bokowskihttps://www.blogger.com/profile/06344587055927544695noreply@blogger.com