• Home
  • Events
  • About
  • GWT and HTML5 Canvas, the future of the web?

    August 25th, 2011

    The future of computing lies in mobile computing, more and more devices come on the market, tablets and phones that will connect through the Internet as technology is getting cheaper and wifi and 3g more common. That means our software will also need to run on these handheld devices, because our clients will want their services on all platforms. This is what Java set out to do 15 years ago, so that we have the ability to write software once and run it everywhere. The problem is these new platforms, that I believe will make up a large part of the future have, until now, no Java. It would be great if we can find something that will give us the ability to write our software only once.

    I believe that the technology that is going to deliver us this promise is called HTML5. More and more applications will run inside you browser. I’m typing this article in google docs, which is a perfect example of how applications will evolve. No need to install anything or maintain up to date versions, even an operating system could be very minimalistic (google chrome). So Google is obviously sharing this vision, but also Microsoft is building it’s next version of office on something that is based on their web-browser.

    Sadly the development language of HTML5 Javascript and not Java. Java has been around a long time and there are a lot of libraries that people have made. Would be cool if we can still use these, the answer is Googles Web Toolkit. GWT provides a way to code in Java and then translate that code into Javascript. This way we can still use all that great stuff that others made.

    A good example of this future is Angry Birds, you have probably heard of this game. To create this game they have taken the java implementation of box2d called jbox2d and created a javascript version of that with the help of GWT. Once that is done you can use HTML5 Canvas to draw the Birds and calculate their positions if they are falling. Now because they have build it this way with HTML5 this game could also work on an iPhone, but even better because android is based on java you could create from this source a android version with only one line of code.

    Have a look at some of the great things people are building with the HTML5, be sure that your browser supports it.

    1. Drawing program deviantART
    2. Old style game with new technology area5
    3. Quake GWT HTML5 port

    Maintenance Release Canoo RIA Suite ULC Update 1

    October 1st, 2010

    We are pleased to announce that the maintenance release
    Canoo RIA Suite ULC Update 1 is now available for download !

    This is a maintenance release for the Canoo RIA Suite.
    Besides many bug fixes and improvements it includes

    – Builtin animations for ULCLabel, ULCScrollPane,
    ULCSplitPane and ULCInternalFrame
    – Radial Gradient Paints

    Please see the release notes for the complete list of
    implemented feature requests and fixed problem reports.

    And don’t miss the demos.

    Please note: the ULC Core license key and any ULC Package license key
    are valid for all releases labeled Canoo RIA Suite ULC. If you already have
    any Canoo RIA Suite license key, no new license key is required.


    Juggling with DLLs, WebStart and Maven

    May 6th, 2010

    Juggling with DLLs, WebStart and Maven

    Recently we were asked to implement a Drag & Drop mechanism between Microsoft Outlook and a Java based internet application. This necessitated our Java server having to communicate with COM objects on the client side. How do you do that?

    The good thing is that our application was built using UltraLightClient, so we had java on both the server and on the client side. And after some thinking, the steps seemed pretty clear, even if a tiny bit of juggling would be required. However, the juggle almost turned into a struggle when we encountered some unexpected pitfalls.

    In this blog I will give a quick sketch of our solution and point out some of the traps to be aware of.

    Step 1: Talking COM using JACOB

    In order to communicate with Microsoft programs from Java you need a Java COM Bridge.
    We were using JACOB and it was surprisingly easy to extract Outlook mails into Java objects.

    The idea:
    The following method extracts the selected outlook mails to a directory and returns the list of created files:

    The trap:
    Using the email subject as a file name is practical, but it can contain many weird characters which may not be supported when the files are created. We found out that JACOB has problems creating files containing even characters like “:” and “,”. Furthermore, no exception is thrown, although the file fails to be created completely.

    The solution:
    Replace potentially dangerous characters with something neutral using regular expressions:

    To be on the safe side we were using a whitelist approach. We treat everything as invalid except for characters which are listed after the “^” character.

    Step 2: Shipping a DLL with Webstart

    JACOB can talk to Outlook because it comes with a DLL which has to be present in the classpath. This means we either have to ensure that all our users have this library installed (yikes!) or we ship it together with the application client using Java Webstart.

    The idea:
    We include the DLL in the jar file and sign it with a valid certificate. Then it can be referenced from the JNLP file that launches your web application:

    The trap:
    We were using the optional parameter download=”lazy” to ensure that the library is only downloaded when it is really needed. The result was that it never got loaded at all(!) because we did not specify to which “part” the library belongs. This is another optional parameter which turns mandatory in combination with download=”lazy”.
    Unfortunately this little detail is not too well documented. The only hint found was this one (in german). It took me quite some time to find this critical information.

    The solution:
    Since the jar containing our DLL is really small we chose to use download=”eager” (which is the default anyway) instead of defining “parts” in our JNLP.

    Step 3: Using native lib references with the webstart-maven-plugin

    We already were using Maven as a build system and our client distribution is generated with the webstart-maven-plugin as follows:
    – We use a separate module with packaging type “pom” for the generation of the webstart client. Of course, this module is part of the multi module build for our application.
    – We provide a template for the JNLP file containing a parameter “$dependencies” which will be replaced by a list of the dependencies of the current module
    – At build time the dependencies will be signed and put into a zip file together with the JNLP file.
    – The zip file can be extracted to a java webstart server or, in our case, into a war file that will be deployed on a server.

    The idea:
    Since JACOB is available via Maven Central integration seemed pretty easy. We only have to generate the correct reference to the native library.

    The trap:
    Unfortunately the current version of the webstart-maven-plugin (1.0-alpha-2) does not support native libs (open issue). So we will need a workaround that wraps the jacob.dll into a jar file and generates the nativelib reference in our JNLP.

    The solution:
    Perform the following steps:
    – Change the packaging type for the module from “pom” to “jar”.
    – Configure the pom.xml to copy jacob.dll from the maven repository into the build directory of the module using the maven-dependency-plugin
    – Add the nativelib reference to the velocity template using the build artifact of the current module as a reference.

    Summary:

    After successfully having avoided the traps (okay: by stepping into them and finding a way out again) we got an application with a pretty cool feature integrated seamlessly in our build process. Nice!


    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.


    css.php