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:
Continue reading Dependency Injection by Extension pattern
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:
verify().that(sut.update());
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.
Well, it’s been a while. Having spent the last 8 months working on the YouView set top box platform, I’ve been so busy that I wasn’t even sure my site was still up. And now that I’ve dived headlong into the tricky world of embedded systems development, I wanted to starting playing with other platforms out there. The first two that recently caught my eye were Apple iOS (specifically the iPad) and the new Blackberry PlayBook.
I was keen to see what the application development process is like for these two platforms, especially for Flash Developers and how the two Big Tablets, iPad and PlayBook, measurement up as potential target platforms for the crazy ideas in my head that I’d want to build. So, I made the first steps at development for both.
iPad
Now that Adobe is ‘allowed’ to pursue iOS as a target platform for AIR, via its cross-compiler again, I went through the process of signing up as an iOS developer, jumping through the various other hoops and getting my first ‘hello world’ app onto my iPad. The whole process is a lot more complicated than it probably could be, but then, the same could be said of device development at YouView – this is the nature of such platforms, they are emerging technologies and, as such, are moving targets and simply not like the desktop machines we are all used to developing for. I have to say though, I’m impressed with the recent leaps in performance and functionality Adobe has made with AIR 2.6 for iOS – it leaves Packager in the dust.
PlayBook
Perhaps because the tool chain for PlayBook development feels more like developing for YouView, I was more comfortable with developing for the Playbook and managed to crack out a very simple app, getting in App World in a matter of a couple of days.
Now that I’ve stepped well outside the desktop comfort zone, I have been playing for a while with resource constrained device development, hardware acceleration of Flash content and developing an unhealthy obsession for writing clean, memory/rendering performance optimal code. I hope to bring some of this to projects for iOS and Playbook, as well as share what I’ve learned over the last year.
The problemYou want to embed an entire SWF, full of assets, into a class and retrieve individual symbols from it – but you don’t want to have to embed each asset individually.
SWFAsset – a couple of lines of code and you’re away.
The problem:
You’re using Flash 10’s native 3-D API and notice the projection goes a little skewiff when resizing the window.
The solution:
You need to reset the stage’s projection centre on stage resize, like so…
|
1 2 |
var centre:Point = new Point(stage.stageWidth/2, stage.stageHeight/2); root.transform.perspectiveProjection.projectionCenter = centre; |
In moving to compiling projects with the new Flex SDK 4, I noticed a couple of gotchas to do with the EMBED metatag that I thought I’d share:
Runtime Shared Libraries
If you wish to embed assets in your SWF with the EMBED metatag, so you can manage and update things easily, there’s an extra compiler parameter you must add, in order for your project to compile properly:
|
1 |
--static-link-runtime-shared-libraries=true |
This is already added as a new default parameter in FlashDevelop projects. But if you’re planning to build projects from outside a similar IDE, you must add this to your compiler string. Otherwise, the compiler will think you have uninitialised constants and warn you so.
Embedding Fonts
Using the EMBED metatag, or even better runtime loading, for fonts is the sensible way forward. The amount of projects I’ve seen where you need to build from an FLA file full of fonts, which you need to hunt down and install is crazy. With Flex SDK 4, you’ll need to add an extra attribute to your embed tag for fonts, called ’embedAsCFF’:
|
1 2 |
[Embed(source='myfont.ttf', fontName='MY_FONT', fontWeight='regular', unicodeRange='U+0020-U+0040,U+0041-U+005A', mimeType='application/x-font', embedAsCFF='false')] public static const MY_FONT :Class; |
Happy compiling!
