In addition to using the same scripting language as PowerBuilder, Pocket PowerBuilder eases data-driven mobile development through a patented DataWindow control that includes built-in SQL statements and multiple data formats such as graphs, grids and tabs. Sybase's SQL Anywhere Studio, a scaled-down version of the Adaptive Server Anywhere database and an enterprise synchronization tool are integrated into the product.

MARIO MOREJON
Technical EditorPocket PowerBuilder applications are built similarly to DLLs. Developers can deploy executables with link libraries to reduce their size. The Pocket PC platform has a total memory of 8 Mbytes, while Pocket PowerBuilder's runtime virtual machine has a 3-Mbyte memory footprint. Currently, developers can't determine how much memory their applications use or how much data can be transferred safely to maximize a Pocket PC's memory utilization. CRN Test Center engineers recommend that business logic and data transfers be kept to a minimum to avoid unpredictable memory errors.

The IDE contains a couple of template applications that give developers a head start. In future releases, Sybase plans to add more templates based on feedback from developers. The templates are wizard-driven and point to the main functions in the IDE that a developer will need to incorporate when specifying data synchronization and types of executable.

The DataWindow control is a database painter Window that includes a series of tabs to generate SQL without any coding. Developers can build complete SQL statements in seconds and control the amount of data transfers through SQL filtering or by explicitly restricting the data that is retrieved to a single window at a time. Data transfer is therefore controlled through a sophisticated mobile synchronization object that passes along only enough data to fill one pane; the program requests more data when a user scrolls.

On the server side, Pocket PowerBuilder relies on a bidirectional synchronization MobileLink product to retrieve data from enterprise databases. MobileLink can synchronize data with SQL Server, DB2, Oracle and most other enterprise databases in the market. Through MobileLink, SQL code created inside Pocket PowerBuilder can read/write with SQL variants such as TSQL or PLSQL, so developers will find that little knowledge of the targeted server-side enterprise database is required.

SYBASE POCKET POWERBUILDER 1.0Typical Pocket PowerBuilder applications only have a small display layer that is usually added at the beginning of a program execution. The IDE provides a simple way to attach a graphics file to the executable.

Pocket PowerBuilder uses an event-driven scripting language and follows some object-oriented constructs. Most of the language components are datacentric. The IDE also includes some painting controls such as scroll bars, a progress bar and various buttons. Developers can add new controls, which opens the door for solution providers to create all sorts of controls.

One of the earliest products that Sybase offered was a biometrics application that scanned fingerprints on a Pocket PC. Sybase integrated Hewlett-Packard's biometrics security tool with Pocket PowerBuilder's database to identify users. That tool can be used in conjunction with other applications to secure access to corporate data. The biometrics application will be native in the next version of Pocket PowerBuilder, version 1.5, and can be accessed as a component.

Pocket PowerBuilder can call Web services using the open-source PocketSOAP component. Sybase supplies a DLL that interfaces with that component. CRN Test Center engineers found that applications communicating with Web services are a little more complex because they require more coding from the developer than DataWindow applications.

The synchronization tool uses 128-bit encryption for data transfers. On the server side, all data exchanges have to be coded. On the Pocket PC side, any accessed record set other than simple scrolls from the MobileLink technology cannot be done unless it is coded on the server side. Sybase recommends that developers code-store procedures on the server side to retrieve records when random access is required. Most of the business logic should also remain on the server side, where developers have more control.