• Home
  • Events
  • About
  • 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.
    • email
    • Print
    • Twitter
    • LinkedIn
    • XING
    • Facebook
    • Google Bookmarks

    MobileTech Conference | Mar 11-14, 2013 | Munich

    March 14th, 2013
    When it comes to the development of sustainable mobile strategies and the development of apps on various platforms then a visit to the MobileTech Conference is a must for your 2013 todo-list. Canoo’s mobile expert Andreas Hölzl will be a speaker at the conference. In his talk “Android-UIs für alle(s)” [Android UIs for everyone & everything] he will be presenting concepts that enable the efficient realization of user interfaces for all imaginable Android smartphones and tablets. Why not pay a visit?
    Share and Enjoy: These icons link to social bookmarking sites where readers can share and discover new web pages.
    • email
    • Print
    • Twitter
    • LinkedIn
    • XING
    • Facebook
    • Google Bookmarks

    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.


    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

    Share and Enjoy: These icons link to social bookmarking sites where readers can share and discover new web pages.
    • email
    • Print
    • Twitter
    • LinkedIn
    • XING
    • Facebook
    • Google Bookmarks

    OpenDolphin 0.7 released: maven central, server events, faster

    March 1st, 2013

    dolphin logo

    The OpenDolphin team is happy to announce release 0.7, which is a major step towards 1.0 that is planned for end of march.

    First of all: OpenDolphin is now available from maven central under the group id org.open-dolphin! We have also aligned the package structure (with release 0.6) such that the former com.canoo.dolphin is now org.opendolphin to reflect the open-source nature of the project.

    With OpenDolphin being in the central maven repository, you can now simply declare a dependency and use Maven or Gradle or @Grab to build your dolphin-enabled application.
    If you need any advice on how to best structure your application and get your feet wet with OpenDolphin, there is now a special JumpStartProject for the pure Java, Maven, JavaFX setup. A second variant is available for doing the same with Gradle.

    In terms of new capabilities in this release, one stands out from all others: server side events.
    Any asynchronous event that happens on the server side can now instantly be displayed by the dolphin client – and consistently across many clients. Think of your server being notified via JMS or receiving Hibernate events. Dolphin introduced a server-side event bus that can be notified asynchronously from any event source and dolphin actions can subscribe to
    receive these events. There is of course a demo for this capability in the code base and even a video on youtube to show the effect.

    But dolphin actions can also be event sources themselves, effectively allowing cross-client synchronization via the server.
    Another youtube video demonstrates instant cross-client updates.

    More demos have been added and updated. Please check out the release notes since version 0.5.

    Last not least, we did some profiling and performance testing along with a few selective optimizations.
    Even though we consider optimization work a post-1.0 activity, these few changes made our dolphin swim 60% faster!

    We hope that you will like the 0.7 release and we are happy receive any feedback.

    The Happy Dolphin

    Share and Enjoy: These icons link to social bookmarking sites where readers can share and discover new web pages.
    • email
    • Print
    • Twitter
    • LinkedIn
    • XING
    • Facebook
    • Google Bookmarks