• Home
  • Events
  • About
  • Dolphin Train Station

    April 17th, 2013

    During the 2013 Spring Canoo Code Camp Dieter and myself with a lot of support from Mittie implemented an Application which we called Dolphin Train Station.

    Use-Case

    Here is the situation: on the platforms of a train station, say Olten in Switzerland there are many departure boards informing people about trains starting from this station in the near future.

    GUI Overview

    The application implements such a departure board in form of a window with a table showing the next 5 trains. One goal was that the departure boards are displayed on a Raspberry Pi. In addition the application contains a so called admin GUI to maintain information about trains and simulate arrivals and departures of trains. The Admin GUI uses the master-detail paradigm.

    The following screenshots of the Admin GUI and the Departure Board should give you an impression on how the two GUIs look like.

    To make this post not too boring I will just describe the important things from a concept point of view.

    Project Setup

    We started with an empty directory and created the initial open dolphin project structure with the open dolphin gdt template which meant our project was up and running within minutes. As GUI technology we decided to use JavaFX and also GroovyFX to make working with JavaFX even easier.

    Admin GUI

    When the Admin GUI shows up a so called named command (COMMAND_GET_ALL_DEPARTURES) is sent to the server asking for all train departure data. The server creates presentation models (PMs) which are sent to the client by dolphin automatically.  When the PMs arrive on the client a callback is invoked so that it can bind the PMs to the table on the GUI.

    After having put the details view (which we also called editor) next to the table the goal was that it shows the data of the currently selected row in the table. Here the PMs start to shine. We simply created a separate PM which we called selectedDeparturePM.
    Note that this selectedDeparturePM is nothing visible by itself. It is simply a placeholder for the concept of the currently selected PM. Whenever the selection in the table changes the newly selected PM of the table got applied to the selectedDeparturePM.

    Then we bound the editor’s widgets to selectedDeparturePM. This means the table and the editor are completely decoupled. And if you start typing changes in the editor fields you immediately see the changes in the table while typing (that’s done by open-dolphin in the background). You could easily think of putting a second version or instance of the editor on the GUI (also bound to selectedDeparturePM) and the three views would all be in sync.

    When we noticed that the table as a widget was still too much in control we created another “invisible” PM: selectedDepartureIdPM which we bound to the table. This means whenever the selected row in the table changes selectedDepartureIdPM is adapted and vice versa. Now you will ask why is it necessary that the table listens to changes of selectedDepartureIdPM The use case for this was the undo/redo support. We wanted that a change of the selected row in the table is also undoable. Changing the selected row in the table say from row 5 to row 6 now causes a normal value change of selectedDepartureIdPM from 5 to 6. When the user presses undo selectedDepartureIdPM changes back from 6 to 5 and since the table is bound to selectedDepartureIdPM the selection of the table also changes back to row 5. Nice, isn’t it?

    And then of course we had to bind selectedDepartureIdPM to selectedDeparturePM and vice versa. This appeared like a best practice to us: views like the editor which are interested in all details of the selected PM bind to the selectedDeparturePM, those (like the master/table view) which are only interested in the id bind to the selectedDepartureIdPM. That’s all.

    Departure Board

    Now to the Departure Board. This is basically a second client to the same application. You have to know that the server side PMs of the AdminGUI and those of the Departure Board live in their own separate worlds (sessions). Also note that there is no concept of a shared PM. So if we want to show data visible on the Admin GUI on the Departure GUI you have to send the data to it. This is issued by pressing the button ‘erster Eintrag auf Abfahrtstafel’ which sends the PM’s data to the other client(s) by making use of Open Dolphin’s event bus.

    The Departure Board clients use a long polling approach to be able to display changes immedately. This means whenever the AdminGUI presses the button they new 5 records appear immediately on the Departure board. And what’s more if you change data in the editor the changes appear on the Departures board which typing. We found that quite impressing.

    During the code camp we wanted to use @hansolo_’s very nice departure board custom control on the Raspberry PI. It turned out that some adaptions have to be made first in order to make it PI ready. This is currently on the way. So for the PI we used a normal table for the time being. On the desktop we created a second version of the Departure Board using Swing as GUI technology. See for yourself how nice the result looks like:

    It was really easy to add input validation to the Editor using tags of the PM’s attributes. We also made use of tags for the labels of intput fields so that validation and labels (think of internationalization) are defined by the server.

    Altogether we were positively surprised how far we got in just a couple of days. It was a real joy to develop this application. If you’re interested you can find it on https://github.com/canoo/dolphin_train_station . The readme file appearing on the github page explains how to build and run the application.

    My personal conclusions are:

    • Using the presentation model approach with Open Dolphin is the way I want to build GUIs from now on.
    • It will be hard if I have to go back and use other paradigms now that I know how to do it right.
    Share and Enjoy: These icons link to social bookmarking sites where readers can share and discover new web pages.
    • DZone
    • Y!GG
    • Webnews
    • Digg
    • del.icio.us
    • DotNetKicks
    • Facebook
    • Google Bookmarks
    • Newsrider
    • Twitter
    • YahooBuzz

    OpenDolphin code camp

    April 16th, 2013

    SchwendenIt is now six years that Canoo developers and friends go “Canoo Camping” twice a year.
    We enjoy the break from our everyday work and explore new and exciting fields by means of
    collaborative learning by doing.

    These are the ground rules:

    • you have to be there all three days
    • we work in small groups
    • you have to present your achievements Saturday afternoon

    What happens in code camp doesn’t stay in code camp!

    This spring, we decided to work on OpenDolphin in connection with JavaFX, Raspberry Pi, and HTML5 with 10 developers in three projects.

    Canoo Campers

    Detailed blog posts about all three projects will follow and I wouldn’t want to reveal too much in advance beside that we have all been thrilled by the achievements.

    We were not surprised to see JavaFX living up to its promise of allowing great user interface development from desktop down to small embedded devices. It worked like a charm.
    The cool thing was to hook these user interfaces up with OpenDolphin presentation models and to control the application from a remote server – even synchronizing the views.

    We were able to extend OpenDolphin’s reach to multi-client / multi-channel HTML5 applications working in perfect harmony with JavaFX views, which triggered a bit of discussion on Google+.

    Most of all, the OpenDolphin approach passed a most scrutinizing test: being used in anger by a Canoo team. We identified a few possibilities for improvement along the way but the general assessment concluded that OpenDolphin was

    dolphin- “quick to get into” in a day or so
    - “made from a few simple, reliable concepts”
    - “versatile and powerful”
    - “the best way to structure UIs”.

    Even advanced tasks like supporting reliable undo/redo (even rollback of selections) and scaffolding complex forms with three lines of code suddenly became possible in this very short time frame.

    You bet that beside the exciting work – which sometimes almost led us to being late for the delicious catering – we had a tremendous amount of fun.
    Late in the night, we even defined a new software development methodology:
    beer programming.

    beer programming

    Stay tuned!
    There is more to come soon.

    Share and Enjoy: These icons link to social bookmarking sites where readers can share and discover new web pages.
    • DZone
    • Y!GG
    • Webnews
    • Digg
    • del.icio.us
    • DotNetKicks
    • Facebook
    • Google Bookmarks
    • Newsrider
    • Twitter
    • YahooBuzz

    JUGS Event – Talk Open Dolphin | Apr 30, 2013 | Basel

    April 12th, 2013
    Open Dolphin was first announced by Canoo at the JavaOne keynote 2012. Those for whom San Francisco was too far to travel, however, now have the chance to find out more about the open source project at the end of April right on our doorstep. Dierk König will be providing a fascinating insight into the concept and architecture of Open Dolphin at the JUGS Event in Basel. Be sure to be there!
    Share and Enjoy: These icons link to social bookmarking sites where readers can share and discover new web pages.
    • DZone
    • Y!GG
    • Webnews
    • Digg
    • del.icio.us
    • DotNetKicks
    • Facebook
    • Google Bookmarks
    • Newsrider
    • Twitter
    • YahooBuzz

    No end to the mobile hype

    March 22nd, 2013

    The topic mobile is on everyone’s lips – indeed throughput the year! The MobileTech Conference is therefore the biannual venue for captivated visitors. Following the successful spring edition in Munich, preparations are now in full swing for its autumn counterpart.
    Andreas Hölzl was a speaker at the conference and presented concepts in his talk “Andriod-UIs für alle(s)” for the efficient realization of user interfaces for all conceivable Android-smartphones and tablets. On the conference sidelines, Claudia Fröhling invited the mobile expert for an interview and chatted with him about mobile business apps, Wikihood and tablet UIs. The main message was: due to the expanding bandwidth of mobile end devices, platform-independent mobile development expertise is in demand as never before.

    Share and Enjoy: These icons link to social bookmarking sites where readers can share and discover new web pages.
    • DZone
    • Y!GG
    • Webnews
    • Digg
    • del.icio.us
    • DotNetKicks
    • Facebook
    • Google Bookmarks
    • Newsrider
    • Twitter
    • YahooBuzz

    JavaFX Abacus Tutorial, Part VII – proper structure with OpenDolphin

    March 3rd, 2013

    This is the seventh part of a basic tutorial on JavaFX. The other parts can be found here and the code is on github. The running example of the tutorial is to build an abacus. If you are curious how the final solution will look like, please
    have look at this 7 min video.

    Until part six, we have developed a nice-looking and basically functional abacus. It isn’t yet fully functional since the overflow rule is missing: when pushing balls to right and we come to the last available ball, we must push all balls on the current rail back to the left and add a ball in the rail above. You can see this effect in the video around the 1:50 timestamp. We could do this work just as manually as one does it with a physical abacus but it would be much more convenient if the application could do it for us – imagine how much easier it would be to calculate 999’999 + 1 if we had an automatic overflow (video).

    With this new requirement we have reached the limit where it no longer feels appropriate to

    • have all view and controller logic as well as starter configuration in one class
    • have controller logic working directly on the view without any model.

    Now, we could go the route of creating model classes like Board and Rail and Ball and work with observable lists and bindable properties (and I advice you give this approach a try) but that would mean that we model the domain while at the same time we make the domain aware of the view’s presentation technology (because of all the additional observable/bindable work).
    Let’s go for different approach, where we use presentation models with the help of OpenDolphin.

    Enter OpenDolphin

    OpenDolphin gives us a very clean structure with a clear separation of the following modules

    • client: only containing the view; depends on the view technology (JavaFX) and optionally on shared
    • server: only containing controller logic (actions), optionally depends on shared
    • shared: optionally share constants between client and server, depends on nothing
    • combined: starter configuration that depends on all the above

    There is a huge number of benefits that come with OpenDolphin but for the sake of brevity, we will only use a few of them. We can see a first obvious benefit from only looking at the dependency structure: the actions have no access to the view. The view and the view technology isn’t even on the classpath! No longer can you “accidentally” reach out from a controller onto a view. But how can an action do its work then?

    Presentation models are synchronized between client and server.
    Actions work on presentation models (CRUD operations).
    Views bind against presentation models and send commands to the controller.
    Presentation models are generic, i.e. we do not have to implement any specific class.

    Setting up

    Creating the modules and the dependencies may sound like a lot of work but there is a template that we have used to create the current codebase. The template is available from DolphinJumpStart where we used the dist/jumpstart-maven.zip, unzipped it to dolphinized, and changed the application name in the maven POMs.

    There also is a Gradle variant but if you are using Gradle, you will probably find your way around anyway.

    Abacus_Project_ViewTo get started, you best point your favorite IDE to the root pom.xml and let the IDE create a project for you.

    Tip: with multiple modules and source roots, it is often more convenient to use the “package view” (see screenshot on the right) than the classical directory view.

    Lifting the curtain

    AbacusStarter is the class with a main method that you use for starting the application. It sets up OpenDolphin with the in-memory mode since we currently run client and server in the same JVM (we can add remoting later). It also registers the AbacusDirector, which works a bit like a movie director: it tells what “actors” are in the play.

    After the setup, the AbacusStarter starts the show.

    And ” ACTION ! “

    We have two actions: the CreateBallsAction that initially creates a presentation model for each ball in the abacus, and the ToggleAction that is called when a ball is clicked.

    The gist of the CreateBallsAction creates a presentation model for each row/column combination:

    In the presentation model, we think in terms of “digits on a scale” and whether that digit is switched “on”. The view in contrast – which is only one of many possible views – uses the concept of balls sitting on a rail.

    The ToggleAction is a bit more involved as it contains two command handlers: one for toggling a digit (and its neighbors), and one for the overflow rule.

    The important point to note here is that the server knows, which ball has been touched on the client for toggling, because there is a special presentation model with the constant name PM_TOUCHED which is shared between client and server.

    The overflow rule is a value change listener on the server side that is triggered whenever a “leftmost” digit in switched to “on”.

    We get the nice effect that the overflow rule works separately from the toggling and that the proliferated overflow as in “99 + 1″ comes automatically.

    The separation of the overflow rule in this manner is not quite as easy to achieve without OpenDolphin. One has to ensure a proper sequence of events: pushing the ball to the right, moving the ball in the rail above, moving all balls in the current row to the left. It is all-too easy to fall for a “sham solution” that occasionally leaves balls in the wrong position because they are first moved left and then to the right.
    OpenDolphin guarantees a proper event sequence – even though it executes all actions asynchronously.

    Simple View

    This leaves us with the AbacusApplication JavaFX view. It has been slimmed down to the bare essentials: displaying the presentation models, calling the toggle command when needed.
    Two points are of main interest: the start method and the click handler.
    The start method now looks as follows:

    Note that we create the touchedBall presentation model on the client side and we are sending the CMD_CREATE_BALLS command to the server. Only when that command is finished, we have all necessary presentation models on the client to bind against. Therefore, we provide an OnFinishedHandler that is called when the command has finished with all newly available presentation models.

    The click handler is now registered like so:

    When a ball is clicked we first have to update the touchedBall state before we send the toggle command. Updating via apply essentially copies all values from the ballPm over to the touchedBall presentation model.

    But wait – the toggle action (see above) changes that value of the touchedBall – not of the ballPm that was copied. How is the change propagated back?
    That is because of the qualifier that we have set when creating the presentation models. This qualifier has been copied as well and when a value changes, all presentation models with the same qualifier are updated to the same value.
    Such a construction is only possible because all OpenDolphin presentation models live in a managed object space. OpenDolphin is always in total control of all presentation models, can retrieve them by id or other features, and cares for consistent updates.

    Finally

    This has of course only been a short introduction to OpenDolphin – or better not an introduction at all but a very special use case that can only show a very small fraction of its capabilities.
    I hope you found it useful and it made you curious to find out more.

    I planned this series to have 7 posts, which means we have now completed the curriculum. Congratulations!

    However, our final solution is so versatile, it would be a shame not to make use of it.
    It is has become simple to test the application logic (set/assert the presentation models), use other number systems (binary abacus anyone?), or make more use of cool JavaFX features to dramatically change the visual representation by solely changing the view. So don’t be surprised if you hear about post (8/7) in the near future.

    Please send me your questions/ideas/suggestions on twitter
    @mittie

    Share and Enjoy: These icons link to social bookmarking sites where readers can share and discover new web pages.
    • DZone
    • Y!GG
    • Webnews
    • Digg
    • del.icio.us
    • DotNetKicks
    • Facebook
    • Google Bookmarks
    • Newsrider
    • Twitter
    • YahooBuzz

    css.php