Ever had a problem where a site or application you are creating looks great when scaled to the browser window at a large screen size but crap when viewed on smaller screens? A major issue with sites that are embedded via SWFObject and set to 100% x 100% is that when viewed via a smaller screen size resolution, things get messed up and overlap each other and some elements become un-viewable, which of course provides for nightmare positioning issues if done via actionscript within the application. I have had this problem myself a few times recently and was looking for a way to implement the resizing via javascript within the browser when I stumbled across a fantastic utility called swffit. Swffit is incredibly simple to use and works well with SWFObject. What it actually does is control how the browser window interacts with your flash application's resize settings, once it gets smaller than your defined window size it adds a scollbar, when it is bigger the scrollbar dissappears. As an example, my main site now uses swffit and in the main javascript which I use to embed my swf I have simply included the fit() function of swffit like so:
As you can see via swfobject I have defined a window height of 650 pixels, swffit registers this and listens out for when the browser window goes below this size, when it does it adds a vertical scroll bar so that when a user with a small window size views the site they are able to view the site properly rather than all squashed up! There are loads of other features available as can be found within the example folder of the downloadable swffit source files. More details can also be found on the swffit site.
Click the screen for transition in then again for transition out.
Well it has been some time since my last blog post - nearly three and a half months and now finally I seem to have found a little free time to dedicate to some writing, I tell you dispite all of the fuss in the press lately with the Apple - Adobe thing and also Flash vs HTML5, it seems to me that it sure is a great time to be a flash developer as we seem to be so in demand!
Anyway, to ease my self back into my blog writing I am going to post a little class which I knocked up when working on a project recently as a nice transition effect for adding / removing images. It is simlilar to an experiment I posted on my very bare lab site some time ago. The class is called Broken image and it does just that. It is a simple class which takes any movieclip / sprite / bitmap passed as one of its parameters, the image passed can be added to the stage already or not it doesn't matter. Other parameters include, x & y positions that you wish the final image to sit on, width and height of each pixel and whether you wish the transitions to be 'in', 'out' or both. The below code, would add an asset called 'image' as the image to be broken apart, set it in the middle of the stage, with an in & out transition, and each 'pixel' as they are defined in the class would be 15 x 15 pixels.
var bi:BrokenImage = new BrokenImage(image, (stage.stageWidth - image.width) * 0.5, (stage.stageHeight - image.height) * 0.5, "inOut", 15, 15);
It then reacreates the image as a series of smaller bitmaps made up of the original which are then ready to be animated. As a basis of the class I have included a simple tweenIn and tweenOut, which of course can easily be adjusted to suit your needs.
As you will see if you explore the code, the actual inner workings of the class are very simple and pretty self explnatory. In the example document class which I have included with the source, I have used a loader to load in a bitmap, this is mainly to reduce overall file size so that it can easilt be loaded onto this blog page, but you can easily use any asset from flash by giving it a linkage ID or even just an instance name. Of course as the example included is 100% actionscript, if you do compile in flash you will to define a document class. The class also requires tweenlite as its tween engine so you will also need that defined in your library preferences.
Well once upon a time, my answer would of definately been a resounding no....I, along with many other people from what I have read and heard never really saw the point to them. Why go through all the hassle of typing out all that extra code when you can just declare your variables as public so that they can be accessed outside the class?!
Well now I can fully see the usefulness of this little coding gem and how it fits nicely into proper OOP principles, I have done for a while and have been fully using them to boost the reusability of my frameworks, but only today really thought about how great they really are.
Public variables are great if you simply want your variables to be easy to access, but using a setter for something like this makes things a lot easier in the long run. Lets have a look at a real world example. Lets say you have created a custom class that creates a sprite with a text field. Now to change the text in this class from outside you would access the public String variable that difines the text, then you would have to access the actual text field of the class, which of course would have to be public for you to access it which of course opens the textfield up to be able to be edited from out the class....not good as you really want to have things like this closed, unless of course it really suits you to have the textfield as public, but any way it goes against the OOP principle of encapsulation. Also everytime you want to change the text in the textfield from outside the class you eventually have to enter more code as each time you access the string varaibale and also the textfield's text. So if we use a setter for this like so:
Now one thing you will notice here is that through accessing this setter you automatically update the textfield so that the text changes, so that all you have to type when targeting the instance from outside the class is:
One line to change the text, and also no need to access any string variables or even set them. Its is the same with getters also making assets and their properties and also private variables easy to access.
So you can see that getters and setters really are very useful and something that I seem to use pretty much in every class I seem to create these days, they not only keep your code cleaner and easier to read but make your classes seem to make more sense and function a lot better.
Originally from a fine art background, it took me a while to get in to the world of digital media, but now that I have, Flash has become my tool of choice. For the last 3 years I have been working as a freelance flash designer / developer and I now work as a Rich Internet Applications Developer for a well know communications company and strive to create engaging and creative applications for the web.
This site has become a medium for me to share my experiences and what I have learned with other flash and actionscript enthusiasts, in the hope that maybe what I have to show may help others in their working lives.
![[Valid RSS]](http://www.ultravisual.co.uk/blog/images/valid-rss.png "Validate my RSS feed")
