I completely agree that it has been poor communication from Adobe, especially after what they have announced at AdobeMAX this year. So, timing could have been better and the messages that they initially shared could have been better formulated. Adobe acknowledges this and have sent out their apologies for that as well. But the harm was already done. I even saw people leaving prerelease and other programs (I can’t mention by name) furious about what happened and turning their backs on Adobe entirely. I respect those decisions, but come on, is it really such a bad thing?

For those of you who are not quite up to speed on what exactly is going on at Adobe. Let me briefly state the latest developments.

Let’s start with LiveCycle. For those of you who don’t know what LiveCycle is, it is a product that allows you to define information workflows, mainly based on PDFs. So, for example, you could fill out a job application form in a PDF, digitally sign it with you eID card (in Belgium at least) and send it to a specific email address. The PDF attachment gets picked up from the mailbox and the information is extracted and put in a database. After that a “thank you” email is sent to the applicant, while in the mean time the HR manager is notified of a new application. Upon approval by the HR manager in the so called “workspace” a new PDF is sent to the unit manager, notifying him that he should interview this candidate, together with the candidate’s résumé. After the interview the unit manager can then input his findings in a evaluation form and LiveCycle will pick that up as well to put it into the database and notify the HR manager that the evaluation has been submitted. Would the candidate be rejected, the can be marked in the “workspace” again for example, an automatic email will be sent to the candidate notifying him of his rejection.

Now, this is just one example of what LiveCycle can do. Even though Adobe is shifting its focus towards other strategic solutions, they will continue to develop LiveCycle (as you can read here), invest in finding new customers and product support is still guaranteed, so you’re not left alone with your solution if you’re currently using LiveCycle.

As for dropping the Flash Player on mobile devices, I don’t think that is a bad thing. You see, if Adobe wants to keep the same version of the Flash Player on all devices (desktop, mobile, tablet) then a lot of code will have to go in checking whether or not things certain features are available. This requires a lot of effort and slows down progress on the features that matter the most. I mean, come on, when did you actually use a Flash based website on you mobile device? Either it wasn’t mobile optimized causing frustration in content that is not scaled properly, or it just was overkill for a mobile device.

Now Adobe has the opportunity to focus on the desktop platform and make full use of the GPU hardware acceleration and other cool features that require more processing power than what the other devices can offer at this moment. It is clear that Adobe wants to move in the direction of gaming with Flash, which I have been expecting for some time now.

Remember, I just said that the Flash Player will be dropped on mobile. That does not mean that the cross-device AIR solution is being dropped. On the contrary! AIR for mobile devices will continue to be developed by Adobe and is one of the key products/features they will maintain. So you don't have to worry about your cross-device development.

However, the Flex SDK is going to be put into the Apache project, bringing along a new produt name as well, since Adobe won’t own the SDK anymore. Once the incubator is accepted, the product will be called "Apache Flex". You can read all about the Apache Flex Incubator right here.

That means that from that point on the SDK will be developed and maintained by the community. That will be a good thing in the sense that probably we’ll get more features more rapidly developed. But – and there’s a big "but" in here – I do see a problem in the adopt of the Flex technology in big companies. You see, what companies want is a support contract with time frame commitment. They want a red phone to the help desk when they encounter serious problems and at the moment they are paying big money for that. Once Flex is owned by the community, Adobe probably won’t be doing anymore support, because it is now up to the community.

This lack of support is what could harm Flex in the high end business companies. But then again, this will also lead to new opportunities for companies such as multimediacollege in the sense that we can now write and publish our own training material, as well as provide support contracts for helping out companies who need assistance with some Flex problems.

So, is Flex dead? Definitely not! And it isn’t dying either. We will have a huge community supporting the development and some highly skilled developers working on the features. I wish I had some magical device that allows me to see into the future to see what will happen with Flex when it becomes completely Open Source. But for now, I’m not yet worried about it’s future…

Well, the first step is having a user identification system that keeps track of how many users have already logged in for the same company as the user that is currently trying to log in. This part is fairly easy and can be accomplished be using a counter at company level. The licensing can then easily be managed by a non-public admin console. Each time a user tries to log in, the counter is checked against the maximum allowed concurrent users. Depending on the fact whether or not the maximum number of users is reached, the user gets an error message or the counter is updated as the user is verified.

That’s the easy part. It’s the logging out that can give you some headaches. If you provide a logout button, it is again fairly easy to attach a remote back end call to update the counter again, so it reaches zero when all the users for that company have logged out. But unfortunately users don’t always do what they are expected to do. So a lot of times they will just close the browser and your counter remains unchanged. And this poses the biggest problem, because the user has actually closed the application, but now the licensing part has been corrupted. Fortunately, LiveCycle Data Services has a nice feature called RTMP (Real-Time Messaging Protocol), which allows you to monitor a session on the server and act upon it when the session has been dropped.

Now, there are 2 types of sessions available on the server side: HTTPSession and FlexSession. The first one is actually a browser session. A browser session does not automatically close when the user closes the browser. It is a common misconception, but a lot of server technologies work in this way; be it LCDS, ColdFusion, … The browser session actually needs to timeout before it is closed. So it could very well remain in server memory for a couple of hours even before closing, depending on the server settings. The later one, the FlexSession, does react to the closing of the browser and therefore can be used to adjust the licensing server in the back end. To be able to use this, you need to use an to be able to use the RTMP channel. Another option would be to use the messaging service over RTMP connected to a Java Adapter. The advantage of using the DataService is that in the mean time you can also use it to implement server pushed data synchronisation, which is a very nice feature.

Now how do you let your back end service react to the dropping of the FlexSession? Well, all you have to do is implement the FlexSessionListener interface. You need to override the sessionCreated() method in which you save the session for later use and to add an event listener for the sessionDestroyed event. This event is fired when the user closes the Flex application by closing the browser window. You can find the code below in the SessionWatcher class I created for demonstration purpose, but you can include this functionality in any Java class that is connected using the data management feature. Enjoy…

public class SessionWatcher implements FlexSessionListener {
  protected FlexSession session;
 
  public SessionWatcher() {
    FlexSession.assSessionCreatedListener(this);
  }
 
  @Override
  public void sessionCreated(FlexSession session) {
    this.session = session;
    session.addSessionDestroyedListener(this);
  }
 
  @Override
  public void sessionDestroyed(FlexSession session) {
    system.out.println("Session " + session.getId() + " has been destroyed");
  }
}