8.2 Connecting to .NET

Flash Remoting supports integration with ASP.NET pages ( .aspx files), .NET class libraries ( .dll files), and XML web services. This support allows developers to construct hooks for Flash interfaces using whatever back-end implementation they prefer; however, each implementation provides certain advantages and disadvantages when it comes to Flash Remoting, as shown in Table 8-1.

Table 8-1. Comparison of ASP.NET implementations for Flash Remoting

Connection method	Advantages	Disadvantages
ASP.NET page	Fast development timeBuilt-in session and application state managementGood performance	Limited to one result per pageBreaks with object-oriented design practices if used without code behindNot remotely accessible to other applications
.NET class library	Object-oriented designExposes multiple methods and propertiesGood performance	Longer development time and more planningNot remotely accessible to other applicationsSession and application state management is not built-in
.NET XML web service	Accessible to remote applications..NET allows quick development timeBuilt-in session and application state management	Slow runtime performance

ASP.NET pages (pages with an .aspx extension) must be service-oriented (SO) in Flash Remoting because they can return only one value to the calling Flash movie. Developing ASP.NET pages is extremely quick and allows developers to separate presentation and business logic within a page. However, ASP.NET pages lack the structure of properly programmed and developed assemblies if done without the benefit of code behind (which we cover later in this chapter under Section 8.2.1.1). This lack of an object-oriented structure can make it hard to reuse code across multiple ASP.NET pages without duplicating that code.

ASP.NET pages also have built-in support for session and application state management. State management allows developers to store values unique to each user session and share variables across all pages within an ASP.NET application. ASP.NET pages and XML web services are the only .NET implementations with state management built in. Developers creating assemblies ( .dll files) must build a custom system for handling state management. State management with .aspx pages and web services is covered later in this chapter.

Typically, developers build ASP.NET applications as collections of object-oriented assemblies, each encompassing a different focus and containing exposed properties and methods. When an assembly is called by Flash Remoting, all of the assembly's public methods and properties are exposed to the Flash application. Unlike ASP.NET pages, which are compiled at runtime, assemblies must be compiled using a tool like Visual Studio .NET (VS.NET) or #Develop (See the .NET Editors sidebar). You can also create .NET applications in a text editor like Notepad and use the command-line compiler that comes with the free .NET SDK.

.NET Editors

Though you can develop all of your .NET applications using Dreamweaver MX, you may want to use a third-party editor for other tasks such as compiling assemblies:

Visual Studio .NET (http://msdn.microsoft.com/vstudio)

The de facto .NET development environment. Features such as IntelliSense make it a very attractive solution.

#Develop (http://www.icsharpcode.net)

Totally free and totally open source. Coded completely in C#, and including many Visual Studio .NET features such as IntelliSense, #Develop can hold its own against any other .NET editor.

PrimalCode (http://www.sapien.com)

Comes with all the standard features you might expect, such as PrimalSense (Sapien's version of IntelliSense) and syntax coloring. Sapien claims that their editor is very fast due to its small file size footprint.

Of course, you could always just use Notepad. ;-)

A class library can, and should, require more planning at the beginning of your application's development. Because you need to decide on the methods and properties to expose via its public interface, it's up to the developers to create the framework for the application. ASP.NET pages inherit from existing classes in the System.Web namespace with the intent of making implementation as quick as possible. It is also important to remember that most class libraries don't do anything by themselves . They usually require an ASP.NET page (or other client, such as a Windows form) to display output. Properly structured, object-oriented applications connect to and reuse business logic through these exposed methods and properties. Class libraries, therefore, prevent replication of commonly used code and allow developers to easily build an application upon a pre-existing foundation.

Developers use classes as a key component to object-oriented programming (OOP) by grouping methods and properties based on a specific business method or object. However, when connecting Flash applications to a .NET back end, issues with datatype conversion can make connecting directly to business logic a bad idea. The best way to avoid this problem is by developing your classes using service-oriented (SO) programming. SO programming means creating a wrapper that provides a specific service by manipulating several business logic components or handling the implementation itself. This way, a service can be built that is optimized for Flash Remoting and manipulates an existing .NET back end while exposing multiple methods to your Flash movie.

.NET XML web services are the best development choice when you wish to share data or functionality over the Internet or other distributed networks. .NET provides a strong API for quickly developing XML web services based on WSDL 1.0 and other W3C standards. Chapter 10 covers connecting with XML web services.

8.2.1 Connecting to an ASP.NET Page

ASP.NET pages use a custom server control to send and receive data through Flash Remoting. Server controls are compiled blocks of code that can be reused. (The server control is sometimes known as the Flash Remoting gateway or Flash Remoting adapter .) A server control also allows developers to add functionality or create visual elements with very little code. The Flash Remoting custom server control can grab parameters passed from the Flash Player, return results to the Flash Player, and bind database data directly to our Flash application.

Let's create a Hello World ASP.NET page that returns a simple string to our Flash application. To get started, create a new plain text file in any text editor and name it helloWorldpage.aspx .

In our new ASP.NET page, we need to register the Flash Remoting server control, which allows us to place the server control tag onto the page. To register the Flash Remoting server control, add this tag to your ASP.NET page:

 <%@ Page Language="C#" debug="true" %> <%@ Register TagPrefix="MM" Namespace="FlashGateway" Assembly="flashgateway" %> 

The TagPrefix parameter should always be set to the same thing, for consistency's sake. We'll use " MM " for Macromedia. The Namespace and Assembly parameters provide the location of our Flash Remoting server control.

Once our Flash Remoting server control has been registered with the ASP.NET page, we can begin to communicate with our Flash application. The following code example implements our Flash Remoting server control using ASP.NET's custom tag structure:

 <MM:Flash id="Flash" runat="server" /> 

Notice the tag's name, MM:Flash , which corresponds to the TagPrefix we set when registering the server control and the name embedded in the server control. Our Flash assembly will always use the name " Flash ". The id parameter creates a unique identifier for us to reference this server control programmatically; we'll call our control " Flash ". The runat parameter tells our web server to process this line of code on the server; the server control will not work without this parameter set to " server ".

With the instance of our server control created, we can send and receive data to and from our Flash application. To do this, we access our Flash Remoting server control instance and use its methods and properties to communicate with Flash. The main properties for communicating with Flash are:

Params

The Params property is an array of parameters passed by the Flash Player to the ASP.NET page (used to determine the number of parameters passed and access the parameter values).

Result

Setting the Result property passes the results of our ASP.NET page to the Flash application, as would a typical return command in most languages.

DataSource

The DataSource property allows us to bind Flash with an ADO.NET-compatible data source (SQL, XML, Access, etc.). See Section 8.2.2 later in this chapter for details on binding data sources.

We'll access our server control's properties from the ASP.NET Page_Load( ) event, which is called automatically after our ASP.NET page loads but before any data is shown to the user. The following example shows how to set the Result property to " Hello World! ", the text string that will be returned to Flash. In this example, we use Flash.Result , where the portion before the period, Flash , matches the id attribute that labeled the control with the identifier Flash . Here is the C# code:

 <%@ Page Language="C#" debug="true" %> <%@ Register TagPrefix="MM" Namespace="FlashGateway" Assembly="flashgateway" %> <MM:Flash id="Flash" runat="server" /> <script runat="server"> public void Page_Load (Object Sender, EventArgs E) {   Flash.Result="Hello World!"; } </script> 

As written, our ASP.NET Hello World page is already available as a Flash Remoting service ( assuming you've uploaded it to your web server).

To build our Flash application that accesses this ASP.NET page, we'll create a standard Flash Remoting connection. However, instead of specifying a gateway in the same fashion as we do for ColdFusion, we create a blank ASP.NET file and name it gateway.aspx . A physical gateway.aspx file is always required when using Flash Remoting through .NET to establish a connection to the service. Flash can also use the filename without the .aspx extension to establish a connection to the ASP.NET page. Here is an example:

 NetServices.setDefaultGatewayUrl("http://localhost/myASPApp/gateway.aspx"); gatewayConnection = NetServices.createGatewayConnection( ); ASPXservice = gatewayConnnection.getService("helloWorldPage", this); 

Make sure that your web.config file has the following entry within its main <configuration> tag:

 <system.web>   <httpModules>     <add name="GatewayController"          type="FlashGateway.Controller.GatewayController,flashgateway" />   </httpModules> </system.web> 

Once Flash has established a connection to the service, we can call our method. Naturally, we should create the _Result and _Status callback methods to handle the results returned before invoking the remote method. Since our ASP.NET page does not have a method for Flash to call, Flash treats the entire ASP.NET page as a method. To call this implicit method, use the identifier helloWorldPage , the same name as our ASP.NET page (without the .aspx extension):

 ASPXservice.helloWorldPage( ); function helloWorldPage_Result (Results) {   trace(Results); } function helloWorldPage_Status (Status) {   trace(Status); } 

When our Flash application runs, it accesses our ASP.NET page, establishes a Flash Remoting service, and displays "Hello World!" in the Output window.

8.2.1.1 Using code behind with ASP.NET pages

Microsoft learned from the shortcomings of ASP 3.0 and has allowed .NET developers to provide better separation of presentation and business logic within an ASP.NET page. This implementation, called code behind , allows us to create and register server controls within the presentation layer of the code and implement that code programmatically in .NET assemblies.

With code behind, a separate page is created to hold the business logic. To keep things consistent, the name for the code-behind page should be the complete name of the ASP.NET page (including the .aspx extension), followed by the proper extension for the given programming language. For example, if the ASP.NET filename is helloWorldPage.aspx , the code-behind file should be named helloWorldPage.aspx.cs if programmed in C#, or helloWorldPage.aspx.vb if programmed in VB.NET. If you're using Visual Studio .NET as your programming environment, this is done for you automatically.

In our helloWorldPage.aspx file, we need to change the Page tag to properly reference the code-behind page. The Page tag references the namespace and class name for our code-behind page, using the Inherits tag. If you're using Visual Studio .NET, you'll notice that an extra property is set; the CodeBehind property is purely a Visual Studio .NET construct and not necessary for those using other editors or IDEs :

 <%@ Page language="c#" debug="true" CodeBehind="helloWorldPage.aspx.cs"  Inherits="FRDG.helloWorldPage" %> 

We can also remove the script tag from our ASP.NET page, since we will reimplement the script in our code-behind page.

In a new file named helloWorldPage.aspx.cs , we create a class named helloWorldPage within the FRDG namespace. This class is used by our ASP.NET page to implement our Flash server control.

In our code-behind page, we need to reference the necessary .NET namespaces so that we can access their classes from within our application. You'll notice we also reference the Flash Remoting assembly as FlashGateway so that we can have access to its classes in the code-behind page:

 Using System; Using System.Web.UI; Using System.Web.UI.WebControls; Using FlashGateway; 

Finally, let's build a class to implement our ASP.NET page. This class inherits from the ASP.NET Page object, which every ASP.NET page automatically inherits. (Technically, the ASP.NET page inherits from the code-behind page, and the code-behind page manually specifies that it inherits from Page .) Among other things, the Page object invokes the Page_Load( ) callback function when the page loads.

Within our class, we must create an instance of the Flash server control to access its properties and methods. This object must have the same identifier as we used in our server control's id parameter. Notice that the type, FlashGateway.Flash , is referenced using the namespace, despite the namespace being imported at the top of the file. The reason for this is that since our server control instance is called " Flash ", it would cause a name clash if we didn't use the full namespace path . We also define the Page_Load( ) event handler to provide result data to Flash:

 namespace FRDG {   public class helloWorldPage : System.Web.UI.Page {     protected FlashGateway.Flash Flash;     public void Page_Load ( ) {       Flash.Result="Hello World!";     }   } } 

We can reference the code-behind ASP.NET pages from Flash using the same ActionScript code as the previous section. When the Flash movie is run, the ActionScript trace( ) method prints "Hello World!" to the Output window.

8.2.2 Connecting to a .NET Assembly

Class libraries allow Flash to connect directly to business logic. This allows Flash to access multiple methods and properties from one service.

To explain how an assembly is called from Flash, we'll develop a Hello World assembly and access it as a Flash Remoting service. To get started, create a new text file named HelloWorldAssembly.cs , because we're writing it in C#; name it HelloWorldAssembly.vb if you're programming in VB.NET.

Before writing the skeleton for our assembly, we must reference the required namespaces. For our example file, we'll need the base namespace ” System ” as well as Flash's namespace FlashGateway.IO :

 using System; using FlashGateway.IO; 

Assemblies and code-behind pages require a different namespace than ASP.NET pages to implement the Flash component. Assemblies use FlashGateway.IO , while ASP.NET pages use FlashGateway .

Within our file, let's create the skeleton of an assembly by defining its namespace and class name. Every assembly requires a class name, but the namespace is an optional item used to help developers categorize assemblies based on their responsibilities. You'll notice our Flash Remoting namespace differs from our ASP.NET pages. This is because the ASP.NET page includes a server control object with additional functionality for use in ASP.NET pages.

 using System; using FlashGateway.IO; namespace FRDG {   public class HelloWorldAssembly {     // statements go here...   } } 

Next, we'll add a constructor to initialize any variables for the object and our SayHelloWorld( ) method, which returns a string to our Flash application:

 public HelloWorldAssembly ( ) { } public string SayHelloWorld ( ) {   return "Hello World!"; } 

Compile the assembly into a DLL and place it in your web server's /bin directory.

Unlike their COM predecessors, .NET assemblies need not be registered with the server. To make an assembly active and available, just place it in the /bin directory.

Once the DLL file is placed in your web application's /bin folder, Flash Remoting can access the assembly's methods and properties. Establishing the service in Flash is similar to accessing our ASP.NET page. The difference is that we use the class's full name (including namespace) as the service name. Also, unlike our ASP.NET page, we can call the assembly's service methods directly and create wrappers to catch their results. (Although an .aspx page is compiled into an assembly by the .NET application server, it is not available in assembly form to Flash Remoting, hence the difference in the way Flash Remoting deals with assemblies and ASP.NET pages.)

 NetServices.setDefaultGatewayUrl("http://localhost/myASPApp/gateway.aspx"); gatewayConnection = NetServices.createGatewayConnection( ); AssemblyService = gatewayConnnection.getService("FRDG.HelloWorldAssembly", this); 

With a reference to our assembly available as a service, we can access any of its methods directly. Invoke our assembly's SayHelloWorld( ) method and trace the Results returned from our SayHelloWorld_Result( ) callback function as follows :

 AssemblyService.SayHelloWorld( ); function SayHelloWorld_Result (Results) {   trace(Results); } function SayHelloWorld_Status (Error) {   trace(Error); } 

When run, our Flash application displays "Hello World!" in the Output window.