• Home
  • Events
  • About
  • MVC and the Brave New World of RIA

    January 28th, 2008

    Canoo’s CTO Bruno Schäffer is speaking at SD West 08 on “Design Patterns for Rich Internet Applications”.

    SD West 08

    The following blog post outlines some of the concepts that he will cover in his talk. This is part one of a series of blog posts:

    Rich Internet Applications pick up the ball where plain Web applications dropped it: they promise to bring the power of desktop applications to the Web. Desktop applications almost went out of fashion with the advent of Web applications. But most people still prefer the rich user interface (UI) and interactivity of desktop applications such as Outlook compared to their Web-based siblings such as GMail and Yahoo! Mail. In many cases the convenience of ubiquity compensates for the inferior or cumbersome user interface.

    MVC diagram

    Client-server applications with rich user interfaces first emerged at the beginning of the nineties. Usually implemented in C++ or Smalltalk, they followed a fat-client approach, the predominant client-server architecture at this time. The principal way to organize the presentation layer of such applications was the MVC model. The concept was first proposed by Trygve Reenskaug (see http://heim.ifi.uio.no/~trygver/2007/MVC_Originals.pdf) for the Smalltalk environment. As with any proven object-oriented design, MVC splits up the responsibilities of a user interface component into domain data (Model), rendering (View), and event handling (Controller). Quite often, view and controller are merged together, though.

    Today’s GUI component libraries still make use of MVC. For example, most non-trivial UI components in Swing employ some sort of MVC. However, if one tries to apply MVC to complex (form-based) applications, which is typical for desktop or Rich Internet Applications, experience shows that criteria such as clean design, maintainability, or reusability cannot be met. There are several reasons:

    1. What is the model of a form based application with a rich UI? Most developers point to the business object to be rendered in the form as the model. A form-based RIA has more model states than just the business object, though. This additional state is usually kept in the view class and increases the complexity of the view.
    2. The presentation logic of a Rich Internet Application is vastly more complex compared to a traditional Web application. The presentation logic has to deal with more events caused by extended interactivity. Another feature of RIAs is an up-to-date rendering of the presentation state. For example, UI components may be enabled/disabled or visible/invisible depending on the state of the application. This is also part of the additional model state as mentioned above. On top of that, RIAs feature instant validation (without interrupting a user’s flow of work by throwing a modal dialog into their face). This “silent” validation has to be handled (at least partly) by the presentation logic as well. Naïve design puts all of these aspects into the view class. As a result, the view class becomes overly complex, hardly reusable, and difficult to maintain.
    3. Automated testing of such view classes can only be accomplished by running the user interface. Tests are executed by triggering user events through a test tool or accessing the components through a library (e.g. Jemmy for Swing component library). This way of testing is slow and fragile: running hundreds or thousands of UI tests takes quite some time and changes to the user interface are likely to break the tests resulting in false negatives.

    As a company specializing in RIA, we have witnessed quite a few transitions from plain ugly Web applications to the brave new world of RIA. Some of our observations:

    • Typical Web developers have not heard of MVC and try to design RIAs like they would design a typical HTML application.
    • Seasoned developers who may have had some experience with fat client-server applications try to apply MVC concepts in the same way that they did in the nineties, without adapting to the new scenario.

    Both approaches have their weaknesses and lead to poor results. In part two of this blog post series – “The world needs more models” – we will discuss possible remedies to this situation.

    Part 1: MVC and the Brave New World of RIA
    Part 2: The World Needs More Models
    Part 3: A Simple View on Complex Stuff
    Part 4: Hierarchies
    Part 5: Presentation Model Framework
    Part 6: What’s Needed Besides the Presentation Model

    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

    Speaking about RIA, Groovy, Grails and WebTest

    January 28th, 2008

    I just updated the Canoo events page and would like to point you to the impressive schedule of events:

    Canoo’s CEO, Hans-Dirk Walter is presenting a one-day course on Rich Internet Applications at the ETH in Zurich, in cooperation with Prof. Dr. Donald Kossmann and Prof. Dr. Gustavo Alonso this Friday.

    Dierk König will be speaking in Denmark, the USA, Switzerland, Sweden and Germany in the next couple of months on Groovy, Grails and WebTest topics.

    Bruno Schäffer is presenting at SD West 08 in Santa Clara, California on “Design Patterns for Rich Internet Applications”.

    And we will be exhibiting at this year’s JavaOne in San Francisco from May 6 to May 9.

    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

    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!

    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

    Adobe open sources BlazeDS

    January 15th, 2008

    This has been discussed in several Flex blogs, but I thought I’d add a cross-reference here:

    Adobe has open-sourced BlazeDS.

    “BlazeDS is Adobe’s server-based Java remoting and messaging technology. Adobe had recently announced that it is contributing the proven BlazeDS technologies to the community; previously it was only available as part of Adobe LiveCycle Data Services ES.”

    This is great news for Flex developers because BlazeDS simplifies the client-server split. In addition Adobe published the AMF specification, its binary message format. Have a look at James Ward’s benchmark tool at http://www.jamesward.org/blazebench/.

    See also Ryan Stewart’s blog post on the BlazeDS announcement.

    And there are plans to develop a Flex plugin for Grails using BlazeDS.

    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

    Canoo Code Camp

    January 11th, 2008

    The second Canoo Code Camp is currently taking place somewhere in the Swiss mountains.

    Canoo Developers at Code Camp

    The Code Camp is an internal event where Canoo developers take some time to evaluate new technologies and develop project ideas. For example, at last year’s camp, we had a closer look at Java FX and developed this sample application.

    More photos are available in the Canoo photostream at Flickr.

    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

    css.php