Andrey Butov

This solution is for Windows and Mac. It was tested with Qt 5.5.

void setAppToStartAutomatically ( bool startAutomatically )
{
#if defined ( Q_OS_MAC )

    // Remove any existing login entry for this app first, in case there was one
    // from a previous installation, that may be under a different launch path.
    {
        QStringList args;
        args << "-e tell application \"System Events\" to delete login item\"" 
            + macOSXAppBundleName() + "\"";
        
        QProcess::execute("osascript", args);
    }

    // Now install the login item, if needed.
    if ( startAutomatically )
    {
        QStringList args;
        args << "-e tell application \"System Events\" to make login item at end " + 
            "with properties {path:\"" + macOSXAppBundlePath() + "\", hidden:false}";
        
        QProcess::execute("osascript", args);
    }

#elif defined ( Q_OS_WIN )

    QString key = "YouApplicationName";

    QSettings registrySettings(
        "HKEY_CURRENT_USER\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Run", 
        QSettings::NativeFormat);
    
    registrySettings.remove(key);

    if ( startAutomatically ) {
        registrySettings.setValue(key, QString("\"" + windowsAppPath() + "\""));
    }

    registrySettings.sync();

#endif
}


QString macOSXAppBundlePath()
{
#ifdef Q_OS_MAC
    QDir dir = QDir ( QCoreApplication::applicationDirPath() );
    dir.cdUp();
    dir.cdUp();
    QString absolutePath = dir.absolutePath();
    // absolutePath will contain a "/" at the end,
    // but we want the clean path to the .app bundle
    if ( absolutePath.length() > 0 && absolutePath.right(1) == "/" ) {
        absolutePath.chop(1);
    }
    return absolutePath;
#else
    return "";
#endif
}


QString macOSXAppBundleName()
{
#ifdef Q_OS_MAC
    QString bundlePath = macOSXAppBundlePath();
    QFileInfo fileInfo(bundlePath);
    return fileInfo.baseName();
#else
    return "";
#endif
}


QString windowsAppPath()
{
#ifdef Q_OS_WIN
    return QDir::toNativeSeparators(QCoreApplication::applicationFilePath());
#else
    return "";
#endif
}

Comments closed

I open sourced my simple drop-in library for working with Gravatar profile photos in Android.

The code is available on GitHub.

Comments closed

The standard approach to implementing a draggable/movable View in Android is to rely on DragShadowBuilder. For many situations, this would be the easiest approach. However, in some cases, where, for example, you need to modify the view as it is being dragged, DragShadowBuilder won’t do, as it’s just not flexible enough.

As part of a larger project, I created an alternate implementation of a draggable View, without the dependency on DragShadowBuilder. With this approach you have full access to the view being dragged (actually, the cached Bitmap image of the view), and, as such, the view can be modified while moving.

The code is available on GitHub.

Comments closed

In 2010, I wrote a utility for Antair that allowed us to easily view the email headers of any email in the BlackBerry inbox.

The application integrated nicely with the BlackBerry inbox, making it really simple to view the headers of any incoming email message.

We released the application as a free app shortly thereafter. From what I heard, quite a few system administrators have found a use for it.

Today, I cleaned up the code a bit, and released the project as open source.

Comments closed

I often build mobile apps that have a web app counterpart. Typically, during development, the web app is running on some local machine, while the mobile app is being tested on a device.

A common issue that arises with this setup is that the mobile app, being tested on a device, doesn’t know the host name of the machine where the local web app is running.

With web development, I would set up a hosts file on each machine, to let it know how to reach the other hosts. But with a mobile app, I can’t simply modify the hosts file on the device (well, you can, but you would need a jailbroken device).

There are various solutions to this, such as modifying your router settings, but I find it easier to just use an HTTP proxy.

Here is how I would test an iOS app, with a web app counterpart running on a local Windows machine named “athena”.

If I just run the web app on “athena”, and then run the iOS app on my iPhone, the iOS app would not be able to connect to the server running on “athena”, as the iPhone doesn’t know what or where “athena” is.

The idea here is to run an HTTP proxy on “athena”, and then have the iPhone route its network traffic through the HTTP proxy. Since the HTTP proxy runs on “athena”, it can read the hosts file on that machine, which has an entry pointing the name “athena” to something like 127.0.0.1. So, when the iPhone routes its network traffic through the proxy, the proxy can then resolve the name “athena”, and direct the request to the web app being served there.

It’s worth noting that the HTTP proxy does not need to run on the same machine as where the web app is running. The proxy can run on any local machine, as long as that machine has a hosts file with an entry for the location of the machine from which the web app is being served.

For Windows, the HTTP proxy I like to use is Fiddler.

After installing Fiddler, I go into options, and make sure “Act as system proxy on startup” is checked, and that “Allow remote computers to connect” is checked.

After that’s done, I go into the File menu and make sure “Capture traffic” is checked.

Fiddler is a great option on Windows. There are also great options for setting up local HTTP proxies on a Mac, such as the Charles HTTP proxy.

Once my HTTP proxy is running, it’s time to configure the iPhone to use that proxy. I will need to know the IP address of the machine where the HTTP proxy is running. In my case, the proxy is running on “athena”, which has the local IP address of 192.168.1.11. The Fiddler proxy is listening on port 8888 (this can be seen in the Fiddler settings dialog).

On iOS 7, to set the proxy, I go into Settings, then, Wi-Fi, and select my Wi-Fi network. I scroll toward the bottom of that screen to find the section for HTTP PROXY. I click on “Manual”, and enter the IP address (Server) and Port of the machine on which my HTTP proxy is running. I entered 192.168.1.11 for the Server, and 8888 for the Port.

That’s all. Now, when I run the mobile app on my iPhone, and the app wants to connect to the web app on “athena”, the network request is routed to the Fiddler HTTP proxy running on 192.168.1.11:8888, the proxy reads the hosts file, finds the entry for “athena”, and directs the traffic to the correct local machine.

This is an easy way to test your mobile apps against local web servers. Just don’t forget to disable the local HTTP PROXY setting on your iPhone before you leave the house!

Comments closed