Details

    • Type: New Feature
    • Status: Resolved
    • Priority: High
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: Release 5.0.0
    • Component/s: None
    • Labels:
      None

      Description

      Appcelerator Studio will no longer need to call ti info -t <platform> a bunch of times each minute. With the appc daemon, Studio can simply connect to the server over a WebSocket and query the system information as well as listen for changes.

      The appc daemon will ship with the appc cli, so Studio will not need to worry about installing the appc daemon. However, Studio will need to make sure appcd is running before trying to connect to it. If appcd is already running, the start operation immediately returns successfully.

      Note: appcd isn't guaranteed to be globally installed. You will want to manually invoke it by calling node /path/to/appcd start.

      This applies to all platforms: OS X, Linux, and Windows.

      Studio will need to open a WebSocket to 127.0.0.1 port 1732. Once the socket is open, it will need to send a request using the appcd protocol. It's pretty simple. To kick off a request, Studio needs to send a stringified JSON object containing a version, path, id, and optionally a data payload.

      Here's the JavaScript equivalent:

      socket.send(JSON.stringify({
          version: '1.0',
          path: '/system-info',
          id: '0'
      });
      

      The "version" must be 1.0.

      The "path" can be /system-info to get the info for ALL supported platforms (i.e. Android & iOS on OSX, Android & Windows on Windows, Android on Linux). The "path" may also contain the specific platform such as /system-info/ios or even platform specific info such as /system-info/ios/devices.

      The "id" must be a string containing a unique request id. It can be a sequential number (cast as a string) or a UUID. The purpose of the "id" is that a single WebSocket can service multiple simultaneous requests and "id" is the only way you can match up the response with the initial request. For example, the appcd client generates a UUID for each request and then registers that UUID with an event emitter so that responses to the request ID are emitted to the code that made the request. Studio can use whatever mechanism it wishes to match responses with requests.

      The "data" payload is optional. It's a JSON object containing additional information. It will allow Studio to specify additional request arguments and filtering options.

      The response is a stringified JSON object containing an id, data, and possibly a status.

      If the latest appc cli is not installed, and thus appc daemon is not installed, then Studio should continue to use the ti info method it does today.

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                kkolipaka Kondal Kolipaka (Inactive)
                Reporter:
                cbarber Chris Barber
                Reviewer:
                Prashanth Pedduri (Inactive)
              • Watchers:
                2 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: