Flex Amusements

Some really simple messaging

2011-12-05T21:24:00.001-08:00

Update:
The approach below will work, but Roboguice's Events are more elegant.

I've been working through my first non-trivial Android app, and had a need for some simple messaging (Intents didn't seem like a good fit for simple, internal, app messages). I came up with the following classes.IMessage is simply a message object whose type is identified by a string. My favorite implementation is an enum, but any class would do. Here's a simple message:ISubscriber<T extends IMessage> describes a simple class which subscribes to a message, having its onMessage() method invoked when that message arrives. Here's a snippet of an activity and a subscriber:IBus simply connects up the messages and subscribers, here's my simple implementation of that.This approach works best if the IBus implementation lives outside the scope of an Activity. I've had good luck with instantiating the above Bus and injecting it where needed via Roboguice. There's probably an easier way to send simple messages around, but this is what I'm using until I find that :)Here's the source-code for a simple test app outlining the above approach.

A bit of (crazy) code to manage Android fragments

2011-11-23T13:52:00.001-08:00

Here's a bit of code I use to manage Compatibility Library Fragments in Android. Hopefully this will help someone else out.
fragmentById()
fragmentById() is doing a few odd things. <T extends Fragment> T is saying that we don't care about type-safety beyond the assurance that type T extends the Fragment class. It's worth noting that if we dropped <T extends Fragment> in favor of <T> T, then we'd lose all type safety. Here's how fragmentById() is used:The main benefits of this method are that it gets rid of a cast and it isolates the compatibility library bits off to the side (e.g. the calls to getSupportFragmentManager()).

showFragmentIds() / hideFragmentIds() / setFragmentsVisibility()
The Enum argument is an attempt at readibility, a boolean wouldn't be readable and would have the downside of limiting my ability to, say, put a 3rd visibility mode in to rip out a fragment completely. Here's what that method looks like with a boolean parameter:</rant>. The only other thing to note about setFragmentsVisibility() is the varargs parameter int... fragmentIds. This approach makes the calling code nice and simple, e.g.:As always, I welcome suggestions for accomplishing this kind of thing in a more elegant way :)

One thing to note:
The above solution works fine for trivial Fragment cases, but for more interesting things (such as specifying enter and exit animations), your best bet is to stick with the built-in fragment support.

ActionBarSherlock and RoboGuice can be friends

2011-11-21T11:37:00.001-08:00

The ActionBar

In Android applications, the ActionBar is quickly emerging as a UI standard. Although its great, the ActionBar is only supported on Android 3.0 (API level 11, aka Honeycomb) and later. Since (either from prudence or incompetance) carriers seem to push new versions of Android out rather slowly, the majority of phones running Android are on 2x.

ActionBarSherlock and RoboGuice

There's a problem then, the ActionBar is nice, but only a small percentage of phones support it. Luckily, lots of smart folks have created ActionBar libraries for pre-3.0 Android, my favorite is ActionBarSherlock. ActionBarSherlock's API is identical to the native 3.0 ActionBar, and if the native ActionBar is available, ActionBarSherlock politely steps aside and uses it.

Another necessity, at least for me, when developing non-trivial applications is a dependency injection framework. DI frameworks are a big help, allowing me to attack large problems with a set of simple, testable, classes which collaborate but are not coupled. For Android, I'm currently using RoboGuice a popular extension of Google's Guice dependency injection framework. RoboGuice also ships with a nice set of classes easing some of the more annoying parts of developing Android apps. The problem is:

These libraries don't work in the same app

To make ActionBarSherlock work as well as it does, it includes the compatibility library and patches a few of the classes in it. A few of RoboGuice's classes such as RoboListActivity and RoboFragment extend classes from the compatibility library but not the ActionBarSherlock-patched compatibility library. The good news is that these libraries are solving different problems, and we can attack the DI side of the problem using RoboGuice and composition.

Here's a simple solution: extend the ActionBarSherlock-patched compatibility classes and get injection via composition using RoboGuice.getInjector().
You can now extend from IocListFragment (or any other class you need to create in this way such as IocFragment) and get @Inject along with a nice ActionBar:Fortunately you'll only need to extend a few classes in this way to make both of these libraries work in the same app. This solution feels a bit clunky, so if you know a better solution to this problem, please share it.

Dependency Injection Part 5: Mocking and Cool Tests

2010-10-08T22:29:00.000-07:00

In my last post, we wrote a set of unit tests exercising ConsoleInputService, MessageService, and ConsoleOutputService. We tested these classes thoroughly, and in isolation since their behavior was easier to test in a controlled environment. Its now time to test our main stimulation class Magic8BallSimulator.

Remember our humble Magic8BallSimulator class? If not, here's a quick refresh:This class depends on IMessageService, IInputService, and IOutputService and those dependencies are injected via Magic8BallSimulator's constructor. Since unit testing requires a controlled environment, we'll need to make sure that the instances of IMessageService, IInputService, and IOutputService that we instantiate and inject behave in predictable ways. Remember, unit tests aim to test a simple unit of code, and for our purposes a "unit" is a method within a class.

So we have a problem

We need to make sure that the instances of IMessageService, IInputService, and IOutputService that we instantiate and inject into Magic8BallSimulator behave in predictable ways, but we want those instances to behave in different predictable ways for different tests. Consider this test:

[Test]: We want to make sure Magic8BallSimulator prints an exit message before it exits.

To get our injected instances to behave in the way we need them to for this test, we'll have to do the following:

Create a InputServiceStub class implementing IInputService. All the method-bodies in in this class will be empty except for ExitWasRequested() which will always return true
Create a OutputServiceStub class implementing IOutputService. All the method-bodies in this class will also be empty empty expect for PrintExit() which will set a public PrintExitCalled property to true when called.
Create a MessageServiceStub class implementing IMessageService with empty methods.
Instantiate the 3 classes above. Instantiate Magic8BallSimulator and inject our 3 test instances
call Magic8BallSimulator.Run(), and then make sure that OutputServiceStub.PrintExitCalled is true.

No Thanks!

That's too much code for us to write and maintain to test 1 case. We still have to test Magic8BallSimulator, however, after-all they pay us to write software :) The problem is, we don't want to have to write three classes to test 1 case. One way out might be to create 3 abstract classes implementing IMessageService, IInputService, and IOutputService and then extend those class only filling in the method-bodies we need for our test. That still turns out to be a ton of code to maintain, and we'd like our application to be fun to work on, not a pain in the ass. Here's a better way.

I love Moq. Check this out

We can leverage the badass, open-source, Moq library to create mock implementations of IMessageService, IInputService, and IOutputService and then use lambda expressions to stand in for the methods we want. We can then inject those mock classes into Magic8BallSimulator. Feel the lightness of the test below :)Hey, make sure you read the comments above, that's where the good explanations are! Now that we're able to use Moq to mock our dependencies, additional tests are easy! Here are 3 more:
That's it. It's been fun!

Here's the source code for this post. Thanks so much for reading these posts on Dependency Injection and Unit Testing. I had lots of fun writing these and only hope my silly examples and code-snippets were clear. If you have any questions, go ahead and leave a comment and I'll try to help you out.

AMF Remoting, Dependency Injection, and exposing Interfaces to Flex - FlourineFx version

2010-10-07T22:22:00.000-07:00

In the previous post, I showed one way to wire Autofac and WebORB together to achieve AMF-Remoting as well as Dependency Injection. This post builds on the last one by providing an inplementation using Autofac and FlourineFx, the latter is a great open-source .NET AMF Remoting solution.

Here's the the source code for this post so you won't have to figure out the context of the snippets below.

Add the following to your WEB-INF\flex\services-config.xml:To tie FlourineFx to Autofac, we'll create and register our own custom Factory (we have to implement the FlourineFx's IFlexFactory interface) and instantiate our objects by resolving them from the DI Container.As in the previous example using WebORB, you now modify your Flex client to use our new destination and exposed interface like this:If there's an easier way to integrate FlourineFx and Autofac, I'd love to hear it, though the above is quite easy :)

AMF Remoting, Dependency Injection, and exposing Interfaces to Flex

2010-10-07T00:51:00.000-07:00

Imagine that we've built a large middle-tier in C# for a Flex client and have decided to remote objects to and from Flex via AMF. AMF is a great choice for us since it's a lightweight, binary, protocol which is easily de-serialized by the Flash Player (we picked the Flash Player as our client because of its current popularity).

Since our middle-tier code-base is large and complex, we've attacked that complexity by making lots of simple, loosely coupled, Single Responsibility classes. We've read about Dependency Injection and expect that if we use that general approach, we'll end up with code which is both flexible and easy to test. We'd like to avoid writing the Dependency Injection plumbing ourselves however, so we've decided to leverage Autofac to help. We've also decided to use WebORB to handle the translation of our .NET objects to Flex DTOs/VOs. Using Autofac and WebORB will allow us to focus on our business logic without concerning ourselves with translating to and from AMF and writing the necessary plumbing for Dependency Injection respectively.

We've decided to create a set of service classes which Flex can access through WebORB. Since these classes are handling client requests directly, they often depend on other injected classes to handle some of the work-load. These dependencies also keep the service classes clean, small and easy to understand. We'd also like to provide these dependent classes to our service classes through Autofac.

There are problems

We've chosen two great tools to help, but we've a few problems to work out first:

Out of the box, to use our service classes in WebORB we'll need to create default constructors in them. This is unpleasant since we'd like to inject our dependent classes as constructor arguments.
To expose our Service classes to Flex, we have 2 options:
1. Expose our service classes directly to Flex, so our client can remote to, say, WebORBAutofacTest.TestService
2. Create an alias which maps to each of our service classes so our client can remote to, say, AppTestService
The problem with (1) is that our Flex clients shouldn't know about the specific classes they're using on the middle-tier. This leaves us free to modify, rename, of delete those classes without the fear of breaking our client. Although this makes (2) a better option, (2) is still a bit more work because we'll have to maintain our aliases which reside in a non compiler-checked config file somewhere.
We have no idea how to get new instances of our service classes created and their dependencies injected. In other words, we cannot get WebORB working with Autofac.

Our goal

We want to inject dependencies into our service classes as constructor arguments (and we'd like for Autofac to instantiate these dependent classes for us).
We'd like to expose only the interfaces implemented by our service classes to our Flex client (that's a more familiar approach on the mid-tier)
and finally, we don't want to constantly update configuration files for AMF remoting

A solution

First go ahead and get the source code for this post so you won't have to cut and paste annoying code snippets.

Next we'll follow the ASP.NET Integration instructions in the all-around great Autofac wiki. After you've read the wiki entry, have a look at this simple ContainerSetup class below. This class is called by our Global.asax class to register our dependencies and help Global.asax implement IContainerProviderAccessor:
Here's the relevant section of my Global application class:The snippet above informs the classes in our application that the main application class Global is an IContainerProviderAccessor providing access to a ContainerProvider allowing callers to access the DI Container and resolve dependencies. We'll make good use of this property.

To tie WebORB to Autofac, we'll create and register our own custom Activator (we have to implement the IActivator interface, see the WebORB docs if you want to know more about Custom Activators) and instantiate our objects by resolving them from the DI Container.Configuration files

We now have to register our new DependencyActivator class in weborb.config luckily we'll only have to modify these configuration files once:Now we have to update 2 XML files which our Flex client will compile against. These files define how and where Flex will send data when remoting. First we'll create a new channel-definition in WEB-INF\flex\services-config.xml:Then we'll add a destination in WEB-INF\flex\remoting-config.xml:We now have Dependency Injection in our service classes via Autofac
Now we can finally modify our Flex client to use the new DependencyGenericDestination in its RemoteObjects. Notice that we're exposing WebORBAutofacTest.ITestService hey that's an interface!Solution benefits and drawbacks

Benefits to this approach:

You get a Type passed into DependencyActivator, which works nicely with Autofac's Resolve method.
You do not have to make any modifications to your service classes for this to work (in fact your service classes do not need to depend on WebORB or Autofac at all).
You can expose your Service classes as Interfaces.

Drawbacks to this approach:

Instantiation of classes that don't use Autofac will be slowed down by DependencyActivator going to Autofac first. To avoid this slow-down you'll have to pick a different destination in the relevant RemoteObjects in your Flex client

If any of you folks see a better way of accomplishing the goals I set out to tackle using WebORB and Autofac, by all means post a comment.

Dependency Injection Part 4: Tests

2010-10-05T21:53:00.000-07:00

In my last post, we identified that the SimulationRunner class violated the Single Responsibility Principle by concerning itself with:

Setting up our application, (in fact SimulationRunner created an instance of every class in the application)
Running our application (via simulator.Run())

(In case you've forgotten, the Single Responsibility Principle is the assertion that there should never be more than one reason for a class to change). We addressed the disparate responsibilities in SimulationRunner by creating the ContainerSetup class and leveraging Autofac (a badass Dependency Injection framework) to create and wire-in instances of our dependencies for us (i.e. setup our application).

We've arrived at code which is easy to change. That's valuable for our requirements will certainly change. There's only one rather large lingering concern:

I'm not sure it works

As our code stands now, I've no justification for believing that our application will work correctly in every circumstance. If you're sure, then you're new to this and new developers seem to know everything :) For us to be sure our code is solid, we need evidence, but why gather evidence if you're certain this application won't break? See the problem? We'll gather our evidence via a suite of simple Unit Tests.

Unit Tests

A Unit Test is a simple test of a small unit of code, for our purposes, units will be single methods. Remember our ConsoleInputService class?Here's a simple set of unit tests for ConsoleInputService. We're testing the following cases below:

The ConsoleInputService.GetInput() accurately returns console input
The ConsoleInputService.ExitWasRequested() returns true when it reads a new-line from console input
The ConsoleInputService.ExitWasRequested() returns true when it reads empty input from the console
The ConsoleInputService.ExitWasRequested() returns true when it reads a new-line from console input
The ConsoleInputService.ExitWasRequested() returns true when it reads a string containing only spaces from console input

The ConsoleInputMock class below is a simple test helper which simulates a given string coming from the console as input. Often to isolate a single class to test its methods, you have to do sneaky things like this.
As a general guideline, unit tests should be self-contained, clearly named, and as simple as possible. They should also only test one thing. This is important for when a test fails, its helpful to know exactly what broke. Have another look at the methods in ConsoleInputServiceTests above, you should be able to see what they're testing based on their names (e.g. ExitIsRequestedOnEmptyInput). Speaking of testing, here's a screen-shot of the output of the tests in ConsoleInputServiceTests, see the failure?

ExitIsRequestedOnWhitespaceInput failed. When ConsoleInputService.ExitWasRequested() encountered input that was just spaces, we expected it to return true, signalling that the user wished to exit. It evidently sees that as valid input. Let's fix ConsoleInputService.GetInput() to trim all input and re-run ConsoleInputServiceTests.We can now re-run our ConsoleInputServiceTests and we pass.

Here are a few tests of the MessageService and ConsoleOutputService classes. Here's the source code for this post as well, to run it, make sure you grab a copy of xunit, unpack it somewhere meaningful like C:\Program Files\xunit-1.6.1 then goto the Properties of the Pass4Tests project and in the Debug section set Start external program: to point to one of the xunit.console executables. Your setup should look similar to this:

Up Next

In the next post we'll tackle unit testing the Magic8BallSimulator class which is more interesting since it contains 3 dependencies.

Happy testing.

Dependency Injection Part 3: Making our lives easier

2010-09-29T01:20:00.010-07:00

In my last post, we implemented a set of interfaces in our service-classes and injected those interfaces into the Magic8BallSimulator class. This de-coupling of Magic8BallSimulator and its dependencies, allowed us to radically change how we output text in our application without breaking it. Here's the Magic8BallSimulator constructor we ended up with last time, it's nice and de-coupled:Here's our previous implementation of the the SimulationRunner program (I dropped our crazy MultipleOutputService class in favor of ConsoleOutputService for the moment):

Wait a moment

Have a look at the SimulationRunner class above one more time. SimulationRunner is closely coupled to several specific classes, namely Magic8BallSimulator, MessageService, ConsoleInputService, and ConsoleOutputService. There's also a more subtle problem with SimulationRunner, it has more than 1 responsibility. SimulationRunner is currently:

Setting up our application, in fact it creates a new instance of every class in the application
Running our application (via simulator.Run())

Certainly SimulationRunner ought to have the responsibility of running our application, but how can solve our two remaining problems of:

Removing our application's setup responsibility from SimulationRunner, and
de-coupling SimulationRunner from specific instances of our service classes?

Our attack will involve using a Dependency Injection framework and a new class whose sole responsibility is setting up our application.

Autofac (http://code.google.com/p/autofac/) - a badass Dependency Injection framework for .NET.

Here's an absurdly brief overview of what Autofac can do for us (if you want more information, check-out the above link to Autofac's google-code site or this article on CodeProject). Autofac allows us to register classes like MessageService as implementations of specific interfaces (like IMessageService). Here's the best part, if we register all our dependencies for Magic8BallSimulator as well as Magic8BallSimulator itself with Autofac, Autofac will also examine Magic8BallSimulator's constructor parameters and inject the registered dependent classes for us. That kicks ass!

Here's our new ContainerSetup class, it registers our application classes with Autofac and does our application setup work.
Inside BuildContainer() we're registering the classes that Autofac will provide when their relevant interfaces are requested. For example, on line 10, we're registering ConsoleInputService as the class to use when one of our classes has a dependency on the IInputService interface (hey, Magic8BallSimulator depends on that interface!). Notice that we didn't map Magic8BallSimulator to anything, it doesn't implement an interface.

Problem Solved!

Here's our new SimulationRunner class. It's de-coupled from the specific classes in our application and is free of all setup responsibilities. It's asking Autofac for the class to run (that's the call to Resolve() on line 6):As I mentioned before, since we've registered our Magic8BallSimulator class with Autofac as well as its dependencies (MessageService, ConsoleInputService, and ConsoleOutputService), Autofac will create and inject instances of those dependent classes into Magic8BallSimulator for us. Scroll up and look at the old Magic8BallSimulator constructor, it hasn't changed at all :)

For the curious

To keep this post relatively simple, I dropped our crazy MultipleOutputService class in favor of ConsoleOutputService. Remember MultipleOutputService? We used that class to show how de-coupling with interfaces allowed us to radically change a whole section of our application (and even its behavior) without breaking anything. It's also worth noting that MultipleOutputService's constructor takes a file-path string as it's argument.

If we wanted to use MultipleOutputService as our implementation of IOutputService we'd make the following change to our ContainerSetup class:In the code above, we're still specifying MultipleOutputService as our implementation of IOutputService, but we're also providing Autofac with a simple lambda expression to use when creating MultipleOutputService. The good news is, if we keep the code above, nothing else has to change (we'll still get radically different output behavior).

Source code for this post.

but wait, there's more

Steve asked a great question: But what if I want to use both MultipleOutputService and ConsoleOutputService? Say there is a user option to select which method to output with, can a DI framework handle this for me?

Since it's trivial to register more than one implementation of IOutputService with the dependency injection framework, the framework can still help us here. We'll have to write the user-activated output switch option though :) Here's the approach I see:

Remove MultipleOutputService and add PopupOutputService and FileOutputService to express our new modes of output. We'll also keep ConsoleOutputService around since one of our options is to print to the console.
Since this silly example currently runs in the console, I'm going to let users pass a few command-line parameters specifying how they'd like their output delivered. Legal parameter values will be: "popup","file","console", and "all". If we get odd combinations like "console all" we'll assume "all".
We'll also need a class to hold our configuration. That class we'll be constructed by parsing our command-line arguments and will be passed into our ContainerSetup.BuildContainer method so we'll know which classes to regsiter as implementations of IOutputService.

Here's our configuration class, aptly named Config:Here's ArgumentsParser its whole point in life is to sanity-check and parse our command-line arguments: Here are our change to ContainerSetup.BuildContainer, notice the new config parameter:We're now expecting a collection of IOutputService's in Magic8BallSimulator, so we'll modify that class as follows (notice the new IEnumerable constructor parameter and the _outputServices property:And finally, here's our new SimulationRunner tying it all together:The PopupOutputService and FileOutputService classes were trivial, I've posted those here. Here's the new source-code for this section of the post as well.

Unit Tests up next

Although our new code is de-coupled, to ensure that its solid, we'll need to test it a bit. We'll start by testing each class separately. >> Next Post

Dependency Injection Part 2: Loose coupling to the rescue

2010-09-27T23:42:00.011-07:00

In my last post, we finally injected dependencies into our Magic8BallSimulator class, but soon realized that by injecting specific classes with specific behaviors we were coupling Magic8BallSimulator to its dependencies. We discussed how this kind of coupling would make our application brittle for the following reasons:

If we want to change, say, ConsoleOutputService we risk breaking Magic8BallSimulator too, since it depends directly on ConsoleOutputService (and changing the output on the console really shouldn't break our entire application).
If we get a requirements change to alter how we output messages, say, to send them as Instant Messages or via Email, we'll have to rip out ConsoleOutputService and change Magic8BallSimulator as well. This makes our application less maintainable because changes to one section break and cascade to other parts of our application making the whole thing a pain in the ass to work on.

Here's the Magic8BallSimulator constructor we ended up with last time:We decided that we needed to alter Magic8BallSimulator to depend upon abstractions instead of concrete implementations, making Magic8BallSimulator loosely coupled to the classes it depends on.

Consider our ConsoleOutputService class. It's a concrete class which has a specific behavior. It prints output to the console, and it's "to the console" behavior is rather specific don't you think? This means that when we inject ConsoleOutputService into Magic8BallSimulator, Magic8BallSimulator knows not only that ConsoleOutputService outputs things, but how it outputs them as well. Now how ConsoleOutputService outputs things is its own concern, and we'd like to keep our application flexible enough so we can change how we output things without without breaking Magic8BallSimulator. The solution is simple, we need to tell Magic8BallSimulator that we have a class capable of handling output, but not how that class does its job. Here's the solution to our output problem:

Interfaces!

IOutputService - a contract to provide output functionality
This bit is important:

IOutputService is a simple contract which says "I agree to provide the following behavior (PrintExit, PrintInputPrompt etc), but how I work inside is no one else's concern. Now we only need a simple modification to ConsoleOutputService to complete our de-coupling.

ConsoleOutputService - implements IOutputService and prints to the console
Let's modify Magic8BallSimulator's constructor to take its new de-coupled dependency (notice we're now passing in an IOutputService interface instead of an instance of the specific ConsoleOutputService class):2 more Interfaces

Let's de-couple Magic8BallSimulator from, the rest of its dependencies. Here are our remaining interfaces:
I won't bore you with pasting copies of ConsoleInputService implementing IInputService or of MessageService implementing IMessageService. If you'd like to have a look at those classes, I've posted them here. Stay with me, things are about to get interesting.

Success!

here's our new Magic8BallSimulator class: Magic8BallSimulator still has its dependencies injected, and behaves the way it did in the last post (in other words, we didn't break anything). Magic8BallSimulator still relies on the services provided by its dependent classes, but now it's de-coupled from the concrete details of how those classes do their work. Don't believe me?

Check this out

A really different implementation of IOutputService:

Yeah, that's certainly *different* :)

Here's the new implementation of IOutputService, check out PrintMessage(), it prints messages to the screen, a file, and within a Windows-forms MessageBox:What did we just do?

Well aside from writing a crazy output class, we've radically changed the output behavior of our application without breaking it! How? Simple. All Magic8BallSimulator knows is that it gets passed (or injected) an instance of a class which implements IOutputService, and our new (slightly odd) MultipleOutputService class does that.

Here's our new SimulationRunner class, it injects dependent classes into Magic8BallSimulator (remember, Magic8BallSimulator still sees these classes as Interfaces).Source code for this post (that really is an odd output class).

In the next post

We'll have a look at a Dependency Injection framework for .NET (there are quite a few to chose from) and how it can make our lives easier. We'll also discuss the differences between running our application and starting it up to run. We'll also check out a better (and more interesting) way of wiring in our dependencies to Magic8BallSimulator. >> Next Post

Dependency Injection Part 1: Dependency Injection at last

2010-09-26T20:04:00.028-07:00

In my last post (read it, its short, honestly), I created an awful Magic8BallSimulator class which violated the Single Responsibility Principle by concerning itself with:

Message retrieval
Reading user input
Printing message and program output
Handling user-interactions via a lame read-eval-print (aka REPL) loop

In this post, I'm going to:

Create a class per responsibility
Make the Magic8BallSimulator class depend on those classes
Inject those dependent classes into Magic8BallSimulator (you'll laugh when you see how simple this turns out to be).
and finally, make you sad by exposing a new problem with the code

The new classes broken out are:

MessageService - gets messages
ConsoleInputService - reads user input from the console.
ConsoleOutputService - prints output to the console.
Magic8BallSimulator - Simulates a Magic 8 Ball via a lame read-eval-print (aka REPL) loop.

Oh there's a bit of Dependency Injection - MessageService, ConsoleInputService, and ConsoleOutputService are dependencies of Magic8BallSimulator, which is to say that Magic8BallSimulator cannot do its job of simulating a Magic 8 Ball without them. These dependencies are given to this class (or injected) as simple constructor parameters.
SimulationRunner - Runs the simulator class, and injects new instances of the dependent classes into Magic8BallSimulator.
Hmm, there's still a problem with this code

Let's have one more look at the Magic8BallSimulator constructor.
Notice how we're injecting instances of MessageService, ConsoleInputService, and ConsoleOutputService? What this does is, for example, couple Magic8BallSimulator to ConsoleOutputService which is a specific class printing output in a specific way (to the console). This coupling exposes us to 2 threats:

If we want to change, say, ConsoleOutputService we risk breaking Magic8BallSimulator too, since it depends directly on ConsoleOutputService (and changing the output on the console really shouldn't break our entire application).
If we get a requirements change to alter how we output messages, say, to send them as Instant Messages or via Email, we'll have to rip out ConsoleOutputService and change Magic8BallSimulator as well. This makes our application less maintainable because changes to one section break and cascade to other parts of our application making the whole thing a pain in the ass to work on.

You might be tempted to try something like the code below, don't do it. This is actually worse because it adds another responsibility to Magic8BallSimulator namely that of creating its own dependencies. This actually couples us even tighter to these dependent classes since now we're not only using their specific service-implementations, but instantiating them as well.

Luckily there's a simple way out.

We need to alter Magic8BallSimulator to depend upon abstractions instead of concrete implementations, making Magic8BallSimulator loosely coupled to the classes it depends on.

(Awfully coupled) source code for this post, witness the bad design first hand!

We'll explore this way out in the next post

Dependency Injection Part 0: The tragedy

2010-09-26T11:02:00.024-07:00

Consider this simple Magic 8-Ball Simulator class, here's the UI:

and here is the code, reading it should take perhaps a minute. Heck just read the Run() method.
Why does this class suck?

Simple, it is doing way too much work. As our requirements change and we work on this class, we'll start to introduce bugs in unexpected places.

[Requirements Change]: We'd like to store the 8-ball messages in a flat-file database.

Can you honestly do that without the risk of breaking unrelated code like message output? Imagine the following scenario:

You: "Yeah, so I was making changes to how the messages are stored and fetched and I broke the way they print to the screen."
Your teammates: "Hmm, OK". sheesh this guy cannot work on one feature without breaking something completely unrelated

Hey those two responsibilities are not related! So put them in different classes. In fact the code above has lots of responsibilities:

Message retrieval
Reading user input
Printing message and program output
Handling user-interactions via a lame read-eval-print (aka REPL) loop

Separate responsibilities, separate classes, separate reasons for changing code. This is the Single-Responsibility Principle, a grand and simple assertion that: There should never be more than one reason for a class to change. In my experience, most programmers dismiss this principle as obvious, and yet cannot seem to follow it when programming. In fact this kind of code is present in project's which I've otherwise been damn proud to work on.

Source code for this post, please only download it to shun it, and never speak of it again.

Let's fix this code

In the next post we'll see what breaking this class up entails.

AIR Ersatz Thread Example

2010-06-11T23:44:00.003-07:00

Citing the lack of threading as an example, I recently ranted that Air had a ways to go as a desktop application platform. In the context of such rich platforms like Winforms and WPF, I think that's a fair assertion (the API's are all public, judge for yourself). At any rate, leaving aside dramatic pronouncements, I decided to create an example AIR application which would both search the file-system and keep the UI responsive. This silly example simulates threading by doing small bits of searching on ENTER_FRAME.

Have a look here.

AIR has a ways to go as a desktop application platform

2010-06-09T18:35:00.032-07:00

Imagine a simple file-search desktop application. A user could type in a search string and press a button to start the search. The application would then recurse the directories on the user's computer searching for files whose names contained that string. Nothing complex, not even a cancel-search button or progress bar.

Now while the application recurses sub-directories, we want the user-interface to be responsive so the user (and the operating system) don't think the application has crashed. In .NET and JAVA, this is as simple as putting the file-search and user-interface on different threads.

In AIR this is simply not possible. Using the file-system search as an example, Adobe provides a getDirectoryListingAsync() function, you call it and then listen for a FileListEvent. Since our simple application needs to recurse sub-directories in search of matching files, it will need to parse the returned file-system items and venture into the returned directories calling getDirectoryListingAsync on those as well and so on. Adobe also provides the getDirectoryListing() function which if used will yield much the same outcome through synchronously and without the need for an event listener.

A few folks have asserted that getDirectoryListingAsync() does in fact run on a separate thread. If that's true then great, the problem is the FileListEvents are still handled on the UI thread, and when recursing through lower-level directories, there are quite a few FileListEvents. So sadly, when these methods are used to access the file-system in AIR, the UI becomes sluggish and unresponsive, especially when recursing from lower directories. AIR is simply doing too much work on one thread and doesn't have the resources to paint the UI.

There are a lot of smart folks (another smart person) who've come up with work-arounds for this limitation, most attacks boil down to this:

Split up your process in some way and call sections of your newly split-up process in chunks on each frame, allowing AIR to paint the UI.

That sure is a lot of work.

If we had threads, we could write this application via two simple concurrent processes. Recursing sub-directories is easy to do, and so is responding to user gestures on the UI. The sub-directory searching process could even raise events that we'd listen for on the UI thread letting the user know interesting bits like: progress, files found, directories searched, etc. The directory search could even be a simple, synchronous process (hey, its running on its own thread).

It is certainly worth noting that concurrent programming is hard (if you don't think so, you're either a badass or are new to it) and introduces subtle and confounding bugs. The pay-offs are huge but you run a risk as well (Microsoft charted a great middle course with BackgroundWorker). People are always clamoring for features in AIR, so here's my vote. Give me threads.

Edit: I've put up an Ersatz threading example which attempts the attack outlined above.

A Funny Skype chat

2010-03-24T14:42:00.005-07:00

I'm lucky enough to work with some smart (and funny) folks.

[12:59:18 PM] Joel Hooks: I'm not a geek
[12:59:52 PM] Max Nachlinger: yeah a certain degree of self-deception is necessary for one's sanity :)
[ 1:00:04 PM] Max Nachlinger: I'm not a geek either
[ 1:00:05 PM] Glen Whitbeck: ... admitting it is the first step towards recovery
[ 1:00:07 PM] Joel Hooks: fu Nachlinger!

Simple Horizontal Scrolling List

2010-02-14T09:52:00.006-08:00

I recently needed a horizontal scrolling list which would display 1 item at a time (2 items while the new item is sliding in) and have 1/32nd the functionality of Flex's HorizontalList. Here's a modified example (right-click to view source).

Edit: I noticed an annoying flicker in this control and have fixed that.

Flex ItemRenderers ought to be home-schooled

2010-02-09T20:50:00.011-08:00

ItemRenderers ought to be considered private children of their parent control and get their data from their parent only. Of course sometimes itemRenderers need data beyond what's supplied to them via IDataRenderer. Imagine that we've a List-based control and want our itemRenderer children to know when some bit of data has changed perhaps isTheWorldEnding:Boolean. The itemRenderers can then prepare from the upcoming conflagration by changing their states accordingly. I've seen lots of bad solutions to this problem, two common ones are:

Injecting a Presentation-Model into the itemRenderers (bad)
referencing an awful Singleton with the desired data (real bad)

Here's a better way. Sub-class the List control (make a MyList control) and add a publicly accessible property of isTheWorldEnding. In MyList when isTheWorldEnding is set to a new value, call invalidateList() to refresh the renderers. Meanwhile, implement IDropInListItemRenderer in the renderers and get isTheWorldEnding by casting _listData.owner as MyList. Here's the code to be put in MyList:

and the code to be placed in our renderer:
Edit: Joel pointed out that it would be nice to have a convenient method to cast the list, here it is:

Server Errors

2010-01-16T16:53:00.024-08:00

When writing a client app, we can lump server-errors into two broad categories:

Exceptions - the code running on the server has failed in an unexpected way. Examples:

The server-code cannot write to or read from disk.
The server operation violated a constraint in the database.
The server cannot find a matching method signature for your request.
and so on.

Business Errors - The request violated a business rule in our application.

An account with that email address already exists.
The submitted data is not valid.
We cannot lend you "Breakin 2 Electric Boogaloo", you already have that video checked out.

In my opinion a server exception should never be pitched to the client for at least two reasons:

exceptions often expose sensitive information, and
the server-code ought to handle the exceptions in question; not just re-throw them.

Now the server certainly needs to let the client know something went wrong, but that response need only indicate the severity of the exception and whether or not the client should try again.

Consider the case where a user uploads a corrupt file and the server throws an exception while trying to read it. In this case the client ought to inform the user that their file was malformed and to try again. If user-input from the client causes a violation of a database constraint however, then the software has failed and there's no point in allowing the user to retry their operation.

Back to the two categories of errors, Exceptions and Business Errors, which do you think the client should handle?

Both? Hell yes both! Here are a few ways to recover:

Recovering from Exceptions
If the exception is fatal, the server should send a text message to the poor bastard(s) on call and return the fatal-status to the client. The client could then display a standardized alert, much like the following:

We're sorry but we've encountered an error , please try again later. We apologize for the inconvenience, the support staff has been notified and is working to resolve this issue. If you have questions, please contact our support staff at support@domain.com

The user would then be logged-out for the application is no longer stable. This of course is a severity 1, high-priority, wake-your-ass-up-and-fix-it issue. Have I mentioned how much I hate maintenance? At any rate, say a user uploaded a corrupt file causing a server exception and we'd like for the user to try again. Our Alert might read:

We're sorry but we've encountered an error processing the file you uploaded. Please fix the file, or try uploading a different file. We apologize for the inconvenience. If you have questions, please contact our support staff at support@domain.com

Recovering from Business Errors
This actually varies depending on the error, but it is worth noting that the server ought to return a code indicating the error in question so the client can proceed accordingly.

I've used variants of the following server-response object on lots of projects with success:

A useful result object

When I get one of these back from the server, I check the operationStatus first and if its OK, I parse the result property. On "error" I then see if I need to try again (and often keep a count of how many times I've retried) and use the "faultCode" to drive my message to the user. On business errors, I check the businessStatus and notify the user accordingly.

NULLs in SQL

2009-10-10T18:53:00.013-07:00

In SQL, NULL is an indicator of the absence of value; consequently, the assertion that NULL = NULL cannot be parsed. To be evaluated, something must first have a value. I've certainly not explained anything here, I've merely proven that I understand the meaning and use of the English word "evaluate".

Imagination can be fairly described as visual thinking, and often when folks imagine NULL, they conjure images of empty strings or zeros; but both of these are values. Try imagining nothing. My favorite (though over-used) example of imagination versus non-visual thought is a Hectogon (a hundred-sided polygon). Try as you might, you cannot form a mental-image of this shape, but you can certainly think about it all the same.

Back to SQL. Consider the following simple table of Colors:

We allow the name column to be NULL, for 2 reasons:

1) we might not know the name of a given color or
2) perhaps this combination of red, green, and blue lacks a known name altogether

We cannot, however, allow the red, green, or blue columns to be NULL, for each of these is an essential bit of information used to define a Color. So we've tables which represent Entities, and those Entities have attributes some of which are necessary to define and describe the Entity in question. Basic database concepts. Consider this table of Tools:

Can you spot the error? Here's a hint: "Could you hand me a tool?" , "Sure, which tool?", "I don't know." "Well how about this one?" "I really don't know" and so it goes. The problem with this table is that we've allowed an essential attribute (the name of the Tool in question) to be NULL. I've seen lots of these awful tables in production we're-so-proud-of-our-flagship-product applications.

NULL and NOT NULL are important considerations, and the horrors continue when we find Tools with empty strings for names and NULL as well. This means that:

1) the client failed to require the obvious data
2) the middle-tier failed to check for the required data
3) the database allowed the bad data right in as well.

There are lots of defenses against bad data, foreign keys are great for this as well. Perhaps I'll add another crabby post about those.

Month Calendar control (with a MATE test-app and Degrafa skins)

2009-08-05T09:34:00.006-07:00

Here's a month-calendar (right-click to view source) I recently built. The skins are done with Degrafa and the test-app leverages MATE.

I'm honestly ambivalent about doing skins via Degrafa, for tools like Illustrator and Flash seem better suited for that kind of work (and you don't have to recompile to check simple things like colors, alphas and ratios). Every team has its own workflow it seems.

-- Edit
I've implemented the following changes suggested by a few fellow programmers on flexcoders:

You can now add events via a day-cell double-click.
The description-text is now printed on the Event.
Changed the Add/Edit Event Popup's title to match the Add Button text.

Thanks Kevin and Pedro!

Boolean columns suck as statuses or types

2009-06-27T08:43:00.011-07:00

A boolean column in a database table can usually have two possible values, TRUE or FALSE (I say usually, for one could make the column in question NULLable, allowing for the absence of a value). The problem with boolean columns is that in any non-trivial database, they're not expressive enough to describe the status or type of an entity. Consider the following simple requirement.

Users may access the system by typing in their username and password.

Easy enough; here's the table (we might even imagine an index on username and password to speed up logins):

As they often do, the requirements changed:

We'll also need the ability to disable certain users' access.

"That's easy enough", thinks the new developer, "I'll add a boolean field indicating whether or not the User is active. After all they're either active or they're not." Here's his design.

We can imagine that an inactive user attempts to login, and the system politely informs them that:

We're sorry but your account is no longer active. If you feel this is an error, please contact support at: support@domain.com.

Requirements changed again (at least in this example the requirements are still reasonable):

We're worried about spammers, so new users will have to verify their accounts before we allow them to login.

This is a standard process for lots of websites, the system sends you an email with a link containing a code which verifies your account. I am an English speaker and have learnt the meaning of the terms "active" and "inactive". Certainly un-verified new users are not active as they cannot log-in, but they're not really inactive either for we've not explicitly disabled them. Imagine showing an unverified new user the no-longer-active message above, their response would be some variation of "but I just registered!" (shortly thereafter the user stops attempting to use your crappy amateur-hour application).

Unfortunately there are lots of bad solutions to this problem and only a few good ones . Here's a bad solution:

Bad Solution 1 - another fun boolean field

"That's just another field, isVerified." Here's his design.

Look at the complexity we've caused.

Active users can be defined as isActive = TRUE AND isVerified = TRUE, New un-verified users can be defined as isActive = TRUE AND isVerfieid = FALSE, disabled users have the status of isActive = FALSE AND isVerified = FALSE. This is not maintainable.

Bad Solution 2 - NULLable boolean field

"Let's set isActive NULL for un-verified users" I'm not including the table graphic for this design, as I recently ate.

Great now our data-model says you're either inactive, active or we have no idea what your status is. I'd say the isActive column no longer really means "is-active". This is not maintainable either.

If you've read this far and are relatively sober, you'll realize that I've been building an argument to support my earlier assertion that in any non-trivial database, boolean columns are not expressive enough to describe the status or type of an entity. If you're not already convinced of this fact, imagine handling the further requirement via boolean columns:

We'd like to expire the accounts of users who've not paid within the last thirty-days. We also need to know the users who've expired so we can notify them.

What we need is a design which corresponds to how we think about the data. Most English speakers do not, for example, describe someone standing as isWalking = FALSE AND isSitting = FALSE, so why should your data-model act that way? Consider this simple design:

This design handles all the above requirements. Possible values in UserStatus are:

1 - Active
2 - Inactive
3 - Unverified
4 - Expired for non-payment
5 - Mocked for bad db design
6 - sent to an Intro. to Databases class

This design is flexible for if requirements change and we realize we need to account for a new status, just add a row to UserStatus. If it turns out that its possible for a user to be in more than one UserStatus (I can see a few un-named developers as being in statuses 5 and 6), we only need to add that as a new UserStatus ("7 - Mocked and re-educated" or perhaps "7 - Lucky to be working as a Developer").

If you keep things simple and model your data in an expressive way you'll be fine.

COMMIT

2009-06-21T15:10:00.000-07:00

Were you ever been forced to read something in school that, only after a period of time - having forgotten all about it, and on the 3rd glass of wine, you recalled- made sense? I was forced to read Freud in school, and (if you take a superficial glance at his ideas) he seems easy enough to dismiss. The insight I took away from Freud was this:

people are neither motivated nor governed by reason

Great. Given the leaking sack of fear, hope, un-fulfillment and the precious things we all carry around, it's easy to understand this insight. It is in this context that I hope to understand why several of my team-mates are not using transactions when performing multiple INSERTs, UPDATEs and DELETEs.

The utility of transactions is easy enough to prove, do a set of INSERTs, say, followed by an UPDATE referencing a column that doesn't exist. You've now fucked your database. I've actually run this experiment for junior developers at a few jobs; the response is always a variation of "it (meaning the DBMS) doesn't handle that for you?".

What's interesting is that, even after proving multiple SQL statements that modify data ought to be wrapped in a transaction, a few of my team-mates continue to piss in their code, firing off batches of these commands without a single transaction. Why? I've no answer. I've honestly never called on these folks socially and am not able to confirm the messy rooms and dirty dishes one might expect to find in the dwellings of people unable to COMMIT or ROLLBACK.

Please understand, I like the fact that these people are running around, it makes the world more interesting and they've something to offer. I just don't want these people on my team if they're allowed to INSERT, UPDATE, or DELETE.

In Protagoras (something else I was forced to read) Socrates asks Protagoras if he agrees with the rest of the world which thinks that one can have knowledge:

and yet that the knowledge which is in him may be overmastered by anger, or pleasure, or pain, or love, or perhaps by fear,-just as if knowledge were a slave, and might be dragged about anyhow.

I think I agree with the rest of the world too. If you have doubts, I've got some source-code to show you.

How to make a SWC into a (much smaller) RSL

2009-04-04T11:53:00.015-07:00

This of course only works if your SWC isn't already compressed.

Extract library.swf from the SWC
0. Let's refer to our SWC as {SWC} and its location on the file-system as {PATH}
1. Open {SWC} in your favorite unzip utility (7-zip works great and is free)
2. Extract library.swf to {PATH}

Run the Optimizer Tool against library.swf
3. Within /bin in your Flex SDK directory, you'll see optimized.exe, run that and point it at {PATH}:

Example on my machine: {FLEX_SDK} = location of Flex SDK
{FLEX_SDK}\bin\optimizer -keep-as3-metadata="Bindable,Managed,ChangeEvent,NonCommittingChangeEvent,Transient" -input {PATH}\library.swf -output {PATH}\output.swf

(the output SWF is quite a bit smaller now)

4. Delete DIR/library.swf and rename output.swf to library.swf

Run the Digest Tool
5. Since our SWF file changed, we need to update the digest info in our SWC

Example on my machine {FLEX_SDK} = location of Flex SDK
{FLEX_SDK}\bin\digest --digest.rsl-file {PATH}\library.swf --digest.swc-path {PATH}\{SWC}

6. Modify your FlexBuilder projects and mxmlc ANT tasks to point to {SWC} as an RSL with a URL of library.swf