Why YOU should contribute to Flex.

So I’ve been developing Flex since the 1.5 days, and before that using <cfform format="flash">, aka flex-lite. Yet, until recently I haven’t really been too involved with the community… well unless I needed something. I guess I’ve pretty much been self-absorbed and in my own little world.

I’ve now realized that the only reason I’ve ever found what I needed was because someone was willing to share. I know, I know… you knew that already… sometimes I’m one taco short of a combination plate.

So here are the reasons why YOU should get involved with the Flex (and flash) open source world.

The Adobe Team

I had the opportunity to meet some of the Flex team. And let me tell you, these guys (and girls… ahmmm.. Deepa) really care about this project. I’ve never seen a group so devoted to what they do. If you’ve had the chance to read through the specs that the team is putting online. You will see how well thought out the SDK is.

It’s also not uncommon to see the Adobe team participating within the community. If you’re subscribed to FlexCoders, you’ll frequently see members of the Flex SDK team answering questions and making comments. They also answer questions on the Adobe forums. I’m pretty sure the team at Adobe already has a full plate. Yet, they still contribute to the community. They go above and beyond the call of duty. For example, as I’m writing this post at 10pm PST on a Sunday night, I’m watching Alex Harui answering questions on the FlexCoders mailing list. Thanks Alex.

They’re asking for help!

Most people don’t realize how easy it is to get involved with open source Adobe products. Everyone can (and should) sign up for the Bug and Issue Management System. It’s quick and easy to get setup.

If you’re a developer, become a contributor and submit patches. It’s actually much more painless than I thought it would be. I faxed over my Contributor Agreement and was approved within 20 minutes.

Take matters into your own hands

One thing that I have been guilty of in the past is complaining that the Flex framework, or Flash in general, is missing what I consider no brainers. I found myself saying, “Self, why on earth would the person writing the Date class not think that someone, somewhere would want to change the timezone offset”, or other types of complaints. I soon realized that, Nate you dummy, this is an open source project. Fix it yourself! (again… sometimes I’m slow). It hit me like a ton of bricks: If you build it, they will come… errr…. include it into the framework.

It’s more likely that a feature will be put into the framework if it’s already written for them. Heck, in my previous post I was amazed by how quickly my fix was committed to the code repository. Adobe wants us to help! Which is a great place to move on to my next point.

YOU have a say

YOU have a say! It’s our framework. Sure, maybe Adobe has the final say on most of these things. And sure, Adobe may mark your feature request as deferred. But you know what, since it is open source with a public issue system, you do have a say.

Every user within the Bug and Issue Management System has the option to vote on bugs and features. This isn’t a dictatorship. Adobe has given us to right to vote on issues, and if an issue is getting lots of attention from the community, they will look at it and likely fix it.

You don’t even have to be a programmer (or an expert programmer)

I know there are some of you out there who don’t write code, or people who simply think, “I’m not a good enough programmer to contribute to the SDK”. Well good news, you can be part of the revolution too! You have the ability to contribute quality to the Flex Framework and Flash Platform. Here are few ideas: Submit bugs, submit feature requests, correct spelling mistakes in documentation. Get involved!

In regards to bugs and feature requests, I cannot stress this enough. Before you submit a bug, please… PLEASE… verify that the bug (or feature) doesn’t already exist, do some research before you just willy nilly submit feature requests and bugs. It ends up being counter productive. Other people doing the research you’ve should have done now have to spend time cleaning up the issue system because of duplicates and other issues. Having said that, another thing that helps the community is to browse through the issue tracker looking for duplicates, or general cleanup of the issue tracker. If you find something that needs to be cleaned up you can report it to Adobe and they will take care of it.

Anything that reduces the time others have to spend wading through issues is a good thing. It means that the people who are writing fixes to the issues spend less time in the bug system, and more time fixing the issues themselves.

FlexCoders Mailing List

Now I should mention, that FlexCoders is not a mailing list that is controlled by Adobe. It was started by a group of developers within the community. I’ve been following the list for a very long time, and frankly it’s kind of annoying. I’ll be in the middle of typing out a response to a question, when gmail pops up to tell me the conversation has been updated. Maybe it’s just bad timing, but it always seems that someone else beats me to the punch.

Another great thing about FlexCoders is the people that post there regularly. I usually end up laughing over some debate or a nerdy joke that someone included in their response.

Flash isn’t going anywhere

Let’s be honest here, against Silverlight… and whatever Sun, Google, Apple and everyone else is cooking up, The Flash platform is here to stay. With a ~90% client install base, and a large development following. I don’t foresee Adobe taking their ball and going home.

So what does that mean for us developers? We have a stable, time tested platform to develop on. We don’t need to worry about the Adobe going under.

Conclusion

The last point that I want to make… I’m proud to be a Flash developer. Looking at code that I submitted now being part of the Flex SDK just makes a person feel good. I’m beginning to understand why the Adobe Team puts so much dedication into this platform. And I have to admit, that dedication and devotion is contagious.

Flex, DateTimes, .NET….. Why can’t we all just get along?

Recently I’ve been working on a project that has a very interesting architecture. It’s a scheduling application that has a Flex front end, C# .NET Middle tier, nHibernate DAL and Oracle database.  We’re using SOAP to transfer data back and forth to the Flex client…..

[Rant]

I’m well aware of the other options that this client could have used to pass data back and forth. Frankly, I would have been much happier with anything other than SOAP.  But alas, this is the decision the client made before I was on the project. 

<3 AMF

[/Rant] 

….. so there I was, writing a dashboard which polls to see if the data has been updated. The idea is to request data from the server, store the servers timestamp on the client, and then check for updates by sending the timestamp back to the server.

Using C#, the web method is very simple:

[WebMethod]
public StatusResponse IsUpdated(DateTime timestamp)
{
	StatusResponse response;
 
	// Query or do what you gotta to give a valid response based on timestamp
 
	response = new StatusResponse(DateTime.Now, false);
	return response;
}

In Flex I set up a test application which allows me to send requests to the server. I should mention, the client and the server are running on the same machine, which is why I am comparing local client time to server time. This is my result handler

protected function onStatusResponse(event:ResultEvent):void
{
	_lastTimestamp = event.result.Timestamp as Date;
	var now:Date = new Date();
	var diff:int = now.time - _lastTimestamp.time;
	trace("ClientTime: "+now);
	trace("ServerTime: "+event.result.Timestamp);
	trace('Difference (ms): '+diff);
}

As I’m watching my data being outputted, I was a little disturbed with the results.

– Requesting Server Time –
ClientTime: Sat Dec 6 09:09:05 GMT-0800 2008
ServerTime: Sat Dec 6 09:23:32 GMT-0800 2008
Difference (ms): -866850
– Requesting Server Time –
ClientTime: Sat Dec 6 09:09:25 GMT-0800 2008
ServerTime: Sat Dec 6 09:32:00 GMT-0800 2008
Difference (ms): -1355072
– Requesting Server Time –
ClientTime: Sat Dec 6 09:09:25 GMT-0800 2008
ServerTime: Sat Dec 6 09:10:02 GMT-0800 2008
Difference (ms): -37070

You’ll notice that the ServerTime is getting pushed forward by some random amount of time. This is a big problem! If I am polling for updates every 30 seconds, and the last timestamp I received was 10 minutes in the future, the query will always return a status of false.

So what’s going on here? Why does Flex think that my Date is actually in the future when it’s retrieved from the web services?

Naturally, I started by looking at the web service response:

 
2008-12-06T08:49:02.2292832-08:00
false

A status of false simply means that the data has not been updated. Let’s look closely at the timestamp.

2008-12-06T08:49:02.2292832-08:00

According to the w3.org xml schema, everything looks good with that string. But one thing catches my eye: ‘.’ s+ (if present) represents the fractional seconds.

With a bit of research, I quickly learned there is a big difference between milliseconds (0-999) and fractional seconds. The schema doesn’t dictate what precision the milliseconds need to be in. So the C# webservice is using a precision of up to 7 digits. This seemed highly suspect to me, but the string is technically correct.

So now I needed to dive into Flex, and figure out where the data was being corrupted.

** fast forward a week **

After quite a bit of investigating, I figured it out.

frameworks/projects/rpc/src/mx/rpc/xml/SchemaMarshaller.as

Within the SchemaMarshaller, the milliseconds are being treated as just that… milliseconds. So when C# returned fractional seconds with a precision of 7 places (2292832), the marshaller was simply just appending 2,292,832 milliseconds to my date.

I submitted a patch which solved the issue, and while I was writing this post, I noticed that the fix has already been committed into the the Flex 4 repository.

Thanks Adobe, you guys rock!