During everyday development with the Xcelsius SDK there are quite a few things that can be taken for granted once you get comfortable with the technology and process. These “for-granteds” can often be points overlooked by developers getting started with the SDK and can cause considerable pain if they’re not properly evaluated and accounted for up front.
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.