jalbrant.com
blogs
j2's blog has moved....
My futures trading blog has moved to:
http://360.yahoo.com/wormaninc
Thanks Jer for introducing me to blogging. You have a great website!
Adding custom code to autogenerated classes by xsd.exe in .NET
I recently needed to add some custom code to a couple autogenerated classes that were created by xsd.exe. Unfortunatly, anytime you make changes to the XSD, xsd.exe overwrites changes made to the class. To insulate a custom code from xsd.exe, create a new class that simply inherits from the generated class, then add the custom code, methods, properties, etc to the inherited class and use it for all accesses to the data.
AAVOnline Versioning Scheme
In order to standardize how releases and development builds are versioned I came up with a scheme for AAVOnline that I have been using since v1.0.0. The version number can be broken up into four parts, Major, Minor, Revision, and Build. The Visual Studio .NET does a decent job of automatically creating and incrementing these numbers if I allow it to, however, I prefer to do it on my own.
Major
The major version will only be changed whenever I make a large sweeping architectural change to the program. As is the case with most software, this number is rarely changed and in AAVOnline's case will probably remain at 1. At this time I only see a large change when I move to .NET 2.0 or possibly straight Visual C++.
Minor
I use the minor version number to introduce new features to AAVOnline. For example, v1.1 added an online timetable to v1.0 and v1.2 added semi-instant messaging.
Revision
The revision number exists so I can release bug fixes and minor enhancements to an existing version. When automatic flight reporting was having problems, updates to it were released under the same minor version but different revision version.
Build
The build number is use solely for development versions. This is incremented with each intermediate development version that gets sent to beta tester(s).
Release Versioning
Following a similar model as the open source community, stable releases will only be versioned with an even numbered revision. Development versions will have an odd numbered revision and possibly a build number. For example, I am currently working on v1.3 of AAVOnline so my development builds have been given numbers like v1.2.5.4. Once it is ready for primetime, it will be reversioned v1.3.0.0 and sent out. An subsequent stable release will get v1.3.2.0.
AAVOnline2 Development Started
AAVOnline has been an excellent learning experience for me. I have been able to extend what I learned from EZFrep about .NET into AAVOnline and feel quite comfortable. The next big thing for AAVOnline will be what I call AAVOnline2. As of this writing I will not be using the .NET framework and instead be using MFC. This, obviously, has its advantages and disadvantages. One major disadvantage is that I will be losing the power of .NET and the ease with which I could implement higher level features. However, I have realized that AAVOnline2 should not be such a resource hog as I have found it to be using .NET. Using MFC I will be able to use a lot less memory, maintain greater compability with users, and use fewer precious cycles.
This probably sounds like a step backwards and I can agree with that, but if I expect people to run this program while Flight Simulator is running, I should probably be courteous with the resources AAVOnline uses.
I have been able to demonstrate a portion of the core functionality found in AAVOnline. I have written a small console based program which simply downloads the XML data from the web service, parses it, and creates the appropriate data structures in memory. Being able to download from my web service and parse the XML are two of the major hurdles I needed to get over before I could move ahead with this idea (as crazy as it sounds). The 3d globe will not be an issue since my OpenGL experience is primarily with C++ not C#.
Synchronous web service based near-instant messaging framework
In v1.2.0 of AAVOnline, the biggest feature will be the ability to send messages to other pilots while logged in. To accomplish this I have created a web service based near-instant messaging framework.
The idea behind it is rather simple and easy to implement. Because AAVOnline already provides a framework for authentication I am able to piggyback on this existing framework and concentrate on message delivery. Validation is done on each messaging request made to the server (get or send) via a callback to AAVOnline's server side web service. This callback returns true or false and from there the messaging framework determines if it should continue processing the request. I implemented it this way so I can use the same messaging system in other applications in the future.
To retreive messages from the server, AAVOnline has a thread running in the background that sends a request to the server for any and all messages it has for the user. If the server has any (and the pilot can be authenticated) it returns all messages in XML. Each message has a unique hash identifying it from the rest as well as sender's name, base64 encoded content, and a timestamp assigned by the MySQL server. The get message thread on the client side receives this xml, processes it and creates new Message objects internally for each message received. If no messages are received it does nothing and waits until the next time around to check again.
In this messaging framework I have made an assumption on how people interact with instant messages.
Immediate responses are only expected in cases of active conversation.
Using this assumption, I am able to throttle up or throttle down the delay at which the get message thread downloads messages based on the activity of messaging the AAVOnline client is experiencing. i.e. If somebody is engaged in active conversation with another person responses are expected to be quicker than if a message is sent during an inactive conversation. If I had an asynchronous connection to the AAVOnline server, this would all be a moot point but with web services everything must be synchronous.
Finally, when a client wishes to get messages, they also send the highest timestamp which they have received. The server can now assume that it has successfully delivered all messages with a timestamp less than or equal to this to the client and can dequeue them from the database. After that it pulls out any remaining messages for delivery to the client.
Sending a message is simpler. When a pilot wishes to send a message, the client connects immediatly to the server where the message is queued in the database for delivery the next time the recipient wishes to get their messages.
Use Base64 to avoid SQL injection attacks
One easy way I've found to avoid SQL injection attacks and related errors is to simply Base64 encode the contents of data that users enter. It's a simple way to make sure you are escaping every possible special character.
AAVOnline will use this functionality with all of it's messaging capabilities. Since users will be sending arbitrary text to each other it is important to come up with a way to allow this.
Below you will find the C# code for the Base64 Encode/Decode routines I used to accomplish this. (From http://www.vbforums.com/showthread.php?s=&threadid=287324)
public string base64Encode(string data)
{
try
{
byte[] encData_byte = new byte[data.Length];
encData_byte = System.Text.Encoding.UTF8.GetBytes(data);
string encodedData = Convert.ToBase64String(encData_byte);
return encodedData;
}
catch(Exception e)
{
throw new Exception("Error in base64Encode" + e.Message);
}
}
public string base64Decode(string data)
{
try
{
System.Text.UTF8Encoding encoder = new System.Text.UTF8Encoding();
System.Text.Decoder utf8Decode = encoder.GetDecoder();
byte[] todecode_byte = Convert.FromBase64String(data);
int charCount = utf8Decode.GetCharCount(todecode_byte, 0, todecode_byte.Length);
char[] decoded_char = new char[charCount];
utf8Decode.GetChars(todecode_byte, 0, todecode_byte.Length, decoded_char, 0);
string result = new String(decoded_char);
return result;
}
catch(Exception e)
{
throw new Exception("Error in base64Decode" + e.Message);
}
}Xml Serialization Quickie
Just to add a couple things to my previous XML serialization post. I've been trying to serialize a couple classes that are the backbone for track data in AAVOnline. One of them, PilotData, stores each pilot's information and an ArrayList of their DataPoint's. In order for XML Serialization to work, the compiler *must* know the types of every piece of XML data at compile-time. When you have a collection such as an ArrayList this is unknown. The way you get around this problem is to declare your arraylist as an XmlArray using the XmlArray attribute like so:
[XmlArray(ElementName="Datapoints")]
public ArrayList Datapoints;The ArrayList also must be attributed with all the possible types it is going to store. For example, my ArrayList only stores DataPoints so I add the attribute:
[XmlArrayItem(ElementName="Dp", Type=typeof(Data.DataPoint))]to the ArrayList and voila, it works.
My understanding it that you can actually use more than one XmlArrayItem attribute, thus allowing you to have more than one type of object in your ArrayList.
An optimized, cached, pooled, weather download system for AAVOnline
One of the features I included in AAVOnline v1.1.0 was the ability to download METARs from NOAA. This feature was active but hidden in AAVOnline as it had not reached production level yet. Now for v1.1.2 I'm planning on making weather a key component to AAVOnline and in doing so I've come up with a very nice weather downloading system.
In v1.1.2 weather information for the departing and arriving airports will be displayed in a Marquee style label at the bottom of the screen. In the main window I have included a timer which goes out to the resource loader (shared memory used by AAVOnline) and uses the latest METARs for the airports then formats those into a string and updates the Marquee label. Below you will see the Timer's FSM:
As you can see the timer is pretty simple and just displays the metars from the resource loader at every tick.
The next part of the system is the Download Weather Thread. It is responsible for getting the latest weather information into the resource loader every few minutes. To do this it sends a request to the local weather cache for the latest weather and blocks until it gets the weather. Having a thread block instead of the application blocking while a possible download of the weather is occuring is preferred so the user's experience is not changed. From here, the weather cache checks its local cache of metars for the weather station identified. If it can't find it or the metar has expired it goes out to a web service of mine and downloads the latest metar. Once the web service gets a request for a metar it then checks to see if it has a non-expired copy of the metar locally and returns it. If not, it FTP's into NOAA's site and downloads the metar and returns that, while caching it for future requests. Caching the metar on the server allows requests to be pooled assuming there are multiple pilots requesting the same weather station at almost the same time.
Here's a graphic showing the status thread as a FSM:
Finally here's a graphic showing the entire system:
C# WinForms Bitmaps
Quick one for today...
I've been a little busy "sprucing" up the AAVOnline GUI and found that if I use a 16-bit bitmap as the background to my form it slows everything down on the computer, even flight simulator. However, if I use a 32-bit bitmap everything runs just fine! I figure this is probably due to it having to convert from 16-bit to 32-bit with every redraw of the form. Now my executable is bigger but it runs smoother!
Flight continuation and state resets
In the current beta version of [AAVOnline] I tried to see how well the program could pick up its flight status state after a flight continuation. The logic was there, I had tested it and it had appeared to work when I first wrote it, but unfortunatly did not work when I tested it in a real situation. So, of course, I set out to see if I could fix it. Here is what I found:
When the "Start Flight" button is clicked the program grabs some information from the user then procedes to login to the server, the server then replies back and gets the flight setup or replies with "duplicate" meaning they're already logged in. The gui then takes that displays a message to the user asking if they want to continue or not. If they wish to continue the server send all the info needed to communicate with it with the existing flight and the client loads its previous state from the hard disk. In theory this was supposed to work and it actually did work, except for one problem: Once a login (new flight or continued flight) is performed the gui calls a method in the middle tier that makes the program go online (fires off threads, sets up memory, etc) One of the actions this method takes is to start up the status checking thread which in turn resets its state which is where the flight report data is generated. So the state is being loaded correctly but then reset once the program tries to go online.
To fix this I simply added a flag signifying whether or not the flight was continued which tells the next call to start up the thread NOT to reset the state. Voila, it should work and I would test it but I'm in the middle of a flight at home that I don't want to lose on [AAVOnline]. (My computer's hibernated, but I'll install this version to do my test before I resume)
