May 21 2009 
Creating Tcal, a full featured cross platform Calendar Application
Can architects program? How I went from architecture to (may be) software development.
It all started while I was working here in Torino (Italy) for a small architectural firm.
There were around 30 architects, doing lots of small projects (shops and franchising renewal) and I was in charge of the productivity of this bunch of professionals.
Accounting for this kind of work is based on time spent on each project. Over the years, with the help of the IT manager, I elaborated a management FileMaker database that grew into something rather complex...
This relational database was holding each job name and number, its related job information, who was in charge of it, the members of the team, and, through related files, the expenses and the daily hours spent by each team member on each project.
Expenses were easily recorded by the accounting department. Hourly work input on the other hand, depended on the manual submission via the networked database, of each architect, theoretically at the end of the day but usually and painfully done at the end of the week.
Over time, we looked into several alternatives for the input of hours (the more difficult the input, the more prone to forget was the architect):
• The company was small enough so that the cost of a customized job management software was out of question. Computers were Mac and PC.
• FileMaker, as a job management database was pretty good: easy to modify with our ever changing needs.
• FileMaker simply did not have a flexible enough structure to enable the creation of a calendar with a graphic interface, a la iCal or Outlook
• iCal and Outlook plug-ins work one way only: you can have iCal to record Events on FileMaker, but cannot easily link FileMaker records to calendar Events. They just were not sufficiently integrated.
Then, one day, I discovered Revolution, with its easy programming language (that reminded me of my Hypercard days), its networking possibilities, its fast compiled applications.
I downloaded the demo and the same day I tested a few scrolling rectangles containing the events of the day and the networking between a Mac (OS9 at the time) and a PC (Window NT). The following week I showed my test to the proprietor and I was encouraged to go on (but as a personal side project, since we were in the architecture business, not on software...).
The idea was to create a Client application (the user calendar) that would communicate with a Server application (on a different computer) through TCP/IP on the intranet. The Server would talk to the FileMaker database through AppleScript.
After two years of software development (I don’t work for that company anymore and I do this in my spare time), three upgrades of the Calendar, changed operating system several times (OS9 > OSX10 > 10.5 > Intel....Windows NT, Windows XP > Vista) I am still convinced of my choice, but, ehi…
A Client/Server multiplatform network shared calendar, with a graphic interface, alarms, scroll editing, with a Server side linked to commercial database and more, IS A BIG JOB (at least for a one man band that needs to learn the tools of the trade).
I must admit that I underestimated the task. If you are like me, learning and alone, you should start software development with something small, done in a few months, without being tempted continuously to add improvements.
But let's see how I managed to arrive where I am today.
At the time I began with a simple window, showing a 12 hour calendar, no Saturday and Sunday, with scrollable events. It was the Client application and it looked like this:
Most of it was pretty easily accomplished (the monthly box coding was inspired from Sarah's Revolution Page Calendar example, at "http://www.troz.net/Rev/recent.php?id=[opt1]" …).
Of great help were the tons of info and prompt help available on the RunRev forum (thanks to all...)
- the handling of the mouse events order (mouseUp,mouseDown, doubleUp, doubleDown). The user had to MouseDown > scroll down > mouseUp in order to create the rect of the Event. He also had to doubleClick to edit the same. Somehow I always got confused on which came first…(doubleDown or MouseUp?). Since Event rects were text flds created on the spot, I needed to keep down the amount of code on each fld (no behavior at the time on RunRev). The template fld would just pass mouse action to the card, together with Event info (held on the custom properties of the fld).
- Date formats: In Europe we use dd/mm/yyyy. Sometimes they use dd-mm-yy. With leading zero or without. In USA and other countries they reverse dd with mm (bah…). And you always need to convert the dates to a common internal format because, since I wanted to link to Filemaker, I had to take into account how it handled the dates. I used Applescript to do the communication between the Server and Filemaker. Applescript has its own way to handle things too…
Only recently I decided to finally use the “short date” (English format) as an internal format. When I show dates to the user, I force “/” separation and move dd and mm according to the system preferences (I did not use System dates because it was confusing to me). Dateitems conversion was very useful; too bad that "2009,4,13,0,0,0,2" > "2009,4,6,0,0,0,2" = false. To do comparison (>=<) between dates I always had to convert to seconds (seconds are difficult to debug, tough…). - The handshaking protocol between the Client and the Server.
Revolution is so easy to use that you forget that for certain tasks you need specific knowledge: the tool is not enough.
Let me explain with an example:
When the user creates a new Event, the data of the Event gets transmitted to the server. So you have to be sure that the server answers with some kind of flag. But you cannot wait for it to answer in order to draw the event rect, otherwise the user experience would be continuously delayed. You draw the rect, send to the server, get the answer and act accordingly (if no answer, tell the user and erase the rect).
What if in the same time user2 creates another Event (with you on it): your calendar must receive its data and create a rect for it. Things get pretty mixed up after a while…
This was the Application server window:
After a few months I had a more or less working application (remember…I do not do this for a living).
It had only 12 hour time, no Saturday and Sunday, no montly view, no alarms and the communication with the Server was buggy. But with a simple scroll I could create an Event, add resource names and Job name to it (taken from the database) and record the working hours of each Job to a specific database.
In Italy we say “la fame vien mangiando” (you get hungry if you start eating). So after having published the calendar on its Web site (more time for this), I decided that I needed to implement the other things, otherwise nobody would take my calender seriously.
In the next article in this series, I will discuss how I added alarms to my calender. Later in the series we will look at socket handshakes, and how to communicate with Microsoft Access.
 |
|
