Server API Documentation - LemontechSA-backup/TideSDK GitHub Wiki

Note: All server API:s are being re-designed for 1.4.x series. This document is useful to understand the legacy API:s only.

TideSDK 1.3.1 Server API Documentation

For anyone looking to set up a server backend from which their app can query updates, track analytics etc. Some initial server code can be found on https://github.com/neam/TideSDK-Server

The common request url format is:

http://baseurl/{resource}-{method}

Reverse-engineered API definitions

Update process

The SDK will query the server with app metadata, receive one or more available updates in a list, and then proceed to install the first one in the list in case its version number is greater than the currently installed version.

The actual update is performed by writing the new manifest file into a file called “.update” in the app base directory, which will cause the installer to download the latest update upon restart.

Sources: https://github.com/TideSDK/TideSDK/wiki/Packaging-service (thanks!), and the SDK source code (tinetworkmodule.js).

Update check

Query url:

Ti.App.getStreamURL("release-list");

Client SDK example request:

      updateCheck('app-update', Ti.App.getVersion(), function (success, update) {
        if (success && Ti.UpdateManager.compareVersions(
        update.version, Ti.App.getVersion()) > 0) {
          updateDetected(update);
        }
      });

Query parameters:

Method: POST
version - Ti.App.getVersion()
name - 'app-update'
mid - Ti.Platform.id (example: ‘841b4cfedc1d13e027bf0c56a0cb7d8e’)
limit - 1 (default in Client SDK)
guid - Ti.App.getGUID() (example: ‘0d776399-a82e-48c5-a711-5d0f158d4cfe’)
os - Ti.platform (example: ‘osx’)
ostype - Ti.Platform.ostype (example: ‘32bit’)

Response:

{
        “success”: “true”,
        “releases”: [
                {
                        “version”: "2.1.3.GA",
                        “manifest”: “MANIFEST CONTENTS OF UPDATED APP”,
                        “release_notes”: “app:\/\/CHANGELOG.txt”
                }
        ]
}

Update download upon restart

The actual update will only be downloaded and installed upon restart of the app. The actual restart command seems broken, but the user can manually restart the app, and then the update process will begin with requesting the actual update zip.

Query url:

Ti.App.getStreamURL("release-download"); //http://api.appcelerator.net/p/v1/release-download

Query parameters:

Method: GET
os - Ti.platform
osver - 
tiver
mid - Ti.Platform.id
aid
guid - Ti.App.getGUID()
ostype - Ti.Platform.ostype
osarch
name - 'app_update' ← Note: Different from update check, which was “app-update”
version - the version that is requested for download
uuid

Example query parameters (albeit POST-encoded):

?os=osx&osver=12.2.0&tiver=1.3.1-beta&mid=841b4cfedc1d13e027bf0c56a0cb7d8e&aid=org.gapminder.desktop&guid=0d776399-a82e-48c5-a711-5d0f158d4cfe&ostype=32bit&osarch=x86_64&name=app_update&version=0.0.3&uuid=353AACB5-A36C-406A-8A67-33CD45E36550

Response:

The update zip, ie appupdate.zip.

SDK Updates

Client needs to specifically start listening:

Titanium.UpdateManager.startMonitor(['sdk'],function(details) {
// Handle sdk update when available
});

(in startMonitor)
updateCheck(components[c], null, function (success, details) {})

Query url:

Ti.App.getStreamURL("release-list");

Query parameters:

Method: POST
version - null
name - ‘sdk’
mid - Ti.Platform.id
limit - 1 (default in Client SDK)
guid - Ti.App.getGUID()
os - Ti.platform
ostype - Ti.Platform.ostype

Appcelerator sample for mobilesdk:

https://api.appcelerator.net/p/v1/release-list

Example response:

{
        "success":true,
        "releases":[{
                "build_type":"64bit_i386",
                "name":"sdk",
                "guid":"05645B49-C629-4D8F-93AF-F1CF83200E34",
                "version":"1.3.0",
                "os":"linux",
                "url":"http:\/\/api.appcelerator.net\/p\/v1\/release-download?token=X4yyckn0",
                "checksum":"ee720059091efbe1efd183166cb90cbc",
                "children":null
        },{
                "build_type":"32bit_i386",
                "name":"mobilesdk",
                "guid":"05645B49-C629-4D8F-93AF-F1CF83200E34",
                "version":"2.1.3.GA",
                "os":"linux",
                "url":"http:\/\/api.appcelerator.net\/p\/v1\/release-download?token=C4yyck20",
                "checksum":"ee720059091efbe1efd183166cb90cbc",
                "children":null
        },
etc...

Analytics

The SDK API includes five methods for tracking five different types of analytics: http://tidesdk.multipart.net/docs/user-dev/generated/#!/api/Ti.Analytics

All of these are then submitted to the backend All of these methods created standard events in the following format:

{
      type: type,
      event: event,
      data: data
}

These were sent as POST parameters to the backend, together with a lot of information:

    AddQueryParameter(baseData, "mid", PlatformUtils::GetMachineId(), true);
    AddQueryParameter(baseData, "guid", app->guid);
    AddQueryParameter(baseData, "app_name", app->name);
    AddQueryParameter(baseData, "app_id", app->id);
    AddQueryParameter(baseData, "app_version", app->version);
    AddQueryParameter(baseData, "sid", DataUtils::GenerateUUID());
    AddQueryParameter(baseData, "mac_addr", PlatformUtils::GetFirstMACAddress());
    AddQueryParameter(baseData, "osver", Poco::Environment::osVersion().c_str());
    AddQueryParameter(baseData, "platform", OS_NAME);
    AddQueryParameter(baseData, "version", PRODUCT_VERSION);
    AddQueryParameter(baseData, "os", Poco::Environment::osName().c_str());
    AddQueryParameter(baseData, "ostype", OS_TYPE);
    AddQueryParameter(baseData, "osarch", Poco::Environment::osArchitecture().c_str());
    AddQueryParameter(baseData, "oscpu", 
        Poco::NumberFormatter::format(PlatformUtils::GetProcessorCount()));
    AddQueryParameter(baseData, "un", PlatformUtils::GetUsername());
    AddQueryParameter(baseData, "ip", NetworkBinding::GetFirstIPAddress());
    AddQueryParameter(baseData, "ver", SPEC_VERSION);

    // The 'tz' property is the amount of minutes to add to local time to get
    // UTC time. According to: http://pocoproject.org/docs/Poco.Timezone.html
    // local time = UTC + utcOffset() + dst().
    AddQueryParameter(baseData, "tz", Poco::NumberFormatter::format(
        -(Poco::Timezone::utcOffset() + Poco::Timezone::dst()) / 60));

Query details:

    SET_CURL_OPTION(this->curlHandle, CURLOPT_POST, 1);
    this->url = app->GetStreamURL("https") + "/app-track";

Query parameters:

Method: POST
type
event
data
mid
guid
app_name
app_id
app_version
sid
mac_addr
osver
platform
version
os
ostype
osarch
oscpu
un
ip
ver
tz - The amount of minutes to add to local time to get UTC time. According to: http://pocoproject.org/docs/Poco.Timezone.html

Response:

CURLE_OK is all that is required, so http status code 200