Looking for a way for Javascript and Actionscript to share one copy of data in memory in a Flex Mobile app. Read on.
I'm building a Flex app where a portion of it is implemented in HTML/Javascript. In the browser, the SWF lives on the main page, and the HTML portion lives in an iframe, on that same page.
These two parts share about 1.5 MBytes of JSON data in the following way. The outermost page loads the data once, and defines a function that provides access to the loaded data. The Actionscript code uses ExternalInterface to call this function, and the HTML/Javascript code calls this function through its parent (which is the outer page). It's my assumption that both paths are accessing the same memory, and that I'm not actually marshalling data back and forth.
For the Flex Mobile version of this app, I'm using StageWebView to render the HTML part, which works well.
But I don't know how I can share data between the two sides.
Please note, I've looked at StageWebViewBridge, and I'll give it another look. But at a quick glance it looks like pushing data around, not like actual memory sharing. Am I wrong?
Related
I am building my first electron desktop app. It creates a formatted document/book from spreadsheet data to either be printed or made into a PDF. I am trying to figure out the best way to prevent performance loss from reflow/repaint when having a large document(lots of divs). I have found that if I have the book in an iframe then I do not suffer reflows/repaints from UI changes and can control when to have it loaded. If I try to create a PDF however I will only get the amount of the iframe that is visible.
Simply, I'm looking for the best solution to prevent reflow in a complex HTML element while still being able to print it to PDF.
I've found a solution to the problem.
As far as I understand, for an electron desktop app, that is not running a server, you cannot directly access myIframe.contentDocument on elements for actions such as append, innerHTML, or offsetHeight etc. The only thing you can do is contentDocument.write(), however once you have used this method, you have access to all of the other regular DOM methods. The best I can understand is that when you use contentDocument.write() it essentially creates a virtual HTML document. This is my workaround at the moment which is working like a charm in giving me control over what elements reflow and what ones do not.
Hope this helps anyone dealing with the same issue.
I do a lot of work with GWT but don't have experience of Flex. I was talking to a guy today who was looking at moving some large Flex based applications to GWT due to the Flex application getting too big and using too much memory in the browser. This is a problem I have had before with GWT - browser apps using lots of memory as all the code gets loaded when it starts.
However, in GWT 2.0 there is now a code splitting feature to overcome the problem of the client code getting too big. This allows all the code (javascript) not to be loaded as one big file on start up but instead code split into different files that can be loaded when required.
I was thinking as to if there is anything similar in Flex. I assume the Flex application code all lives in one single SWF file which loads at start-up so this approach is not possible but thought there might be other solutions.
You might want to look into Modules. Otherwise the code is in one SWF. You can also move the Flex framework code out of yur SWF. And you can always dynamically load your resources such as images.
We are loading external swf content into an adobe air application. Content is provided by an increasing number of third parties.
Being third party content, it will be loaded in a separate security domain (trustContent=false) and a sibling app domain (loadForCompatibility=true). We are doing this using the Loader class.
What are the features/options/approaches that would cause problems when using the swf as external content?
I am interested in any kind of issues, as we have already reproduced issues with content that occur regardless of the app domain / security domain where its loaded ( and occurs also in both Loader and SWFLoader).
Any workarounds for the issues are highly appreciated, especially ones that can be applied from the main app.
The big nasty problem (and one we've dealt with a lot!) is the fact that external SWFs simply can not be directly trusted. Ever. This makes communicating between them and the base AIR application difficult at best.
There is a hack around this based on loading the data of the SWF via a URLLoader and then taking the bytearray from it and pumping it into a Loader. However, I believe that hack was killed with AIR 1.5.1.
That being said, it is possible to communicate between the AIR app and the loaded SWF through what Adobe calls the sandbox bridge. However, setting up the sandbox bridge is a royal pain and any complex data (objects, even as simple as Arrays) get stripped down to generic objects on the other side of the bridge and can not be cast back to their original form.
For our recent projects that needed to use the bridge we created a specialty class called AIRBridge that you use on both sides of the bridge and it facilitates setting everything up properly. If you're interested, you can pull the current source from our Google Code project Automata-Tools.
One we already addressed:
Content outside of the external swf stage shows in the application, and when setting the size where it will be displayed the offstage elements are taken into account. Workaround: Add a mask on the main app so the external content is hidden. Use .content.width/height (full with offstage elements) and .content.loaderInfo.width/height (original stage size) to calculate how much to scale content so the original stage matches the visible area.
I have a problem I am trying to solve in an elegant manner. I have a .net application that I have created. I am trying to get one of the forms to be shown from a webpage. This sounds strange I'll admit, so here is the backstory
We have some large monitors at work, that show information on them. I have no control over how the information is displayed. Currently they are just using a browser and tabbing in the browser to show each different piece of information on the screen. Most of the info they show is just standard html stuff, text and images.
Now along comes my winforms application. The part of the application I need to show is a graphical display. Everything on this display is drawn using GDI+, if that matters. I need to get this form into a format that I can show. Below is my own solution, but I am pretty sure this is not the best method, but it may be the only method I can use
Create a console application. The application would do the following
1. Run as a service on a server
2. Create the display in memory, and save it to a bitmap every so ofter
3. Save the bitmap to a location on the network.
4. have an HTML file that links the image that can be shown in the browser
I though about doing something with the clients, however the clients are not always up, so I could have periods where the image wouldnt be updated.
I also was thinking about an ASP.net solution, but that would require me to learn ASP.net, and I am not quite ready to take that challenge
In IE you can host a winforms app/control as an ActiveX control, like so:
<object id="DateTimePicker" height="31" width="177"
classid="bin/Web.Controls.DateTime.dll#Web.Controls.DateTime.DateTimePicker" VIEWASTEXT>
</object>
See this article for more information: http://www.codeproject.com/KB/miscctrl/htmlwincontrol.aspx
Now, I'm not claiming that this is any more elegant than your solution, but it is an alternative.
I think using Asp.Net to serve a dynamic image using a HttpHandler would be the best approach, but depending on your skills and time this may not be an option. Here is a nice tutorial: http://www.codeguru.com/columns/dotnet/article.php/c11013
IMHO The best way to build this would be as a browser plug-in, like how Flash works. Microsoft has created a plug-in framework called SpicIE, that allows you develop managed plug-ins for IE. This is probably your best bet.
The old unmanaged way is to build out your WinForms dll app and then package it in a signed cab file, and then reference that cab file with an HTML object tag (codebase arg is the one you need).
i.e.,
document.write("<object CLASSID='clsid:DC187740-46A9-11D5-A815-00B0D0428C0C' CODEBASE='/MyFormsApp/MyFormsApp.cab#Version=1,00,0000' />");
The first time the user hits the page they will be asked to allow for the installer to load its payload (dll's). Once they do, they will have a fully fledged WinForms desktop APP running through a browser window.
I took the easy route on this one. I created a small winform app, that coverts the GDI objects to a bitmap, and then I save the bitmap to a network share. This file is refenced in a simple HTML file that is displayed on the monitor.
I chose the winform app, because it makes it really easy for me to set this up in task manager, and run it every 10 minutes to update.
Usually Flash and Flex applications are embedded on in HTML using either a combination of object and embed tags, or more commonly using JavaScript. However, if you link directly to a SWF file it will open in the browser window and without looking in the address bar you can't tell that it wasn't embedded in HTML with the size set to 100% width and height.
Considering the overhead of the HTML, CSS and JavaScript needed to embed a Flash or Flex application filling 100% of the browser window, what are the downsides of linking directly to the SWF file instead? What are the upsides?
I can think of one upside and three downsides: you don't need the 100+ lines of HTML, JavaScript and CSS that are otherwise required, but you have no plugin detection, no version checking and you lose your best SEO option (progressive enhancement).
Update don't get hung up on the 100+ lines, I simply mean that the the amount of code needed to embed a SWF is quite a lot (and I mean including libraries like SWFObject), and it's just for displaying the SWF, which can be done without a single line by linking to it directly.
Upsides for linking directly to SWF file:
Faster access
You know it's a flash movie even before you click on the link
Skipping the html & js files (You won't use CSS to display 100% flash movie anyway)
Downsides:
You have little control on movie defaults.
You can't use custom background colors, transparency etc.
You can't use flashVars to send data to the movie from the HTML
Can't use fscommand from the movie to the page
Movie proportions are never the same as the user's window's aspect ratio
You can't compensate for browser incompetability (The next new browser comes out and you're in trouble)
No SEO
No page title, bad if you want people to bookmark properly.
No plugin information, download links etc.
If your SWF connects to external data sources, you might have cross domain problems.
Renaming the SWF file will also rename the link. Bad for versioning.
In short, for a complicated application - always use the HTML. For a simple animation movie you can go either way.
You also lose external control of the SWF. When it's embedded in HTML you can use javascript to communicate with the SWF. If the SWF is loaded directly that may not be possible.
Your 100+ lines quote seems pretty high to me. The HTML that FlashDevelop generates for embedding a SWF is only around 35 lines, with an include of a single swfobject.js file. You shouldn't need to touch the js file, and at the most would only have to tweak the HTML in very minor ways to get it to do what you want.
In my experience not all browsers handle this properly. I'm not really sure why (or which browsers) but I've mistakenly sent links like this to clients on occasion and they've often come back confused. I suspect their browser prompts them to download the file instead of displaying it properly.
One upside I can think of is being able to specify GET parameters in the direct URL to the SWF, which will then be available in the Flash app (via Application.application.parameters in Flex, not sure how you'd access them in Flash CS3). This can of course be achieved by other means as well if you have an HTML wrapper but this way it's less work.
Why would you need 100+ lines of code? Using something like swfobject reduces this amout quite some (and generally you don't want to do plugin detection, etc. by hand anyway).
More advantages:
Light weight look cuz you can get rid of the header with all the tool bars that seem to accumulate there and even the scroll bar is not needed. This enhances the impact when you are trying to show a lot of action in a short flash.
The biggie: you get it in a window that you can drag larger or smaller and make the movie larger and smaller. The player will resize the movie to fill the window you have. This is great for things like group photos where everyone wants to enlarge to find themselves and their friends. I've done this for a one frame Flash production!
Downsides:
As with popups in general, if you are asking for multiple ones from the same site, and you want different size popups, the browsers tend to simply override the size you ask for in window.open and reuse whatever is up. You need to close any open popup so the window.open will do a fresh create. It gets complicated, and I have not been able to get it to work across pages in a website. Anyone who has done this successfully, pls post how!
Adobe should be ashamed of themselves with the standard embed, which defeats the puprose of convention over configuration. Check ^swfobject (as mentioned above) or swfin