One of the most influencing factors behind the new features we add to Degrafa comes from the community. As Degrafa has progressed we make sure to follow the Degrafa Group as much as possible to help guide people on how to use it and answer questions.

In some cases it’s hard to help because the version in question just doesn’t support what the person is asking about. When these scenarios come up we take notes and add it to our “to do” list to see if we can provide a solution in a way that elegantly fits into the roadmap for Degrafa.

One scenario that came up was the ability to load a bitmap from an external URL to be used in a Degrafa Fill. Currently you have to embed a bitmap to use it in a fill. However, Degrafa Beta 3 will allow to specify any external bitmap source to be used in a Fill. This will be no real effort to achieve this if loading images from the same domain as your application, but you’ll also be able to use images from an external domain that provides a permissive crossdomain.xml file, like Flickr.

Another recent addition to the existing COLOURlovers API, was support for runtime ‘pattern’ loading via crossdomain permissions, from COLOURlovers.com. The way we’re implementing this makes it pretty easy for users to take advantage of.

Below is a simple example using the ColourLovers API and runtime loaded random ‘patterns’ used as BitmapFills. That’s to give you an idea of what’s possible. After that a quick explanation of how easy it will be to use runtime loaded images in your BitmapFills.

View Sample

Loading BitmapFill images from your own domain

If you are loading images from the same domain as your Flex application, no access permissions are needed, and using a runtime loaded BitmapFill is very easy*.

If you have your images in an images directory within the same directory as your main application swf, then you would normally specify the source as follows:

1
2
3
4

<bitmapFill
      id="localExternalBitmapFill"
      source="images/myImage.png"
      angle="45" />

That’s basically all there is to it! When the image has loaded the fill will appear, for the Geometry item(s) that use(s) it. The additional delay is an indeterminate time after your Flex application has initialized, simply because your image is not embedded and it takes a little time to load. If you use the same source url assigned to multiple BitmapFills (you may for example use the same external image, but have different settings applied in another BitmapFill), then the external image file is only loaded once, and only one set of BitmapData is generated for all the BitmapFills that use it.

Loading BitmapFill images from External Domains

These examples relate to using a Flickr source:

a) A simple, one-off example:

1
2
3
4
5

<bitmapFill
      id="bitmapFill"
      source="http://static.flickr.com/15/88928122_0f06ac7417.jpg"
      rotation="45"
      smooth="true" />

The above works as is, because flickr has the crossdomain permission policy file in the default location expected by the flash player at http://static.flickr.com/crossdomain.xml. This example can be expressed in another way as a separation of basePath and relative url as in the following example.

b) Loading multiple images from a single external location, managed with a LoadingLocation:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

<utilities:LoadingLocation
      id="flickr"
      basePath="http://static.flickr.com/"
      policyFile="http://static.flickr.com/crossdomain.xml" />
<paint:BitmapFill
      id="bitmapFill"
      loadingLocation="{flickr}"
      source="15/88928122_0f06ac7417.jpg"
      rotation="45"
      smooth="true" />
<paint:BitmapFill
      id="bitmapFill2"
      loadingLocation="{flickr}"
      source="142/325447236_ac4c1b9b3a.jpg"
      rotation="30"
      smooth="true" />

The above is likely to be suited to applications which have collections of external assets hosted externally, and where the location of the assets (domain) may change at some point in time. By setting up a single LoadingLocation to reference a basePath and policyFile (particularly if the policy file granting access is not using the default name and/or in the default location) you can make code maintenance easier if/when the external location of the assets changes.

As you can see the use of external images from within mxml is quick and easy. Watch out for more additions in the Degrafa Fills arena coming up before too long in another beta3 preview post.

*However you should also be aware that if your domain is accessed with both http://www.mydomain.com and http://mydomain.com then you may still need a crossdomain.xml file that grants permission to both, if you specify absolute urls for the local domain image files. The reason for this is that if you specify a url for the image that is on a different subdomain than that under which the application swf has been accessed, flash player security rules come into play and the flash player will seek permission via a policy file – which will fail to be granted it doesn’t exist. You should be ok using relative urls.

One of the benefits Degrafa offers as part of the framework is the ability to repurpose code to no end. This may be obvious for things like geometry, but if you find yourself writing redundant code for fills and strokes, this tip should help.

Rather than specifying the same common fills and strokes in every MXML file where you’re doing your drawing, you can separate fills and strokes in to their own MXML files. Then, whenever you need to access a fill or stroke, you can add that component to your MXML file and easily access them when appropriate. By doing this, you also have the advantage of code hinting, which makes for quick and easy coding.

As an example, I could make a Fills.mxml file where I specify a fill, like this:

Then, I can reference that MXML file wherever I’m drawing with Degrafa. For example, the following Circle.mxml code would reference the Fills.mxml:

Those two code samples represent some of the basic methods for cutting down on the amount of code you need to write. I could reference that Fills.mxml in any other component and use the fills defined in that file. You could do the same for strokes as well or make separate MXML files for each type of stroke or fill. It’s up to you. I put together a more evolved example than what was shown above and you can view it here:

View External Fills and Strokes Example
(View Source enabled. Also available on Degrafa Samples page)

Taking This Further

You can expand on this example by making separate Fills and Strokes files for different parts of an application, share those files with other Degrafa users, adjust the structure for what makes most sense for you, etc. One thing that would be interesting is to make a separate Colors class that you can reference from the Fills and Strokes files. Then, when you change the color values in the Colors class the whole scheme of the app could change. Hook that Color class up to a color API like Kuler or COLOURlovers and you could get some really unique opportunities for custom UIs, data visualization, compositions, etc.

We’ve been thinking about a way to grab a color palette using a color API, present a user with a bunch of variations of Fills and Strokes based on that selected palette, allow for selection of which Fills and Strokes the user wants, then write out MXML files with those selections in it. The user could then drop those MXML files into their Flex project and they’re ready to go. It could work the other way too where a user could read an MXML file and be presented with Fill and Stroke swatches of which they can edit and write out a new MXML file.

The more we keep plugging away on Degrafa it seems there are more and more opportunities for creating some really unique tools. Imagine a Fills and Strokes palette that uses the Fills and Strokes MXML files as the model. Who knows what other kinds of things people will come up with as the framework progresses. Any suggestions?