If you’re still churning out Flash banners, please use this!
I created this simple utility, called SWFIdle, to enable the Flash Player to lower its CPU usage while the user is not interacting with it. Since it’s possible to have multiple Flash instances embedded in one page (for example, a game and a couple of banners), I recommend using this in your projects, so that Flash instances needn’t fight for CPU and give Flash a worse name than it has already 😉
I know there’s the hasPriority embed attribute now. But:
- That assumes you have access to the HTML that embeds your SWF
- If no other players are present, it has no effect
- There’s still usually little reason to be running your SWF at a high framerate if the user isn’t interacting with it
- Flash banners with wastefully unoptimised drawing routines are probably one of the key reasons that Flash got poo-pooed off of mobile platforms and disabled on everyone’s laptops – CPU usage = battery usage!
You need to use some kind of Dependency Injection (DI for short) to provision some System Under Test (SUT for short) in tests you’re writing, but can’t or don’t want to use a DI framework to do so.
Alternative titles for this post include:
- Dependency Injection without a Dependency Injection framework
- Why misusing the default namespace for tests is evil
- Make code more testable without completely messing it up
Continue reading Dependency Injection by Extension pattern
I’d recently been playing around with packaging AIR for iOS, to run on my iPad. While the performance has been improved massively since CS5 Packager, it’s still not great in AIR 2.6. It seems that AIR 2.7 brings with it some great performance enhancements – though I’ll reserve judgement until I’ve tried it myself – check out the article and video here.
My ScratchPad app for Blackberry Playbook is now live. It’s a simple drawing app where you can export your creations to the image gallery. When the BlackBerry Playbook launched, there was nothing like this available, so I created it 🙂 If the Playbook does well, I’ll be creating more apps for the platform – it’s certainly a nice piece of hardware and BlackBerry OS is easy enough to work with.
I recently had a bit of a shock while reviewing someone’s code, finding the following line in one of their unit tests:
Where: sut is their System Under Test and verify is the part of the Mockito Flex framework.
Exercise for the reader: What’s wrong with this picture?
The answer: You cannot expect Mockito to verify that something was called on anything that isn’t a mock! How the hell is it supposed to know?
At least, if attempting to stub a method of a non-mock, you’ll get a handy error telling you not to be so damn silly. But, in this case, the verify will always work. So the test will pass, but it isn’t actually verifying anything! Where do I start with the bad? This is the worst kind of test, since it provides a false sense of security on the robustness of a system. Thankfully, all the tests in this codebase had called their System Under Test either sut, _sut or SUT, so it was pretty easy to get Hudson to mark a build as unstable if it finds such madness.
So, in my first steps in tablet development, I cracked out a simple app for the new Blackberry Playbook and got a free Playbook! It’s a very nice piece of hardware. You can see my app (a very simple doodling application, called ScratchPad) here.