I was writing a program to run on my television and encountered a scenario that I’ve encountered many times before; an HTML enabled device supports a JavaScript standard that is older than the one that I would like to use. The easiest workaround for this is to use a tool that will compile from a more recent version of JavaScript (or something similar) back to the version that is supported by the hardware. This is something I’ve done when developing for BrightSign and other devices.

For targeting the Tizen based Television I decided that I would use TypeScript to accomplish this; in addition to getting access to some more recent features that can be found in JavaScript there’s we also get type checking.

A bit of work was required to get this working though. On my first attempt I tried includint the TypeScript files in the same folder as the project. This doesn’t work;when the project is being compiled the compiler will try to take these files and package them in the solution. This isn’t something that we want to happen. It’s necessary to have these files in a folder that is outside of the project folder to prevent this from happening. I moved the files and made a TypeScript configuration file that specified the destination to which I wanted the resulting JavaScript files moved.

{
  "compilerOptions": {
    /* Basic Options */
    "target": "es2015",
    "module": "commonjs",  
    "sourceMap": false,   
    "outDir": "../tizenWorkspace/projectName/js"
    "strict": true,                           
    "noImplicitAny": true,                 
  }
}

This almost works. The next problem encountered is that when there is a reference to anything on the tizen object the compiler will complain about it net having been declared. The tizen object, not being a web standard object, is not something that is recognized by the compiler. There are two ways to handle this project. A work around would be to declare the tizen object as being of type any. With this declaration the compiler will just ignore what ever we do with the object and not complain.

I made a TypeScript definition file named tizen.d.ts in which to place my definitions. TypeScript already has an understanding of the interface provided by the Window object. To augment this I declare another interface that will be merged with the understanding that TypeScript has and added a definition for the tizen member there.

declare	interface Window {  tizen:any }

That works, but that’s also eliminating some of the type safety features that that TypeScript has to offer. Instead of working around the problem I wanted to address it. I wanted to provide the type definitions for the Tizen object.

There’s a project called Definitely Typed in which contributors make TypeScript definitions that can be downloaded and shared to other developers that are targeting the same environment. At first glance there appears to be existing entries for targeting Tizen within the collection. But upon further inspection it turns out that the definitions that are there (at the time of the writing of this post) are for targeting a cross development tool that also supports Tizen. that’s not what I needed. Instead of relying on community provided definitions I’ll have to make my own. When I’m done though I may have a definition file that could be shared through Definitely Typed. Since that repository is constantly being updated I would encourage seeing what it has to offer before using the code that I provide here.

declare	interface Window {  tizen:ApplicationManager}

This is when I start my descent down the rabbit hole. To define the ApplicationManager interface that is implemented by the tizen object there are a number of other interfaces that must be defined. Those interfaces have dependencies on other interfaces.

The interfaces for the various objects are documented and can be found on a Tizen.org page. Browsing through it there are some types mentioned that ultimately are strings of some type of another. Within TypeScript we can make a declaration that is similar to a typedef for equating some custom type to another.

type ApplicationId = string;
type ApplicationContextId = string;
type PackageId = string;

There is also a frequently used callback type for successes and errors of callbacks. The links to the documentation for the functions’ call signatures are broken taking me to a 404 page. I was more generic with defining these in my type definitions until I can get the specifics of the actual accepted call signatures.

type SuccessCallback = (...args: any[]) => void;
type ErrorCallback = (...args: any[]) => void;

The rest of the definitions are interfaces and follow the same patterns. I’m showing a few of the interfaces closer to the root of the definitions.

declare	interface Window {  tizen:ApplicationManager}
declare var tizen:tizenInterface;

interface tizenInterface {
    application:ApplicationManager;
}

interface ApplicationManager { 
    getCurrentApplication():Application;

    kill(contextId:string,
              successCallback:SuccessCallback,
              errorCallback:ErrorCallback):void ;

    launch( id:string, //ApplicationId
                successCallback:SuccessCallback,
                errorCallback:ErrorCallback):void;
    launchAppControl(appControl:ApplicationControl,
                        id?:ApplicationId, //ApplicationId
                          successCallback?:SuccessCallback,
                          errorCallback?:ErrorCallback,
                          replyCallback?:ApplicationControlDataArrayReplyCallback):void ;
     findAppControl(appControl:ApplicationControl,
                        successCallback:FindAppControlSuccessCallback,
                        errorCallback:ErrorCallback):void;

    getAppsContext(successCallback:ApplicationContextArraySuccessCallback,
                        errorCallback:ErrorCallback):void ;
    getAppContext(contextId:string):ApplicationContext;
    getAppsInfo(successCallback:ApplicationInformationArraySuccessCallback,
                     errorCallback?:ErrorCallback):void;
    getAppInfo(id?:ApplicationId ):ApplicationInformation;
    getAppCerts(id?:ApplicationId ):Array;
    getAppSharedURI(id?:ApplicationId ):string;
    getAppMetaData(id?:ApplicationId ):Array;
    addAppInfoEventListener(eventCallback:ApplicationInformationEventCallback):number;
    removeAppInfoEventListener( watchId:number):void ;    
}

There are a lot more objects that could be defined for Tizen. If you’ve come along this article checkout the DefinitelyType archives first. If you don’t find Tizen devinitions there you can download the version of the video that I have from here.