One of the great things about C#, which I grew to love after switching from Java a few years back, are the properties. Properties allow you to use a Get/Set method right in the property which means you can use them like a variable (though .NET encourages you to call them LikeThis with a capital letter instead of a lower case). But why are they so powerful and effective? Well, lets take a look at an example. Take for instance one of the things I came across just today. Every time I compile my application for the Windows Emulator, it installs the application over the last one. This wipes all the files and directories I created on the previous run. This makes sense; it’s a new build so you have to run it as an application that’s just installed. This obviously means I have to make sure all my directories exist on start. One approach, is I can check if my directories exist before doing anything to them; this is cluttered and looks sloppy. Alternatively, this is where I can use the Get/Set of a property to my advantage!
I use a static variables in a GLOBAL class to hold persistent references. Doing this is somewhat deputed but I have found it is the most straight forward way to hold references you want to persist through the life time of an application. (Keeping it to ONLY data that needs to be persistent mind you! I’ll discuss the common mistake made by programmers with static variables in a different post)
Ok, enough talk. Lets go to the example. In Windows Phone 8, I can obtain the default application directory handle by doing the following (took me forever to find this by the way):
GLOBAL.JOURNEY_FILES_LOCATION = Windows.ApplicationModel.Package.Current + "/Journeys/";
For those who came here looking for “how to get root directory”, the above code is what you need to obtain your application directory in Windows Phone 8.
Back to the example; the issue here is that the directory doesn’t exist yet! If my user wants to load all the journeys (regardless if they exist) my application will explode with and IO exception. But wait! I don’t want to clutter up my code by checking if the directory exists EVERY TIME I do anything with the files. So how do I make sure that directory exists no matter what? With minimal clutter? Take a look at what the actual JOURNEY_FILES_LOCATION looks like:
private static string _journeyLocation;
public static string JOURNEY_FILES_LOCATION
_journeyLocation = value;
So what have I done here? Well instead of having to call some function that checks if the directory exists and create one if it does not, I have the property take care of managing that itself. It’s encapsulated; I don’t have to bother with it ever again. I prefer to do things like this on the “get” of a property; most people prefer it to be in the set. Both are equal, with some down and up sides, but it will make sure that the directory exists. So what happens here? When I request to get the current directory, the get method goes in and checks if the directory exists and creates one if it does not. I don’t even need to bother with checking exclusively anymore! As a result, if the user wants to see all their current Journeys and the directory does not exist, it will ensure that the directory is created. Take this as an example:
public static JourneyObjectState RemoveJourney(string name)
if (File.Exists(GLOBAL.JOURNEY_FILES_LOCATION + name))
File.Delete(GLOBAL.JOURNEY_FILES_LOCATION + name);
Why not just create all your directories on the start of the application?
You could and a lot of programmers will code that way. However its not the cleanest way to approach the issue. It’s also very prone to crashes, because if you forget to create one of the directories at the start or somewhere along the lines you delete the directory, your code has the potential to crash. This is what I call “air-tight” programming. I means that it ensures that no matter the the circumstances, your code will not crash the application. You’re safer checking if the directory exists every time rather than creating it and hoping it will not disappear.
Isn’t checking for the directory every time expensive?
Yes and no. We aren’t making a videogame here which has to access the file 30-60 times a second (and why would you code a game to do that?). Obtaining files is very fast via memory chips so I have don’t have much of a concern here. For instance the same application loads photos at one point and it is fast fast fast even on an emulator. This would become a burden if you run this on huge volumes of files but otherwise, this is not a performance bottle neck. Not in today’s age anyways.
Be careful when doing this for database records
I can see people having the temptation to hook up a database call to this. Files are fine but if you will slow down your application trying to call a remote database remotely like this. I would look for other ways to handle database interaction as this is expensive. For instance if you want to obtain a user through the “get”, this is not a good approach unless you make sure that you are not recalling the database after the user has been obtained.