Please explain me what is a framework RSL and difference between Signed and un-signed framework RSLs in Flex. Thank you in advance.
First, there is a wonderful tool called "search" on this website which could have also pointed you in the right direction.
For example:
Flex RSL Understanding
using framework RSL to reduce SWF filesize
Then after googling for "unsigned rsl", you take the first entry being an official Adobe LiveDoc
There it clearly states:
Every Flex application uses some aspects of the Flex framework, which
is a relatively large set of ActionScript classes that define the
infrastructure of a Flex application. If a client loads two different
Flex applications, the application will likely load overlapping class
definitions. This can be a problem for users who are on dialup or slow
network connections. It also leads to the perception that Flex
applications load more slowly than HTML-based applications.
To overcome these limitations, you can use framework RSLs with your
Flex applications. These libraries are comprised of the Flex class
libraries and can be used with any Flex application. Framework RSLs
come in two versions: signed and unsigned. Signed framework RSLs are
cached in a special Player cache rather than the browser cache. They
can be accessed by any application regardless of that application's
originating domain. They only need to be downloaded to the client
once, and they are not cleared from the client's disk when the
browser's cache is cleared. Unsigned framework RSLs are cached in the
browser cache and can only be used by applications that have access to
the RSL's domain.
Flash Player 9.0.115 and later support loading signed framework RSLs.
These RSLs can be loaded by applications in different domains. The
framework RSLs are signed and have the extension SWZ. Only Adobe can
create signed RSLs, and only signed RSLs can be stored in the Player
cache. If you create an RSL that contains a custom library, it will be
unsigned. You cannot sign it. If a Player with a version earlier than
9.0.115 attempts to load a framework RSL, then Flash Player skips it and loads a failover RSL, if one was specified when the application
was compiled.
Cheers
Related
I am new to Silverlight. We are migrating our project to Silverlight. We are just changing our presentation layer. (ASP.NET WebForms site to Silverlight web application). So our other class libraries having business & data access layer will remain as it is.
Firstly I added a Silverlight web application to my solution. It created 2 projects: PM_Tool and Pm_Tool.Web. Now I need to add project references of the Business and Data Access layers to this, since I need to access them in my MainPage.xaml.cs.
But I can't add a reference to Pm_Tool - I get the following message:
You can only add project reference to other Silverlight projects in the solution.
I then added project references to Pm_Tool.Web, but I can't access the business layer objects in MainPage.
Can anyone help how I can proceed further?
A Silverlight application can only reference other Silverlight projects. This is simply because Silverlight uses a lighter version of the .NET framework; if you could reference 'full' .NET projects then it would be required to support the entire framework. Microsoft have made a design decision to limit the functionality - presumably this is to reduce the installation & runtime footprint of Silverlight.
Having said that, it's quite likely that most of your code will still run in Silverlight. You should create "Silverlight Class Library" projects and include your classes into those projects. You will soon see which (if any) classes are using parts of the framework that are not supported by Silverlight. From there, implement workarounds.
Of course all your data access and server side code must remain in your 'Web' project. Silverlight implements a correct client-server model and doesn't allow you to 'cross the boundary' in the same way that ASP.NET WebForms does. Your Silverlight application runs solely in the browser - anything that needs to happen 'on the server' must happen in the 'Web' project. Your Silverlight application posts and gets information from the 'Web' project via WCF (or WebClient, etc).
Unless you have a very well designed ASP.NET solution, I would expect that your transition is not going to be as simple as 'just changing our presentation layer'.
you can only add referances to other silverlight assemblies. you are not allowed to add referances to "normal" windows assemblies--asp.net or WPF, or winforms (etc.) however, you ARE allowed to add referances of silveright assemblies to other projects.
you are going to have to make silverlight versions of the assemblies you want to add. the main reason for this is the security model.
now, the problem you may run into is that since silverlight is really a subset of WPF is that many of the classes that you would like to use will not be available. however, there are ways around this--using webservices, etc.
We have a web site built as an 'ASP.NET Website' type project, rather than the 'ASP.NET Web Application' type.
Aside from the obvious debugging advantages that the app type offers and access to the designer files for each page:
What, if anything, can be gained by switching from website project type to app?
Are there performance losses with one over the other?
How much work is involved in switching an existing (dev) site from website to app? Is it as simple as creating another site as app type and adding these existing aspx files and libraries to it?
This question (How To Convert ASP.NET Website to ASP.NET Web Application) seems to cover the steps.
What are the risks (if any?)
How much work should we plan on?
Are there differences in how HTTP Application deals with requests or how handlers work between the two types?
Anything we forgot to think of?
http://msdn.microsoft.com/en-us/library/aa730880%28VS.80%29.aspx#wapp_topic5
That describes some of the features and advantages/disadvantages between the two.
The main reason to use the web project versus the web site is that the web site is dynamically compiled which tends to incur a performance hit whereas the web project is precompiled. You should gain performance moving to the web project method. You also gain control over the naming of your final compiled assemblies.
The amount of work really depends on how many pages are in your old site.
I don't think the .NET framework handles code differently in the web site versus the web project. It's really the configuration of the file structure, the lack of a central project file, and the method of compilation that ends up being different between the two.
I don't understand the purpose of the WPF browser appliction. Is it simply another way of serving information through a browser, or is it not intended to be used for external deployment?
WPF Browser applications allow you to create very rich, application style UI's deployable via the web, using coding languages windows developers already likely have in their toolset. The downsides are that the users must must have .net installed, and use IE to access the application, considerably limiting the size and scope of your audience. WPF browser applications are very similar to Java applications in that they run in a virtual machine on the client. As it runs on the client, all data access and communication with the server must be done through WCF or web services.
With ASP.NET you have considerably more cross browser compatibility and support, giving you access to a much larger audience, with the possible downside of learning new libraries and the ASP.NET programming model. ASP.NET also provides a rich data access model and data control support. Silverlight is another interesting option based on .NET and WPF, as it is supported by a wide variety of browsers and provides similar rich user interface experiences. It can als be run out of the browser, disconnected if neccesary.
** Update based on Comment Request ***
The big advantage to Silverlight out of browser, is that you get most of the Rich, windows application style functionality, with a web deployable model and tiny install (4-6MB). Silverlight also supports an auto update feature which is VERY nice if you have a large user base.
Microsoft's Official description (propaganda :) )here
Silverlight Out Of Browser
Enables users to place their favorite Silverlight applications directly onto their PC and Mac, with links on the desktop and start menu—all without the need to download an additional runtime or browser plug-in. Further, the new experience enables Silverlight applications to work whether the computer is connected to the Internet or not—a radical improvement to the traditional Web experience. Features include:
Safe and secure. Leveraging the security features of the .NET Framework, Silverlight applications run inside a secure sandbox with persistent isolated storage. These applications have most of the same security restrictions as traditional web apps and so can be trusted without security warnings or prompts, minimizing user interruptions.
Smooth installation. Because Silverlight applications are stored in a local cache and do not require extra privileges to run, the installation process is quick and efficient.
Auto-update. Upon launch, Silverlight applications can check for new versions on the server, and automatically update if one is found.
Internet connectivity detection. Silverlight applications can now detect whether they have Internet connectivity and can react intelligently including caching a users’ data until their connection is restored.
A WPF browser application is a client side technology, rather than ASP(.NET) which is server-side. It is definitely not meant to replace it.
Using a WPF browser application one can provide a rich client inside the browser. However, this will only work when the whole .NET framework is installed. Another similar technology is Silverlight, which uses a very small (the installer about 5-6 MiB) framework, and is available to multiple platforms. It includes a small subset of .NET framework.
You can use it in external deployment considering the above requirements.
The following portion of the above selected comment is wrong:
and use IE to access the application,
considerably limiting the size and
scope of your audience
WPF in the browser (aka XBAP) is works just from FireFox (Mozilla) and Google Chrome. It was true about 2 years ago, but not today.
You could use XAML in silverlight, if thats what you are looking for.
Plus the RIA Application templates makes development quite neat.
i'm new to creating desktop applications. I've a working site in php with mysql support. I want to convert this site into a desktop application. Is Adobe AIR or Adobe Flex better?
can i use php as such in both AIR and Flex? or should i convert them to xml or something which it uses?
AIR is Flex on the desktop... So... I suppose you mean whether you can use AIR with PHP? AIR/Flex should be able to handle whatever communication protocol you're using on the server.
Saying 'should i convert them to xml or something' is a bit nebulous.
I guess what you really asking is: Should I rewrite my application entirely in Adobe technologies or Can I/Should I integrate it with my existing PHP code.
I would recommend you expose the existing PHP functionality as RESTful web services and redo the user interface in Adobe AIR. That way you can leverage the existing site to make the desktop application. There is a ton of information of building applications like this, just research REST, SOA (service oriented architecture), SAAS (Software as a Service).
Adobe AIR/Flex is fine, especially if you want it to work on multiple operating systems, but the Application won't necessary have the looking and feel of its host desktop environment.
Adobe AIR is a runtime that adds to the capabilities of Adobe Flash Player to allow the creation of desktop applications.
Adobe Flex is a framework to build rich user interfaces. Flex applications are supported both in Flash Player and AIR.
This cannot be a question of one or the other. Flex can be used together with AIR. If you want a desktop app that allows you to use Adobe's Flash Platform technologies, definitely use AIR. If you want a set of pre-built UI controls to use in that AIR app, use Flex too!
You can communicate with PHP on your server in both Flash Player and AIR. PHP cannot be run directly in AIR. If you want the application to be entirely self-contained with no server, then you can't use PHP.
What is the difference between Adobe AIR and FLEX?
The "Flex Framework" is a collection of AS3 classes and components used in developing RIAs.
"Flex Builder" is an IDE used to develop "Flex Applications."
Much in the same way HTML is a collection of tags to develop web pages and Dreamweaver is an IDE for developing web pages. However you don't need Dreamweaver, you can use Notepad, BBEdit, etc. as well.
If you use something other than Flex Builder to develop in Flex, you need to download the Flex SDK to compile. The end result of a compiled Flex Application is an SWF file (Same as Flash).
With the compiled SWF file, a user only needs to have Flash Player installed to run the application.
Most Flex apps are developed, deployed to a server and then a web browser is used to serve the application to the user for use.
I haven't used AIR yet so I don't know what the end product of a compliled AIR Application is, but AIR is an alternative delivery system for Flex Applications, replacing the web server and browser so to speak. It's primary purpose is for deploying RIAs to a user's desktop, independant of an internet connection.
AIR, also allows for the use of HTML, AJAX etc. So an AIR Application could be a collection of all these things, compiled together.
To run an AIR Application, you need AIR Runtime installed on your computer.
Source
AIR is not a superset of Flex.
Adobe AIR is essentially Webkit, Flash, Javascript, Flex, XHTML, CSS, sqlLite.
The applications for air are primarily developed in ECMA. (Actionscript/Javascript). Most AIR applications out and about in the world right now consist of Javascript, xhtml, images, and sqllite.
The Actionscript engine has been extended for AIR to support disk IO and other 'local' system functionality. This allows your application to act just like a normal system application. Although most people are storing their data in sqlLite and rarely write to disk for anything other than logging. (From what I've noticed/read)
Regardless, there isn't a ton of Flex going on in AIR or the AIR community. From what I've noticed its a lot of Javascript/Flash/XHTML people making small apps that run on multi-os through the AIR runtime.
I'd add to Garry's (excellent!) answer by saying it sort of depends on what you're asking. There are conceptual differences and specific differences. Garry's answer details a handful of the specifics.
Conceptually, though, AIR is a superset of Flex, and Flex is a superset of Flash.
A Flash-authored SWF generally (though not always -- but most of the time) runs in a Web browser and is composed of ActionScript code. A Flex-authored SWF also runs in a Web browser (or again, some comparable container) and is composed of ActionScript code, but usually also takes advantage of the Flex framework, which is essentially a bunch of ActionScript classes provided by Adobe to assist developers in building more feature-rich Flash-based applications. AIR, finally, is Flex running on the desktop -- it's Flash-plus-Flex, plus some additional desktop-oriented facilities that allow SWFs authored in either Flash or Flex to be installed and run as desktop applications.
Excellent posts. As a side note, I'd like to add that unlike Flex/Flash SWFs, AIR SWFs cannot, and I repeat, can not be played in a browser. AIR SWFs need their own little sandboxes to run in (that the run time provides).
There are two runtime Flash Platforms one is Flash Player and other Adobe AIR(Adobe Integrated Runtime). Adobe Flash Player is a highly expressive cross-platform runtime that works across all the browsers which have the Flay Player plugin. Flash Player delivers the SWF files that runs within the browser, while AIR delivers the .air standalone applications that run on desktop outside the browsers.
You can find more details about AIR & Flash from here: http://readymadeflash.com/blogs/what-is-the-difference-between-adobe-AIR-and-flash.html
I was under the impression porting flex to air was simple => http://forums.adobe.com/message/2887004
My understanding is that in theory your app should work with only one real change required.
Of course now I have to test this theory...
I would be very exicted if I could retain all of the power of flex, and then gain the HTML Control and the Update Framework since thats all flex is really missing to be all powerful.
Off to experiment.
To understand Flex and Air you need to understand the whole Adobe Flash Platform. Flash is overloaded to mean many things, the Flash platform, the runtime, the runtime API, and the IDE.
Adobe Flash Platform - a broad term that includes everything else
Runtimes:
Adobe Flash Player - the plugin you install on web browser, supports Flash API
Adobe Air Runtime - another plugin you install run as desktop application, supports Air API (a superset of Flash API)
APIs:
ActionScript - backend with either Flash API or Air API, you can choose which API to compile your application with, and it will run on respective runtime. AS works with both Flash UI or Flex UI
UI - Flash component (proprietary fla format) or Flex Framework (XML based)
IDEs:
Adobe Flash Pro (CS4/5/6/CC) - work with Flash projects
Flash Builder - work with Flex projects
Flex is a framework that is used to render content on Flash player, mostly for Enterprise Applications. AIR is a runtime which wraps flex, flash and/or html in a package that can be accessed on a desktop without the use of browser, so that a user can get desktop (like accessing directories, interacting with system chrome, etc...) in addition to giving the user the web feeling (accessing http requests, rendering html, calling web services, etc...).
This is a good comparison thread! I've just built a series of AIR apps for several museum installs. AIR apps are just that...Standalone, compiled and optimized applications, wrapped in it's own installer. It's a rather versatile wrapper in that it will compile a bevy of codes, if you play your cards right. You could essentially build a website, and then crush it all into a desktop application. Because it runs locally, it also has the ability to bypass Flash's security protocols (something I'm not sure Flex is capable of). This allows you to access a whole different level of functionality when it comes to seamlessly linking apps, displays, input/output, etc.
Thusly, you can wrap FLEX builds within an AIR app... Adobes AIR dev center breaks everything down pretty thoroughly, and be sure to read through the adobe livedocs as well!
http://www.adobe.com/devnet/air.html
http://livedocs.adobe.com/flex/3/html/help.html?content=Part5_AIR_1.html