Flash Builder

02
Jan
2021

Goodbye Flash

So, I finally uninstalled Flash Player on 31 December 2020 as it ceases to be supported by adobe.

Adobe Flash Player was removed from your system.

Consequently a number of the older articles on this blog, if they didn’t already, will cease to make sense. I started the blog back in 2006 when I had decided to freelance and focus my programming skills on flash.

I now have couple of archive boxes books and DVDs of redundant material.

The first time I encountered Flash was around 1996/1997. I was at the time developing CD-ROM applications using Macromedia Director. The web was starting to take off, although outside of corporate networks everybody’s access was via a dialup modem. Very slow. Browsers were pretty crude and inconsistent in behaviour for all but the most basic interactions.

We had a visit from someone at Macromedia that excited our manager at the time, but I didn’t see the potential in Flash. Yes, it used vectors. Yes, it had animation. But there was little or no interactive capability – no programmatic language – Director was so far ahead.

My career moved to project management, and Flash did make it’s way into our studio, primarily in the realm of designers – interactions remained extremely limited but Flash had two key valuable properties that I think gave it a solid foundation: It looked and behaved the same, no matter what browser or platform, and that being vector based, it was extremely bandwidth efficient compared to anything that could be built in Director (or Authorware)

Next step in my career was server side, and xhtml/javascript. Flash added a further string to its bow by enabling video streaming – mixed with vector animation and more sophisticated interactions – again maintaining consistent appearance across platforms and browsers while the browser wars raged.

As the dot com boom went bust, I went freelance, but having to decide where to focus. I spent time learning Java and Flash, and eventually Flash won my attention – I have always enjoyed working on ‘creative’ projects along with designer and other creative types.

I enjoyed programming ActionScript 2, but Flash felt somewhat buggy at the time. The ActionScript components were good in principle, but again, buggy – so much time spent developing workarounds against a tight deadline.

I really enjoyed programming ActionScript 3 – It was far more solid. capable and better structured, Flex provided a solid framework that did not suffer the problems of the earlier UI component framework.

Flash with Flex remained great at:
* Being consistent across platforms
* Providing a video playback platform
* Proving an animation platform and intuitive ways of tying interactions together with ActionScript
* Enabling designers and developers to work together on really interesting creative projects

In 2010, I was really disappointed by Steve Jobs thoughts on Flash, but more disapointed by Shantanu Narayen’s response. It didn’t feel like there was a technical initiative coming to solve the issues raised by mobile. On reflection, Steve Jobs was right. It is true that performance was poor on mobile devices – certainly on my HTC Desire. And using flash to attempt to emulate the new touch controls, even the scroll inertia was hugely wasteful of cpu cycles compared utilising controls already built into the mobile systems.

I quite liked AIR, and used it with Flex on a few projects. It worked well, although it exposed the perennial issue of the UI controls not necessarily behaving as a user would expect. Yes it continued to provide consistency across platforms, but when we move into an application space, compliance with the expectations of the host system becomes more paramount than ensuring the application looks pixel-for-pixel the same across platforms. Attempting to adapt (testing for OS to decide where to position things like dialog button defaults and window controls) became tedious. The end result – spend the extra effort, or release an inconsistent product.

Most of my discussion is from a programmatic / application point of view. For all it’s faults Flash Platform created a great community of designers and developers and a few who could wear both hats, working to build some wonderful projects while the browsers were somewhat chaotic.

Having seen the full life cycle of a product makes me feel old. From its humble beginnings, to massive dominance, to falling back as other technology caught up and surpassed. I still have a sealed copy of Flash Builder 4. I wonder what I’m going to do with that.

Here’s a search that will return my old flash related bloggings

As reported elsewhere

Posted by creacog, 0 comments
19
Jul
2011

Which width? (AIR on devices)

Within the Flash APIs is there there are many similarly named properties which provide subtly different results based on their spec and the state of the application. Width and height are such properties.

Having just read of Mike Jones’ recent article: 10 Tips When Developing For Multiple Devices, and tip #1: Check screen dimension on initialisation, it includes a couple of lines of code to get the landscape height and width of the device screen using a boolean expression to determine the longest dimension. For me this begs the question, why can’t I simply get the right values directly from the API? Especially if my app.xml properties state the app should only display landscape, full screen.

The properties examined here:

Although accurately described in the reference, it isn’t necessarily easy to visualise the differences in behaviour for these properties from the documentation alone. So herewith, a simple HelloWidthHeight app to trace out the values upon initialisation. Included in that app is a class implementing logic based on Mike’s as static methods. The results of debug sessions executed on my HTC Desire are detailed for comparison in the table below.

Key app.xml <initialWindow> properties used were:

  • <visible>true</visible>
  • <aspectRatio>landscape</aspectRatio>
  • <autoOrients>false</autoOrients>
  • <fullScreen>true</fullScreen>
A B C D
stage.orientation default rotatedRight rotatedRight rotatedRight
stage.width 0 0 0 0
stage.height 0 0 0 0
stage.stageWidth 480 800 800 800
stage.stageHeight 800 480 480 480
stage.fullScreenWidth 480 480 800 480
stage.fullScreenHeight 800 800 480 800
Oriented.landscapeScreenWidth 800 800 800 800
Oriented.landscapeScreenHeight 480 480 480 480
Oriented.portraitScreenWidth 480 480 480 480
Oriented.portraitScreenHeight 800 800 800 800
  1. Screen inactive, phone held in any orientation
  2. Screen active, phone lying flat on the desk
  3. Screen active, phone held landscape, mic to the right (this is the intended orientation for the app)
  4. Screen active, phone held portrait, mic to the bottom

In conclusion, unless the application is only ever launched while the screen is active (though that would be the norm), the safe way of determining an oriented width and height is to use a boolean expression along with the fullScreenWidth and fullScreenHeight properties.

UPDATE (20-July-2011): The following table runs the same code in the BlackBerry PlayBook Simulator:

A B
stage.orientation default default
stage.width 0 0
stage.height 0 0
stage.stageWidth 1024 1024
stage.stageHeight 600 600
stage.fullScreenWidth 1024 1024
stage.fullScreenHeight 600 600
Oriented.landscapeScreenWidth 1024 1024
Oriented.landscapeScreenHeight 600 600
Oriented.portraitScreenWidth 600 600
Oriented.portraitScreenHeight 1024 1024
  1. Simulator initially landscape
  2. Simulator initially portrait

Note: Behaviour is slightly different on the PlayBook simulator in that the orientation of the application is set before the initialisation code runs. Therefore unlike on the HTC Desire, fullScreenWidth and fullScreenHeight are correctly returned as the orientation of the application expects.

If anyone else cares to run the code, I’d be interested to hear how variable other devices are in their results, or if this is showing a bug when run on HTC Desire. Running AIR 2.7 here.

Posted by creacog in ActionScript, Adobe, AIR, Flash Builder, HTC Desire, 0 comments
28
Apr
2010

Flex 4 Spark VideoDisplay (measure, overlay, skin)

In a previous article I described some of the steps required in Flex 3 in order to keep an overlay position in sync with a VideoDisplay component. With the release of Flex 4, VideoDisplay is one of the components to be updated. Via VideoPlayer, it gets a Spark makeover. Internally its core, or ‘view’, has been reimplemented using Open Source Media Framework. For anyone wishing to keep an overlay in position over the view, however, the same key issue remains:

None of the various width or height properties of the VideoDisplay component describe the width or height of the contained view.

So, to get the properties of the view we need to delve deeper into VideoDisplay and use the mx_internal namespace. Even then, the ResizeEvent.RESIZE event is broadcast by VideoDisplay before it’s view dimensions (column B) have been updated to the new site.

In that previous article I observed that if, after each resize, I added an Event.EXIT_FRAME listener, I could guarantee that the VideoDisplay’s view had been sized by the time it was called. I observed that the same is true in Flex 4. However EXIT_FRAME didn’t feel like the right place to be doing this. So with a closer look at the component life cycle we can see that handling the FlexEvent.UPDATE_COMPLETE event is more appropriate. Column C shows the view’s width/height after UPDATE_COMPLETE has been broadcast. It colours red when a value  disagrees with column B (RESIZE). And so, it is column C that contains the values we want to use while managing our overlay.



Sample 1 : Comparing width/height after resize, then updateComplete

Using this information and Flex 4’s new component and skinning architecture, we can build quick and simple to use video overlay component rather than messing about with external listeners and calculating positions as we did in the previous Flex 3 examples.

Reviewing what Flex 4 includes ‘out of the box’…

  • VideoDisplay : a non-skinable component that wraps an osmf ‘view’. It translates much of the osmf api and events to what we are accustomed to with Flex 3.
  • VideoPlayer : A skinable component provides hooks for skin parts. A required part is an instance of VideoDisplay. The others are the buttons and controls we’d normally expect when giving the user control of the video.

The VideoPlayer and it’s skin are overkill for this example, so we’ll create something far simpler…

  • VideoDisplayOverlayContainer : A container component who’s children will overlay a VideoDisplay
  • VideoDisplayOverlayContainerSkin : A simple skin, providing the required videoDisplay skin part.

This way, overlaying the video is as simple as giving the container some child components and a layout (defaults to basic layout). In the example that follows we overlay a label instance to each of the four corners and the centre of the view…

<components:VideoDisplayOverlayContainer
    id     ="videoDisplayContainer"
    source ="VideoSampleForFlex.mp4"
    width  ="100%"
    height ="100%" 	>
    <s:Label text="A" top="2" left="2" backgroundColor="0xffffff" backgroundAlpha="0.4" />
    <s:Label text="B" top="2" right="2" backgroundColor="0xffffff" backgroundAlpha="0.4"  />
    <s:Label text="C" bottom="2" left="2" backgroundColor="0xffffff" backgroundAlpha="0.4"  />
    <s:Label text="D" bottom="2" right="2" backgroundColor="0xffffff" backgroundAlpha="0.4"  />
    <s:Label text="O" verticalCenter="0" horizontalCenter="0" backgroundColor="0xffffff" backgroundAlpha="0.4"  />
</components:VideoDisplayOverlayContainer>



Sample 2 : Overlay container component

View source

Posted by creacog in Adobe, Flash Builder, Flex 4, Flex Components, Spark components, 3 comments
22
Mar
2010

Flex builder 4 help system (CHC) and backups

(Edit: Of course this should have been titled Flash Builder 4)

One of the changes with Flash builder over previous Flex Builder products is in the help system. The help files are no-longer bundled and indexed by eclipse help. Instead a new help application is installed which attempts to combine the documentation with community content.

I must admit to not receiving this application particularly well in the first instance. However I have seen it develop over a number of weeks and as an AIR application it is expected to continue to develop independently of major product release cycles.

Since it is a new product, some rough edges can be expected. There is already a technote (cpsid_83103) relating to getting context-sensitive help working correctly in a fresh install of Flash Builder 4.

Randy Nielsen’s post on using the help client provides a good orientation for new users.

However I think there are some other things that system administrators at least (and users who backup their user-directories – particularly to the cloud) should be aware of…

1. The many names of adobe help

On a Mac it installs application “Adobe Help” into /Applications/Adobe. The main application window when running is titled “Adobe Community Help”. And you will see this application widely referred to in Adobe communications as CHC or Adobe Community Help Client. If you ever look for the preferences files for the application, you’ll find them in ~/Library/preferences/chc.xxxx.1 (where xxxx is a 40 digit hex number). Note: missing is the usual “com.adobe.” prefix.

2. Downloading the help files.

The help files need to be downloaded to your local system in order for the application to work. The current version of the application (3.0.0.400) only displays local content if the network is not available. Otherwise it always displays content from the web. This seems slightly wasteful and slow. Though we can expect an option to default to local content irrespective of network connectivity in future versions.

3. Help file size

You can manually control the downloads via Preferences>Updater settings then  “Manage now”. This will show a table of help files, whether they are current or not and their size. The size however is slightly misleading. It refers to the zip file size and therefore the network bandwidth required to download the help package. Once unzipped however, the disk-space used is a considerably larger number. I find that the help packages for Fb4 and associated stuff expand to use 563Mb.

4. Where the help files are stored

On a mac the help files are expanded and stored in the user’s preferences folder. ~/Library/Preferences/chc.xxxx.1/Local Store/Help

To me this is not the right place to be storing such content. Help content is not preferences and is not necessary ‘per user’. Preferences are usually backed up. There is absolutely no need to be backing up this content – to do so is a waste of storage, network bandwidth and machine time. Once all Adobe products are integrated with CHC, the help folder will be considerably larger than my current 563Mb.

In summary

Adobe Help, Adobe Community Help Client (CHC), is currently in its infancy as an application, but will be soon in the hands of many, many users. As an AIR application, the development team have far more flexibility to make releases between major product cycles. I hope and believe that the points I highlight (and location of help files in particular) will be addressed in coming releases – they have all been submitted to the team – not just blogged here. However they are blogged here because I think storage suppliers could be in for a field day unless sys-admins are made aware, and add rules to their backup process to omit the help files.

Posted by creacog in Adobe, Flash Builder, Flash Platform, Flex, Flex 4, Flex Builder, 1 comment
22
Mar
2010

Flex 4 and Flash builder 4 final, finally released

It’s been a long time coming, but looks worth the wait. Lots of improvements and a fundamental change (enhancement) to the skinning components in the form of Spark. Although Flash Catalyst isn’t released yet, there’s still scope to get to grips with the developer side of the Spark skinning architecture in the meantime.

Although the charting components have now been open-sourced, i.e. you don’t need the professional licence to access them, significant differences make the premium version vital for heavy development e.g. Performance profiler, Memory profiler and network monitor. For more detail check the Flex version comparison chart.

Andrew Shorten’s post on the Official Flex Team Blog is a good start point for getting into this release.

Posted by creacog in Adobe, Flash Builder, Flex 4, 0 comments
20
Mar
2010

my first Flex 4 spark : component + skin = ResizeableTitleWindow

With Flex 4 having been in beta for ages and hopefully soon to be released, it really was time I started to get my head around the spark components and how to approach to skinning them. Rather starting off with the usual button, I thought I’d kick off with getting a ResizeableTitleWindow going. Of course a few others have already created variants. I think everyone using Flex at some point needs a resizeable version of TitleWindow. To that end, looking at the TitleWindow specification page of the Flex 4 wiki, clearly Adobe planned on implementing resize behaviour on the TitleWindow. It doesn’t seem to be implemented yet. So in the meantime my version is as close as I think I can get to that specification.

The end result (view source enabled):

My 1st spark skin

In the running example above, window ‘A’ is a normal instance of spark.components.TitleWindow. This leads me to my first spark skin. If you are viewing on a windows or linux platform it won’t look any different from normal. In that case it is simply using spark.skins.spark.TitleWindowSkin. However if you are viewing on a Mac you’ll notice that the close button is located at the left of the title bar rather than the right. This is where a Mac user will expect it to be – but the default in Flex is currently to the right, no matter what platform. This was achieved through the most basic technique of skinning a spark component : clone an existing skin, adapt it and apply it. To that end, spark.skins.spark.TitleWindowSkin was cloned to creacog.spark.skins.TitleWindowMacSkin, and a couple of lines changed swap around the closeButton and title. We switch skins if we are on the mac platform by loading the compiled Mac style sheet in the preinitialize handler of main.mxml.

This technique of cloning is one thing that initially feels slightly wrong with spark. It leads to a lot of duplicate code which is something developers normally do their best to avoid. The reasoning seems mainly to facilitate Flash Catalyst workflow, where skins are predominantly the domain of interaction designers for whom duplication is the norm and code re-use doesn’t really figure. However until and unless Flash Catalyst matures into a product that can support round-trip editing, there’s a good chance that developers will be making a lot of use of diff tools and duplicate code across skins is something we’ll probably just get used to. The subject has been discussed in detail in a number of other blogs and their comments:

Implementing and skinning ResizeableTitleWindow

We now need to know a little more about the mechanics of spark skinning. I must admit having previously read some blogs and watched some video posts of how simple spark skinning is – and I got it until sitting in-front of an empty editor scratching my head – where to begin? The key thing that crystallised it for me was to read the skinning contract.

So, first was to create the component class. This extends spark.components.TitleWindow. It adds a new optional skin part of resizeHandle of type UIComponent. Essentially we need something the user can click on no matter what it’s appearance. creacog.spark.events.TitleWindowBoundsEvent was created extending spark.events.TitleWindowBoundsEvent with the new event constants for resizing. Using the creacog package is the main deviation from the specification – for obvious reasons.

Catalyst was used to create the ResizeHandleSkin. A simple custom component with two states: up and over. It has a semi-transparent white background that transitions it’s alpha on mouse over. Importing ResizeHandle.fxpl into the flex project resulted in slightly odd packaging. Simply moving ResizeHandle.mxml to the creacog.spark.skins package brought it into structure consistent with the rest of the project.

spark.skins.spark.TitleWindowSkin was again cloned, this time to creacog.spark.skins.ResizeableTitleWindowSkin. To that 3 new lines is all that was required to add an instance of the resizeHandle skin part – positioned front-most and at the bottom right corner. It could be any size and positioned anywhere, but the logic behind resize adjusts the width and height of the component, leaving it’s x and y untouched.

creacog.spark.skins.ResizeableTitleWindowMacSkin is a further clone, this time with the closeButton skin part positioned to the left for mac users.

Finally we use styles (being careful of  the new namespace syntax) to the  notify the flex framework to use creacog.spark.skins.ResizeableTitleWindowSkin (and substitute creacog.spark.skins.ResizeableTitleWindowMacSkin on the Mac) whenever a ResizeableTitleWindow instance is drawn. If we omitted this step, the ResizeableTitleWindow instance would be created, but it would fall back to using the TitleWindowSkin which does not include the resizeHandle skin part and therefore the resizing functionality would be ignored.

Summing up

This new approach to skinning components feels far superior to what we have been used to in Flex 3. I’m slightly scared that the workflow from designer  via catalyst could result in inflexible skins (at least in the short term), as post-production work is required of the developer if the skin is intended to take on runtime styling for example. Lack of any sign of round-trip capability means skin production is currently one way from catalyst. i.e. tweaks or changes within catalyst will create a new output and it will be for the developer to merge the changes with additions s/he may have implemented on previous skins.

Looking forward to getting going on some real flex 4 projects.