Preparation

To get this sample to work, you first need to register for two services. Each of these services needs to recognize your application, and see that is different from anyone else who has downloaded and is using this sample, so the registration needs to be done by you rather than by Sybase.

• Sybase Hosted Relay Server. The relay server lets Android phones on public networks connect to a MobiLink server on your machine, even if there are firewalls between. You can register here; some instructions are here.
• Google C2DM. C2DM is the push service for Android. You can register here.

In addition, you need to have some development tools:

• A SQL Anywhere 12 installation such as the Developer Edition, available for free download here. This tutorial assumes that you have some experience with MobiLink.
• A Java 1.6 or later JDK.
• The Android SDK, downloadable from here.
• The Google APIs add-on for Android emulator images, downloadable from here, if you wish to run the sample in an emulator.
• The Apache HTTP Components libraries, which can be downloaded from here.

And, of course, you need the sample code itself. Here is a zip file that has the source code for this sample application. Unzip it to create a folder named distrib, which you can rename or move. The two subfolders are db (the server-side code and database) and client (the client side code).

Finally, you will need an Android phone. You can run the application on any Android device, or on the Android emulator that comes with the Android JDK. Some company firewalls, however, block the port that push messages use, so you may need a phone with a plan to see the push capability at work.

The sample application is a simple message sending application. Random text messages (constructed from Latin words) are generated at the server, and a push system delivers them to the Android device.

At each stage of this walkthrough, you may need to customize the batch files and source code to reflect your own setup.

Customize the Java source code

You must edit the Java Source code to include your own C2DM account information. Open db\ml_c2db\src\com\sybase\c2dm\MessageSender.java and fill in the correct strings for C2DM_EMAIL and C2DM_PASSWORD.

Build the server

The first step is to build the server-side database and logic. The build process builds the following:

• The consolidated database, which is a SQL Anywhere database that holds a table for messages, a table for information about each user, and a set of tables/stored procedures that generate messages and fill the messages table. The database also has a trigger so that whenever a message is added (or deleted) a table called PushRequest is updated. The PushRequest table holds, for each user, a timestamp for the most recent message to that user.
• A Java package that is run by the MobiLink server.
• An ODBC Data source definition, which the MobiLink server uses when connecting to the consolidated database.
• An UltraLite database, which has the same schema as the database on the Android device. It can be used for desktop testing.

To build the server-side database and logic, open a command prompt, change directory to the db folder, and run build.bat.

If you have problems running build.bat, you may need to edit the file to set the environment variables that point to your SQL Anywhere installation, and you may need to edit the build.bat file in db\ml_c2dm, which contains environment variables for your JDK installation as well as the location of the Apache HTTP components JAR files.

Customize the MobiLink server command line

You must provide the MobiLink server with your Relay Server information. Create a file in the db folder named C2DM.config with the information from your hosted relay server account. It will look like this:

-f account-name.farm-name

-id C2DM

-t alongalphanumerickey

-cr “host=RELAYSERVER.sybase.com;https=1;port=443;url_suffix=/ias_relay_server/server/rs_server.dll”

Start the MobiLink server

From the db folder, run mobilink.bat to start the server.

If you have problems, you may need to edit the file to set the local environment variable that points to your JDK installation directory. You may also need to change the lines that include location of the Apache HTTP components. Note that mobilink.bat contains a commented-out line that would set an appropriate setting for debugging the Java code from Eclipse. The batch file sets logging verbosity to high for debugging purposes, but if you are interested in performance you should edit the mobilink.bat file to reduce the logging verbosity (-v option).

Part of the startup code for the MobiLink Java classes is to execute the ClientLoginTokenFactory.getToken() method, which sends the Sender ID and password to Google C2DM servers, and retrieves a token that MobiLink supplies as authorization when sending any subsequent messages.

Test the synchronization setup

Once the MobiLink server is started properly, you can test synchronization using the sync_ul.bat file. This file synchronizes the MobiLink server to the C2DM.udb file created as part of the build. It doesn’t test the push part of this sample, but it does confirm that synchronization is working properly. A successful synchronization is shown as a message in the MobiLink server console window; errors will be logged in the file mobilink.mls, on lines starting with E. If you have problems with this synchronization, you may need to edit the file build_ul.sql and change the synchronization profile definition.

You can inspect the data in the databases by running the isql.bat file in the db folder, which starts one instance of Interactive SQL connected to the SQL Anywhere database, and one connected to the UltraLite database. Again, you may need to edit the file to set environment variables.

At this stage, there are a few messages in the consolidated database, but no additional messages are being generated.

The next step is to build the Android application and test it.

Customize the Android application

From Eclipse, with the Android SDK, open the project in the client folder. You will need to supply your own Relay Server information (so that the application can synchronize with your MobiLink server) and you will need to supply your own C2DM information (so that the application can register with the C2DM system and be matched up with your MobiLInk server.

• In com.sybase.c2dm\C2DM.java, supply the ML_URL_SUFFIX needed for your Relay Server. It will be something like /ias_relay_server/client/rs_client.dll/yourname-yourproject.
• In the same file, edit the C2DM_SENDER_ID field to include our C2DM email. There is no need to supply the password on the client side.

You should now be able to build the application.

Build and run the Android application

In order to run the application, you must run it on a device or emulator that has the Google APIs installed. Essentially all devices have these APIs, but you may need to download a special emulator add-on (as described at the top of this article) to use them on an emulator. You must have a Google ID (email address) to access the Google servers.

Once you start the application, you should see a synchronization take place (watch the console of the MobiLink server) and some messages (random Latin words) appear on the screen. You can carry out an explicit synchronization by choosing Menu > Synchronize. At this stage there will be no notifications, as no new messages are being generated. Once you have synchronization working, you can generate new messages so that push is used.

The application uses AsyncTask objects to carry out database operations on a background thread, leaving the UI thread active. After creating the database, DatabaseTasks.CreateOrReplaceDatabaseTask.onPostExecute() calls C2DM.requestC2DMRegistrationID(), which posts a request to the C2DM servers for a registration ID that identifies the device to the servers. The C2DMReceiver class handles the response from the server, stores the registration ID in the UserDevice table of the application, and synchronizes it to the MobiLink server. Once this synchronization is complete, the MobiLink server can send messages to the device using the registration ID.

Start generating messages

From a command prompt in the db folder, run “isql.bat sa” to open up an Interactive SQL window on the consolidated database. Enter the following command to start generating messages.

alter event add_messages

enable

You can watch messages being added to the message table by executing “SELECT COUNT(*) FROM messages”. Also, you can see the PushRequest table being updated by executing “SELECT * FROM PushRequest”. To see the actions of the MobiLink server, execute “SELECT * FROM PushLog ORDER BY log_id DESC”

At this point, new messages for a user prompt a push message from the MobiLink server to the Android application. On receiving the message, the application synchronizes and then notifies the user with a sound. On the emulator, the sound is not played.

The sample does not include code to update the display after the message is received. You can check that messages are received by choosing Menu > Refresh on the device, or by changing the orientation of the device (which prompts a refresh). To change the orientation of the emulator, press Ctrl+F11.

If you are running the application on an emulator or on a device running WiFi on a company LAN, then a firewall that blocks port 5228 will prevent push messages getting to the application.

Summary

So that’s the complete sample. It’s not simple, but it shows, I hope, that you can add push features to SQL Anywhere application for Android, integrating the client and the server into the Google Cloud-to-Device Messaging system.

The sample code is not complete – it does not have sufficient error checking or consideration of all possible cases for a production application, but it does cover the essentials of a push application.

The HTTPS implementation on Android uses the OpenSSL library, which has slightly different behavior to the Certicom libraries that SQL Anywhere uses on other platforms. So here are some pointers on getting HTTPS synchronization to work on Android.

Setting up the certificates

You may already have a certificate signing mechanism set up, so you may not need this stage, but if you don’t then you can use the SQL Anywhere createcert command-line utility to create the certificates that you need. Here are two ways of creating certificates that can be used on Android.

Creating a self-signed certificate

Here is a createcert session to generate a self-signed certificate with the needed properties. The responses that I typed in are bold. Obviously the particular entries for country code and so on would be different in each case, but do notice the non-default key usage entry of 3,4,5,6 , which is required for this to work.

c:\demo>createcert
SQL Anywhere X.509 Certificate Generator Version 12.0.1.3356
Choose encryption type ((R)SA or (E)CC): r
Enter RSA key length (512-16384): 1024
Generating key pair…
Country Code: CA
State/Province: ON
Locality: Waterloo
Organization: Sybase
Organizational Unit: iAnywhere
Common Name: SimpleSync
Enter file path of signer’s certificate:
Certificate will be a self-signed root
Serial number [generate GUID]:
Generated serial number: a670722d106c4cc7b204e02c9c00a34c
Certificate valid for how many years (1-100): 1
Certificate Authority (Y/N) [N]: n
1. Digital Signature
2. Nonrepudiation
3. Key Encipherment
4. Data Encipherment
5. Key Agreement
6. Certificate Signing
7. CRL Signing
8. Encipher Only
9. Decipher Only
Key Usage [3,4,5]: 3,4,5,6
Enter file path to save certificate: rsa_cert.pem
Enter file path to save private key: private_key.pem
Enter password to protect private key: pwd
Enter file path to save identity: identity.pem

The generated files get used by the server (identity.pem) and by the client (rsa_cert.pem), as shown below. But first, let’s show an alternative way to generate certificates, this time using a certificate authority.

Creating a certificate authority

You may use a certificate from an authority such as Verisign, but here is a sample for creating your own authority, and an identity from it, using createcert. You need to run createcert twice; once to create the certificate authority and once to generate an identity file from it. If you are using an external authority you can skip the first session.

1. Create Certificate Authority

c:\demo>createcert
SQL Anywhere X.509 Certificate Generator Version 12.0.1.3356
Choose encryption type ((R)SA or (E)CC): r
Enter RSA key length (512-16384): 1024
Generating key pair…
Country Code: CA
State/Province: Ontario
Locality: Waterloo
Organization: Sybase
Organizational Unit: iAnywhere
Common Name: MyRoot
Enter file path of signer’s certificate:
Certificate will be a self-signed root
Serial number [generate GUID]:
Generated serial number: cfbbe4ac774a49f9984e470f842ba306
Certificate valid for how many years (1-100): 1
Certificate Authority (Y/N) [N]: Y
1. Digital Signature
2. Nonrepudiation
3. Key Encipherment
4. Data Encipherment
5. Key Agreement
6. Certificate Signing
7. CRL Signing
8. Encipher Only
9. Decipher Only
Key Usage [6,7]:
Enter file path to save certificate: rsa_cert.pem
Enter file path to save private key: private_key.pem
Enter password to protect private key: pwd
Enter file path to save identity:
Identity not saved

2. Create server certificate

c:\demo>createcert
SQL Anywhere X.509 Certificate Generator Version 12.0.1.3356
Choose encryption type ((R)SA or (E)CC): r
Enter RSA key length (512-16384): 1024
Generating key pair…
Country Code: CA
State/Province: Ontario
Locality: Waterloo
Organization: Sybase
Organizational Unit: iAnywhere
Common Name: SimpleSync
Enter file path of signer’s certificate: rsa_cert.pem
Enter file path of signer’s private key: private_key.pem
Enter password for signer’s private key: pwd
Serial number [generate GUID]:
Generated serial number: 873b60b268754ce3ad00264bb8970a40
Certificate valid for how many years (1-100): 1
Certificate Authority (Y/N) [N]: n
1. Digital Signature
2. Nonrepudiation
3. Key Encipherment
4. Data Encipherment
5. Key Agreement
6. Certificate Signing
7. CRL Signing
8. Encipher Only
9. Decipher Only
Key Usage [3,4,5]:
Enter file path to save certificate:
Certificate not saved
Enter file path to save private key:
Private key not saved
Enter file path to save identity: identity.pem
Enter password to protect private key: pwd

Running the MobiLink Synchronization Server

Here is a MobiLink server command line that uses the identity file identity.pem (for either setup).

mlsrv12 -x https(port=443;tls_type=rsa;identity=identity.pem;identity_password=pwd) -c …

Client side code

Here is a synchronization profile that you can use at the client side, which needs access to the certificate (rsa_cert.pem). I use this for testing synchronization from Interactive SQL without needing to build an application. The statement is split across several lines for readability.

CREATE OR REPLACE SYNCHRONIZATION PROFILE https
‘MobiLinkUid=user_1;MobiLinkPwd=password_1;
Stream=https{host=localhost;port=443;
tls_type=rsa;trusted_certificates=rsa_root.pem};
ScriptVersion=version_1′

An Android client needs to get the certificate into the right place on the client, and then use it for synchronization. Here is the process:

First, you need to be sure that you include the encryption library in your project. I posted about the basic setup for an UltraLite Android project here, and all you need different is to make sure that libmlcsra12.so (from the UltraLite\UltraLiteJ\Android\ARM subdirectory of your SQL Anywhere install) is in the libs\armeabi folder of your Android project.

Next, in your Android project folder, create a folder res\raw, and add the certificate to that folder. In Eclipse this will look as follows:

Your startup code needs to read this resource and save it to the file system. Here is an example:

InputStream is = getResources().openRawResource(R.raw.rsa_cert);
FileOutputStream os = openFileOutput(“rsa_cert.pem”, MODE_PRIVATE);
byte[] buff = new byte[4096];
int n;
for(;;) {
n = is.read(buff);
if (n < 0) break;
os.write(buff, 0, n);
}

This adds the certificate to the files folder of your application’s private storage area, which is /data/data/<package-name>.

And here is the code to synchronize, reading the certificate and passing it to the synchronization function.

SyncParms sp = _conn.createSyncParms(SyncParms.HTTPS_STREAM, "user_1", "version_1");
sp.setPassword("password_1");
StreamHTTPSParms streamParms = (StreamHTTPSParms)sp.getStreamParms();
streamParms.setHost("10.0.2.2"); // This is the URL that identifies the host machine for the emulator
streamParms.setPort(443);
streamParms.setTrustedCertificates("/data/data/com.sybase.simplesync/files/rsa_cert.pem");
_conn.synchronize(sp);


So that describes how to create certificates for HTTPS synchronization on Android, how to use them at the server, and how to use them at the client.

But still, people understandably want to know, how long does a sync take? And sometimes I have the feeling that people think of data synchronization as a heavy, time consuming process – perhaps thinking back to pushing the button on old PDAs – when much of the time it is anything but.

So here are some syncs and the times they take. These are all download syncs (getting data from the consolidated database to the device), because for many applications the biggest sync happens the first time the application is started, when it downloads the data it needs. After that, it’s often incremental changes that are much easier to manage. They are all done with a light server load (we document MobiLink server throughput and scalability here) because the focus is on the experience at the client. The MobiLink server is running on my desktop, but communication goes through a Relay Server on the other side of the continent so this data is recorded over realistic networks.

Here is data from an HTC Desire running Android 2.2, over a WiFi network.

You can see that downloads of anything less than 100KB or so can be done in under two seconds, from request to the successful completion. Put this in the background, and it means that data transfer can take place with basically no interruption to the user. Once or twice network connectivity issues led to delays (the two off-line points) but for most cases you can see that the download time is linear with data volume. You can see that this extends to higher volumes in the next figure.

The top-right value here is a download of 50MB of data, and it takes about 15 minutes. In practice, most downloads of this size to a smartphone, tablet or handheld computer will be on initial setup of an application (the initial loading of reference data) and this can be better achieved by downloading a pre-populated database file. But if you do need to synchronize this much data, it can be done.

And here is data from a BlackBerry Bold 9700 downloading data over a 2G or 3G network (the higher values for a given volume are 2G). You can see from the log-log plot that the smallest download (a few KB) has an overhead of a few seconds, which is a reflection of the latency of the network. A download of a megabyte of data can be accomplished in about a minute (a rate of about 15KB/s). The largest sync, which is 10MB, takes about 15 minutes to complete. For downloads of this magnitude, you may want to consider using the MobiLink file transfer capability instead to download a database file, rather than to download the data and insert it into the file.

There are downloads for four different schemas, at various scale factors, included in the single graph below.

You can see that the times for BlackBerry are significantly longer than those for the Android device. This is partly because of the slower network, partly because of the less-powerful device, and partly because of the overhead from Java software on the BlackBerry.

The takeaway message here, I’d like to think, is that data synchronization is not a heavy operation, but is often a short operation that, when carried out on a background thread, can be done with no interruption to the user experience.

UltraLite is the mobile database management system that is included in SQL Anywhere. This post is a Hello World for UltraLite on Android. It assumes that you have what you need to develop Android applications (Eclipse and the Android SDK), and that you have SQL Anywhere installed (perhaps the Developer Edition free download). It covers setting up a project, and carrying out simple database access, but doesn’t cover data synchronization (sharing data between device and a backend system) which is the primary reason for many people to choose SQL Anywhere.

First, create an Android Project. Here are the settings I’ll be using.

Once you have created the project you should be able to run this default application in an emulator (or on a device) and see that it shows a screen with the words “Hello World, Hello UltraLite” in a textView control. Choose Run > Run As > Android Application.

Next, create a folder named libs\ under the HelloUltraLite folder, and copy the UltraLiteJ files into it. You will need to rename the ARM subfolder to armeabi. Here are the instructions from a command line:

workspace> mkdir HelloUltraLite\libs

workspace> xcopy /s “c:\Program Files\SQL Anywhere 12\UltraLite\UltraLiteJ\Android\*.*” HelloUltraLite\libs

workspace> move HelloUltraLite\libs\ARM HelloUltraLite\libs\armeabi

The UltraLite files include the UltraLite JAR file (which holds the API), the UltraLite database management system, which is a C++ shared object, and the Javadoc documentation files.

Back in Eclipse, add the UltraLite libraries to your project:

In the package explorer press F5 or right click the project and choose Refresh so that the project is aware of the UltraLite files.

Add the UltraLite JAR file to your build path, as in the following dialog. You can also specify the Javadoc location as the libs\HTML subfolder of your project so that you get tooltip-style documentation from the edit window:

Here is what the Package Explorer looks like, with the libs folder included.

The next step is to add some code to the com.sybase.com.HelloUltraLite.java file to create and connect to a database. Most of the time you would keep your data access code in a separate class, but for this simple case we are going to keep everything in one file.

Here are the imports that the file needs:

import java.util.Random;
import android.app.Activity;
import android.os.Bundle;
import android.util.Log;
import android.widget.TextView;
import com.ianywhere.ultralitejni12.*;

When Android starts the application in response to a tap of the icon, the entry point is the HelloUltraLite onCreate() method, so that is where we will put the database access code. Here is the complete onCreate() method:

public void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    setContentView(R.layout.main);
     try{
        // Define the database properties using a Configuration object
        ConfigFileAndroid config = DatabaseManager.createConfigurationFileAndroid("hello.udb", this);
        // Connect, or if the database does not exist, create it and connect
        try{
            _conn = DatabaseManager.connect(config);
        } catch ( ULjException e) {
            _conn = DatabaseManager.createDatabase(config);   �
        }
 
        // Create a table T1 in the database if it does not exist
        StringBuffer sb = new StringBuffer();
        sb.append("CREATE TABLE IF NOT EXISTS T1 (C1 integer primary key default autoincrement, C2 integer )");
        PreparedStatement ps = _conn.prepareStatement(sb.toString());
        ps.execute();
        ps.close();
           
        // Insert a row into T1
        sb = new StringBuffer("INSERT INTO T1 (C2) ON EXISTING SKIP VALUES ( ? )");
        ps = _conn.prepareStatement(sb.toString());
        ps.set(1, new Random().nextInt());
        ps.execute();
        ps.close();
        _conn.commit();

        // Select the values from C2 and show them in the user interface
        sb = new StringBuffer("SELECT C2 FROM T1");
        ps = _conn.prepareStatement(sb.toString());
        ResultSet rs = ps.executeQuery();
        StringBuffer c2 = new StringBuffer();
        while(rs.next()){
            c2.append(String.valueOf(rs.getInt(1)));
            c2.append(",");
        }
        TextView tv = (TextView)findViewById(R.id.textview1);
        tv.setText(c2.toString());
    } catch ( ULjException e) {
        Log.e("HelloUltraLite", e.toString());
    }
}

The class R is the Resource class, and includes the user interface and any strings.

When this application is run, it carries out the following tasks:

1. Connects to a database, or creates the database if it does not exist (and returns a connection)
   
2. Creates a table T1 if it does not already exist
   
3. Inserts a row into T1.
   
4. Selects all the rows from T1, concatenates them into a string, and displays that string in the TextView control that is included in the default user interface.
   
5. If there is an error, a message is written out to the LogCat window in the Eclipse user interface.
   

Here is the Android application after running the application a few times, showing the random numbers inserted into the table.

And that completes the tutorial.

Here is the architecture of a typical SQL Anywhere mobile application:

The logic that decides who gets what data is held at the synchronization server; the traffic optionally goes through a relay server which eliminates the need for inbound traffic through the firewall, and the local database on the device makes it possible to build responsive, always-available applications that use rich data sets.

SQL Anywhere has a significant number of mobile deployments with tens of thousands of mobile devices, so the technology is proven to scale to large numbers of clients. The free Developer Edition is available for download here (you need the Windows Edition as development is carried out on Windows), and there is documentation at the DCX web site that Phillipe just wrote about. Here is an introductory tutorial.

Our Android implementation uses the same UltraLiteJ Java API as that of our BlackBerry database. Under the covers, though, we have used the Android NDK to provide a C/C++ library for better performance – a port of the same code base that is supplied on Windows Mobile and iPhone. This means that although the Android implementation is new, the database code itself is mature and extensively field-tested.

I hope to write a small set of posts in the near future that focus on the Android-specific client, its performance and what you need to develop applications. Those posts will be based on the content of a webcast we gave last week, which you can find on the Resources tab here.

When I’m looking up our docs (way too much to memorize and faster than looking it up in the code) and see something weak or confusing, I simply add a comment. If it is in my own product, I add a clarification visible to all. It’s the same as emailing our doc team and it makes the clarification available to our customers.

So where am I going with this? Following the theme of my previous post, all vendors should have a site like our DCX!

And all users of SQL Anywhere should take advantage of DCX. Don’t get me wrong, our doc team and developers who provide documentation are quite busy so a massive flood would have to be prioritized. Yet even a volume of constructive requests for clarification will help us know what sections of API are used frequently and really could benefit from improvement. While the docs themselves are not updated until the next release, we do post responses to comments when we feel they would be of benefit to the general user base.

Of course, sometimes what is needed is much more that what would be appropriate in an API reference. This is where the newsgroups and the SQL Anywhere forum (which is currently in beta) comes in. Here not only can Sybase iAnywhere staff provide answers and samples, the whole user community can share and grow to the benefit of all!

As I said, I’m a developer, and in my utopian world, all developers would have perfect documentation. In the meantime, everyone should have and use DCX-like documentation.

Yes, I’m a developer working deep down in the bowels of the code – striving to make it better, faster, able to leap tall buildings in a single bound. The problem is UltraLite and UltraLiteJ are just one piece of a great mobility solution offered by us and is in fact, not even sold as a separate product. We don’t get nearly as good a feel as to who is using it and what is being done with it. Sure we (Product Management and Development) hear about some of the big projects but we know there are some very interesting uses out there that slip our radar.

So why should you care? I can sum it all up with one example. A number of months ago we had a pre-sales inquiry as to whether UltraLiteJ could handle a particular scenario. Product management or our support specialist quickly created a sample and tried it out on a device to promptly discover that, yes indeed, UltraLiteJ could easily meet the performance requirements given the particulars of the request.

Yet the story does not end here. They told me about this customer and described to me the environment they were working in (we were lucky because we were given the full schema and class of devices). This sat in the back of my mind for a little bit when another issue came up that brought this story to the foreground. I figured out that there could be some issues that would not show up unless the client application ran for a significant amount of time. We added better code and thus UltraLiteJ was improved, to the benefit of all, long before the customer went to production.

What caught our attention were the particulars of the environment (ok, it is hard to write this while keeping the details private because I don’t know if we are under NDA) – it wasn’t a giant deal but it was a neat everyday use of our technology – one we might encounter in our everyday travels and it didn’t come from the usual support channels.

Letting us (Product Management at Sybase iAnywhere) know the environments our technology works in lets us plan and think about what features we can add to make your life better. While we can’t customize the product for every customer, we can look at common issues and ease of use features that will help everyone.

Make providing feedback a New Years Resolution and Happy New Year!

We had been experimenting for years on BlackBerry devices before the first release of UltraLiteJ, but the very features that endeared the BlackBerry to the corporate users – long battery life – was holding back the development of advanced database synchronization technology for this platform. Despite our years of experience in the mobile space, the clocked down processors, slow persistent memory and object handle limits of the BlackBerry made it impossible for us to achieve the minimum performance we deem acceptable – that was until the 4.0 devices arrived. Even with the 8700, we did many experiments before arriving with the architecture of UltraLiteJ. We would not compromise in ensuring we had a reliable product that would provide a recoverable database.

But that was then … before cameras and SD cards. So now SQL Anywhere 12 was release this summer, with UltraLiteJ 12.

There are lots of great new features, including MobiLink file transfers, BlackBerry internal flash and SD card support, and support for binary data in external files (i.e. pictures taken by the on device camera become part of the database without time consuming copying). While all these features and more give UltraLiteJ some good kick, what I really want to talk about is what is hidden under the covers!

For 12, we made some fundamental changes to the underlining architecture to address scalability and performance. First of all we implemented a new row limiting algorithm to make it easier for users to manage the BlackBerry’s unique object handle issues (yes, row limiting in not new in 12 but the old algorithm did not handle the fact that different tables use up different number of handles per row). Next we added better management of index pages, better storage (both in memory and persistent form) of the transaction log, improvements for large downloads and finally, we greatly reduced database page read and writes. Basically, stuff guys like me love to brag about.

We tried to push as many partial and full performance improvements into the 11 “express bug fix” releases as we could but the full benefit could not be achieved without the store format change that occurred in 12.

So if you are still on 11, what are you waiting for? Upgrade to UltraLiteJ 12 and reap the benefits!

One interesting point is that multiple devices are becoming the norm. This is one of those trends that seems to go in multiple directions at once. In some ways the smartphone is driving out other devices (watches, alarm clocks, music players) and the world looks like it is converging on one device, but at the same time we adopt e-readers, tablets, and more. As Mitchell says:

The conventional wisdom was that people would never carry an iPad or other tablet computer because it can’t replace a smart phone or a laptop and no one would carry three devices. It’s looking like that’s not true. iPad users here appear to be carrying all three – including another Computerworld reporter covering the conference. Gartner now envisions a world where users’ lives are associated with many different devices, a world where those devices will disappear into functional “objects” (think e-book reader).

And all these pockets and bags full of devices drive another need, which Mitchell calls “The synch ecosystem”:

An acute need is emerging for app and data orchestration between all of these computing devices. What all of those objects you use need is portable, universal access to your information. “If you’re working on four or five different machines you can’t remember which has what,” says Cearley. And you shouldn’t have to.

Most often when I think about moving data from device to device I am thinking about sharing it among different users, but the point here is that there is a real need to share my data with myself at different points in my day, and this sharing should be transparent. It’s something that we are working on here at Sybase, and good to hear that it’s a task others think is important.

I recommend reading the whole article.

First: which devices are you targeting with your application?

SUP is designed for the burgeoning world of smartphone applications, with support for BlackBerry, iPhone, Windows Mobile and Symbian smartphones and handheld devices.

While SQL Anywhere also supports smartphone platforms, most SQL Anywhere mobile applications are deployed on enterprise handheld computers and on laptop computers. Delivery, logistics and warehouse applications are common users of handheld computers; inspections, CRM and field service applications are often deployed to laptops.

In addition, SQL Anywhere supports “remote office” and point-of-sale systems which, while not “mobile” in a strict sense, share a common data architecture with mobile applications. The “mobile device” in this case may be a multi-user database server at a regional office, restaurant or other location – typically with limited or no IT staff.

Second: SUP and SQL Anywhere provide a different experience for developers, both on device and at the enterprise.

SUP developers can take advantage of a 4GL programming model which uses Mobile Business Objects to generate application code from an Eclipse-based workspace. Mobile Business Objects provide a level of abstraction that unifies the device, data movement, and enterprise integration aspects of mobile applications and which insulates the developer from the need for low-level programming. Developers using SQL Anywhere work directly with low-level APIs and use the SQL language for data manipulation: this approach takes more work but provides maximum control and performance.

On device, SUP Mobile Business Objects allow device-independent generation of application code, while SQL Anywhere developers work directly in the native application programming tools and native APIs for each device.

At the enterprise, SQL Anywhere is focused on working directly with relational database management systems, including Oracle, Sybase, Microsoft and IBM DB2. SUP is designed to work more closely with enterprise systems such as SAP.

In short, SQL Anywhere provides optimized components for each device and for data movement, allowing maximum control for high-performance and highly scalable applications. SUP’s higher level of abstraction lets developers produce applications more rapidly, and the SUP server is built for organizations building multiple mobile applications.