RemoteObject vs. mxml.RemoteObject

The product I work on has some unique requirements, which create some very unusual problems to solve on a pretty consistent basis. That’s fun and challenging, so Great. But, sometimes the problems take it too far.

The application is built in Flex. Flex 3, to be specific.

That’s fine, BUT we build against the 3.3 SDK, which is basically a more buggy version of the 3.5 SDK (which was released like, a year ago). We build against the 3.3 SDK because of a common reality of software development in mid-sized/large companies.

About half a year ago we started having really wonky issues with our builds. Short story: it was because our build machine was using the 3.3 SDK and none of the developers realized it (also due to a reality of software development common in mid-sized/large companies). We all thought everything was on 3.5. Several of us started working on the project after 3.5 was released and never even thought to ask what version of the SDK we should be using. Bad on us.

We decided at the time to stick with 3.3, even though we were having a bunch of problems with event dispatching / value commitment in DataGrids (a specialty in 3.3 in terms of bugginess). The idea being that ‘after this release’ we would upgrade to 3.5.

Six months later, we suddenly start having bad builds again, and I realize that my local build works correctly if I build against 3.5. So, I blame my friend – who had been developing against 3.5 – and we start trying to figure out what our next steps should be. There are a lot of other competing details that I’m leaving out, here. The point, at this point, is that we had another meltdown based on 3.3 v 3.5, and we couldn’t see any good reason not to upgrade our build machine to 3.5.

However, things being what they are sometimes, we encountered a lot of pushback. Some of it quite valid. So, I started rolling back my local build, to find the last time that the app compiled correctly against 3.3.

I found a rev that worked, and then bumped up a rev until I had the first revision that broke on 3.3. Brilliant sleuthing.

I was expecting a complete rock fetch, but was happy to see that there was just one change between the last working revision and the first broken revision. And it was small and easy to revert. And we wouldn’t have to roll back any work – we could just modify the latest revision.

BUT – this was the sickest bug I have seen in a really long time. And I’m trying to vent my frustration by writing this out.

So, this application was fully formed by the time I joined the team. And, as often happens, it was fully formed by people who had never used the technology/language/whatever before. And it was a mess in large ways and small.

For example, in the object that is responsible for communicating with the server application, we instantiate a RemoteObject object. This class is written entirely in ActionScript, by the way – no MXML involved whatsoever. Nonetheless, the package imported for the RemoteObject was mx.rpc.remoting.mxml.*.

That always bugged me. And I always suspected that it would cause some sort of unexpected communication issue, someday.

Well, Backstory #3: Last week we started having a terrible communication issue. Basically, under some circumstances we would make a call against the server that would return a correct response. This was terrible because even though we could see the response in a web debugging proxy, such as Charles (in fact it was Charles), what we got in the app was a fault.

Yeah, a fault. The response comes back correct and with no errors, but we get a fault. The fault said something to the effect of ‘An acknowledge message was expected, but null was received’. What?!

We still haven’t figured out the cause of the problem, but we got past it through a lot of sweaty effort on the client and server teams. Part of the problem may have been sending an object with an undefined Array member, but that remains to be seen. I look forward to writing up a post about it soon.

But, back to the main story. So, we’re getting this awful message and we can’t figure out what is going on. As part of the troubleshooting, I finally change the RemoteObject’s package from mx.rpc.remoting.mxml.* to mx.rpc.remoting.RemoteObject. Because I think, ‘Here are two weird things. Maybe they are connected.’

The change did not help. But, at least that package import statement wasn’t bugging me anymore. Or was it?

Somewhere along the line, as I mentioned earlier, the build started going goofy. Right around the time my friend who had been developing against 3.5 committed a bunch of changes. Honestly, I didn’t care that much, and I was VERY involved with fixing the baffling communication issue.

Back to present time. It turns out that if the app uses the .mxml version of the import statement for the RemoteObject that is not instantiated in MXML, but in ActionScript, the app builds correctly against the 3.3 SDK. If the correct package is used, the app breaks so bad your teeth hurt.

When I say ‘break’, I mean this:

• Our application performs a read/write operation behind the scenes with a specific XML document every 3 seconds – those read/write processes were broken;
• Buttons in the application did not trigger any actions
• The dropdown menu in the top left of the application did not drop down (actually, same problem as Buttons not triggering any actions, but I’m enumerating so stand back)
• The first tab in our tabbed section did not display until you selected a different tab and then came back to it

Because we weren’t importing mx.rpc.remoting.mxml.RemoteObject. I could kind of think about understanding if we were using MXML to define the RemoteObject – I would at least not be completely wantonly baffled – but we WEREN’T. No MXML at all in that Class.

Now, again, the app started out its life as a spaghetti fight, but STILL… Does this make sense, I ask? Once I’m over this a little bit, I’ll probably be curious as to why the .mxml version of the RemoteObject is required for our app to work. Maybe I’ll write you a blog post about it if I ever figure it out.