... 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.

Also, have a look at my book "Developer on the Stage".


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):

Posted by Steven

I worked with Java Swing for quite some time now. However Swing is said to be dead since a couple of years, it seems that nobody notified some companies about that. I don't feel a siginificant movement away from Swing. But that doesn't mean that there will be none in the next years, so it's wise to be prepared for the next iteration of de-facto-user-interface-standard. After thinking and reading about some promissing candidates, I decided to bring myself up to date with JavaFX.

Posted by Steven

Recently, I stumbled over the following code: