• Home
  • About
  • Sample Apps
  • Canoo.net Talk at BlogCamp Switzerland

    September 9th, 2008

    Stephan Gillmeier and I attended the recent BlogCamp in Zürich, Switzerland.

    Stephan presents the Canoo.net blog

    Stephan Gillmeier presented an excellent talk on Canoo’s German language blog “Fragen Sie Dr. Bopp” (in English “Ask Dr. Bopp”):

    www.canoo.net/blog

    This is where Canoo’s chief linguist Dr. Stephan Bopp publishes some of the questions we receive at www.canoo.net.

    As a special highlight, Stephan Gillmeier revealed one of his plans for Canoo.net:

    Look up German words from your iPhone

    An iPhone application to look up words on Canoo.net.


    Canoo @ Jazoon

    June 13th, 2008

    Here’s an overview of the technical sessions that Canoo will be presenting at this year’s Jazoon from 23rd to 26th June, 2008 in Zürich.

    Sibylle Peter and Dieter Holz are presenting “Why RIA is not only about technology”. See also my recent write-up.

    Canoo CTO Bruno Schaeffer is presenting “Against all odds - efficient Rich GUI development in Java” together with Christoph Henrici and Daniel Buffet.

    Dierk Koenig is presenting two talks:
    “Grails: all you need for Java Enterprise webapps”
    and “Automated functional testing of web applications” .

    Andreas Hoelzl and Christian Stettler are presenting a talk on RIA for mobile devices, “Google Android and developer expectations: a ‘real world’ report”.


    29th May: JUGS Event on RIA for Mobile Devices

    May 19th, 2008

    Canoo and Java User Group Switzerland are organizing an event on Rich Internet Applications for mobile devices on 29th May at the Technopark in Zurich.

    Canoo’s Dierk Koenig will present a talk on “Going Mobile with JavaFX Script, Groovy and Google Android“:

    Since the 2007 JavaOne conference, the JavaFX Script technology-based application MusicPinboard has been justifiably cited by many (including Sun) as a significant demonstration of the power of JavaFX Script technology as well as a radical improvement over Java technology in terms of developer productivity.

    One year on, Dierk König shares his thoughts about what kind of audience JavaFX Script technology is likely appeal to, today and in the future. In addition, he offers objective comparisons with some rising competitors in what he calls the RIA/mobile space:

    • Groovy, which has in recent months encroached on the JavaFX Script technology space by including a data binding mechanism as part of its Swing GUI Builder
    • Google’s prototype Android platform, which the global giant hopes to position as the platform of choice for providers of high-end mobile device and business applications alike

    Dierk contends that each of the solutions described embodies a different vision of how the mobile experience will evolve in the near future and that the time frame may be shorter than we think when it comes to seeing which technology gains the upper hand.

    Dierk recently presented this talk at JavaOne 2008 together with Mike Mannion. If you’re based in Switzerland, this is your chance to hear the talk.

    The second talk will focus on Google Android. Markus Pilz and Peter Wlodarczak of Greenliff will provide an overview of the Android GUI framework and show a short sample how to write and configure phone GUIs with it.

    Android provides a nearly complete JDK 1.5 class library. However, AWT is only partial supported, and Swing is not supported at all. Instead, Android introduces its own GUI framework with Screens, Views and its own widget set, which nicely integrates with the Android application live cycle which is based on Activities, Intents, Providers and Services. Mobile application development is made easy through very simple reuse of existing Activities, Providers and Services. Full XML-based GUI layout allows dealing with different screens sizes and color depths without development know-how. Contrary to other mobile platforms like the iPhone, Android has been designed as an open platform for software development and doesn’t have many of the limitations i. e. JME has.

    Event details

    Program:

    17:00 - 17:50: Talk: Going Mobile with JavaFX Script, Groovy and Google Android incl. Q/A
    17:50 - 18:00: Break
    18:00 - 18:50: Talk: The Android GUI Framework incl. Q/A

    At: Technopark, Technopark 1, Zurich, Switzerland

    How to get there: PDF or .html


    Sun asks for a repeat performance!

    May 9th, 2008

    Fun and great feedback following Mike and Dierk’s talk at JavaOne; Sun asks for a repeat performance!

    As previously announced, Dierk and I held a talk at JavaOne today (actually Dierk held no less than TWO talks - there’s just no stopping this guy!) The title of our over-subscribed session was “Going Mobile with JavaFX Script Technology, Groovy and Google Android” and in addition to an eager and informed public, we were honoured to have some of JavaFX’s and Android’s champions and contributors in the audience.

    We took the first few moments of the session to emphasize one of Canoo’s core value propositions: The discernment of hyperbole from reality. Indeed, much of my part of the talk concerned the current
    status of JavaFX Script (scheduled official release in June 08) and how it does not (yet) live up to many of the claims being made about it.

    Unsurprisingly, our statements concerning the immature status of functionality and tooling in JFX were not met with silence. And in a delightfully spontaneous moment at the end of the talk we invited
    James Weaver to join us on stage for what amounted to a mini panel session.

    James’ main point was that JFX makes rich client development significantly easier than, say, with Swing, and that this can only be good for the Java platform. Of course, we don’t disagree with this
    statement. But where differences in opinion remain is (a) in the use of the word “significantly”; and (b) in our level of confidence regarding whether or not JavaFX Script will succeed in a market, where
    competition is tough, well-established, and only getting tougher by the week. JFX’s current deficiencies (which we talked about in some detail) of course only reduce its chances of success.

    So what’s our primary take-home based on the feedback we got directly after the talk and at the Canoo booth? That a level-headed and unbiased opinion on a given technology is what the majority of
    conference attendees are looking for. And who are these attendees? Quite simply: Real people representing real companies who serve real customers, who nevertheless enjoy being inspired by examples from the cutting edge, such as our MusicPinboard JavaFX and Mobile Shopping Android applications.

    Finally, to top off all the great feedback, Sun asked us to repeat the session this coming Friday!!! So if you didn’t catch us the first time around, we’d be thrilled to see you in hall 302 of the Moscone Center at 13:30.

    Thanks to everyone who did attend for coming and for the positive feedback!


    Canoo session at JavaOne 2008

    April 22nd, 2008

    While Dierk König is speaking at this week’s JAX in Wiesbaden, Germany, I’m sending out an info pointing to his next session in San Francisco.

    JavaOne 2008

    Dierk König and Mike Mannion are presenting a session at JavaOne 2008 on:

    Going Mobile with JavaFX™ Script Technology, Groovy, and Google Android



    Add this session to your schedule! And stop by at the Canoo booth at booth number 429.


    Rich(Mobile) != Rich(Desktop)

    January 16th, 2008

    Shortly before the end of last year, we completed a mobile demo application, which we used to analyze and investigate the status of Rich Internet Applications (RIA) technologies for mobile devices (what we will refer to as “RIA4Mobiles” within this blog post) .

    The showcase application we developed describes the following scenario: field engineers use a mobile device to receive their daily work tasks or orders (called “mission” in our application) which they need to complete for that day and to communicate certain states such as “starting to work on mission X” or “completed mission Y” to a back office team application. The field engineer can use the mobile device to book the time spent and material used for a certain mission, so that the back office team can directly process the billing once a mission has been completed. In addition, the back office team can send “high prio” missions to a specific field engineer.

    After having a look at different architectural approaches (ranging from device-specific fat clients to browser-based generic Web applications), we decided to go with an in-between approach: a GWT application tailored for mobile devices that runs in a generic, JavaScript-enabled mobile browser and connects to a server-side service infrastructure to fetch data and post back state changes.

    For the target devices, we used a brand-new iPhone and an older iPAQ (about two years old, running Windows Mobile 2003).

    The back office application is written in server-side Java, using UltraLightClient as the RIA technology.

    Here is a screenshot of the mobile client:

    Showcase application: mobile screen

    Here is a screenshot of the corresponding back office application (click on the image to view a larger screenshot):

    Showcase application: Back office screen

    Instead of going into the gory technical details here (we will do that in a future posting), let me discuss some of the lessons learned:

    First, the approach chosen (GWT application + “Web services”) works for mobile applications. We were able to deliver the mobile application to the mobile device. Nevertheless, there are some shortcomings:

    • whereas the generic, browser-based approach supports any device that hosts an up-to-date browser (with JavaScript support enabled), it also prevents a tight integration into the device itself: the look and feel is not completely “native”, its usability may be different from the concepts known from other device-native applications, and the application shows a “low fidelity”. In addition, the reuse of existing device-specific applications such as map tools, address book or telephony application is either impossible or only achievable in a device-specific way (e.g. the iPhone supports dialing numbers from a website that are encoded as a URL with link type “tel://”, other devices may support the “callto://” link type, others may not support this functionality at all). A browser-based mobile application is somehow isolated from the device, running in its own world. This is especially irritating as two of the most current developments in the mobile world, Google’s Android and Sun’s Java FX Mobile, propagate an application model that is based on the reuse of existing applications available on the mobile device.
    • one evil thing we know from the desktop world also holds true for the mobile world: browser hell. There is no „write once, run anywhere“ (not even with GWT’s cross-browser abstraction layer). This is due to the fact that there are various different mobile browser products and versions available on the market. Some of them are state-of-the-art and support a wide set of JavaScript and CSS features, others provide no JavaScript support at all (or only a very small subset of the language). Some of the good browsers are not available for free (such as Opera Mobile). Tweaking CSS properties and pixels was part of the daily business while developing the showcase application.
    • in mobile scenarios, (bad, broken) connectivity is an important topic, and so is offline capability. Thanks to the client-side JavaScript-based approach of GWT, offline “reading” is possible to a certain extent, but modifying data offline and synchronizinig the changes back to the server has very narrow limits in a browser-based world. Typically, there is no on-device persistent storage (such as a local database) available for browser-based application, as the browser builds some kind of a sandbox for that application. Ideas and projects such as Google Gears aim to ease those limitations, but currently require the installation of additional software (i.e. a browser plugin) on the mobile device.
    • even in times with high-end mobile devices such as the iPhone, performance issues on mobile devices are ubiquitous. The rendering performance is often poor, resulting in disturbing lags when rendering large option lists or tables (on the iPAQ device, even DOM manipulations on small HTML-based tables lead to unwanted “update effects”).

    In addition to these shortcomings, rooted in the architectural approach chosen for the showcase, another thing became obvious to us: Rich(Mobile) != Rich(Desktop):

    • one important difference when it comes to “rich”, especially related to the usability aspect of richness, is the fact that on mobile devices, users do not have a mouse pointer. Mobile users use either a pen, their fingers, or a navigation button (for devices without touch screens). These facilities reduce pointing precision. There is no “mouse move” equivalent as there is no difference between moving the pointer and activating the pointer (as soon as you touch the screen, an event is triggered). This reduces the number of available gestures and thus, prevents applications from using some of this gestures for interaction (e.g. hovering effects or tooltips are normally not supported on touch screen devices due to the lack of “mouse move” events). A further effect of the reduced set of useful gestures for mobile devices and the corresponding pointing devices is that gestures often get “overloaded” (on the iPhone, for example, dragging means “scroll the web page”, and not “perform a drag and drop operation”).
    • the set of useful UI widgets is reduced as a consequence of the low-precision pointing device and the small screen size. Widgets such as spinners that allow toggling a value up and down using small arrows is not very usable on a mobile device, the same applies to scrolling in large lists (guess why the iPhone provides enhanced support for selecting a value from a combobox shown on a Web page).
    • the general layout-policy for mobile devices differs from desktop-based RIAs: whereas on desktop RIAs, layouts such as the dock layout are often used to provide as much flexibility to the user as possible and let the user choose almost any desired application with as little clicks as possible, mobile applications use a stack-based layout that limits the information displayed and the actions available to the user at a given moment. A mobile application needs to reduce the application context to the most important information and actions at any given time. This layout resembles the page-based approach of old-school Web applications that the one of modern RIAs.

    The bottom line: RIA4Mobiles developers will need to focus a lot more on usablility, device limitations and richness compared to the development of desktop RIAs in order to deliver highly usable, responsive and appealing mobile RIAs.

    All in all, RIA4Mobiles is an exciting new application area. Stay tuned to hear more about our showcase application!