... to the digital home of Steven Schwenke.

This site is supposed to be a showcase for my thoughts about software engineering, less a personal homepage. If you want to know more about me, invite me to a beer.


Posted by Steven

This week, I practiced my first architectural kata (alternative link) with my mentor Jens Schauder and my co-mentee Thomas. These katas are meant to practice the process of designing an IT system from scratch, given a specific task. Jens picked one of the tasks for me which was to design a digital UN conference system for students. This system should serve as the technical infrastructure for hosting UN gatherings via video chat as well as one-to-one-video chats between the users. News events should be created by admins and shown to the users, which are students from all over the world who aren't meant to buy new hardware to use the system. In this article, I want to describe my thoughts about the task, the process of getting to an architecture and of course my failures in this solution.

Posted by Steven

This week, I got around to adding some animation into the game and fixing a (again) thread-related bug.

Exiting the application

After playing around with the application, I noticed a problem: After a couple of executions from within eclipse, my computer got pretty slow. It turned out that after closing the application, one Java thread always stayed alive. The reason for this is my architecture. In my starting class, I called the JavaFX application as follows:

Posted by Steven

For the next iteration of my tiny game, I wanted to add some action. I decided to let resources grow on themselve: Every three seconds, a resource spawner should create one more resource. Because of the architecture of my application, I ran into some threading problems that shall be the topic for todays post.

As I wrote in a recent article of this series, the business logic of my application is separated from the Java FX user interface. This means that the reaction of a user input is determined by the classes in the business layer. Also, repeating events should be managed by the business layer and only graphically represented by JavaFX. Regarding the mentioned resource spawners, this means that the logic for the creation of new resources is stored in the business class ResourceSpawner:

Posted by Steven

A couple of days ago, I saw an interesting way to prohibit the use of a method from a superclass. A coworker of mine wrote a subclass of a JTextField that should display a date in a specific fashion. Before you comment the obvious: Yes, there where reasons not to use JFormattedTextField. ;)

Here's how he wrote the new class:

  1. public class CustomDateField extends JTextField {
  3. public void setDate(Date date) {
  4. c.setTime(date);
  5. // the real method was a bit more complicated, but for the example that is sufficient
  6. super.setText(String.valueOf(c.get(Calendar.YEAR)));
  7. }
  9. /**
  10. * @deprecated Use setDate(Date date) instead
  11. */
  12. @Deprecated
  13. @Override
  14. public void setText(String arg0) {
  15. throw new RuntimeException(
  16. "This method is not supported. Use setDate(Date date) instead.");
  17. }
  18. }
Posted by Steven

This article is part of my JavaFX Series. Get the preceding articles here.

After setting up the basic world in which the simulation takes place, I decided to tweak the user interface a little bit. As you can see below, there are context menus at the resource spawners that allow for manipulation of the radius in which new resources are being spawned. The new objects now grow into existence by using a FadeTransition and a ScaleTransition.

Get the executable jar here.

Posted by Steven

With the last post of this series, I started experimenting with JavaFX. Since then, I figured out how to separate the user interface (UI) framework from the business logic and how the life cycle of the objects should be like.

First impressions

As I explained before, I want to write a small simulation in which some civilization uses growing resources to expand. The whole idea is pretty scetchy right now, but there should be a bord on which the whole simulation takes place and the mentioned resources. Because resources don't grow on their own, there are resource spawners that can be set programmatically and appear on the UI. These things spawn new resources every time the user clicks on them. The new resources (yellow thingies) are spread in a random fashion around the spawners (grey buttons):