# Overview of SkypeKit Classes

All the wrapper classes roughly fall into 5 categories:

- Skype class
- Helper classes
- SkypeKit classes
- List classes
- Reference classes

## Helper Classes

Helper classes are basically type primitives. Having our own primitives minimizes external dependencies and makes the SDK as platform-independent as possible. All helper class names start with the prefix SE - SEString, SEStringList, SEIntList etc. These classes should be self-explanatory. For example, SEString can be used in normal string operations by typecasting it like this:

    SEString SomeString;
    printf("%s", (const char*)SomeString);

## Skype Class

This is the wrapper's main class. It provides access to Contacts, Conversations, audio-video related methods and more or less everything else. Initialisation and cleanup sequences of Skype class should look like this:

    // Initialisation
    skype->init(keyBuf, inetAddr, portNum, "streamlog.txt");
    skype->start();
    ...
    // Finalisation
    skype->stop();
    delete skype;

The first argument of Skype::init - the keyBuf - a null-terminated character array containing a valid SkypeKit key pair, which you can get from developer.skype.com website. The inetAddr is normally 127.0.0.1 (localhost) and default port for communication with the runtime is 8963.

## SkypeKit Classes

SkypeKit classes represent objects in SkypeKit Runtime, such as Account, Conversation, Message etc.

All the SkypeKit class instances are reflections of corresponding objects in the SkypeKit Runtime. They are descended from the SEObject class, which implements basic property accessors, cache access and anything else that is common to all the SkypeKit objects. When the SkypeKit Runtime spawns an instance of some class, that instance may or may not be communicated to the wrapper. (Not all objects are sent over immediately, to conserve IPC bandwidth.) Thus, you do not normally construct SkypeKit objects (such as Account, Conversation, or even Message objects). All of those are constructed by the wrapper, as the corresponding objects are created in the SkypeKit Runtime. There is only one exception: your Skype object. All other SkypeKit class instances will be given to you, pre-constructed, as return arguments of some SkypeKit wrapper method or in event callbacks.

NB! The object references can be returned as nulls if the method that was supposed to produce them failed to execute or if the object in question was deemed to be unnecessary by SkypeKit Runtime. You should never assume that an object you get back from a method call actually exists.

These objects are returned to you inside a class-specific reference container class (example: MessageRef for Message). These reference containers can be thought of and used as pointers. For more information about reference classes, see below.

The SkypeKit classes are provided as parents to your own classes, even if just to implement the OnChange event callback, to get access to property change events. In anything more complicated than a quick test client, you should rarely use SkypeKit classes directly.

The Skype class owns the instantiation of the classes. To introduce your own behaviour into those classes you will need to inherit from them and override existing methods. In addition to declaring a new child class, you will also need to override its corresponding Skype::new<Classname> method, since objects are generated as responses to what happens in SkypeKit Runtime. You do not actually get to call constructors for your own classes. Those constructors are called by the wrapper, in response to events, runtime method calls and property update messages. For the wrapper to know what constructors to call, those (child) classes need to be registered. You register your own class with the wrapper when you override the new<Classname> methods by for example, telling Skype::newMessage to return as a MyMessage instance instead.

As the instances are only accessible through references to offload from memory management, you may need to downcast the Skypekit references to references to you own classes to access your own functions. Do this by using the pattern typedef DRef<YourDerivedClass, SkypeKitClass> Ref; inside your derived class definition.

Example: to detect whether your account login command actually worked, you would need to catch the Account class OnChange event and insert your code into it. For this you will need to derive your own child class from Account and override the Account::OnChange virtual method.

    class MyAccount : public Account
    {
    public:
       typedef DRef<MyAccount, Account> Ref;
       MyAccount(unsigned int oid, SERootObject* root);
       ~MyAccount() {};
       void OnChange(int prop);
    };

The typedef in that declaration will make your MyAccount work with reference containers. Implementation part of the OnChange callback would look like this:

    void MyAccount::OnChange(int prop)
    {
        if (prop == Account::P_STATUS)
        {
           Account::STATUS LoginStatus;
           GetPropStatus(LoginStatus);
           if (LoginStatus == Account::LOGGED_IN)
            {
                > insert your code here <
            };
        };
    };

The int argument in OnChange callback will give you the ID of the property that changed. Note that there are no individual callbacks for class property change events. Each class only has one OnChange event, in which you will need to have a switch, depending on the value of the prop argument. GetPropStatus will give you the current value of the property.

Now, to register your MyAccount class with Skype, you will also need to derive your own child class from Skype, with newAccount method now returning MyAccount rather than Account instance.

    class MySkype : public Skype
    {
    public:
       MySkype() : Skype() {}
       ~MySkype() {}
       Account* newAccount(int oid) {return new MyAccount(oid, this);}
    };

Note on object lifecycle: as you are not constructing the objects, you are also not responsible of destructing them. Memory management of wrapper objects and properties is handled by the wrapper. The only object you should explicitly delete is your Skype object.

## List Classes

List classes - collect either SkypeKit objects or helper primitives. SE* list classes do not need to be explicitly constructed before passing them into SkypeKit methods. The item count in these lists can be accessed via .size() function. A basic loop across a list looks like this:

    SEStringList ExistingAccounts;
    skype->GetExistingAccounts(ExistingAccounts);
    for (int i = 0; i < ExistingAccounts.size(); i++)
    {
        printf("%d. %s\n", i, (const char*)ExistingAccounts[i]);
    };

## Reference Classes

Each SkypeKit class and list class whose items are SkypeKit class instances, have corresponding reference classes. Contact class, for example, has a corresponding reference class named ContactRef. There is also another class - ContactRefs that is basically a list of ContactRef items. All the *Ref classes can be treated as pointers to objects of corresponding SkypeKit class.

Reference classes enable us to keep track of objects in the wrapper via reference counting and remove unreferenced objects from the wrapper's object cache.

So, all the wrapper objects are returned to your UI code in reference containers. For example, Skype::GetAccount method does not return an Account object. Instead, it returns an AccountRef. So, you will have to write your code like this:

    SEString SomeAccountName = "somename";
    MyAccount::Ref SomeAccount;
    skype::GetAccount (SomeAccountName, SomeAccount);
    SomeAccount->LoginWithPassword(SomePassword, false, true);

All Classes Files Functions Variables Typedefs Enumerations Enumerator Friends Defines

(c) Skype Technologies S.A. Confidential/Proprietary

Last updated: Fri Mar 16 2012