When I Googled myself, I wasn’t so worried about the SEO aspect of my own sites, but wanted to see where I was being mentioned on the Web. Turns out, there aren’t a whole lot of places I’m mentioned, which is exactly what I expected. And while there are a few other people out there with my same name (even a Chicago-based metal band), I didn’t see too much out of the ordinary that I needed to worry about.

The main thing that I noticed was that there were a handful of websites that I had used once-upon-a-time for portfolio hosting and job searching that had some really old information about me, and equally as old work of mine displayed. Some of the sites I don’t even remember ever using, and was surprised that I showed up in their system. So I used my self-Googled time to scrub through the results, and visited (almost) all of the sites where I was mentioned. In most cases, I did something simple like update a profile picture or my bio. In other cases, I ended up deleting my accounts that had the old info and work samples. While I could’ve gone through the process of updating those sites, I found those particular ones to have never been too fruitful in any of my job searches. I mean really, in this day and age, as a Web developer, if I can’t make my own portfolio site and have to rely on another hosted site, then any job I may ever try to get is in fairly serious peril.

So, the moral of my story: Google yourself some time. You may find that it’s time for some much-needed spring cleaning to get your Web presence accurate and back in order.

Until next time, happy coding and Googling!

Until next time, happy coding!

In my container SWF, I had a library item set to export with class name “PreloaderMC”. As you might imagine, I created and added this preloader to the stage when my two SWF files were loading, then removed it from the display list once everything was loaded. I also had a library item exporting as “PreloaderMC” in one of my loaded SWF files. When testing and exporting the loaded SWF by itself, there was no issue. However, when I loaded that SWF into the container SWF, the preloader that was created and used in the loaded SWF was the one from the container SWF.

After asking a few colleagues and perusing some of the documentation, this wasn’t necessarily an unexpected find. It all has to do with application domain, which I won’t go into detail about here. In short though, if you use Loader.load() when loading another SWF file, and don’t specify LoaderContext (which, among other things, defines the ApplicationDomain for the loaded object), then the loaded SWF is considered a child domain of the container SWF, and thereby uses whatever class definitions are in the container that may have the same names.

So, lesson learned. Either be more explicit about specifying the application domain when loading external SWF files, or just use unique class names for item that are set to export to ActionScript.

There. I said it. That feels better.

But why am I not a fan of what they’ve done? Quite frankly, in the process of trying to build a mobile application with Flash Builder 4.5, I’m finding myself either engineering components from scratch, or reengineering the default “mobile-optimized” components to get them to do what I want/need. Plus, I’m finding that in an application of even a decent size (more than just a “hello world” app with a couple simple views like Adobe likes to show off to get Flash developers excited about mobile apps), the optimization and performance are still lacking.

Maybe I’m just being pessimistic. And maybe I’m not doing everything correctly to get things optimized for the mobile app. Honestly, I hope that I am missing something that I’ll catch soon and have a light bulb-over-the-head moment. But my experience thus far has taught me that Steve Jobs was right in bashing Adobe’s ability to create mobile-optimized content.

Here’s a snippet from a blog post from Steve Jobs, dated April 2010:

As you probably noticed, this post was from April of 2010. Yeah, that’s over a year and a half ago. And guess what? Adobe still doesn’t have it right. They’re close. But not there. And with the news of Adobe dropping mobile support for Flash Player a couple weeks ago, I’m guessing they never will be there. They may try to really hone in on the mobile application side, rather than just the Flash Player plugin for mobile, and they may get close. But like Jobs eluded to, Adobe holds all of its developers at the mercy of when they choose to adopt new features, whereas developing a mobile application natively gives immediate access to the full spectrum of features.

Don’t get me wrong. I’m not completely agreeing with the Flash haters out there who think that all Flash needs to go away—there is definitely still a time and place for Flash on the web. I’m just agreeing that Adobe needs to realize what their strengths are, and really concentrate on them rather than trying to get a foot into every single realm and telling developers that the Adobe solution will change their lives and work seamlessly.

The Glitch

In the mobile app that I’ve been working on, the design calls for the text input label to be placed “inside” of the text input field, on the left side. As such, I needed to add left padding to the TextInput component, so the text field wouldn’t overlap the label, which was sitting behind the TextInput control. So I set up my code to include the appropriate padding, and tested the result. When viewing the application, it looked just like it should, with the label positioned “inside” the TextInput component.

However, when I started typing a value into the fields, that’s when I saw the glitch:

The problem was this: When typing in your text into the field, and the text goes longer than the width of the visible width of the text field inside of the component, you completely lose the cursor and can’t see the text you’re entering. That is, until your text width is as long as or greater than the width of the TextInput component. Then, your text suddenly shifts, with the text field taking up 100% of the width of the TextInput component. So naturally, I let out a huge sigh and asked, “What happened to my left padding? Did I do something wrong?”

The answer to my question is this: The padding never got incorporated into the component correctly. And no, I didn’t do anything wrong. Adobe did.

The Solution

In my wrestling with how to fix this issue, I copied over the default TextInputSkin file (spark.skins.mobile.TextInputSkin) and put it into my project files. Then I opened it up and started investigating. Here’s what I found:

In the “layoutContents” method, I found a very big issue with the logic. And while it may seem like a small, innocent issue, it looms large when trying to add padding of any sort to the component. The issue is caused by 3 errors in the code of this function.

Error #1

These two lines are worthless. Why? It doesn’t solve any problems. It creates the skip in the text inputting described above, specifically when paired with the other two errors below. So, I commented these two lines out.

Error #2

This error is just plain and simple wrong. There’s a variable for “unscaledWidth”, which is the width of the ENTIRE component, NOT the width of the textDisplay (i.e. text field) after having padding taken into consideration. There’s actually a variable called “unscaledTextWidth” in the code, which is the value that SHOULD be used in this instance of “setElementSize”, because the textDisplay should have a width that has the left and right padding taken into consideration.  So, I changed this line to be:

Error #3

This error, like the last, is also just plain wrong. The 2nd argument for the “setElementPosition” method is the X value, which you’ll notice is HARD-CODED to “0″. This means that no matter what your left padding value is, the textDisplay will ALWAYS be set to the left side of the component. The x value should be based on the value of the left padding. So, I changed this line to be:

Conclusion

With the 3 errors above fixed, my TextInput component was finally working as intended, with the correct padding values, no intermittent skipping, and no random resizing of the text field inside of the component. Rather, like any other good text input field out there, it only displays the text width it should, while hiding the rest.

So if you find yourself questioning why something isn’t working as intended, take a few minutes (or hours, in some unfortunate instances) and look into the class/component/code you’re working with. Not only will you get a better understanding of how everything is set up, but you might just find another spot where the software engineers overlooked something and made an error.

Until next time, happy coding!

Postscript

Even though I am not a fan of how Adobe laid out this TextInputSkin, I must admit that I can see how/why it was done the way it was. There aren’t many times where a mobile application would call for a situation like the one I had. Chances are, Adobe’s quality assurance and testing didn’t think to include such a circumstance. After all, most mobile application components like text input boxes are set up to take up 100% of the screen (or close to it) to optimize hit area and visual space. So, giving them the benefit of the doubt, I can’t say I’m mad at Adobe for how they put things together. But I stick to my statement that if something isn’t working as intended, take some time to look into the code behind the scenes. You just might find something in need of fixing.

The solution was to make a “container” SWF file that would load in the actual content for the page.  This was nice because the container ended up also acting as a preloader for the main content.  All I had to do in the container file was to append a query string to the end of the content to load in (i.e. “photo.jpg?id=12345678″), which effectively acted as a “cache buster” that would make the browser and server think it was loading a new file each time the page was loaded.

The result was this little nugget of Flash goodness: FileLoader.

I polished up the container file I made in my solution above, adding in a couple of customizable variables, and am making it freely available for download.

Version Information:

• Version: 1.0
• Release Date: 1/12/11

Download:

Like what you see? Want to use FileLoader with your own Flash projects? Click the button below to download the most recent version of FileLoader, including a demo file with full instructions.

License:

FileLoader is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License, and is free to use. Links back to hesslerdesign.com are always appreciated. Permissions beyond the scope of this license may be available by submitting a Contact Request.

Description:

FileLoader is a simple, lightweight, easy-to-implement FLA/SWF file that acts as a preloader and container for files. It is made to load a specified URL, can enable “cache busting”, and provides the ability to change the hex color of the preloader and text. It can load any type of file that the built-in Loader class loads (SWF, JPG, PNG, GIF).

Example:

Instructions:

To use this file, simply update any/all of the customizable variables located on the aptly-named “Customizable Variables” layer (in .fla file). These variables include:

1. contentURL (String): URL path of the content you wish to load into FileLoader. (Default = “”)
2. tintHex (uint): Hex value to tint the preloader and error message. (Default = “0×000000″)
3. cacheBuster (Boolean): Enables/Disables “cache busting” on your content. (Default = “false”)

Once the variables are updated, just export the SWF and it’s ready to be embedded into your HTML page for the web.

Notes:

1. FileLoader is set up to resize itself to 100% of the stage width and height, making it flexible to be used at any size. This means you don’t have to worry about changing the dimensions of the file, and when embedding this file into your HTML page, you can specify any width and height you wish. The Preloader and Load Error (if applicable) will automatically center themselves to the stage. The content, however, has no special positioning logic, and will be placed at the (0,0) point of the stage. Thus, it is intended that this file will be embedded at the exact size of the content you’re loading into it, as this file is only intended to be a preloader and container for the contents of one file.
2. The Preloader and Load Error elements (where applicable) are automatically added to and removed from the file when needed. Your content will automatically be placed into the file when it’s loaded, and be the only item on the stage at that point. You don’t have to do anything special to get your content to display other than specifying a valid content URL.
3. When you’re ready to post the files to your website, just make sure you upload this file along with the content it loads. Also, make sure your pathing is set up appropriately for the content URL or your content may not load correctly.
4. If you update or change any of the MovieClips in the library, or update, append or change any of the code in the main Actions layer, this file may break. If you know what you’re doing with Flash and ActionScript, you shouldn’t have any problem figuring out how things work and can be edited. If you’re a beginner or novice, you may have a harder time editing. With that said, edit the non-customizable elements at your own risk.
5. If the “cacheBuster” variable is set to “true”, a random 8-digit ID will be appended as a query string to the “contentURL” variable (i.e. “photo.jpg?id=12345678“). When the cache buster is enabled, it will force the FileLoader to load a fresh version of the content URL each time it is loaded. This is helpful if you are posting your Flash content on a server with its own cache settings that would result in updated content not being immediately visible until the server cache clears. If this variable is set to “false”, no ID will be appended to the content URL, and the loaded content will be cached as normal.
6. Important: Use the cache busting sparingly and only when necessary, as it may end up bogging down the server with unnecessary calls to the server to reload the content.

Yahoo!  Heard of that website?  Thought so.  It used to be my home page.  That is, until the Flash ads literally started to hamper my user experience and demand my attention not only to see the stupid thing, but to figure out where I needed to click to close the darn thing.  I’ve since boycotted Yahoo! because of the repeatedly poor user experiences I had.  I mean seriously, check out this screenshot I took of the Yahoo! start page and see if you notice what may have annoyed me:

Yep, you guessed it.  That innocent little ad in the right side column (which started out in its own box, by the way) expanded itself — on its own — multiple times before settling into its home, where it should have been in the first place.  And when it expands, it overlays the main content of the page.  So if you click just a split second too late, you’re getting passed off to the ad’s site like a proverbial peace pipe, becoming another statistic in their “click-through rate” column, and furthering the spread of expandable ads, because the stats are saying they’re more effective due to the increase in click-rate.

Call me old fashioned, but that sort of in-your-face advertising represents a key problem with advertising — specifically with what is done with Flash.

Somewhere in the world, some Flash developer worked on this ad.  And this is happening all over the place.  Maybe the Flash developers are thinking it’s cool, and a good idea.  Maybe they are doing it because The Man is telling them they have to in order to get their paycheck.  Or because the client is paying them handsomely and for that, they just don’t care.

Whatever the reason may be, here’s my humble opinion:  Any Flash developer who works on ads like these and doesn’t feel remorse for the end user is not a true web developer.  In my mind, they simply fall into the category of someone who knows how to use Flash as a program, not as a tool to use  to truly create a good user experience with it when the situation calls for it.  It’s like someone who picks up Photoshop (or PS Elements) and thinks they’re a graphic designer just because they own the software and know how to crop a picture or auto-adjust levels.  I don’t claim to be an auto mechanic just because I’ve changed my own oil and own a socket wrench.  Or a heating and cooling expert just because I changed the air filter on my furnace.  Or a doctor because I own a thermometer and can gauge when I’m running a fever.

Simply put, I am seriously starting to dislike and even boycott websites with poor user experiences.  And like I said, because of my Yahoo! experience, I have honestly stopped visiting their site as my source for news and email.  I’d much rather get news from somewhere like Google, where clean and simple hierarchical text and images are used, and intuitive user interface design is present.  It’s clean, easy to read, and unassuming, letting me get to where I need faster and easier.

Until next time, happy (and better, more intelligent, less obtrusive) coding!

Here’s what my realization entailed:

As some of you may know, I’m always a big fan of keeping live text — be it static or dynamic — in Flash files, so that when I or anyone needs to go back in and make an update, it can be done w/o opening a Photoshop file, slicing and dicing image(s), and importing them into Flash.  Not only is it easier, but it’s a tremendous help in keeping file size down.

One aspect that is sometimes difficult is when a design calls for an effect on text, such as a gradient.  In Flash, we’re all probably aware that you can create a static text field and a shape (such as a gradient box), set the text field on the layer above said shape, and right-click the text layer to set it as a mask over the shape.  But here’s where my realization came…

It’s very true — this same effect can be done with pure ActionScript, for more dynamic scenarios… or if you’re one of those people who hate the stage with a passion.  All I’d need to do in the code is create a text field and a gradient box, layer them appropriately, and set the text as the mask on the gradient box.  And, since you can embed fonts in Flash (see the previous post about Embedding Fonts Using ActionScript 3.0), it can be done with any crazy display font that a design calls for (Immi 505 in the example below).

With that in mind, I put together a little demo to prove to myself (and you) that it was as easy as I thought it would be.  The demo has an input text field that you can use to change and update the text — which happens on the fly each time the input field is updated (so you know it’s truly live and dynamic, and not slight of hand).  So go ahead and play around with it.

So there you have it.  Dynamic text with a gradient fill effect.  Easy peasy, eh?

Until next time, happy coding!

Download

What’s that, you say? You want to see the source code to make this work? Well, ask and ye shall receive. Just click the button below to download the source FLA and AS file for this demo.

Lucky for you, Flash comes well-equipped with providing tools for developers to use when coding their Flash applications.  My three most-used Flash methods for clean lines and exact placement are listed below, and are all part of Flash’s Math class.  If you use them, you’ll be sure clean up the lines and sizes of your site in no time.  (It may not help poorly-drawn shapes that you draw by hand, but for dynamically-drawn, code-generated items, or code-based asset placement, it’s golden.)

A Few of My Favorites

Math.ceil()
This function returns the ceiling of the specified number or expression, which equates to the closest integer that is greater than or equal to the number.

Math.floor()
This function returns the floor of the specified number or expression, which equates to the closest integer that is less than or equal to the number.

Math.round()
This function rounds the value of the passed-in parameter to the nearest closest integer. If the passed-in value is exactly in the middle, it rounds up.

How and When to Use the Math Functions

Let’s say you have a square MovieClip that’s sitting on your stage with an x coordinates of 133.  You want to tween it with ActionScript to a point 50% of the way to the left edge of your application from it’s original point of 133.  You’ll need to have the x coordinate change for the move, obviously.  But if you simply figure out what point to tween to without somehow finding the nearest integer value, you’ll be left with a non-integer value (66.5), and your horizontal and vertical lines will get fuzzy.  However, if you use the Math.round() method, for instance, you’ll get an integer value (67), which will keep your horizontal and vertical lines crisp and clean.

In the example SWF below, there are two square MovieClips, both placed at an x coordinate of 133, as in the example above.  The top one does not use the Math class to get the integer-based pixel value it will end on.  The bottom one, on the other hand, does use the Math class, and rounds the target value to the nearest integer, thus resulting in a final x coordinate that is an integer.  Click on each box to tween it, and notice the end result of the boxes side by side.  You’ll quite obviously notice the top box having fuzzy edges when compared the the clean lines of the bottom box.

Know, Love, and Understand Integers

The important part to note about all three of these methods is that they all calculate the closest “integer” — or whole number.  This is immensely helpful, because if you base your width, height, x, or y values on any of these methods, you’ll always get back a whole-pixel value, which will give you the crisp edges that we all know and love.  With that said, there is one important exception….

Even though these methods return integers, there is still one more “gotcha” that you’ll need to keep in mind when developing your Flash application.  If you have a MovieClip of a square shape, for instance, and you have it centered to the registration point of the MovieClip, you may still get fuzzy pixels.  How, you ask?  If your square has a width and/or height whose value is an odd number (57, for example), its x and y coordinates will be half-pixels within the MovieClip (-28.5, -28.5 for a width of 57).  And if you place this MovieClip on the stage and put it at coordinates whose values are integers, the edges will be fuzzy, because of the coordinates of the object within the MovieClip.

To combat this, there are a couple of options:

• If you center your object(s) in your MovieClips (or other display objects), make sure they have dimensions that are even numbers.  If this isn’t doable, at least make the x and y coordinates integer values, even if it means your assets won’t be “exactly” centered in the MovieClip.
• Instead of centering your object(s) in your MovieClips, use corner-based orientation, so, for example, your object(s) will have an x and y value of 0.  This way, you’ll be guaranteed to have crisp lines when the MovieClip is placed at coordinates whose values are integers.

Other Best Practices for Clean Lines

• When drawing shapes with horizontal and/or vertical lines in Flash, make sure that the x and y coordinates are integer values in your Properties panel.  Also, make sure the width and height are also integer values.  Every so often, Flash will want to add/subtract a random 0.05 from your typed-in values, so you may need to re-type in a value now and again.
• If you’re nudging objects around on your stage, turn on “Snap to Pixels”.  To do this, select the “View” menu, and select “Snapping > Snap to Pixels”.  Doing this will always snap your objects to integer (pixel) values.

Wrapping Up

So there you have it.  With a little careful planning and knowhow, and with a little help from the Math class, you can ensure your Flash applications have vertical and horizontal lines that are crisp and exact, creating a much stronger, cleaner design.

Until next time, happy coding!

// This variable gets set as 1,234,567,890
var commaFormattedNumber:String = formatWithCommas("1234567890");

function formatWithCommas(pNum_str:String):String {
   var lReturn_str:String = "";
   var lStringAsArray_arr:Array = pNum_str.split("");
   var commaCounter_num:Number = 1;
   for (var i=lStringAsArray_arr.length-1; i>=0; i--) {
      lReturn_str = lStringAsArray_arr[i] + lReturn_str;
      if ((commaCounter_num == 3) && (i != 0)) {
         lReturn_str = "," + lReturn_str;
         commaCounter_num = 1;
      } else {
         commaCounter_num++;
      }
   }
   return lReturn_str;
}

Notes:

• In our example, we pass in 1 String value into the function, and it returns a String.
• Inside of the function, we split the passed-in string into an Array, then we loop through the array backwards, adding the number in each array slot each time through the loop.
• While looping through the array, notice that we have the variable commaCounter_num, which keeps track of which slots to also add in a comma. The conditional logic checks if the commaCounter_num is up to 3 and if the value of i is NOT zero. If both of these are true, we add in a comma and continue on. We must add the check of ensuring that i is not zero, so we don’t get a 6-digit number, for example, that ends up being returned with a comma at the very beginning of the string.

So there you have it.  A nice little chunk of code you can use to format a number into a correctly comma-formatted string. Not a whole lot to it, but still a nice reference function to have for future use.

Until next time, happy coding!