Home Products Services Company Developer Connection
Applied Informatics

Developer Connection

Mailing Lists

We now have two mailing lists available for users of our C++ libraries and tools:

  • appinf-announce is a read-only list used for important announcements from Applied Informatics, such as new releases or important patches.
  • appinf-user is a general discussions list.

In addition, there is the poco-develop lists for users of the POCO C++ Libraries.

Windows CE Support Is Here

The POCO C++ Libraries, as well as our commercial libraries and tools (Fast Infoset, Remoting, Open Service Platform), can now be used for Windows CE development as well. We have created a port of the POCO C++ Libraries to Windows CE 6 based on the current 1.3.7 branch. The port should work on Windows CE 5.x as well, however, testing has only been done on a Windows CE 6 device. There are a few minor restrictions to some POCO features, due to restrictions in the Windows CE operating system (e.g., no support for environment variables, no pipes), but apart from that, almost all libraries can be used.

Starting today, the Windows CE port is available to our support subscription customers and sponsors of the POCO C++ Libraries project upon request. If you’re not yet a support customer, you can become one here.

More information about the Windows CE port is available here.

Release 2009.2p4 is Available

2009.2p4 is another patch release for 2009.2 that fixes bugs in Remoting, OSP and Fast Infoset. Also included is better iPhone support (new build configurations for iPhone and iPhoneSimulator). Upgrading is recommended. For a list of changes, please see the release notes for Fast Infoset, OSP and Remoting.

Remoting on The iPhone

Thanks to Apple’s excellent support of C++ on iPhone OS, Remoting is working fine on the iPhone, iPod Touch and iPad. The hardest thing when building a Remoting-based iPhone application is to integrate the necessary C++ libraries into the Xcode project. This article shows how to build an iPhone client that works with the Remoting-based Stock Quote Server sample shown in our first Remoting Screencast.
The first step is configuring and building the POCO C++ Libraries and Remoting framework for the iPhone (and, optionally, the iPhone Simulator). The POCO C++ Libraries and Remoting source code distribution come with a build configuration for building static libraries for the iPhone. Note that shared libraries are not supported on the iPhone, as there is no way to distribute them via the iPhone App Store. A standard POCO C++ Libraries distribution contains a few libraries that cannot be used on the iPhone, due to a lack of required third-party libraries. These are the Data/ODBC and Data/MySQL libraries. The Crypto and NetSSL_OpenSSL libraries require OpenSSL static libraries, which are not included in the standard iPhone SDK. If required, they can be built from the OpenSSL sources, though. On the iPhone, we do not need the Remoting code generator (it cannot run there anyway), so we leave it out as well. So we end up with the following steps to configure and build the libraries:

$ cd poco-2009.2p4
$ ./configure --config=iPhone --no-samples --no-tests
--omit=CppParser,CodeGeneration,Remoting/RemoteGen,
Crypto,NetSSL_OpenSSL,Data/ODBC,Data/MySQL
$ make -s -j4

If required, we can also build the libraries for the iPhone Simulator, by simply using the iPhoneSimulator build configuration instead of the iPhone build configuration. Note that the iPhoneSimulator build configuration is only available with release 2009.2p4 or later.

$ ./configure --config=iPhoneSimulator --no-samples --no-tests
--omit=CppParser,CodeGeneration,Remoting/RemoteGen,
Crypto,NetSSL_OpenSSL,Data/ODBC,Data/MySQL
$ make -s -j4

Now that the static libraries for the iPhone have been built, we can start building the iPhone application with Xcode. For this sample, we simply create a new iPhone application project based on the View-based Application template.
After creating the template, the first step is to add the necessary POCO and Remoting libraries to the project. This can be simply done by dragging the libraries from the poco-2009.2p4/lib/iPhoneOS/armv6 directory into the project’s Frameworks folder.

Libraries

The next step is setting the header file and library search paths in the project’s settings.

HeaderPaths

For the library search paths, we want two separate search paths, one to be used when building for the iPhone, and another one to be used when building for the iPhone Simulator. This can be done by using build setting conditions in the project settings window.

LibraryPath1

LibraryPath2

LibraryPath3

After the search paths have been set up, we can start with the code. First, we need to register the Remoting Binary transport with the Remoting ORB. We do this in our application’s main() function. The main() function is implemented in file main.m. Since we’re going to mix C++ with Objective-C, we change the file’s extension to .M, which tells the compiler to assume Objective-C++ as source language.

main

Next, we add the Remoting client files generated by the Remoting code generator to the project. We simply use the files generated for the original client application — see the screencast for how to generate these files. Simply drag the header and source files into the project, and let Xcode copy them into the project directory.

GeneratedFiles

We can now work on the application’s user interface. The application has a text field for entering a stock symbol, a button for sending a quote request for the symbol to the Remoting server, and a label for displaying the result. We also add the necessary actions and outlets to the view controller.

IB

The final thing to implement is the getQuote() method in the view controller. This is the method that will use Remoting to send the stock quote request to the server. The important thing in this method is to catch all POCO-based exceptions, to avoid C++ exceptions spilling into the Cocoa framework. The necessary conversions from std::string to NSString and vice-versa are straightforward.

getQuote

What’s left to do is some code to handle the text field input, and a few other things typical for iPhone applications. Please note that the file extension for the source file containing the controller has been changed to .M, as the file contains Objective-C++ code.

The final application can be seen below.

App

The complete source code for this application can be downloaded here. The source code for the server and command-line client can be downloaded here and here.

Release 2009.2p2 is Available

2009.2p2 is another patch release for 2009.2 that fixes bugs in the Foundation, XML, Net, Crypto and NetSSL libraries. The release also includes performance improvements in the Fast Infoset library. OSP and Remoting have not been changed for this release. Upgrading is recommended.

Release 2009.2p1 is Available

2009.2p1 is a patch release for 2009.2 that fixes a few bugs introduced in previous releases. Upgrading is recommended for everyone using the Crypto, NetSSL and XML libraries. There are no changes to OSP, Remoting and our other commercial libraries and tools.

Release 2009.2 is Available!

Release 2009.2 of our C++ Libraries and Tools is now available. We have updated our evaluation packages as well. 2009.2 is based on POCO C++ Libraries release 1.3.6 (which was also released today) and contains major improvements to our Remoting toolkit. Upgrading to this release is highly recommended.

C++ SOAP Web Services With Remoting

Our second screencast shows how to build a SOAP web service in C++ with Applied Informatics Remoting. The sample project shown in the screencast is based on the StockQuotes server from the Remoting in 15 Minutes webcast, so please watch that one first if you haven’t yet. Apple QuickTime or another player capable of playing H.264 video is required to watch the screencast.


Screencast

Remoting in 15 Minutes

Our first screencast shows how to build a simple distributed C++ application based on Applied Informatics Remoting. You’ll learn how to write the service class, how to configure and run the code generator, and how to write the client and server applications. All in just 15 minutes. Apple QuickTime or another player capable of playing H.264 video is required to watch the screencast.


Screencast

Where to Put The OSP CodeCache Directory

One of the questions that comes up frequently when installing an OSP-based application on an end-user system is where to put the OSP codeCache. The OSP framework itself does not care where the codeCache is located, so you’re basically free to put it wherever you’d like. Of course, there are system-specific conventions and restrictions where such things like the codeCache should or can be stored. Also, the location will be different whether your application is a server application that runs in the background, or an interactive desktop application.
For example, on Windows, the codeCache should go into the AppData\Local\ directory within the user’s home directory for a desktop application. If the application runs as a Windows service, another directory might be more appropriate — in this case it might be possible to put the codeCache into the Program Files folder. On a Linux system, for an interactive application, the codeCache should go into a hidden application-specific directory within the user’s home directory, whereas on Mac OS X, ~/Library/Application Support/ is the right place. For a Unix server application, /var/cache/ is a good place.
To make configuring the codeCache location in the application’s configuration file easier, it is a good idea to define a configuration property in your application that makes the path to the directory containing the codeCache available. Following is some example code that shows how to do this for a Windows application.

Following is some sample code that determines an appropriate directory for holding the codeCache on Windows, Mac OS X and other Unix platforms, for desktop applications.

std::string findApplicationDataDir(
    const std::string& vendorName,
    const std::string& applicationName)
{
#if POCO_OS != POCO_OS_WINDOWS_NT
    wchar_t wpath[MAX_PATH];
    HRESULT rc = SHGetFolderPathW(
        NULL,
        CSIDL_LOCAL_APPDATA | CSIDL_FLAG_CREATE,
        NULL, SHGFP_TYPE_CURRENT,
        wpath);
    if (SUCCEEDED(rc))
    {
        std::string localAppData;
        Poco::UnicodeConverter::toUTF8(wpath, localAppData);
        Poco::Path path(localAppData);
        path.makeDirectory();
        path.pushDirectory(vendorName);
        path.pushDirectory(applicationName);
        return path.toString();
    }
    else return config().getString("application.dir");
#elif POCO_OS != POCO_OS_MAC_OS_X
    Poco::Path path(Poco::Path::home());
    path.pushDirectory("Library");
    path.pushDirectory("Application Support");
    path.pushDirectory(vendorName);
    path.pushDirectory(applicationName);
    return path.toString();
#else
    Poco::Path path(Poco::Path::home());
    path.pushDirectory("." + vendorName);
    path.pushDirectory(applicationName);
    return path.toString();
#endif
}

Note: for the above code to work on Windows, you’ll need to #include <shlobj.h>, as well as #include “Poco/UnicodeConverter.h” and link with shell32.lib.
If you change the BundleServer’s initialize() function to look like below, then you can refer to that directory in your application configuration file.

void initialize(Application& self)
{
    std::string appDataDir(findApplicationDataDir(
            "MyCompany", "MyApplication"));
    config().setString("application.dataDir", appDataDir);
    loadConfiguration();
    Application::initialize(self);
}

This code determines the data directory and stores the path in the application.dataDir configuration property.
In the application properties file, you can now specify:

osp.codeCache = ${application.dataDir}codeCache