I have a large flex application (the app) running on one server, and many small flex applications (widgets) running on another server, which are to be included in the app so that visually the user see's one continuous application. Due to proprietary third party software, this structure cannot be changed. I am looking for some way to allow the app and the widgets to communicate, allowing the app to make changes to the widgets and the the widgets to notify the app when events are triggered, so that user interaction is fluid and continuous.
There are a few related questions which indicate it's possible to do this by setting up event triggers and listeners. I am wondering if there is any standardized way to do this (the answers aren't very clear) or if anyone has developed a library or API to make this easier.
Something I've had success with is using javascript as a bridge between the swf files. It's a nightmare to debug but it works quite well. Check out the tutorial here for a quick discussion of how to interact with javascript from within flash and vice versa
I assume you are running your Flex apps on a client, not a server; is that correct? You want to swfs from multiple servers to act as single application, correct?
I believe that you can communicate between two swfs using LocalConnection:
http://www.adobe.com/livedocs/flash/9.0/ActionScriptLangRefV3/flash/net/LocalConnection.html
The other questions you link to seem to talk about loading onw swf inside the oher; which is a separate approach.
Use Modules and ModuleLoaders. You'll be able to set the security context, and if you sublcass the Module class and add your own API, you can have a consistent way to communicate with your modules.
Check here for a simple Module:
http://blog.flexexamples.com/2007/08/06/building-a-simple-flex-module/
Related
We currently have an application that is usable by several clients, it is used to download and store data from our application that they have on their environment.
We have a need to pass this application over to a developer but at the same time, we need to protect our code. The way that I see it working is that we would like to some how consider our current app a framework, allowing another app to be created on top of it, but the app may have its own screens, but re-use some of the built-in screens.
Is it possible to protect our app in such a way with out rewriting everything into protected DLL's? Or should we just suck it up and share our code with consulting firms that want to build these types of apps for our clients?
If your proprietary code is entirely focused on downloading and storing data. You could create an online REST api that returns the data over the internet. The other developer could then just request the data from your servers using an HTTP call.
However if your code needs to be client-side, the only real thing you can do is compile a DLL, and even then that can be decompiled.
I want to use Vaadin Push in my application. I am using vaadin 7.1.2 which has vaadin push built in. I have 2 question:
How to push the changes from the database on change in data in the database? How can I listen to the database changes? Is there any listeners in vaadin push which can be use?
Since I have many modules in my application I want to add push functionality to only selected modules. Is it possible to add push to only selected modules?
Thanks
Abhilash
Abhilash, what kind of persistence layer you are using?
Common Vaadin Container implements PropertySetChangeListener listener so you can register to and receive event for every DB change. But it will work only if you will change DB via this Container.
Well, external changes won't be noticed and no event will be provided. For this case it is a much harder to get noticed about these DB changes. You should implement kind of "middleware", which will handle all DB changes and also it will notify all registered listener.
To second question, I'm not sure what you mean with modules? Could you provide more information with examples?
How to push the changes from the database on change in data in the database? How can I listen to the database changes? Is there any listeners in vaadin push which can be use?
No, no silver bullet there.
Databases do not generally have an event-notification system to alert external systems about changes to the stored data. You need to code such behavior yourself.
Postgres NOTIFY
The Postgres database offers an unusual feature of NOTIFY where a client connected to the database server can be prodded from server-side code such as PL/pgSQL. The server-side code can ship an optional “payload” string to the client. The client-side database-connection implementation must be coded to accept such notifications.
If you have such a client, then you could do something like have triggers that fire when saving changes to certain tables, then use NOTIFY to tickle the client into querying the table name passed as the payload.
This is nowhere near standard SQL, and is a Postgres-specific feature.
Vaadin events
If the only source of changes to the database is within your Vaadin app, you could set up some kind of alert system within your app.
The ServletContext is required by the Servlet spec to represent your web app at runtime. You can get/set “attributes” as a way for the various threads and user sessions to communicate with each other.
You would need a way to track all your user sessions, as discussed here.
Taking a Vaadin-centric approach may not be practical if there is any chance of other sources of changes to the database outside of your app.
For more info on messaging between current Vaadin users, see the Broadcasting to Other Users section in Vaadin docs, as mentioned in this Answer to a similar Question.
Polling
One common solution is polling. Spawn a background thread to query the database, report findings, then sleep. Lather, rinse, repeat. Set the sleep time for the amount of time your users are willing to be out-of-date.
This kind of work is made much easier with a ScheduledExecutorService built into Java SE. Alternatively, Java EE offers an #Schedule annotation as discussed here, but I am unfamiliar with its usage. Either way, you are scheduling a chunk of code to be run repeatedly. By the way, never use the Timer class in a Servlet-based app or Java EE app.
I have used the ScheduledExecutorService successfully in a Vaadin 7 app running in Tomcat 8.5. Learn about the ServletContextListener as a place in your app to launch and shutdown your executor service. See my slides for my talk on the subject.
And be sure to never access the Vaadin user-inteface layouts and widgets from a background thread. Instead, always interact with the UI by calling access or accessSynchronously on the UI class for user-interface related changes or VaadinSession for non-user-interface related changes. Read the Accessing UI from Another Thread section of the Server Push page in Vaadin doc.
Push technology updates
Push technology has been a rapidly evolving field.
As I recall, Vaadin 8 may be much more efficient with Push than Vaadin 7, though I do not recall details. At the very least, Vaadin 8 may be using more recent versions of the Atmosphere library that powers Vaadin Push features. So if possible, you may want to consider migrating to Vaadin 8. Keep in mind that Vaadin 8 has a compatibility layer feature to make it easier for you to bring over Vaadin 7 code.
Most crucial, be sure to use the latest versions of your web container such as Tomcat or Jetty. The support for WebSocket in particular has had significant improvements over the years.
While perhaps not yet ready in practice, the Servlet 4 spec has major implications for the future of Push technology. The spec includes support for HTTP/2 and Request/Response multiplexing to help with server-side push.
Vaadin Push scoped to UI
Since I have many modules in my application I want to add push functionality to only selected modules. Is it possible to add push to only selected modules?
Enabling Push significantly alters your deployment situation, and so you are wise to carefully consider its use.
Vaadin’s support for Push is scoped to your subclass of UI. Your Vaadin app by default has a single UI object for each user, from a single subclass of UI class. But your are free to instantiate additional UI objects within your user’s session. The instances may come from your same UI subclass, or from additional UI subclasses you have authored.
This is precisely how the multi-window/multi-tab support works in Vaadin 7 and Vaadin 8: You instantiate a new UI subclass object and install it into the new web browser window or tab.
I am not sure, but you may be able to swap out a Push-enabled UI object for an alternative non-Push-enabled UI object within the same web browser window/tab. But I have not tried doing so, and I do not know if this is supported or recommended. Personally, I would choose to keep the same UI object installed for the entire life of the window/tab.
I've recently been slated with a task to port an existing Flash Player-base game to a desktop app for publication on the Steam platform. The Adobe AIR framework seems like a logical choice for distribution, especially given the latest updates in AIR 3. Given the fact that I'm relatively new to flash/flex development, I've read through a fair amount of AIR documentation on the Adobe site in order to gain a better understanding of what the task involves. In general, I think I have a decent idea of what needs to happen, but there are a couple of wrinkles that may affect if/how it is even possible to port to the AIR framework:
The AIR application will need to load the actual game client from an external server due to the quick turnaround time of the client development.
Since the AIR application will be deployed on Steam, I want to use the Captive Runtime bundling that's available in AIR 3.0, i.e. no need for the user to 'OK' a separate AIR installation.
Have minimal impact on code changes within the external SWF as I'm not the primary developer of the game.
My first priority is to figure out the best approach for loading an external game client SWF into an AIR application. Initially, I tried to utilize Loader.load(), but that resulted in the following exception:
SecurityError: Error #2070: Security sandbox violation: caller http://localhost/MyClient.swf cannot access Stage owned by app:/AS3_AIRTest.swf.
at flash.media::SoundMixer$/set soundTransform()
at com.company.client.sound::SFXManager$/load()
at global/client.util::loadEmbeddedSounds()
at MyClient()
The offending code is:
static public function load():void {
SoundMixer.soundTransform =
new SoundTransform(Client.Settings.PlaySFX ? 1 : 0);
}
Upon hitting this exception, I decided to read up a bit more on the AIR / Flash player security domains. I have a much clearer understanding of why the exception occurred, but I'm still uncertain what the best approach would be to load the SWF and not receive the exception above.
After scouring through numerous posts on various forums, I found that a number of developers use Loader.loadBytes() to bring the SWF into the application sandbox. From an ease of implementation standpoint, I can see why many choose to go that route; however, I'm not inclined to pursue that approach due the potential dangers to user systems in the event that the external server is compromised.
The second approach that I've read about is that I can utilize a sandbox script bridge, and write an interface to grant certain privileges to the external client SWF. I'm hesitant to go this route at the moment because the game client is fairly complex, and I'm not entirely certain how much access it will require of the stage via different flash APIs. I haven't written this approach off as it sounds like it may be the best bet, but it could potentially be a large endeavor and I want to have minimal impact on the client SWF.
The final approach I've read about is by making an HTML AIR application. My understanding (sketchy at best) is that a SWF loaded via HTML (I believe in a frame/iframe) will have its own stage. My line of thinking is that if the HTML app loads a main page, which in turn has an iframe with SWF embed of the game client, then the client SWF will load in a remote security sandbox and have access to its own stage. My hope is that the SWF would behave as it does in the Flash Player.
This leads me to the following questions:
Is my line of thinking correct about the HTML app?
Would the client SWF have access to its own stage and pretty much behave like it does in the Flash Player?
Can HTML-based AIR applications be bundled with the captive runtime?
Can I use a traditional flex application with HTMLLoader to accomplish the same goal or does it need to be a full-blown HTML app?
If HTMLLoader can be used, would I need to provide the sandbox script bridge meta tags in the iframe tag?
Any help would be very much appreciated at this point. It seems like there are a number of options available, but I'm not sure which path is the right one to pursue at this point in time.
Thank again.
Josh
You have already investigated a lot. I was going to mention Loader.loadBytes technique but you mentioned that it is not secure. Actually, you could take care of security if you knew the signed hashes of the SWFs that may be downloaded. I remember to have read this approach in a AIR team's manager's blog but I can't recollect the link at this time. Basically, the approach would work if you knew all of the SWFs before hand that could be downloaded, and then generated their signed-hashs and put those hashes in an XML which shipped with the initial AIR app. Then, the initial AIR app can download those SWFs, compare their signatures and load them in application sandbox if it matches up with shipped hashes etc.
(Long question with lots of points, but here goes)
You are correct that passing the Stage object through a script bridge isn't going to work. So, removing the code that accesses the stage and possibly using the script bridge to get the job done in each specific case would be necessary.
If you embed the SWF in an HTML page, it will indeed get its own stage. It does not matter whether this is an "HTML-based" AIR application or an ActionScript-based application that uses the HTMLLoader. (Really the two are the same thing.) You don't need an iframe for this. This sounds like the easiest approach, especially if you aren't adding many AIR-specific features.
For information on signing, see http://www.adobe.com/devnet/air/flex/quickstart/articles/xml_signatures.html
The other thing I'd look at, if you haven't already, is what facilities Steam offers for doing such updates. Is the turn around time for uploading a new project/update to Steam really greater than the time it would take to add this post-install update system to the app itself? (I hope you aren't in one of those Dilbertian situations where, on paper, it looks like you can save time by doing weird things. In my experience, miracles created by dragging sliders around in Microsoft Project (or the like) don't pan out.)
I realize that this question can start a discussion but that's really not my intention. We've created a Flex Application to take tests from candidates. The advantage of the Flex Application is that all state can be stored in the application running in the browser of the client. Things like time limits, navigation, scoring, ... can all be handled within the application without us having to worry about a back button for instance. Even running the app offline with Adobe Air isn't that hard.
My question now is if such an application could easily be made with HTML, Javascript, Ajax, ... ? The reason I'm asking is because an application in HTML would be much easier to distribute on Mobile devices for instance. Also, our domain model for instance is mostly implemented in AS3 (Flex) so using it along the server side means porting it to C#.NET. (with two codebases as a result).
Look at any good MVC toolkit, you will easily be able to handle this. Castle project is good as is Microsoft MVC, both of which allow you to choose from a variety of view engines to handle the actual page rendering thereby allowing you to choose the most 'mobile efficient' engine...
As for the technicalities, you would store all persistent data in a server session object.
I am currently looking into Flex and Liferay for delivering an RIA. We are replacing a rather large existing application built on an internal AJAX/Java library. For this, Flex seems to meet our needs for development but we've had a wrench thrown into the works. We need to integrate with another internal app that's been built on Liferay and JSF.
After looking into Liferay a bit I'm not convinced that it provides any benefits to our existing application since delivery via a portlet doesn't appear to have any inherent benefits other than achieving the integration with the other application. It also appears to have a number of downsides including smooth interaction between the swf and the rest of the page, hooking into Liferay's user management and their general lack of developer oriented documentation.
It seems to me Liferay is a good solution if you need an internal wiki/news/social application, but for delivery of a robust RIA it seems like we're trying to fit a square peg in a round hole.
My question is this: Is Liferay used for delivering full RIA applications or is it a platform that's better suited to delivering smaller apps? Am I missing something about Liferay that makes it a good fit for RIA?
Thanks in advance for any advice!
You can easily get a Flex app to show up in a portal (Liferay or other) but here are some issues you might run into:
1) Typical portal servers hold all of the state - for all of the portlets - on the server. Every interaction causes a page refresh which rerenders everything on the page based on the serverside state. For Flex applications you don’t usually want the state on the server. And you don’t want every interaction reloading the Flex app. Some portals are getting more Ajax’y which solves part of this but there will always be some interactions in HTML portlets or in the portal chrome that cause a page refresh. This means that Flex applications must done some work to persist state beyond a page refresh. A simple way to do this is using LSOs but this requires a lot of extra plumbing code.
2) Inter-Portlet-Communication (in JSR 168 portals) goes through the server based on a page refresh. This also doesn’t work well with Flex apps. JSR 286 is attempting to solve this to support Ajax portlet IPC. Until then making Flex apps work with standard IPC is difficult (but possible).
3) A big part of portals is entitlements, customizations, and preferences. These are all difficult to use and interact with from Flex. In JSR 168 portals there isn’t a standard way of doing this. In JSR 286 there is a standard which makes it easier for Flex to read and update user preferences.
4) With WSRP and other remote portlet technologies portal servers can consume remote portlets and proxy all requests back to the portlet provider. With Flex this is more difficult because portal servers don’t know how to proxy Flex requests (HTTPService, RemoteObject, DataService, etc). In many cases the only solution is to allow the end user’s machine to talk directly to the portal producer server. However many times this causes problems for IT because it means moving another server to the DMZ and potentially bypassing the security constraints imposed by the portal server, SSO server, Security Appliance, etc.
Have a look at www.qooxdoo.org. This is a framework for writing large applications entirely in javascript. It combines excellent GUI control with a java like programming paradigm for javascript and a clever build process for the final application.