You are currently browsing the code.timst() posts tagged: Java

Project: EDT Watcher

EDT Watcher (a rather nonsensical working name, “EDT” standing for “Emploi du Temps”, a timetable) is a Java library and an unfinished Android app designed to access the timetables of my home university of Nantes in a more user-friendly manner.


Nantes uses a web-based timetable system by Celcat for almost every department (engineering, humanities, medical school, etc). Those timetable are comprised of a large (~ 7000 lines for my former class, though we were not the busiest one) XML file detailing the lessons and events of the whole year (although it starts out empty and is then edited throughout the year as lessons are scheduled), and a bit of HTML/CSS and Javascript to make it easier to browse. Quite simple, and fine for most use cases (eg., looking at your next lessons or visualizing your week workload). However, it lacked some advanced features, and more importantly, didn’t display on mobile phones, at least not android phones.

So I started working on a small Java program to retrieve the XML file, parse it, and store the data in appropriate beans so it can be used later. Nearly the whole university is using Celcat’s system, which is a huge advantage: I start by regexin’ this page to get every department’s timetable’s sub-site’s url, and then I go to the department’s site’s group index (typically the url, + “/gindex.html”, for instance this is the group list for my department), and, if it’s not password protected, I can access the groups’ timetables. Now I can easily get the XML file for a selected group and process it.

After that, the group’s data is stored inside a Timetable object, containing an array of 52 Week objects, themselves containing an EnumMap mapping weekdays to Day objects, which hold the lessons in an ArrayList. These lessons comprises a list of teachers, rooms and modules (collectively grouped in a Resource class), a start and end times, and an ascending link to their Day.

I have to admit that it is not the greatest architecture I have ever designed, and it might probably be easier to do away with the Week and Weekdays abstraction and just list the days with their lessons in a collection, but it allow to easily perform operations on a week, and it’s the easiest way to map to the original XML files, which don’t mention days, but use weekdays and week numbers instead. Well, not even week numbers, but a 52-chars-long string with either “N” or “Y” symbolizing the position of the week in the year. Weird.

All in all, the original material seems to be of dubious quality, with esoteric formatting and a lot of redundant information, but I tried to do my best. Also, there was a lot of date and time stuff and the Java native tools in this category are… a bit lacking, so I used the popular Joda Time library instead, and it was a huge improvement.

Once I finished the whole parsing thing I added a command-line interface and a Google Agenda exporter, and then I started to work on the Android app, and, well, that’s where I stalled. I did a welcome screen, two sets of list to browse through departments and then groups, and a screen indicating the next lesson, its location and data (teachers, start and end time…)

It was actually pretty useful, and I used it often throughout the year to find my room without having to walk through half the campus to read the only timetable displayed in a corridor, but it lacks advanced features that I wanted to implement, such as a week / month timetable, statistics, and maybe an alarm clock based on your actual timetable.


As I said elsewhere, I’ll be leaving Nantes University soon, so I’m unsure about releasing it because it would means that I might get tangled up in support mails and possibly legal issues with the University and/or Celcat. However I still want to work on it, and it would be a shame to let it go to waste, since unlike most of my other projects, this one has real, demonstrated use cases. I’ll think about working on it during my last months here, and either release it in a user-friendly form if I think I can handle the support or find a successor / publish the source code on github before leaving. What do you think ?

Project: Pong Fight

Pong Fight (named like that because it was supposed to be AI vs AI) is a Java pong remake that I made during my sophomore year.

Part of our exams included creating 5 mini-projects illustrating the different skills that we acquired during the two years of our programme, including object-oriented programming, imperative programming, database integration, GUI-making and so forth. Most people made simple CRUD applications, and indeed this was the case of two of my 5 projects. The others included a very simple text encryption software, made 2 years earlier (thus being my first real project), and the Casio compiler that I already mentioned, which was even less completed then. And of course when I actually took the exam, the examiners, two old ladies, told me they “hadn’t time for games” and tested me on the filler CRUD software. I got a measly 13/20. What a bunch of dicks.

image du pong

A graphic designer I ain’t.

But back to Pong Fight. It was from a time where we transitioned from procedural programming to OOP, even though we used Java from the start. So yeah, for more than a year we had “static” and “public class” keywords floating around and had absolutely no idea what they did, except randomly generating errors. So when I started the project, everything was in the same class. After a while I divided it, but this was a bit like dividing the code in multiple files in C: every single var and method were static, and the whole thing was completely contrary to everything the language stand for. So when we eventually learned OOP, I tried to restructure it, but it was a massive endeavor, especially since I wasn’t exactly a Java expert then and didn’t want to destroy the project while refactoring (which I did. Multiple times).

* Handles checkbox-style menu
* @param x (int) : x position of the click event
* @param x (int) : x position of the click event
* @param size (int) : number of elements in the menu
public int checkboxMenu(int x, int y, int size) {
    for(int i = 0; i< size; i++) {
        if(x >= Main.settingsFile.getSizeX()/8 &&
           x <= Main.settingsFile.getSizeX()/8 + 40 &&
           y >= Main.settingsFile.getSizeY()/5 + i*50 &&
           y <= Main.settingsFile.getSizeY()/5 + 40 + i*50) {
             return i;

   return -1;

I made my own game “engine”, meaning that I had to reimplement everything from mouse events to menu widgets. It was fun.

The result is a bizarre accumulation of static elements, singletons and bona-fide classes and objects living in (relative) harmony. Another part of the game that was completely cobbled together was the features: at the beginning I wanted a simple pong game that two basic AIs could play together. But after a while I got caught in the project, and added player support, which meant I had to handle keyboard events. Then I added an (in-game) option panel, which meant that I had to handle mouse events and multiple screens. Then I added sounds. Then I added graphic options. Then I made it possible to resize the window. Then I added  the jewel in the crown: network support. I delved into the Socket javadoc and eventually managed to make my pong playable across two computer in our lab, and then added spectator support, so other computers could connect to a game and watch it. My fellow classmates (and more importantly, my teachers) were in awe, and I got 19/20 at our mock exam when I presented it.

Too bad I didn’t get to present it at the real thing.


Project: Casio Basic Editor

I guess most of us had one of these ridiculously outdated graphing calculators in high school or college. You know what I’m talking about: 2 colors? 64K memory? One of the handful of items that still runs on AA batteries? Yes, these ones. Now, I guess real geeks had a TI calculator of some sort, or maybe another, more street cred-worthy brand. Well, I didn’t. I had a Casio. Specifically, a Casio Graph 35+, better know in the rest of the world as a Fx-9750 Plus:

casio fx9750

Back then, "power graphic" didn't exactly mean what you'd expect.

It boasted a badass 128*64 screen, 763 features (of which I used maybe 30 in my whole education), the ability to program in a BASIC-like language, and absolutely zero computer connectivity.  It only had a proprietary socket that allowed you to connect your Fx-9750 to other Casio calculators. Like you would connect Gameboys to exchange pokemons. Only, you know, sadder.

Since then they added a USB port, so for the low price of $80, you can allow your computer to discover how it feels to be stuck in the nineties. But seriously, that would have been a great tool to export and import some of the aforementioned Casio code to a computer where you could have edited it, tested it and so forth. Sadly, nothing of the sort existed back then, so I decided that even though there was nothing I could do on the connectivity part (short of jury-rigging a usb-to-casio cable, which apparently is possible, though I wouldn’t risk it), I could try to act on the edit and test part.

So I fired up Eclipse and set to work on a Casio BASIC Editor, with a poor man’s IDE, a simplified emulator and a compiler (well, interpreter, technically). It was a fun project, but also a hard one, since I had no previous experience in compilers, languages and that sort of things. I was helped by a friend of mine, and at the end I managed to obtain something that wasn’t too shabby. I divided the application in several parts :


  • A system unit, simulating the memory and screen of the calculator,

public final static int SIZEX = 128;
public final static int SIZEY = 64;

public final static int NB_FILES = 6;
public final static int NB_LISTS = 6;

* The user has access to 60 kB of memory.
* Each number in the list represent 10 bytes of memory,
* therefore the theoretical maximum size of a list
* is 6 000 numbers.
public final static int NB_ROWS = 6000;

private int currentListFile = 1;

private Stack&lt;Double&gt; stack = new Stack&lt;Double&gt;();
private Stack textStack = new Stack();

private Vars var = new Vars();
private boolean[][] screen = new boolean[SIZEX][SIZEY];
private double[][][] lists = new double[NB_FILES][NB_LISTS][NB_ROWS];



  • A GUI, displaying the screen of the device, a code editor, and a debug console,



  • And obviously, the compilation unit.

The parsing of the code is divided in three parts. First, the code goes through a lexical analyzer that removes the syntaxic sugar and other human-friendly features to reduce the code to its basic elements.

Then, the lexed code is parsed. In my case, it was basically a large switch structure that created a tree of the program. Each instruction was turned into a class, which defined its name,  behavior during execution, and more important, the kind of data or statement that it contains. So for instance, a statement like NUMBER (representing any kind of numeric constant) can only contains a number, but a statement like PLUS contains two parameters, which can be statements too. Some statements are even more complex and involve entire blocks of instructions (IF or LOOP, for instance). Finding and parsing the parameters of each statement is thus a bit complicated, especially since there are infix, prefix and postfix operators, control structures (including GOTOs), and ambiguous statements (the “-” sign can be used both to denote a subtraction, but also to indicate a negative number). So in the end, I obtain a list of statements that contains statements that contains statements, repeated ad infinitum.

Once the list is complete, it executes it. Each statement has an exec() method that represent what it’s supposed to do. Sometime it’s assigning a variable, sometimes it’s writing to the screen, but most of the time it’s retrieving, modifying and pushing numbers from and to the memory.


Let’s take an example :

Locate 1,1,A

This code initializes the variable “A” (there is only 28 variables, A-Z and two special symbols) to 0, then increments it, then prints it on the top left corner of the screen. Once lexed, this resolve to :


Numbers and vars are encapsulated in appropriate keywords and instructions are ended by an EOL token, but it’s little more than the uppercase version of the code above. The real magic happens during the compilation:

Assign ENumber(0.0) to EVar(A)
Assign Plus
 (EVar(A), ENumber(1.0)) to EVar(A)
Locate ENumber(1.0), ENumber(1.0), EVar(A)

There are three top-level statement here: the initial assignment, that takes the number parameter and assigns it to the var parameter; the second assignment, that takes a plus parameter and assigns it to the var parameter; and the locate statement, that outputs the var parameter to the two number parameters. Note that the plus statement contains itself two parameters, the var and the number.

The code tree is then executed, which means that “0” is pushed onto the stack, then moved to the A var, the content of the A var and 1 are pushed onto the stack, they are retrieved, added, pushed to the A var, then 1, 1 and the content of the A var are pushed onto the stack, then used to write to the screen on the tile (1,1). And a beautiful “1” appear on the corner of the screen.


I didn’t finish the project, sadly. Most features are implemented, including “if” statements and some loops, but there are still a bunch of issues that need ironing out, meaning it probably won’t work as intended for anything but the most trivial bit of code. The harder part is done though, so maybe I’ll get back to it one day to finish it, or at least clean it up nicely and release the source code on github.

If you’re interested,  feel free to send me an e-mail (you’ll find it on the main site). I’ll be happy to talk about it, or about similar projects that you or others have been working on.