When using CDI, the only difference on the client is that you have to use the Cdi singleton. Here is a simple example of remoting with an injected client proxy for an CDI bean:

<?xml version="1.0"?>

<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml"

    creationComplete="Cdi.getInstance().initApplication()">

    <mx:Script>

        import org.granite.tide.cdi.Cdi;

        import org.granite.tide.events.TideResultEvent;

        import org.granite.tide.events.TideFaultEvent;

        

        [In]

        public var helloService:Component;

        

        private function hello(name:String):void {

            helloService.hello(name, resultHandler, faultHandler);

        }

        

        private function resultHandler(event:TideResultEvent):void {

            outputMessage.text = event.result as String;

        }                       

        

        private function faultHandler(event:TideFaultEvent):void {

            // Handle fault

        }

    </mx:Script>

    

    <!-- Provide input data for calling the service. --> 

    <mx:TextInput id="inputName"/>

    

    <!-- Call the web service, use the text in a TextInput control as input data.--> 

    <mx:Button click="hello(inputName.text)"/>

    

    <!-- Result message. --> 

    <mx:Label id="outputMessage"/>

</mx:Application>

            

This is almost identical to the standard Tide API described in the Tide remoting section, and all other methods apply for CDI.

You can benefit from the capability of the Gas3 code generator (see here) to generate a strongly typed ActionScript 3 client proxy from the CDI bean interface when it is annotated with @RemoteDestination. In this case, you can inject a typesafe reference to your service and get better compile time error checking and auto completion in your IDE:

<?xml version="1.0"?>

<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml"

    creationComplete="Cdi.getInstance().initApplication()">

    <mx:Script>

        import org.granite.tide.cdi.Cdi;

        import org.granite.tide.events.TideResultEvent;

        import org.granite.tide.events.TideFaultEvent;

        import com.myapp.service.HelloService;

        

        [In]

        public var helloService:HelloService;

        

        private function hello(name:String):void {

            helloService.hello(name, resultHandler, faultHandler);

        }

        ...

    </mx:Script>

    

    ...

</mx:Application>

            

It is possible to benefit from even more type safety by using the annotation [Inject] instead of In. When using this annotation, the full class name is used to find the target bean in the CDI context instead of the bean name.

<?xml version="1.0"?>

<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml"

    creationComplete="Cdi.getInstance().initApplication()">

    <mx:Script>

        import org.granite.tide.cdi.Cdi;

        import org.granite.tide.events.TideResultEvent;

        import org.granite.tide.events.TideFaultEvent;

        import com.myapp.service.HelloService;

        

        [Inject]

        public var myService:HelloService;

        

        private function hello(name:String):void {

            myService.hello(name, resultHandler, faultHandler);

        }

        ...

    </mx:Script>

    

    ...

</mx:Application>

            

This typesafe mode allows to better detect API inconsistencies between the Flex application and the Java services, because the Flex compiler will immediately warn you when a server method signature has changed (and Gas3 has regenerated the client proxy).

Until now, all client-server communications have been done through the global Tide client context. Tide supports secondary client contexts which represent particular server conversations.

When a remote component call triggers the beginning of a new conversation, the context referenced by the TideResultEvent is a new context object corresponding to this conversation. Of course many such contexts can exist simultaneously on the Flex client, and correspond to different server conversations.

Variables having less than conversation scope are managed in the corresponding context. Session scoped variables and components are always managed in the global context.

@Stateful

public class HotelBookingAction implements HotelBooking {

    ...

    @Inject

    private Conversation conversation;

    

    public void selectHotel(Hotel selectedHotel) {

        conversation.begin();

        hotel = em.merge(selectedHotel);

    }

    ...

}

           

public function selectHotel(hotel:Hotel):void {
(1) tideContext.hotelBooking.selectHotel(hotel, selectHotelResult);
}

private function selectHotelResult(event:TideResultEvent):void {
(2) var localContext:Context = event.context as Context;
    var hotel:Hotel = localContext.hotel;
}
           

All following operations must be then done through the localContext to be executed in the correct server conversation context. That means mainly that this context object has to be stored somewhere in the application, for example in the MXML corresponding to a particular wizard component. Optionally, it is also possible to store only the conversationId, and retrieve the context object by:

var localContext:Context = Cdi.getInstance().getCdiContext(conversationId)
           

When the conversation ends, the context object returned in the result events remains the local conversation context, to allow the Flex client to get the last call resulting context variables. It is deleted just before the next remote component call on the global context.

The Tide client context can register listeners for CDI events triggered on the server-side. The interesting events are sent back along the server response and dispatched at the end of the processing of the result so that the context is correctly synchronized when the event is dispatched.

Here is a simple example:

@Stateful

public class HotelBookingAction implements HotelBooking {

    ...    

    @Inject

    @Confirmed

    private Event<BookingEvent> bookingConfirmedEventSrc;

    ...

        

    public void confirm() {

        em.persist(booking);

        bookingConfirmedEventSrc.fire(new BookingEvent(booking));

        conversation.end();

    }

}

           

[Observer(remote="true")]
public function bookingConfirmedHandler(event:BookingEvent):void {
    Alert.show("Booking confirmed: " + event.booking);
}
           

GraniteDS provides a client-side component named identity that ensures the integration between the client RemoteObject credentials and the server-side container security. It additionally includes an easy-to-use API to define runtime authorization checks on the Flex UI.

The CDI identity component (of class org.granite.tide.cdi.Identity) predictably provides two methods login() and logout() that can be used as any Tide remote call:

private var tideContext:Context = Cdi.getInstance().getCdiContext();

public function login(username:String, password:String):void {
    tideContext.identity.login(username, password, loginResult, loginFault);
}

private function loginResult(event:TideResultEvent):void {
    Alert.show(event.context.identity.loggedIn);
}

private function loginFault(event:TideFaultEvent):void {
    Alert.show(event.fault);
}

public function logout():void {
    tideContext.identity.logout();
}
            

Or with dependency injection:

[In]
public var identity:Identity;
            
public function login(username:String, password:String):void {
    identity.login(username, password, loginResult, loginFault);
}

private function loginResult(event:TideResultEvent):void {
    Alert.show(event.context.identity.loggedIn);
}

private function loginFault(event:TideFaultEvent):void {
    Alert.show(event.fault);
}

public function logout():void {
    identity.logout();
}
            

The identity component also exposes the bindable property loggedIn that represents the current authentication state. As it is bindable, it can be used to choose between different views, for example to switch between a login form and the application view with a Flex ViewStack component:

<mx:ViewStack id="main" selectedIndex="{identity.loggedIn ? 1 : 0}">

    <views:LoginView id="loginView"/>

    <views:MainView id="mainView"/>

</mx:ViewStack>

            

Finally the identity component is integrated with server-side role-based security and can be used to get information or show/hide UI depending on the user access rights:

<mx:Button id="deleteButton" 

    label="Delete"

    enabled="{identity.hasRole('admin')}"

    click="myService.deleteEntity(myEntity)"/>



            

With this declaration, this button labeled Delete will be enabled only if the user has the role admin. Another possibility is to completely hide the button with the properties visible and includeInLayout, or any other property relevant for the UI component.

This can also be used as any remote class with result and fault handlers:

 public function checkRole(role:String):void {
    identity.hasRole(role, checkRoleResult, checkRoleFault);
 }
 
 private function checkRoleResult(event:TideResultEvent, role:String):void {
    if (role == 'admin') {
        if (event.result)
            trace("User has admin role");
        else
            trace("User does not have admin role");
    }
 }
            

You can notice that the result and fault handlers have a second argument so you can use the same handler for many access check calls.

It is important to note that identity caches the user access rights so only the first call to hasRole() will be remote. If the user rights are changed on the server, or if you want to enforce security more than once per user session, you can clear the security cache manually with identity.clearSecurityCache(), for example periodically in a Timer.