Desktop Client

Requires Platform 4.2+

Desktop client functionality allows you to create web applications that you package with an installer and install to the desktop. You can develop a desktop client application to communicate with the server with whatever frequency you find most appropriate and to switch from online to offline while running. The programming model remains consistent across modes (online/offline) and the desktop client redirects the APIs used to access remote resources to access resources locally when offline – providing a very clear path to creating occasionally connected applications.

Desktop client applications can auto-upgrade without additional effort. Whenever new versions of either the Nexaweb components or end user built components are available on the server, the desktop client application will alert the user that an update is available, automatically download the update, and restart the application.

Images

The desktop client includes the images described in the following table:

Desktop Client ImageDescription
InstallImage installed on user's system
Webapp

Server side web application.

Desktop Client Install Image

The install image for the desktop client is what the user must install to run the desktop client.

 /INSTALL_DIRECTORY
   nexaweb-desktop-client.launcher.jar
   /Nexaweb
      /client
         /desktopclient
            /0.0.0.0
               nexaweb-desktop-client.jar
   /Applications
      /APP_NAME
         version.txt
         /FIles
            /WEB-INF
               nexaweb-desktop-client.xml

version.txt must be a single-line text file with the text 0.0.0.0.

Desktop Client Webapp Image

The webapp image is the server-side webapp. It adheres to the following structure:

 /ROOT
 /WEB-INF
  /client
   /desktopclient
       //the desktop client  jar file
       nexaweb-desktop-client.jar       
       //setting for the desktop client                 
       nexaweb-desktop-client.xml            
       //deployment file describing what is included in
         desktop client
       nexaweb-desktop-client-deployment.xml

Configuration Files

Configuration settings information for the desktop client comes from the following:

  1. nexaweb-client.xml and nexaweb-server.xml configuration files as with the browser version of the Nexaweb client.
  2. nexaweb-desktop-client.xml configuration file settings that override any of the nexaweb-client.xml configuration file settings.

For example, if nexaweb-client.xml sets debug-keys-enabled to false, but nexaweb-desktop-client.xml sets this to true, Nexaweb sets debug-keys-enabled to true in the desktop client.

nexaweb-desktop-client Configuration File

The desktop configuration file, nexaweb-desktop-client.xml, must include at least the following:

<client-app>
   <launch-configuration>
      <!-- the start page for the app -->
      <initial-page>index.nxml</initial-page>
      <!-- the server address -->
      <server>http://localhost:4444</server>      
      <!-- the context path for the app --->
      <context-path-override>
          /OfflineFreeChartDemo
      </context-path-override>    
   </launch-configuration>
</client-app> 

Deployment File

The following shows an example of the deployment file, nexaweb-desktop-client.deployment.xml:

 

<desktop-deployment>
- <!-- Files that end with the following extensions will 
   be ignored when -->
- <!-- traversing directory structures.  -->
-   <excludes-by-extension>
        <extension caseSensitive="false">.jsp</extension>
        <extension caseSensitive="false">.do</extension>
        <extension caseSensitive="true">.foo</extension>
        <extension caseSensitive="true">/No</extension>
  </excludes-by-extension>
- <!-- Resources that the desktop client will keep locally. 
       Note that          -->
- <!-- recursive listings of directory structures will NOT 
       automatically      -->
- <!-- include WEB-INF/ and its descendants. To include 
       resources in       -->
- <!-- WEB-INF or its descendant directories, list them 
       explicitly.        -->
- <!--                    -->
- <!-- Note that all resources in the client classpath, plus 
       plugins will       -->
- <!-- be automatically included even if they are in WEB-INF. -->
- <!--                    -->
- <!-- Any file explicitly listed will NOT be excluded based on
       its file           -->
- <!-- extension whether or not its extension is in the excluded 
       list.              -->
-   <resources>
       <directory recursive="true">/Yes</directory>
       <directory recursive="true">/WEB-INF/classes</directory>
       <resource>/No/Hello.txt</resource>
       <resource>/WEB-INF/web.xml</resource>
  </resources>
</desktop-deployment> 

 

Updating an Application

  • The desktop client connects to the server and requests the contents of the /DesktopManifestServlet.
    This servlet obtains information on what needs to be deployed to the application from the nexaweb-desktop-client-deployment.xml file.
    • If the servlet cannot be reached, the desktop client will start up running based on whatever cached content it has.
    • If the servlet is reached, Nexaweb looks at the last modified time in nexaweb-desktop-client.xml
  • Nexaweb compares the last modified time in the local nexaweb-desktop-client.xml with the version number of nexaweb-desktop-client.jar on the server
    • If the locally cached version of that file is up to date, Nexaweb does not update it
    • If the file on the server is more up-to-date, Nexaweb downloads the server version (if a version of it does not already exist locally). Nexaweb displays a pop up dialog alerting the user that a new version was available and that they may want to restart when the update process is finished. The NEXT TIME they run the client it will run with the new version of nexaweb-desktop-client.xml
    • When Nexaweb pulls down a new version of the desktop client the "version.txt" entry for that application changes. Also a new folder appears beside the "0.0.0.0" folder with the new version number.
  • Once Nexaweb updates the desktop client's jar file, it updates the individual files.
    • Nexaweb displays a progress bar as it downloads any changed files.
    • When the update process completes, the application launches based on those new files.

JVM Versions

  1. JVM 1.3+ is supported
  2. JView is not supported
  3. SSL support in JVM 1.3 requires the appropriate JSSE jar.

Security

  • Supports HTTPS (See above for 1.3 notes)
  • No security sandbox provided with the desktop client; installed applications run with full permissions to do whatever they want.
    The types of applications developed with Nexaweb are not presumed to be consumer applications launched by clicking a random link, but applictions run from a known trusted source. For example, sales people using the desktop version of a Nexaweb developed sales application load the application because it was developed and provided by their employer.

Hard drive access

  • Since the desktop client does not include a sandbox, desktop client applications have no restrictions on hard drive access.
  • A Nexaweb helper method or API provides access to an application root directory .

Connection Listening

Functionality is available for testing that a connection exists; a listener can be registered to see when a connection is established or destroyed.

Synchronization

  1. The desktop client does not provide built in synchronization of user data.
  2. The best practice is to make the server-side stateless and store user information based on cookies or username/password and not based on the active Nexaweb session as sessions will come and go over the life of the application.
  3. DOMs are easily serializable and deserializable.

Installation

  1. Only one install of Nexaweb 4.x itself is required to install multiple applications.
  2. Different versions of Nexaweb are supported; for instance 4.2 alongside later versions.
  3. The system will download new versions when available.

Startup

  1. If there is a connection, Nexaweb updates the application as a whole and Nexaweb versions, if necessary.
  2. Only the entire application will be updated.
  3. The update screen(s) can be customized.

Running

  1. Any flat files (MCOs, XML pages, etc) will be looked up in the application cache that was updated in during startup.
  2. Files that require a server (Servlets, JSP pages, etc) will always attempt to go back to the server. The results of Servlets/JSP pages will not be cached. If the server is not available a friendly error dialog will appear informing the user the functionality requires a connection.
  3. Each time an offline client comes online it will create a new session on the server so that the server can do things on the push connection, etc. This new session will not re-launch the application on the client-side. Server pages will essentially have to be stateless.
  4. Applications that require state information on the client side can do this via cookies. (Save a long-term cookie on the client and save information on the server based on that cookie.)