capital H coder

That’s right, according to the latest word from Adobe, we will soon be able to both load files from the client machine into the Flash runtime as well as save files back to the desktop from the runtime.

This is a great example of how Silverlight is making Flash a better product. Microsoft came out with this feature, in my mind the only one-up it had on Flash, and now Adobe is forced to follow suit. Competition is good.

So offer up a big thank you to Microsoft for improving Flash and enjoy that fact that you will no longer have to upload files to the server just so you can download them again (sheds a tear for all of the bandwidth and time that will be saved)!

~Shaun

I recently got down to the “Support Foreign Characters” item in my Knowtes To-Do list, and figured it would be fairly easy to find an example component out there that provided an easy way for users to enter special characters into Flex text controls (TextInput, TextArea, and RichTextEditor).

Unfortunately, both my posts to FlexCoders and my lengthy Google search turned up empty.

So on the off chance that I’m not actually the only person in the world with a need for this type of feature, here is what I came up with (a very simple version of it anyway):

And HERE IS THE SOURCE

Two points worth mentioning:

• The key for getting the unicode characters into the text controls was to use the String.fromCharCode() function.
• To enhance usability, the cursor is placed at the end of the text in the associated control when the character dropdown is closed. The selectionBeginIndex and selectionEndIndex are used for setting the caret position. For the RichTextEditor this property changes to selection.beginIndex and selection.endIndex.

It definitely needs some polishing, but hopefully it will give someone a jump start on providing a simple method of allowing users to easily enter unicode/foreign/special characters in Flex apps.

~Shaun

So we have the ability in Flex to select an image as the background of a container. However, the only control we get over this image is the ability to specify its size. From my background in .NET, I am accustomed to being able to specify the layout of a background image as one of four options:

• Centered: shows up as its default size, centered in the container
• Stretched: made to fill all area of the background (causing distortion if necessary)
• Tiled: repeats itself to fill entire background area
• Zoomed: image stretched as large as possible while maintaining aspect ratio & centered

So what I’m providing here (right-click for code) is my method of providing this functionality as a skin in Flex.



I call it the CuSTomiZableImageSkin (for Center, Stretch, Tile, and Zoom), but you can call it whatever you want (feel free to use and modify it to your heart’s content).

This should work for any containers in your app, and all you have to do to use it is specify the class as your borderSkin, provide a backgroundImage, and set the backgroundSize style to center, stretch, tile, or zoom.

HERE IS THE SOURCE

Possible improvements: allowing a border as well as the image. I haven’t needed a border as well as the image yet, so I haven’t done this.

~Shaun

So I really like the idea of runtime styles in Flex. Enough that I went through the process of moving my styles out of my app and into an external swf even though it wasn’t absolutely necessary. My thought was that this would gain me some flexibility in the future, and I could then share the style swf between apps if I ever needed to.

Then, in the process of optimization, I noticed that my Style SWF file was 127k in size. Ouch. Using an RSL got that down to about 50k. Better… but not good. So I decided to put the styles back into my app to see what the difference would be, if any. It turns out that adding it back only added 24k to main app!

Not only this, but initialization time was cut by 1/4th. On top of this, any dynamic updates I made to styles while running were noticably faster as well.

It was probably my imagination, but it seemed as though everything was faster, even just switching app locations, creating components, etc.

This was all done with Flex 2.0.1, and I am hoping that I do not experience the same symptoms when I move to Flex 3. For now, I am staying away from runtime styles unless they are absolutely required. I recommend you do the same if you don’t have an explicit need for them.

~Shaun

So I decided to do a little experiment. I wanted to create an embeddable player for Knowtes that users could post on their own pages. I could have just used the one I have on the Knowtes site, but it weighs in at a hefty 277k due to its use of the Flex Framework. This is obviously not acceptable if I’m going to have a lot of users embedding this new player on their pages.

So, I set out to create an actionscript only project that would provide all the features of my current framework based player. Here is the result:

I ended up adding more features than the original version (most notably, the theme changes to match the library theme of the user who embeds it), but it still only weighs in at 17k! I think I’ll have to can the original

In creating this I had to convert a few of my personalization classes to work without the framework. So if anyone would like to see how I did one of the following, just post a comment and let me know:

• Bitmap Fade: makes a bitmap copy of a given DisplayObject, replaces the target with the bitmap in the display list and then fades the bitmap, switching it back when it is done. This let me avoid embedding fonts
• Full Gradient Background: allows radial or linear gradients, any number of colors/ratios/alphas, and changeable angle and focalpointratio (pretty much any common gradient option).
• Strech/Zoom/Center/Tile -able Background Image: An actionscript only component that fills up its display area with an image using any of these methods.

So it turns out that Knowtes was not even judged in the Adobe AIR Developer Derby. Apparently in all my heads down coding of the application itself, I left my signup page a little confusing. The judge (yes, singluar - only one visit to my signup page was unaccounted for during the judging period) did not realize they needed to fill out the CAPTCHA on the page in order to have an invitation sent.

In their defense, my code mistakenly showed a message indicating that the invitation was sent on one part of the page while another part said that they needed to fill out the CAPTCHA. It’s kind of tough to swallow that kind of mistake after so much work, especially when it had nothing to do with the application itself.

Still, the competition did motivate me to get quite a lot done on the program, and now it’s time to try and do something with it. To that end, I’ll be trying to get it showcased on Adobe’s website and a few other places. We’ll see what happens.

And yes, I still plan on blogging some of the code I did for the site… just have to find the time.

Shaun

Whew!

So my real job turned out to be a lot less work than programming on Knowtes for the Derby. I need to work on my self-motivation (less would be better I think).

In any case, the bug-ridden AIR version of Knowtes is off, and I can only hope that there are too many features in there for the judges to get too in-depth and find all of the errors

I waited pretty much until the last second to submit it, just in case Adobe had some automated process to download your AIR file as soon as you sent in your submission, though it appears they did not. Now it’s time to sit around and wait for the judges to start doing their thing.

Well, not exactly just sit around. I’ve got plenty of projects to be working on and I’d like to start blogging about different parts of the AIR development experience as well as code I used. So to that end, here’s a list of things I might blog about:

• The Knowtes GradientSelector control
• The BitmapFade effect (gets around non-embedded font issues and is faster than typical fade)
• Secure login via HTML
• Kuler integration
• Tile-able, center-able, stretch-able, zoom-able background image

Just post a comment and let me know what you’d like to hear about and I’ll make a blog post about it.

Till then,
~Shaun (more…)

One of my least favorite things about web development is the need to upload images before being allowed access to them on the client side.  In the era of Rich Internet Applications, where client-side file manipulation is becoming more commonplace, the step of transferring an image to the server just to immediately bring it back to the client seems like a waste of time, bandwidth, and server resources, not to mention being horrible for the user experience.

Of course, it is also necessary unless you want to use a java applet (and who does?).  Or is it?  Apparently Microsoft has decided that this is one security vulnerability that they can deal with and have announced client side access to files.  That’s right, with Silverlight you can now access files before uploading them to the server!  Read about it on Scott Guthrie’s blog (check out the slides) and here.

The only limitations are that you must allow the user to browse to the file with a browse file dialog (as they do now), and you get access only to that file.  Pretty simple.

Of course, I don’t want to use Silverlight.  I want the features and reach of Flash.  So until Adobe decides it is worth it to provide this feature (I’m hoping to hear word on this from an Adobe blog by Lucas Adamski), I’ll just add one to the “Silverlight is the best” column (it’s still rather lopsided in favor of Adobe) and put up with a poor experience in the file upload department.

~Shaun

The End

What better way to start a blog than at the end?  The end of a stage in my life.  Tomorrow is (possibly) the last day of full-time employment I will ever experience.   After five years developing .NET solutions for the public safety communications sector under the employ of The Genesis Group, I’m calling it quits.  In that time I’ve had the opportunity to help design, develop, and manage a wide variety of software solutions (with applications including hardware provisioning, billing and mediation, radio system management, and reporting to name a few…) while honing my skills in C#, ASP.NET, MSSQL, and lately Adobe Flex.  That and I’ve gotten to do it all while working with a really great group of people, so thank you to Phil Burks and The Genesis Group.

So why the change? 
Well,  the reasons are varied and I go into more detail on my personal blog at www.ShaunHalberstadt.com, but suffice to say that after a great deal of prayer, a life-long desire to go it on my own, and a number of things falling into place, the time was right.

And what’s the plan?
No work for 2 months.  WOOHOO! Oh wait, that’s because I’ll be developing a showcase application to enter in Adobe’s AIR Derby.  I’ve been working on Flex projects at Genesis for the past year and I must say that I’m sold on the technology, and my goal is to make a business out of it.  And I plan on blogging all about it here.

So what exactly can I expect on the blog?
In short, anything related to web development and starting a business at it.  Specifically, I’ll try to post about episodes in the saga that is self-employment, my thoughts on Flex, AIR, and other aspects of web development, as well as code samples and components.

Oh, one last thing:  capitalHcoder?
The capital H is in reference to Him.  I am a Christian.  He teaches that whatever work we do, we should do it as though we were doing it for Him.  My goal as a self-employed contractor is to do just that.  No matter who my clients are or what their projects, I will work for them as though for Him.

~ Shaun