Overview

Developers can write applications for 2 types of scenarios by using ITAnyplace:

Connected

Connected applications are browser based. Client need not be installed on the device. Code runs in a device-independent fashion. A network connection is always required to access such applications. ITAnyplace uses WALL/WURFL to render applications on mobile devices in a device-independent fashion. For more information on WALL/WURFL please visit http://wurfl.sourceforge.net/index.php

ITAnyplace tooling can automatically create connected apps from web services. Developers need to be aware of the model used by the Connected App tooling to build such applications. The model for connected app tooling has the following elements:

• WorkflowElement

The WorkflowElement class provides features common to all elements present in a workflow. It is the common abstract class for all other elements. A user will never directly add Workflow Element to the model instance.

• Workflow

The Workflow class represents the description of the workflow of an application. Workflow is the parent of all Connected Applications. Workflow contains Workflow Nodes, which represent the pages/steps in the process and Connections, which represent data and control flow between the nodes. A Workflow may also contain comments that annotate the process described by the Workflow.

• Connected Node

Connected Node represents a page/step in a Workflow. Connected Node has Ports and maybe connected to other Workflow Nodes via those ports.

• BackendCall

A BackendCall should be added anytime the developer wants to access a web service/backend.

• Method

Method represents the method available in a WSDL/web service. It is normally used by the tool for internal processing.

• Parameter

User sends a argument.

• File

File node is used to enable the attachment functionality.

Attachment handling for connected applications

Attachment support can be added by adding the File element under any BackendCall. This element has the following attributes:

• Name

Used to define the File attribute in the code.

• OrderId

       This must be defined and not be greater than (the number of parameters - 1) passed in the function. It specifies the position of the parameter in the function where the content of the file is passed to the web service through Backend Call.

NOTE:

• In Connected Scenario, ITAnyplace toolkit only supports Upload capability. Download capability has to be implemented  by the user. Download is generally as simple as added links to the content.

Semi-connected

Semi-connected applications need a client to be installed on the device. Users run the applications locally, with or without network connectivity and then sync with the server when the connectivity is available. These applications can be of 2 types:

• J2ME CDC based: Generally run on high end, enterprise grade devices like Windows Mobile and Nokia Series 80
• J2ME MIDP based: Generally run on medium end devices like Nokia Series 60 and Blackberry

ITAnyplace tooling can automatically create MIDP and CDC semi-connected applications. The model for semi-connected app tooling has the following elements:

• Semi-connected workflow

Semi-connected Workflow is the parent of all semiconnected applications. It contains one or more Semi-Connected nodes, which represent the screens/steps in the workflow.

• Semi-connected node

Semi-connected node represents a screen or step in the workflow

• Semi Connected Output port

Semi-Connected Output port represent attributes of an object that need to be displayed on a screen

• Link

Link connects 2 or more Semi-Connected nodes and is used for navigation between screens.

• Attachment

Attachment node is used to enable the attachment functionality at the client end.

• Primary Key

Primary Key is used to define the primary key in the client end. On the basis of this key the sync process is done for the update and the delete operations. It is also used to set in the attachment object as the relational field.

The tooling supports the following operations in the semi-connected app:

Insert

• name=xxx
• OperationType=Add
• Object=anyobject (e.g. Patient)
• Attributes to insert (semi-connected output port)
• SOP=xxxx
• SOP=xxxx

View

• name=xxx
• OperationType=View
• Object=anyobject (e.g. Patient)
• Attributes to insert (semi-connected output port)
• SOP=xxxx (e.g. fName)
• SOP=xxxx

Delete

• name=xxx
• OperationType=Delete
• Object=anyobject (e.g. Patient)
• Select search criteria (semi-connected output port)
• SOP=xxxx (e.g. fName)
• SOP=xxxx

Update

• name=xxx
• OperationType=Update
• Object=anyobject (e.g. Patient)
• Select search criteria (semi-connected output port)
• SOP=xxxx (e.g. fName)
• SOP=xxxx

None (Generally useful in creating index pages with links)

• name=xxx
• OperationType=None
• Object=application Entry Point
• Enter links
• link1=xxxx (e.g. Insert Record)
• link2=xxxx

NOTE: User has to define atleast one node of None type. This node is the index page which is used as the entry point to the application, and the first screen after the login from ITAnyplace login page.

Sync (Synchronizes client app with the server)

• name=xxx
• OperationType=Sync
• Object=anyobject (e.g. Account)

Purge (Removes record from the device but not from the server)

• name=xxx
• OperationType=Purge
• Object=anyobject (e.g. Account)
• Select search criteria (semi-connected output port)
• SOP=xxxx (e.g. fName)
• SOP=xxxx

For the semi-connected applications to synchronize automatically with data sources, we require that the web services implement a Syncable interface:

interface com.itanyplace.sync.Syncable

{

// List should have objects of type SyncRecord

List getRecords(SyncRecord syncRecord,PasswordAuthentication passwordAuthentication);

List getAddedRecords(SyncRecord record, Calendar timestampoflastsync,PasswordAuthentication passwordAuthentication)

List getUpdatedRecords(SyncRecord record, Calendar timestampoflastsync,PasswordAuthentication passwordAuthentication);

List getDeletedRecords(SyncRecord record, Calendar timestampoflastsync,PasswordAuthentication passwordAuthentication);

SyncRecord addRecord (SyncRecord record,PasswordAuthentication passwordAuthentication)

SyncRecord updateRecord(SyncRecord record,PasswordAuthentication passwordAuthentication);

SyncRecord deleteRecord(SyncRecord record ,PasswordAuthentication passwordAuthentication);

// checks if there is a SyncConflict between 2 records. Normally a developer would compare primary key here and return true if the primary key of 2 objects is the same

Boolean isSyncConflict(Object a, Object b,PasswordAuthentication passwordAuthentication)

}

SyncRecord has an attribute called recordToSync in which the developer can store the actual object that needs to be transferred.

Attachment handling in semi-connected applications

Web Service Implementation:

The developer needs to implement the following in the web service to handle attachments:

• In the getRecords() function, put a check for the Attachment object type. If there is an attachment, it means that this is a request from the user for attachment download and therefore the file content should be made available to the user as part of the processing.
• Add the attachment object to the wsdl file with the following attributes under the com.itanyplace.sync package
• fileName
• fileExtension
• objectName
• relationalField
• encodedFile

Tooling:

Attachment support can be added by adding the Attachment element under any semi-connected node. This element has the following attributes:

• Download (Yes, No)

Yes enables the attachment Download capability. This property should NOT be set to Yes for a node whose operation type is Add.

• Upload (Yes, No)

Yes enables the attachment upload capability.

• IdentifyAttachmentsForRecordBy

This is used to uniquely identify attachments for selected objects. You will generally use the primary key of the object here.

• Name

Name of the Attachment Node.

NOTE:

• Only Upload option is supported for Add node. View and Update support both Upload and Download. Delete, Purge and Sync nodes do not support either of these 2 options.
• In case of Add operation, the user can use any of the object attributes for IdentifyAttachmentsForRecordBy but in case of View and Update operations,  user should choose only primary key for IdentifyAttachmentsForRecordBy field.

When the app has download attachment capability, the attachments are not downloaded when the records are first synced to the device. When the user selects the record, available attachments are shown. The user can then download one or more of them. At any time, the user can see see all downloaded attachments on the device and see the names of the attachments which have not been downloaded.