In the previous example, we used Lemonade to create a simple service that provides transfer functionality. Probably, many of readers have wondered: "Why do I need Lemonade? I could do the same in pure Java - faster, easier, without the limitations of Lemonade and without the need to learn a new technology."

That was true for the first two examples. However, the next three examples demonstrate the unique value that Lemonade brings to mobile solutions. The application developed through these there examples cannot be easily created in pure Java nor as WAP or XHTML services. It takes a technology like Lemonade to create such an extensible, pluggable service.

You can run this example on your mobile phone by visiting the WAP site lemonade.e-marson.com and choosing 'moBank'.

With Bluelemon you, the service provider, can manage functionality of the MIDlet installed on the customer's mobile phone. This makes it possible to design an architecture implemented in this example, in which:

• The customer downloads and installs a MIDlet that contains the functionality to connect to a single point of access to the services being delivered by the organization,
• When the MIDlet connects to the point of access, a server side manager queries all available services for updates that need to be made to the permanent state of customer's MIDlet. Every service can send a Bluelemon instruction that updates the MIDlet's permanent memory. It could update data in the MIDlet or add new features to it, that will be available whenever the user runs the application - even in offline mode.

The organization can add new services at any time. New services will update the customer's MIDlet when it connects to the server - even if they were added after the customer downloaded the MIDlet.

In this example we will deliver three banking services to users:

• moAccount
  A service seen in the previous example that provides transfer functionality. Upon the first "Update" operation the server-side controller that is responsible for service management will request that the necessary functionality is installed in the user's application. The MIDlet's main menu will be updated to include a "moAccount" option.
  Once this feature is installed, the user can perform transfers and track account balance through this option.
• moCheers
  An example of a service that adds trivial functionality to the user's MIDlet upon the "Update" operation.
  Unlike moAccount, which required an Internet connection for some operations, this service, once installed in the MIDlet, works completely offline.
• moNews
  A service which does not alter the MIDlet's permanent state. It uses "update info screen" (a screen that is displayed to the user after each update operation) to display a news flash.
  The demo logic displays a news flash upon every third "Update" operation.

This and the next scenarios demonstrates how this architecture works in a "pull" model - the user updates the MIDlet by activating the "Update" option.
The third scenario shows how this architecture can be deployed in a "push" model where the MIDlet state is updated by sending a special binary SMS message (we call it a Blue SMS message).

1. moBank

The main functionality, that is initially installed in the MIDlet, which lets the user log in and perform the update.

Initially, the startup instruction will AuthenticationScreen: an instruction that displays a form with two text input fields for user id and password. The entered data is sent to a process that performs the authentication.

If the user id or password is wrong, the process returns an AuthenticationFailed instruction displays AuthenticationScreen again and shows an error alert. If the authentication succeeds, the user id is saved, the STARTUP_INSTRUCTION is updated and the MainScreen is displayed.

MainScreen is an instruction that displays a choice list. Initially the list only contains one option "Update...". When this item is activated, the application calls a process that checks if there are any pending updates for the application.

If there are no updates, the NoUpdateIsRequired instruction is called, which displays MainScreen and shows an information alert. If there are any updates, UpdateIsRequired is called which in turn executes all received update operations and displays an update summary screen.

2. moAccount

The functional diagram for moAccount is identical to that shown in second example, only the meaning of "Exit" instruction is different: instead of closing the MIDlet it calls MainScreen from package "mobank".

3. moCheers

MoCheers provides trivial functionality that works offline in the MIDlet. Two instructions display greetings and the user can navigate between them.

4. moNews

MoNews service does not install any functionality in the MIDlet. It just sends a text that is displayed once in the update info screen.

1. moBank

The following diagram shows that authentication and update processes will be implemented as network processes.

The core instructions are delivered in the package "mobank". The package also contains two instructions, InitializeDownloading and FinalizeDownloading, which provide custom "linking code" for associations to network processes.

2. moAccount

The location diagram for moAccount is nearly identical to that seen in the second example. The only difference is in the custom implementation of network call - here InitializeDownloading and FinalizeDownloading are used.

3. moCheers

Both instructions are placed inside one package.

We need one URL mapping and three installers:

• one for the main moBank service - it will be wrapped in a MIDlet,
• for moAccount and moCheers - these will delivered to the user by controllers responsible for these two services on the server side.

Installer for moBank:

• name:
  com/emarson/lemonade/examples/mobank/ _deployment/Installer
• pre-install instruction:
  no
• packages installation:
  install 'com/emarson/lemonade/examples/mobank' package
• 'permanent' and 'session' updates:
  STARTUP_INSTRUCTION = call AuthenticationScreen
• post-install instruction:
  call AuthenticationScreen

Installer for moAccount:

• name:
  com/emarson/lemonade/examples/mobank/ _deployment/InstallerMoAccount
• pre-install instruction:
  no
• packages installation:
  install 'com/emarson/lemonade/examples/mobank/moaccount' package
• 'permanent' and 'session' updates:
  update mobank's MenuOptions to contain 'moAccount'
  add message to the update info screen: "moAccount service is now available."
• post-install instruction:
  no

Installer for moCheers:

• name:
  com/emarson/lemonade/examples/mobank/ _deployment/InstallerMoCheers
• pre-install instruction:
  no
• packages installation:
  install 'com/emarson/lemonade/examples/mobank/moacheers' package
• 'permanent' and 'session' updates:
  update mobank's MenuOptions to contain 'moCheers'
  add message to the update info screen: "moCheers service has been installed - enjoy!"
• post-install instruction:
  no

URL mapping for moBank:

• name:
  mobankMapping
• URL:
  /mobank.jar
• mapping type:
  MIDlet
• installer to use:
  com/emarson/lemonade/examples/mobank/ _deployment/Installer
• package:
  midlet
• MIDlet name:
  mobank
• MIDlet description:
  mobank example application
• MIDlet version:
  1.0
• MIDlet vendor:
  E-MARSON

Take a look at all the s'N's processes for this example >>>