I spent several hours today porting our code to the new web services system. All that nice stuff I said about in my last post? I take it all back. While it’s good that the process for making a service call is now more intuitive, it came at a heavy price: almost zero type-safety. Since Flex doesn’t have a concept of generics (except for Vector, which I’ll get to in a moment), the old auto-generating method created oodles of subclasses for things like ResultEvents and collections of custom data types. The new system does none of this. I talked about why generic ResultEvents are a problem before, but I hadn’t noticed the lack of custom collections. This turned out to be a huge problem.
Our old code for interfacing with web services took advantage of the fact that we received custom collections in our custom ResultEvents to hang on to a little type safety. These custom collections disappeared, leaving generic ArrayCollections in their place. So I had a choice: roll my own custom ArrayCollections, or use Vectors. I opted for the latter. Vectors are currently the only thing in Flex that has a concept of generics. I think I talked about this before, but although I don’t know how Adobe is implementing Vector, I suspect it’s a massive hack because you can’t create your own generic classes. Moving on from that aside, I rewrote a ton of code to use vectors instead of the custom collections. It turned out that this solution merely created another problem. Datagrids expect to be given something that implements ICollectionView, apparently. Vectors don’t do this. So while the application compiled, all the tables were completely broken. I fixed this by introducing a VectorToArray utility function I found thanks to Google.
So basically, in our attempts to maintain as much type safety as possible, we now have a process that goes like this: the auto-generated code gives us an ArrayCollection, which we turn into a Vector and pass around our application, then turn back into an ArrayCollection for the Datagrids. As if that weren’t bad enough, Adobe still hasn’t fixed the bug that makes their auto-generator screw up when faced with a SOAP operation called “XResponse”. So we’re still stuck with “GetProjectAnswer” instead.
Even getting a key to extend the beta beyond 60 days was a hassle. I used the form on Adobe’s site, which promptly e-mailed me a license key. The one problem: the license key didn’t work. I e-mailed them last night and got a response this morning. Apparently, somebody over there was asleep at the wheel and forgot to update the license key form for beta 2, which won’t accept keys from beta 1. Oi.
Anyway, we’re now back to where we were when I started this little adventure. I’ve updated the test build script but I haven’t actually tried it, mostly because there’s obviously not going to be a test build this week since there’s nothing new to show. Over the course of tonight and tomorrow, I’m going to merge the Flex4Migration branch into trunk and update all of the documentation on the wiki accordingly. I also need to start drafting our weekly report. That ought to be interesting. Maybe Matt did something this week that was actually useful.
Pingback: Flex Sucks: Greatest Hits! « CaptainRichard's Blog