New Developers – don’t use shorthand code!

Our team is increasingly working with folks who don’t have a developer background. So, I’ve been spending time providing tips-and-tricks on some of the basics they’ll need to help them over their first few speeds bumps.

The first thing I always stress is learning how to debug. It’s imperative to know how to do it well, and if you don’t know how to do it then you’ll hate programming forever. It’s just like swimming. If your first experience is bad you may never jump back in the water again. But if you learn to do it right the first time, you are more likely to try it again and again. And, you may even find yourself having fun with it.

One of the fundamentals of debugging is writing verbose code. Those of us who have been doing it a while tend to cut corners sometimes, and we write things in shorthand like this:        

 if(something == 0) return false;

The problem with this line of code is very hard to debug. The recommended best practice is to write the code as such:        

if(something == 0)
{
     return false;
}

This enables three things to happen. First, you can set the debugger on the “return” line. This means you can check to see if the “if” condition actually occurred or not. Second, if there is ever an error you’ll know exactly which line it occurred on without having to decipher which part of your shorthand code caused the problem. This will save you time and headaches. And lastly, it’s much easier to read, especially when your programs start to get large.

So, my recommendation is to “spell it out”!

Regular Expressions with Flex and ActionScript

Adobe has some great regex-based methods that can help you easily parse strings. If you aren’t familiar with regular expressions, they are basically very powerful, short-hand algorithms that are specifically designed to find patterns in strings. There are many people that hate regex’s but don’t let that deter you. They are very powerful and can save you a ton of time. And, even better is ActionScript lets you use either strings or regexes.

They are most commonly used to check form inputs for illegal characters, verifying correct formatting or for parsing complex strings. Here is an example usage pattern that looks for the end of a line:

var content:String = “Read this sentence.\r\n This is the second sentence.”;
var pattern:RegExp = /\r\n/;
trace(content.match(pattern));
var index:int = content.search(pattern);
trace(content.substr(index));

Here are some of the string methods you should become familiar with:

  • match() – uses either a regex or a string for the search pattern and returns an array of matching substrings.
  • replace() – does exactly what is says. It’s great for cleaning up inputs. Use cases include things such as removing inappropriate language.
  • search() – uses either a regex or a string for the search pattern and returns the first index of the substring that is located, or returns a -1. This is a great method to use for parsing strings.

Once you’ve found a match, so to speak, then you can use other string methods to parse the string:

  • slice() –  which slices out a section of the string for you given a start and ending index.
  • substr() – cuts out a substring based on a start index and length.
  • substring() – similar to substr() but the second parameter is the position of the character at the end of the substring.

A few helpful references:

URLStream, Adobe AIR and FLEX security permission issues on Windows 7

I had a particularly vexing problem that took nearly a half a day to dig to the bottom of. I was successfully able to connect to a streaming API using Adobe’s URLStream class, and I could see the passing of packets back-and-forth between the client app and the remote server using WireShark. So, there was definitely a valid connection and hand-shaking happening in the background. And, another key piece to the puzzle was the app ran just fine as a Flex app using the default bin-debug run-time settings. But, other than that running it as an AIR app or a Flex app from IIS, I simply couldn’t get any of the URLStream event listeners to acknowledge any type of connection whatsoever.

I knew this was a permissions issue, but finding documentation on AIR and Flash runtime permissions is, well, not easy. So, after quite a few searches on the internet and many dead-ends, there buried deep in some ancient scrolls of Adobe documentation were a few articles that provided the key to finally unlock the treasure chest.

You may have never heard about it before, but there is a User Flash Player Trust directory that typically contains at least one configuration file. And, in those files you can specifically grant application access to a particularly directory. In theory, there is also a Global Flash Player Trust directory. I originally thought I made the changes to that, but actually I never was able to locate it, and I ran out of time anyway. So, if someone knows where that is on Windows 7 please let me know.

Solution:

I added the pathname to the AIR executable installation directory to the air.1.0.trust.cfg file and bingo the application worked as expected.

The file typically resides in a path that looks like this: C:\Users\<username>\AppData\Roaming\Macromedia\Flash Player\#Security\FlashPlayerTrust

And, I add the following line to the file: C:\Program Files (x86)\BasicStreams.

References:

[Flash Player] Administrator Controls

[Flash Player] User Control document

Adobe Online Doc – Restricting Network APIs