Today’s article will be a backstage pass to one of the new upcoming features being added to LandlordMax Property Management Software. In particular, today we’ll talk about what’s involved in adding column sorting on all the tables in the upcoming release. We’ve been working hard to get this new release of our property management software up and running and I figured it would be a nice change to give you our readers a chance to see exactly what’s involved in adding a new feature.

We’ve had a lot of requests for many features. One of the most common has been the ability to sort any column in any table in LandlordMax Property Management Software. This article will talk about how we’re adding this feature. I’ve tried my absolute best to keep it as least technical as I possibly could. So now that you’re interested, let’s start reading how it’s being done!

The very first thing we needed to do before we even started to implement this feature was to learn how to sort tables in Java. You see this is not a built in function of the Java programming language, it’s something that needs to be implemented. There are hooks into the language to make it possible; however we needed to learn how it works. The good news is that there are lots of books and websites out there to help us out.

After doing some research, we came to the conclusion that we would be ahead by buying a component library from another company called JIDE Software. What this means is that we would buy the programming code from another company that would sort the table for us. You see there are many companies that exist only to provide components for other programs like LandlordMax Property Management Software to use. These can include web browsers, email clients, table sorting, etc., all components that you can directly integrate into your software.

We could have done it ourselves, but we quickly realized it would have cost more than the cost of purchasing it, and not only that but the component library has a lot more features that we could use in the future. For example, we can later add the concept of hierarchical tables. That is, tables where we can expand and collapse whole groups of rows, something that would really benefit some of our reports, such as “Accounting entries grouped by categories” as illustrated in the image above. With this feature, we could collapse/expand all the accounting entries for a particular category in the report, to help us better isolate only the information we want. Another great looking feature is that it gives you the ability to choose which columns to display, so that you can remove columns you’re not really interested in. There are other great features, however unfortunately because of tight the timelines for this release, a lot of these niceties will have to be postponed to the next major release. The good news is that these are furthers features you can expect in our future releases.

In any case, all these features are not free. With this particular component library that we purchased, for every 1000 customers we acquire we have to pay one additional license fee to them which is definitely something we need to be conscious of. We currently believe this is worth the cost.

Although it might look like there’s not much work left from this point because we purchased a library to sort the tables, there surprisingly is! This is only a very small part of the puzzle. The next thing we needed to do was to define each column, and how they were to be sorted. In Java, there is something called a Comparator. This allows two Objects to be compared to each other, so that you can determine their order. Therefore, for each and every table, and for each and every column, we need to define which type of Comparator to use. Is it a Date Object Comparator, is it a Currency Comparator, is it a Number Comparator, is it a String Comparator, etc. Considering the number of tables we have, not to mention reports, you can quickly see that this adds up to about 200 tables times the number of columns. This is a lot of definitions!

Now unfortunately for us today, in the previous versions, because we didn’t have the notion of sorting on the columns, we took some shortcuts in the code to save time (a normal programming design decision to not implement everything and rather only implement what you need today). Actually we did it then for two reasons. But before I go into how it affects us, let’s quickly look into the concepts of Java tables. First and foremost, each entry in a table is an Object. That is if it’s “hello”, “hello” is a String Object. If it’s a date, then the representation of the date is a Date Object. The problem is that when you use a Date object, how does the table know how to display it? Is it 2005/10/10, Sept 15, 2004, 05/23/2005, etc.? This is where the Java language built in something called a Renderer. It takes an Object and renders it into something that we can use, hence the name Renderer. So for example, it will take a Date Object and render it as “Sept 15, 2004” in our table.

This is a great feature of the language because it allows us to store the Objects rather than just their string representations. Imagine if we could only store in the string representation for dates. If I sorted “Sept 15, 2004” and “December 23, 2004” alphabetically then “December 23, 2004” would come first. However if I sort them by their Date Objects, then I can use the Data Comparator above to compare them one to another and correctly sort them by date.

As I mentioned this is a great feature. However in the previous versions of LandlordMax Property Management Software, because we didn’t have any sorting, we didn’t need to store the actual Objects, we could just store the string representation. This would save us all the trouble of writing Comparators as well as Renderers. In essence, this saved us a great deal of time! However today, because we want to add sorting, we need to revisit where all our tables are created to convert the string representations back into Objects and add Renderers to all appropriate fields.

The good news is that we can re-use a lot of the code, we only need to write one Comparator and one Renderer for each type of Object, say our Date Object for example. The bad news is that we need to go through each and every table and convert the string representations to their respective Objects, associate the appropriate Renderers and Comparators. We need to do this for about 200 tables times I don’t know how many columns. This is a very large task!

Although this might seem like it’s the end, it’s not yet the end! Because we knew the Object representing the list of data and table itself we’re identical, they didn’t change order and so on, we could use another shortcut and just reference the Object list at the appropriate position in the list to access the selected Object. So for example, in our list of tenants, if we double clicked on the 10th tenant, then we could either choose to select the 10 item in the table or the 10th tenant from the list of Tenant Objects, either worked. We chose the later because we could greatly automate the process in our code. Today this is no longer true, the 10th tenant from the list of Tenant Objects might not be the 10th tenant in the table (depending on how it was sorted). We therefore needed to change all the code that referenced these Tenant Objects from the list to get them from the table directly and not from the data Object lists. That’s at least another 200 code changes.

It doesn’t end there. Because we don’t display every attribute of an Object in the table, we need to store that Object hidden in a column in the table. So for example, our Tenant Object can contain additional information that we cannot display in the table, such as all the accounting entries associated with that tenant. Therefore, we cannot reconstruct our Tenant Object from only the values in the table, it’s just not possible. Therefore, we’ve had to append our Objects (in this case our Tenant Object) as the last column in each of our tables. Another 200 code changes!

By default all columns are displayed. Therefore we now need to go through every table and hide the column containing the Object itself in the table. We don’t want to display this column, it wouldn’t make sense. Another 200 code changes!

We’re getting there, but there’s still more code changes required. What about printing? Will the printed table match the sorted table? I don’t know yet, we haven’t gotten to that part of the code yet, but in essence we need to verify that all 200 tables correctly transfer their table data to the printer, and not the list of data Objects (because these would no longer be correctly sorted).

Are we there yet? Not quite! Because all our tables are completely refreshed every time you change screens and/or workareas, we currently lose track of which columns were sorted. We’re now looking at how we can manage to keep track of which columns where indeed sorted and in which order so that when you return back to your table, you don’t need to resort it again. Will this require another 200 changes? I don’t know yet because this isn’t completed either, but I suspect that it can be greatly automated and not require 200 code changes.

What other changes are there above this to handle sorted tables, I’m not sure… However, by the time the software is released, you can be assured that this will be completely done as well as all the other features we add. This is why if someone ever asks me if a feature will be available in the next release, I will only say it’s anticipated until it’s 100% completed and tested. You can never be 100% sure it will make it into the product until its 100 completed!

I hope that you found this article informative, that you now have a better understanding and appreciation of what goes into building each and every version of LandlordMax Property Management Software. Although software may seem simple to build on the surface, there’s often a lot of hard work involved. There’s a reason why there’s not a lot of good software, and that’s because it’s hard to do!

Discuss (0)