• 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.

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.

$ 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.

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

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.

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.

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.

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.

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.

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.

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.

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