• Home
  • Events
  • About
  • Canoo RIA Suite 2014 Update 3 available

    March 23rd, 2016

    Canoo RIASuite team is pleased to announce that Canoo RIA-Suite 2014 Update 3 (v 8.0.3) is now available for download from http://ulc.canoo.com/downloads/index.html.

    This is a minor release. It includes some bug fixes and feature requests.

    Please see the release notes http://ulc.canoo.com/external/releasenotes.html for more details.


    AfterburnerDolphin – Effective enterprise JavaFX development

    May 17th, 2013

    OpenDolphin

    During the last JavaOne, Canoo announced the open sourcing of Dolphin.
    OpenDolphin is a library that provides a remoting solution to bridge the world of Enterprise Java and Desktop Java or other client technologies (mobile, web).

    Since then, a lot has happened around OpenDolphin and it keeps gaining more and more attention.
    For me personally, it was from the first time I heard of it a very interesting project, but due to daily business and other projects I didn’t have the time to get into it.
    Using JavaFx as the first client technology to be implemented was also a little hurdle as I haven’t done any serious work with JavaFX, yet. But now, I’ve finally found some time to play with JavaFx and OpenDolphin ;-).
    (Besides, there is an JS implementation of OpenDolphin – it proves that OpenDolphin doesn’t tie you to a client UI technology.)

    Afterburner.fx

    As I attended to Adam Bien’s Airhacks Workshops in March, he introduced the Afterburner.fx mini-framework to the audience and released it a few days later.

    Afterburner.fx is a minimalistic MVP framework for JavaFX that provides
    “Zero-Configuration” dependency injection (DI) of models and services
    and
    Convention-based unification of presenter, view, FXML and css.

    ScenceBuilder

    Thus it enables the usage of the JavaFX scene builder (a UI design tool) to implement a clear seperation of layout and logic (as the layout is encapsulted in the xml). In his talk “Enterprise JavaFX 8” Adam describes it as an implementation of “inversion of control”.
    The outcome is a very powerful set of lightweight technologies to build JavaFx applications.

    The wiring between the UI XML and the code a pretty minimal. On the one hand, in XML, you just need to define the controller class:

    And optionally, event handler methods can also be set via XML with

    In the code, the UI components get injected by the @FXML annotation and the name used as fx:id :

    Combine the power

    My idea on the moment I saw it was to bring those two projects together to benefit from the features of both projects:

    • A clean and easy way to create the UI and build up the client
    • a powerful and non the less easy to use library for client-server communication and clear speration between logic on the server-side and UI-related code on the client with open-dolphin.

    AfterburnerDolphin

    You can find the outcome of this idea at my AfterburnerDolphin project at github.

    It demonstrates the things mentioned above:

    client structure

    In the client module, you can find a clearly structured app, the design and layout clearly seperated (as extracted to xml and css files) from the logic (look at the App class and the DemoPresenter).

    It’s all tied together via DI and convention-based confguration of afterburner.fx .

    The client creates a PresentationModel and binds the button text value to the value of that model.
    (DemoPresenter, Line 43)

    On a button click, the client communicates via OpenDolphin with the server (server module, ApplicationAction) where the command for a new value (current date) of the presentation model’s attribute is created and send as a response.

    (ApplicationAction, Line 17)

    That demonstrates how easy this set of technologies lets you set up a well structured multi-tier application 😉 and implement a roundtrip between client and server.

    Any business logic can be handled on the server, the client only need to implement the presentation. And the implementation and maintenance of the client UI is eased up by the clear structure implemented with the help of afterburner.fx .

    The UI of this sample application is very simple, as you can see from the screen shot – before and after click on the button. The date used as die new button text is set on server side.

    demo-beforeclickdemo-afterclick

    Conclusion

    I think, the combination of AfterBurner.fx and OpenDolphin provides a very powerful featureset.
    At first, it’s easy and quick to setup and design UI Layout with Scence Builder.
    After that, AfterBurner.fx and OpenDolphin allow you to build an application with clear, distinct seperation between layers:

    • UI layout (in XML)
    • UI logic (in client code)
    • Business Logic (and more) (in server code)

    You can be up and running very quickly with a short time to initiate application development. With the clear seperation, I would expected the setup to provide the foundation for a very maintainable project.
    And with OpenDolphin you protect your investment as you can very quickly provide an multi-channel application (providing an mobile app UI based on the already developed server code) or switch to another UI technology and reuse the business logic implemented on server side.

    Further steps

    Fork AfterburnerDolphin on github.

    Find out more about Afterburner.fx, visit the Afterburner.fx Homepage.

    Get more information on OpenDolphin with the OpenDolphin documentation.
    Or look at the OpenDolphin videos on youtube.


    Java Business RIA redefined!

    May 2nd, 2010

    The future belongs to Rich Internet Applications (RIA) – they are increasingly replacing the classical desktop application. And it is no wonder, as this latest generation of web applications offers a totally new kind of interactivity. Furthermore, RIAs spare your budget thanks to their operating system independence and the fact that they can be used without installation. According to the market research organization Forrester Research, RIA technology will be deployed in around 60% of all software development projects in the coming years.

    RIAbox_middle

    The disadvantage of most of today’s RIA frameworks is that they were developed for the optimization of web sites. They rapidly reach their limits, therefore, with complex business applications. Canoo Engineering’s Canoo RIA Suite with its modular design provides a remedy. It’s heart is ULC (UltraLightClient), a proven and stable component for the development of RIAs – optimized for the performance requirements of business applications. Thanks to the 100% java-based homogeneous programming model, ULC reduces the complexity of RIA projects to a minimum. RIAs developed with ULC score highly due to their low development and maintenance costs, and are more than a match for classical desktop applications in user-friendliness, functionality, attractiveness, robustness and performance.

    Since March 31, 2010, ULC Core is available as a Beta Release. The Canoo Ria Suite will be released officially just before Pentecost 2010. The advantages at a Glance:

    • Up to 50% reductions in development costs
    • Puts business functionality on to the web without quality losses
    • Lower operational costs thanks to server side maintenance and standardized technology
    • Maximum security thanks to standard conformity
    • Straightforward and rapid development due to uniform Java basis
    • Robust and scalable architecture
    • No longer time-consuming client-side deployment
    • Enables highly interactive and user friendly interfaces
    • No browser adaptation required
    • Optimal user productivity due to rapid response times
    • Lower project risk thanks to well engineered, tried and tested technology
    • Impressive prototypes in minimal time

    “We switched to ULC in the middle of a large software project, as we were not able to implement all the requirements with the technology we were using at the time. ULC then enabled us to at least double our productivity, in turn allowing the project to be completed on time.”

    Greg Hutchinson, Principal Developer of a large Canadian financial institution


    What RIA developers could learn from the iPhone

    May 1st, 2010

    The Apple iPhone, just like its bigger brother (the iPad), does not exactly shine with its universality: In the end, the technical options and the contents that may be used are determined by the parent company.

    However, it is precisely this limitation in the user and developer flexibility, in addition to the purist and inherently coherent design of the user interface that are the secret of its universal success. The user experiences a successful reduction in complexity from app to app within a homogenous user interface environment, in which he quickly finds his way around. The problem of information transport, according to media expert Neil Postman, has long been solved. Now it is about developing the right selection techniques in order to come to terms with this flood of information.

    Successful complexity reduction

    Precisely this demand is fulfilled by the in-house engineers at Apple, as well as the developers of successful programs that run on the iPhone. Now however, these inventers often are not exactly world-beaters when it comes to experience in UI design or architecture development. Rather they place themselves intuitively in the shoes of the users and ask themselves what information they would like to call up on their iPhone themselves. And Apple supports this implementation via an SDK that delivers many graphic effects and interface components out of the box. This intentional simplification of options creates a world which eases the navigation through this flood of information to such a degree that most users happily put up with any such limitations.

    Levelling the fastest routes

    What can we learn now from the iPhone phenomenon for the development of Rich Internet Applications? In production systems it is less crucial to push the limits of technical feasibility or to place emphasis on the maximum user flexibility. What counts instead is to smooth the most rapid route to the required information and functions for the users, without them having the need to deal with the intricacies of program structure. To fulfil these needs the developers need to put themselves in the users’ shoes, which is easier in the case of greatly restricted iPhone apps than with complicated web applications that quite often cover the scope of entire departments.

    In view of these over-complications it seems tempting in the initial phase of a project not to pose too many questions to the end users (or indeed one’s own intuition), but rather to proceed in the hope that people will get used to the technically more familiar structures. These are, however, shortcuts that can come with acrimonious paybacks at a later date.

    Tools that help those in charge to see things from the users’ point of view (e.g. paper prototyping) may initially appear laborious and, due to the lack of “hard” results, unnecessary. But rather than definitive guide-rails, this phase is more concerned with developing a feeling how the users’ workflows could be integrated into the future application, and to identify which paths in the current IT environment are often or only seldom trodden, so as to provide orientation for the subsequent development process.

    The goal is therefore to pick out the basic limitations and requirements for simplification right at the start of a project, so as to attain similar complexity reductions in the context of productive systems such as some successful iPhone apps demonstrate.


    GWT UiBinder: Better Web App Separation of Concerns

    April 26th, 2010

    One of the newest features introduced in Google Web Toolkit 2.0 is the “UiBinder“. This new way of building views allows the developer to use a declarative approach when doing the layout of a GWT application.

    In case you have not heard about it, GWT is a set of tools that enables Java developers to develop “rich web applications” in the Java language. The term “rich web application” implies two things:

    • Desktop-like interaction, where a user action has immediate feedback (e.g.: input validation, search box terms suggestions, results highlighting, etc) without requiring a server round-trip (executing an HTTP request with the result of reloading the page being browsed). In the world of web applications, this is typically accomplished using Ajax (what is also what GWT does).
    • An application running within a browser, but using native browser technologies (HTML, CSS and JavaScript). If we were talking about applications held in browser plug-ins and running out-of-process within their own virtual machines or by mean of run-times, I would prefer to use the more general term “rich internet applications”. These are launched from a web browser but behave as black boxes for other user agents (e.g.: web crawlers).

    GWT allows us is write Ajax-based “rich web applications” using the Java language instead of the traditional JavaScript. GWT takes your Java code and compiles into JavaScript, HTML, and CSS. So while you write the program in Java, it is translated into a traditional web application.

    Building user interfaces in GWT

    The most common approach to building desktop application interfaces is using visual components called “widgets”. For developers with Swing experience, GWT seems a marvellous step forward because it allows you to leverage most of your knowledge with far less effort than the alternatives. I say seems because this can also be of disadvantage, as I’ll show with an example.
    If we had to create a web interface for a simple web search application, the most common way of doing the interface would be an HTML form for submitting the query and an HTML list to show the results:

    In the case of GWT, a Swing developer might write widget and layout code like this:

    This approach is a valid one and, with some CSS styling, produces a neat interface, but it introduces a too complicated DOM structure that does not scale well for bigger applications:

    Compare the handcrafted HTML tags with the DOM produced using GWT widgets, and the first one is simpler. One of the reasons of the extra verbosity of the GWT one is the use of “HorizontalPanel” to layout the search box horizontally. This is a panel based in tables and it introduces a “too verbose” HTML table for the layout. In the case of a horizontal layout, we can also use a FlowPanel, altogether with some CSS styles, to avoid the search box components stacking vertically (which is the default layout for the HTML “div” elements that a “FlowPanel” produces). The problem is that this approach mixes widgets for layout with CSS for layout (not for styling) what stops being a pure widget approach.
    The next thing to notice in the DOM produced by GWT is the excessive presence of GWT CSS classes (e.g.: “gwt-Label”, “gwt-TextBox”). While they are most times useful when it comes to style the widgets, they are many times not used or they do not fit always our CSS selectors strategy.
    Lastly, there is a lack of HTML semantics in the DOM produced by GWT. Almost every element is a “div”. From the point of view of web standards, it is much more convenient to use an HTML list for the results as it is to use a collection of “div” elements. Producing HTML labels associated with form fields (search box label) is also a usability and accessibility improvement. Using tables for layout should be avoided.
    For a real-world application that use input fields, trees, tables, “tab panels” or splitters, etc… all in the same screen, it is a good practice to get rid of the intermediate superfluous DOM elements. It reduces drastically the amount of “glue” elements, making the DOM much more compact and faster to modify. We should avoid “glue” and automatic generated code, because it needs to be compiled, loaded, executed and maintained. In the case of an overly verbose DOM structure, CSS issues may appear because of the complex structure interactions. Fixing them is akin to fixing bugs in generated code: very difficult!

    Mixing HTML and Widgets

    So how can we mix widgets and html properly? Before GWT version 2.0, the most common way was to use “RootPanel.get(‘someId’)” to access an HTML element in the application host page, and then create an object there to attach the widgets to (ie. a “RootPanel”). If we need to embed only a few widgets in the host page, this technique suffices. But doing this in a real application with a large number of widgets becomes complex and slow.
    UiBinder scales better because it does not inject widgets into the HTML of the host page. Instead, you declare your layout in a stand-alone HTML file that can be composed with other components as many times as necessary to build more complex interfaces. Composition entails componentization, allowing the developer to create subparts of the user interface (UI components) that can be packaged, re-used and tested in isolation.
    But let us see how with an example:

    Our example has been split into three files: the first one is the GWT entry point, that now only instantiates and inserts our new UI component at the interface top level. The second is an XML file representing the view and is required by UiBinder to act as a mark-up template. The third is the Java class implementing the component logic (that as of now is almost non-existent) and invoking UiBinder.
    If you run this code so far, you will notice that now the appearance is exactly the same as in the handcrafted HTML and that there is not yet real integration between the view of the component (mark-up template) and the logic of the component (Java class). Let us fix this by substituting the HTML input field with a GWT “TextBox”:

    Notice the changes in the template where the HTML input field has been substituted by “” and also the little change in the Java class that now has a field of type “TextBox” annotated with “UiField”. When the Java class is instantiated, the UiBinder creates and injects the “TextBox” using the matching field name and “ui:field” attribute. The result is almost the same DOM structure with only some extra attribute values generated by GWT. Note that we also eliminated the “id” HTML attribute. This last change is because of a current limitation in UiBinder which does not allow defining both attributes in the same element. This issue can be solved setting the id attribute in the constructor after the UiBinder has been invoked.
    As next step, let us now integrate the results list by writing out some simple HTML list elements:

    The changes in the UI Binder template is almost the same as the previous one with a subtle difference: in the previous step, we integrated a GWT widget (“TextBox”) replacing the HTML input element. In this second case, we performed a to “bind” the “ul” HTML element from the view because there is no GWT list widget that matches a simple HTML list. Instead of using the API of a GWT widget, we are using the GWT DOM API to directly modify it.

    Adding behaviour

    Let us now go back to the first GWT approach and modify it to create the results when clicking the button. This is what your pre-UiBinder code might look like:

    Here we introduced a “ClickHandler” that modifies the results container with some fake ones when the search button is clicked.
    Doing the same with the UiBinder approach results on the following code:

    We introduced a “Button” GWT widget in the mark-up template together with its corresponding field in the Java class. We also moved the code creating the results to its own method annotated with “UiHandler” (take into account that the signature must be compatible with a “ClickHandler”). Finally, we removed the “form” element from the mark-up (which is not required at all in an Ajax application).
    One of the core design principles in the development world is the benefits of separating logic and presentation. What would happen if now we wanted to change the place where the results appear in relation to the search box? Or, if we wanted to get rid of the “Results:” label because it is not necessary? In the first GWT approach taken, the way in which the widgets are created and nested is reflected in the Java code together with our logic, making necessary changes to this code. Also “static” presentational elements, like the “Results:” label, are embedded in the code where. Applying the separation of concerns principle tells us that they do not belong there. Making a change to either presentation or logic necessarily requires changing both presentation and logic. In the “UiBinder” approach, because of its inherent separation of concerns, these changes would happen only in the mark-up template or in the domain logic, not in both.

    Conclusions

    • When building a web application, no matter which framework you use, never forget that you are still using HTML, CSS and JavaScript. The simpler the DOM produced, the faster the application will perform and the less CSS issues you will find.
    • Web applications have web pages! Always try to use the most semantic HTML structure you can. It improves SEO, usability and accessibility and usually produces compact DOM structures.
    • Even when you program in your favourite language and do everything in code by mean of widgets, do not forget the advantages of principles like presentation and logic separation. Using UiBinder in GWT produces twice the number of files but each is simpler, cleaner, easy to manage, and easier to maintain.
    • With presentation separation, you can let your design team produce a HTML prototype of the different parts of your application that can be easily reused afterwards or even in parallel. Two teams being able to work in parallel reduces the project time span and using prototypes reduces the project risks.
    • Because different tasks require different skills, let the developers code and the designers deal with HTML and CSS. They all will be much happier and the application will be and look much better.

    css.php