Here are 3 points to be aware of that I’ve been meaning to cover. I was reminded of all of them again this week while fielding various related questions from people getting started with the SDK. Hopefully they can help you out.

1. Flash Shared Local Objects just got more slippery

With the most recent release of Flash Player 10.3, users can now delete Shared Local Objects with ease. Individuals could always clear out SLO’s but the most recent player release made it quick and easy to accomplish. In short, if you’re developing custom components for Xcelsius that rely on the use of SLO’s, you may want to brace for more support calls and also document and alert your users on how SLO’s are leveraged. You can bet people will be inadvertently deleting them.

2. XLP’s and XLX’s should be archived

XLP’s, or Xcelsius Add-On Packager Files, generate unique XLX installer files so that end users can install your custom components in their Xcelsius environments. XLP’s stamp XLX’s with unique ID’s that are used by the Xcelsius Add-On Manager to determine if a component that is attempting to be installed already exists in that Xcelsius environment. Long story short, if you lose your original XLP file that you used to generate and distribute your original XLX file(s) and you have to create a new XLP file and generate new XLX files for subsequent distribution to end users, you’re likely going to encounter installation issues that require any preexisting component by the same fully qualified name to be uninstalled before the new one can be installed. This obviously isn’t the end of the world but it can create confusion and should be avoided if possible.

3. Common Component Classes – First in Wins

If you have multiple add-ons that you maintain and some or all of those components leverage a set of base classes and those components and the base class functionality that they rely on can potentially or do evolve (get released) at different paces, be keenly aware that the Flash Player operates using first-class-loaded-wins. This means that any components that rely on a common class will be using the first version of that class that was loaded by the Player. If there are any inconsistencies between the first class loaded and the class functionality that a given component is actually expecting, this can create some obvious and not so obvious behaviors and/or bugs at runtime. Be sure to nail down a strategy that allows all of your components to coexist and evolve peacefully.

Evan DeLodder is CTO at Centigon Solutions, an SAP Partner focused on the development of cutting edge mapping technologies in the Business Intelligence space. To learn more about him, please visit our Gurus page.

With all of this flexibility available, which is what most developers ultimately want, the SDK can often times be a stumbling block for people trying to get started on custom component development. It never was for me personally, I took a look at some of the examples that came bundled with the SDK and was quickly off and running. However, I think that I picked it up faster because I had a lot of experience in Flex and Xcelsius, so there wasn’t a fundamental gap in my mind as to how all of the pieces fit together.

I think that the gap that causes a lot of developers who are new to the SDK to spend a lot of time up front, is trying to figure out how the entire platform fits together and how their component fits into that picture.  This makes sense, because most developers want to know what’s going on in the grand scheme of things so they can make the right development decisions at the component level.

With the way the current SDK is set up, there’s no really, really clear path for even fairly talented Flex developers (that are unfamiliar with Xcelsius) to jump in and get started without first getting mired down in the technical minutia. Like I said, the SDK offers a great deal of flexibility. It’s the brick, mortar, wood and nails you need to build a house. My thought is; is there a way to repackage the SDK to where all of this flexibility still exists, but at an easier to use level? Instead of wood and nails, could we give people highly configurable frames and still achieve the same ultimate objective?

I think this is definitely possible and have started to spec out a framework that would enable a Flex developer to come into the SDK, drag and drop a few components onto a property sheet, and with absolute minimum customization, facilitate even the most complex of Xcelsius integrations. The goal is to bypass the finer details of boiler plate property sheet operations and integrations and instead focus attention on what matters most – the guts of the actual component and making a great UI for the property sheet.

My parting questions to developers invested in the SDK are:

1. Do you like how it’s currently structured?
2. What if anything did you find challenging?
3. What would make it easier to work with?
4. What are the top 3 features you’d like to see included?

I’m gathering this feedback for a labs project that I’m working on for the upcoming ASUG event and will be able to share the result with other SDK developers. All input is welcome.

Evan DeLodder is CTO at Centigon Solutions, an SAP Partner focused on the development of cutting edge mapping technologies in the Business Intelligence space. To learn more about him, please visit our Gurus page.

Recently, a person new to the SDK asked how to create a custom read-only data grid component for Xcelsius.  Luckily, this is fairly easy to achieve with one read-only property integration with the SDK. This basic example could be extended to include style and selector functionality and can hopefully serve as a base for anyone interested in developing a custom grid. This isn’t performance optimized and is meant to be very simplistic, so if you do decide to run with it, you’ll need to do some basic housekeeping to get your component up to snuff.

Why would someone want this?

Most likely due to performance enhancement opportunities, word-wrapping and dynamic formatting and/or dynamic selection capabilities, which are all common features desired by many who use the list view and grid-type components. If you’d like to see some of these features implemented in a subsequent blog post, leave a comment on which one(s) you’d like.

You can download the source files for the data grid here.

Evan DeLodder is CTO at Centigon Solutions, an SAP Partner focused on the development of cutting edge mapping technologies in the Business Intelligence space. To learn more about him, please visit our Gurus page.

Xcelsius does not have a built-in feature that allows the storage of local data, a commonly requested piece of functionality. Up until very recently there has been no really easy way to accomplish it with simple client tools, and one way or another it required jumping through several hoops. Fortunately, HTML 5 brings us a feature called localStorage, which allows HTML pages to store data locally across browser sessions and after the closing of the browser window. This is one of many capabilities that HTML5 brings to the table, transforming the browser into a tool with much more potential for serving up fast, more powerful and lightweight applications.

Working as a Team

In less than a few hours, and starting with zero knowledge on the HTML 5 feature, I was able to integrate HTML 5’s localStorage feature and Xcelsius simply by using External Interface connections from Xcelsius and some JavaScript on the HTML side to bridge the gap. The result is a dashboard that can save data locally to a user’s system and then load it for use during the next browser session. Click on the screenshot below to open a new window with the .swf file.

Thoughts

The drawbacks- HTML5 is not close to being a finalized standard and most browsers in operation only support a subset of HTML 5. Has this stopped people from using it yet or gearing towards it? Not really. However, for most large organizations and developers reaching large audiences with RIA technology, it is a very significant drawback that would still have to be worked around. Cross-browser compatibility support is not a task that I ever miss or that I like to have to factor in when developing, which is why I’m a Flex developer and Flash advocate.

If you need high-quality offline capabilities now…

We use and highly recommend using Antivia’s XWIS. XWIS is an enterprise-ready comprehensive set of tools that provides users and developers alike with extremely powerful and robust offline, data manipulation and data connectivity capabilities.

Try the demo out

We have hosted the HTML 5 dashboard example and all of the source files if you’d like to try it out for yourself.

Feel free to stop by the Centigon Solutions Lab page to check out some of our other demos.

Evan DeLodder is CTO at Centigon Solutions, an SAP Partner focused on the development of cutting edge mapping technologies in the Business Intelligence space. To learn more about him, please visit our Gurus page

The caveats from the previous components still apply, but the data restrictions have been lifted. This is a very simple example that could be extended to share data between production models in an infinitely customizable and more sophisticated way.

Update source code can be found here.

* The event dispatching and listening needs to be cleaned up and will be in a subsequent post. SCDD is preventing some normal event behavior and the current event structure is a temporary workaround to ensure data is updated across the board.

Evan DeLodder is a Senior Software Engineer focused on the development and application of cutting edge Rich Internet Application technologies in the Business Intelligence space. To learn more about him, please visit our Gurus page

How it’s done

To accomplish component-to-component communication across swf’s is fairly straight forward. All you need is a ModelLocator-type singleton that both component’s share data through. The components don’t even need to be the same, they just need to refer to the same ModelLocator class and corresponding ModelLocator variables in order to share data. You can see how this is done by downloading the sample source code.

Next week, we’ll explore the possibilities of sharing data globally between swf’s using this approach. Globally, meaning that any SCDD component can access the data exposed by our custom component that leverages the ModelLocator.

Evan DeLodder is a Senior Software Engineer focused on the development and application of cutting edge Rich Internet Application technologies in the Business Intelligence space. To learn more about him, please visit our Gurus page.

In this is a one of a kind boot camp, you will learn how to transform Flex components into configurable Xcelsius add-ons as well as learn how to maximize the Xcelsius SDK with your existing Flex development skills and create brand new components. Our bootcamp instructors will arm you with enough hands on experience and sample code to tackle custom component and connections for your organization’s Xcelsius dashboard initiatives.

At this Bootcamp you will receive:

• 2 days of intensive hands on Flexcelsius training
• Training material + labs source code
• 2 functional components with source code included
• Lunch is provided on both days
• Perfect San Diego weather!
• And more….

Unfortunately we only have a few seats left so Register Now!

Evan DeLodder is a Senior Software Engineer focused on the development and application of cutting edge Rich Internet Application technologies in the Business Intelligence space. To learn more about him, please visit our new FleXcelsius page.

The problem:

You may develop a button, canvas, list box, tree viewer or other UI component in Flex, apply inline styling directives, package it up for use in Xcelsius and view it in the Xcelsius designer without issue.  However, when you enter runtime mode in Xcelsius, your component may lose some or all of its inline styles, rendering it partially unusable or invisible. This is due to the parent Flex Xcelsius application inadvertently stripping away styles at runtime.

The solution:

For a generic solution to skinning and styling reapplication, you’ll need to reference in your project library path, the haloclassic.swc swc in the Flex SDK directory (a path similar to this C:\Program Files (x86)\Adobe\Flex Builder 3\sdks\2.0.1\frameworks\themes\haloclassic.swc). Once you have referenced the swc, create a CSS file for your component(s) that specifies all of the default skins and styles to their halo default or desired style as shown in the sample code below (full code here). This set of steps will need to be implemented as needed on a per-component basis if your components are experiencing style loss. Once you have defined your CSS file, the next step is to reference it in your component file as you would any other CSS asset.

.myButton {
backgroundAlpha: 1.0;
backgroundSize: “auto”;
bevel: true;
borderAlpha: 1.0;
borderCapColor: #919999;
borderColor: #B7BABC;
borderSides: “left top right bottom”;
borderSkin: ClassReference(“mx.skins.halo.HaloBorder”);
borderStyle: “inset”;
borderThickness: 1;

…..

<mx:Style source=”myButtonStyle.css” />
<mx:Button label=”My Button” styleName=”myButton”/>

There is an alternate to this approach, which would be to reapply styles with ActionScript code. However, this approach is more compact and has little to no impact on your actual component files. As a best practice for visual Xcelsius components, define your styles in CSS as opposed to inline to prevent the build up of redundant style specifications.

Evan DeLodder is a Senior Software Engineer focused on the development and application of cutting edge Rich Internet Application technologies in the Business Intelligence space. To learn more about him, please visit our new FleXcelsius page.

As the marketing and PR battle rages on between Apple and Adobe, blanket statements are being tossed around regarding the viability of both HTML5 and Flash technologies as if they’re competitors. So far, this debate has only served as a disservice the community in general as the misinformation train continues to board people in high places who don’t completely understand the technologies and begin to make decisions for their organizations that are driven by the general influence of external, biased companies promoting their own product interests, as opposed to properly assessing project technology needs based on other factors that have more, real world substance.

Many people have voiced their opinions on this topic and it’s certainly not breaking news though we thought it beneficial to speak directly on the future viability of Flash and Flex for enterprise Rich Internet Applications, specifically in the Business Intelligence space.

Flash and HTML have both been and are still going to be around for a long time for one very good reason: They both serve an indispensable purpose on the web and for supporting business applications that run on web based technology. Both of these technologies fill in unique gaps and should be used as complimentary technologies and not as competitors or as “one-or-the-other” choices.

With the new release of HTML5, some of the new and long awaited features included in the specification are: A new caching utility to support offline web applications, video and audio API’s with native video embedding, a drag and drop API, new form controls and validation utilities that don’t require custom coding, new online and offline data caching capabilities and a 2D drawing API for rendering vector graphics and images on the fly, just to name a few.

With much respect to HTML5 and the forward progress it is making with the aforementioned features, in the BI space of developing RIA portals, dashboards and data visualizations, I’m having a really hard time seeing where HTML5 could even come close to Flash or Flex technology, without a herculean effort, as many have suggested. I say this as an engineer who has years of experience in both camps. For the past several years, since the very first Flex Alpha release, I’ve been enthralled with the Flex technology, the API’s, the SDK and how rapidly one can develop a highly interactive and infinitely customizable application to solve even the toughest challenges and fill in the most demanding requirements. I won’t get into a punch-down list or table of comparisons between HTML5 and Flex/Flash for BI because it would be both unfair and irrelevant; rather provide a higher level assessment of these technologies and the value that Flash brings in the enterprise BI space.

When considering what technology to adopt and run with for enterprise BI projects, below are just a few of the fundamental categories that I consider to be compelling factors that set Flash and Flex far ahead of the HTML5 pack. For most developers, these go without saying.

OOP Rapid Development

Flex technology is simply and absolutely indisputably light years beyond what HTML5 can bring to the table in this arena and will continue to be for the foreseeable future. Why? Because Flex is a highly adaptable software approach developed on top of a robust and comprehensive ever-expanding tried and tested SDK that leverages the powerful concept of Object-Oriented Programming with ActionScript. What does this mean aside from the fundamental benefits gained when comparing a full OOP approach to a scripting language? While HTML5 is getting up to speed and is only scratching the surface of Flash capabilities with its new list of features, Flex and Flash are evolving on a frequent basis with an impressive progress rate and evolutionary leaps of capabilities in each release of the Flex SDK which also happens to have release cycles much faster than releases of HTML (a year or 2 for Flex releases vs. years and years for HTML ). This advantage ultimately means a faster time to market/delivery, lower development costs (because so much is already baked in and easily extensible), much more flexibility and feature-rich applications that can continuously evolve in shorter cycles with much less effort.

Cross-Platform Compatibility

While HTML5 and browsers are constantly taking strides to reduce this gap, cross platform compatibility will remain an uphill issue for HTML5 and its new features for the foreseeable future because there are so many factors that come into play. This is nothing new; it’s the same sort of compatibility issues we’ve always had to deal with when using browser scripting technologies.

Flash has few differences between platforms, most of which are minuscule when compared to those found in HTML applications. Testing and developing for cross-platform compatibility takes a hit on developer productivity, which can have a significant ripple effect. Flash applications in general require exponentially less cross-platform testing, which is a big part of the draw for developers and organizations alike as it saves both time and money.

SDK and API Evolution

I was thoroughly impressed to see that HTML5 has snapped to with native access to a handful of very useful API’s and enjoyed thinking of the new mashup possibilities while browsing the some of the new features in action while taking the IE9 test drive. This is a great step forward for the web and is a direction that will certainly continue to grow.

Flex allows developers to build on a comprehensive SDK which is perfectly suited for BI and enterprise development, complete with a base charting framework, classes for data modeling, and an ever expanding arsenal of highly adaptable frameworks and 3^rd party open source BI technologies.

How fast the HTML5 direction and evolution of its tooling will grow is a good question, but one thing remains certain, and that is that Adobe Flash and Flex products will always be leading the way a good 10 steps ahead and setting the new innovative standards into the future of RIA technology and rich experiences on the web.

The State of Flash Mobile

Flash is alive and thriving in the enterprise and will continue to do so, especially with the imminent release of Flash support for many mobile platforms on the horizon. The mobile platform is another example of where these two technologies can co-exist and add tremendous value to one another. The prospect of having a mobile device with these powerful features combined opens a new world of possibilities and we’re absolutely champing at the bit to get a hold of the Flash releases for Android.

Conclusion:

Flash and HTML will always be a part of the web, serving as complimentary technologies that drive value and ultimately combine forces to provide for an optimal application and user experience. However, they should not be compared or pitted against each other for web dominance arguments, because it’s unfair, inapplicable and way off base. The “versus” argument has no merit when discussing these technologies for enterprise business applications, which is where a large disconnect of understanding around the argument is running rampant. In short, we need to be sure we’re always basing our technology decisions objectively, on technical facts and sound research and not on any particular media hype machine.

Evan DeLodder is a Senior Software Engineer focused on the development and application of cutting edge Rich Internet Application technologies in the Business Intelligence space. To learn more about him, please visit our new FleXcelsius page.

We wanted to reach out in advance to gather preferences on what you would like to learn and any particular SDK pain points that you would like to have addressed. Please leave comments on this post regarding a preferred agenda and please email me if you’re interested in attending.

Evan DeLodder is a Senior Software Engineer focused on the development and application of cutting edge Rich Internet Application technologies in the Business Intelligence space. To learn more about him, please visit our new FleXcelsius page.