Just I have started learning flex for my project. This is project is a kind image, video, audio file management which is accessible from local hard drive like adding, deleting etc..
I heard that Air is doing this kind of work. But our client asking that the project should run only on the browser not like a application.
I have searched lot of tuts. But I haven't get much tutorials. please give me some suggestion to get this type o tutorial.
Thanks
Browser applications cannot manipulate local hard disk contents, regardless of their type - Flash, or JavaScript, or Silverlight - security model is similar for all of them. Try to persuade your client with seamless install of AIR applications (google "AIR badge install".)
Related
If i write an desktop app in tidesdk or tide kit will it be possible for users to read my source code, just like from ordinary web page or not ?
Yes, if the user knows where to look. It's not viewable by right clicking the window and selecting source, but if they browse to the install directory, all the HTML / related files are there in broad daylight.
You could come up with some strategies to protect them, either using encryption or just providing a bootstrapper application which downloads the rest of the source from a server on startup or something like that...but if it's a huge concern of yours you're probably better off using a different platform.
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.)
Please feel free to add multiple answers, each with a single point, to make the voting work well... and don't add something someone else already said.
All I know about AIR is you can have local storage, but there must be more to it... offline access is another key one but then you can run a SWF locally if you save it to your PC.
The biggest benefits (in addition to LocalStorage/SqlLite support) would be...
Read/Write Access to the local file system (including support for native file system dialogs)
Native Drag and Drop Support
In addition, Air apps aren't just Flash based, but can also use HTML/JavaScript via WebKit
Update:
All the info you need on Air is on the Wikipedia page. (and it's external links) http://en.wikipedia.org/wiki/Adobe_Integrated_Runtime
In short, if you need native filesystem and limited desktop interaction Air is the way to go, if you don't need these features, use Flex in the browser.
If you need additional system integration but still cross platform, try Appcelerator/Titanium, Java/JavaFX, Python with WxWidgets, or C++/QT.
It really depends on what you want to build.
You can find all features specific to AIR here :
http://www.adobe.com/products/air/features/
Running a swf file locally doesn't really work for applications that have been pushed out to end users. The user's won't have access to any updates of the application (which an Air application does). Also a swf run locally might not be able to connect back to the server it came from, depending on the security settings.
In reality the nice part of flex is you don't have to commit to web or air. You can develop an application that can be built to run in both the web and on the desktop. For example you can put a majority of the code in a library project and then have a web specific and desktop specific projects that use that library.
Two other advantages of Air - one is that it allows you manage updates to your application and have the updates automatically pushed out. Second is it supports drag and drop (similar to native file access) so you can support dragging pictures or files onto your application.
AIR apps run using Adobe AIR runtime. It has access to your file system and includes more powerful capabilities. Whereas, a web-based flash/flex app runs in a flash player within a web browser. It runs in a sandbox. It has limitations. It can't access local file systems (without user intervention).
Features of AIR:
Can access file system.
With AIR 2.0 you can access (communicate) to native file (executables) of that OS. Means you can communicate to a C app which does some OS specific functionality from the AIR app.
Encrypted Local Store for securely storing credentials.
Easy drag-and-drop functionality.
Behaves as native desktop applications.
Notifications.
System tray icons.
.. and much more.
I need to disable all the aspects of functionality which access the client file system in a flash/flex application. I started having a look on how to do this. It appears that the package flash.filesystem need to be importated to allow the interaction with the file system.
However, I did not find any reference to this package in the application.
I am a beginner concerning these technologies so maybe I am missing a point here. Do I need to look into an other direction?
Thanks
Basic flash/as3 resource: http://www.adobe.com/devnet/actionscript/as3.html
The flash.filesystem library is for AIR applications only because flash is not supposed to be able to reach outside the browser to affect a client's computer. That would be a security violation. Even AIR apps are highly restricted in this way.
Update:
Related Question:
flash actionscript access filesystem without air?
This is brand-new in Flash 10.
Update 2:
And an older reference in Flash 9 here. Though it mentions that it's still subject to the user turning off permissions via their settings manager.
I want (barely computer literate) people to easily submit a large number of files (pictures) through my web application. Is there a simple, robust, free/cheap, widely used, standard tool/component (Flash or .NET - sorry no java runtime on the browser) that allows a web user to select a folder or a bunch of files on their computer and upload them?
swfupload, the best tool I know that lets you do that. Simple, easy to use and even has a fallback mechanism for the 1% web users that don't have flash 8+.
I found that the best way to upload a bunch of files is to zip them and upload a single file (and then decomress it on server). However that's probably not a good option for the audience you are targeting.
We had a company come up with a Silverlight upload that could resize the pictures before hand so that the 5MB files didn't have to be uploaded and then resized. The image resizing capability wasn't included with the clr that comes with Silverlight. Occipital came up with their own. You can see it here:
http://www.occipital.com/fjcore.html
I don't know what they would charge, but we have been extremely happy with how it works. If you don't need the resize capability before uploading then I would go with one of the flash upload options like http://swfupload.org or http://www.codeproject.com/KB/aspnet/FlashUpload.aspx