We are pleased to announce that the UcompOS RPF is now available for commercial release as of May 17, 2011!
Since its alpha release in late 2009, a lot of work has been put forth to ensure that the UcompOS RPF is a rock-solid platform from which developers can deploy Rich Portal Applications. In fact, the UcompOS RPF is a foundational component of our new Octane product offering. The power and flexibility that the UcompOS RPF offers has proven itself time and again as we’ve worked to bring Octane to the market. This fact is a key reason why we believe it is time to make the UcompOS RPF commercially available so it can do the same for you.
For more information about obtaining a license for the UcompOS RPF for your own site, please visit our Pricing Page.
If you are a regular reader of this blog, you know that a lot of blogs have been dedicated to talking about the UcompOS Proxy components. However, one component that hasn’t received a lot of attention so far is the UcompOSStyleProxy.
The UcompOSStyleProxy provides a means to manage the style properties of the UcompOS Main Container. For instance, you can use the UcompOSStyleProxy to override the default background image on the UcompOS Main Container or set fade in\out duration effects on UcompOSWindowProxy instances.
To demonstrate the two behaviors above, let’s take a look at a simple UcompOSStyleProxy code example. First, in my UcompOS instance, I have created a simple HTML application called styler.html that is loaded as a background application by my dockManifest.xml file. The code in my styler.html application is fairly simple and easy to follow as evidenced by the following sample code:
//instantiate the UCompOSSDK
//instantiate a UcompOSStyleProxy instance that we can apply styles to
var styler = new UcompOSStyleProxy();
//set the default background image to Picture1.jpg at the correct file path on the server
//now, set the UcompOSWindowProxy instances to fade in\out 3 seconds
Hopefully, this example is simple enough to follow along with fairly easily; the mechanics involved are designed to be as straightforward as possible. However, one could easily envision scenarios where a user’s preferences are saved in a database and loaded at run-time by turning styler.html into a scripted application using PHP, PERL, or the language of your choice. Or, perhaps you may look at setting and instantiating style properties at startup using your dockManifest. The choice is up to you!
Note also that it is also possible, for example, to change the color of text on the menu bar by using some code like (using our example above):
You will want to keep in mind, though, that it is likely that the UcompOSStyleProxy class will continue to evolve in such a way that setting styles in this manner may not work in the future. Therefore, this practice is not recommended at this time. However, you will want to stay tuned to the updates that are made to this class as the UcompOS SDK continues to mature over the coming months.
As I’ve experimented with some various aspects of the UCompOS framework, I have picked up on a couple of subtle nuances that I thought I’d share.
First, if you haven’t yet switched to the Flash Builder 4 Beta from Flex Builder 3, doing so is probably a good idea. One key reason (beyond enhanced functionality) is that I have noticed a significant reduction in the sizes of exported Flash Builder 4 swf files. For example, one artifact I had created in Flex Builder 3 was about 300 k when I exported it, but this was reduced to about 70 k once I ported it to Flash Builder. I was surprised at the huge difference.
Speaking of Artifacts, after talking with Edward Mansouri at some length about some of the file size issues I mentioned above, and his recommendation is to use Flash CS 4 or 5 (if you’re lucky enough to be in the private beta program) for artifact development wherever possible. Flash can get your file sizes down to roughly a tenth of what I can get them down to in Flash Builder, which is a big deal if you have a lot of artifacts in your implementation.
I want to move on a little bit and talk about developing applications using the AIR 2.0 SDK, which is the only way to take advantage of some of the AIR functionality in the UcompOS framework. The AIR 2.0 SDK and runtime can both be downloaded from http://labs.adobe.com/downloads/air2.html (you will need both). Once you have downloaded it, go ahead and install the runtime (which installs automatically). However, you will need to need to do some tweaking to Flash Builder in order to install the SDK properly (I will only cover Flash Builder in this blog post). What you need to do is find the “sdks” folder in your Flash Builder folder and open it. It should look something like this:
What you are going to want to do next is make a copy of the 4.0.0 folder. In my case I copied it and named it “4.0.0 AIR 2.0″
This will be the folder where we copy the files from the AIR 2.0 SDK into. Simply open the ZIP file containing the AIR 2.0 SDK and copy and paste the files into the 4.0.0 AIR 2.0 folder. If you are prompted, be sure to overlay any old files with the new ones from the ZIP file, or you will run into problems.
Now, you will need to configure Flash Builder to use the new SDK for applications. To do this, open up Flash Builder, and create a new Flex project. On the dialog that comes up, select the “Configure Flex SDKs” on the middle right of the dialog:
On the dialog that comes up, click the “Add” button, and browse to the 4.0.0 AIR 2.0 folder you created earlier:
Then, select the “Ok” button, and your dialog should look like this:
Once you’re done, click the “Apply” button, and then click “Ok”. Then, under the “Flex SDK version” part of the dialog, select the “Use a Specific SDK” radio button, and select your new SDK from the select box. From here on out, setting up your project is normal. Note that unless you made your new SDK the default, you will have to manually select your SDK every time you create a new application that leverages the AIR 2.0 SDK (including UcompOS applications).
The final topic I wanted to touch on was getting your publisherID that you need to add to your application descriptor file in order to make it work with UCompOS. The easiest way to do this is to export a release build of your AIR application and install it. Once that’s done, you will need to browse to the location where you installed the AIR application, and browse to the “META-INF/AIR” folder. In that folder, you will see a file called “publisherid” that contains the value that you need to set for publisherID in your AIR application descriptor file (don’t forget to set allowBrowserInvocation to true!):
I hope some of these tips help you out as you work with UcompOS.
As I’ve worked with the UcompOS platform since its Public Alpha release, I have come to be impressed with its flexibility in bringing a lot of different applications together into one portal system. However, as I built and tested various applications, it became very apparent that I needed to take a few steps back and think about a framework for deploying applications or risk becoming engaged in a never-ending battle with the following tasks:
- Editing static dock manifest files
- Keeping application manifest files between applications straight
- As the number of applications increases, easily finding the files I need to change without worrying about breaking another application becomes a challenge
- Deploying updated versions of the UcompOS runtime without accidentally deleting or overwriting application content
- Managing permissions to applications for different users
These issues were tackled in a fairly systematic manner. My first logical step was to get rid of the static dock manifest and move that to some application code that generates the dock manifest from a database. For my UcompOS implementation, information for applications that go on the dock menu is pulled from a very simple table that looks like this:
The Application_ID field is just a numerical value indicating the identifier of the application. It is the primary key for the database and auto increments as new applications are installed. The Application_Descriptor field is very simple, in function to the “title” attribute in your application manifest. The Background and Default_State fields contain the values each application should have when they are added to the dock manifest file dynamically. The Directory_Path field requires a bit of explanation. What I’ve done is create a folder called “applications” in my UcompOS implementation where all applications reside:
The Directory_Path field is the name of the folder where each of my UcompOS applications is launched from. The final field, Is_Global, is a field that indicates whether or not the application should be globally accessible to all users of my UcompOS Portal or not. Note that if this field is set to false, I have another database table that contains the list of users who have access to the application.
This database is managed through a front-end that grants/denies access to applications based on the selection of a checkbox (Checking a box calls an AJAX function that automatically adds/removes permissions to various applications) like in the screenshot below:
With all this in mind, the script that generates the UcompOS dock manifest file performs the following actions:
- Add all of the global applications in my applications table to the dock manifest
- Retrieve the list of which applications the user has access to, and add those applications to the dock manifest
- Return the entire dock manifest file to the UcompOS main container
You will notice above that I did not provide a filename for each application’s manifest file (just a directory path). This was an intentional decision, as I chose to have a convention where the name of the application manifest file would be in a sub-folder called “manifest” under each application’s folder, and that the application manifest filename would be the same for each application. This makes it very easy for me to easily identify the application manifest for each application, and helps maintain consistency across my UcompOS applications.
In my case, this application manifest for each of my UcompOS applications is named “getAppManifest.php”, and it is a simple script that returns the XML application manifest for the application. In it, the file does a security check to make sure that the user is logged in and that they have permission to access the application (if the application isn’t global). If everything checks out, then gatAppManifest.php spits out the application manifest for the application.
I should note that, for very practical reasons, I chose not to place the information for each application manifest file into a database table. While this was certainly a consideration, the realization I came to was that this was going to be just too cumbersome, especially if you factor in the possibility of multiple languages. Also, I considered the fact that this file is fairly static in nature, and wouldn’t need to be managed all that often. Ultimately, I felt that there wasn’t going to be much of a difference time-wise between managing this manually or through a database interface. For my framework that stresses ease of use, managing the application manifest via straight XML presented a far more straightforward path.
Before I close, I wanted to briefly touch on the file structure I have in place for my implementation. By having each application compartmentalized in its own subfolder, it is much easier to troubleshoot and find issues with each application without worrying about breaking anything else. Further, it allows me to do a simple drag and drop operation to deploy new applications in my UcompOS framework (I have a simple function in my application manifest file that adds the new application to the Application database if it doesn’t exist, and sets up any auxiliary tables needed for the application. I also have been able to create several reusable templates I can leverage or when I begin work on a new UcompOS application). Ultimately, the framework I’ve put into place solves all of the issues I mentioned above and greatly simplifies the application deployment process, allowing me to focus on application functionality instead of the mechanics of application deployment, which for me, is what it’s all about.