SFS2X Docs / Overview / using-the-documentation
» How to use the documentation and examples
This document provides a quick tutorial on how to obtain the best from the provided SmartFoxServer 2X (aka SFS2X) documentation. Our first recommendation is to consult the articles provided in this section before proceeding with the examples and technical docs.
Whether you are a seasoned SmartFox developer or you have just moved your first step in the multiplayer world, you will find the initial articles particularly useful to get started. The Getting Started section will guide you in the client and server setup phase while the Advanced Topics section provides an insight on the new Extension system, the server API and lots more.
» The Examples
We're strong advocates of our patent-pending Learning-While-Doing™ methodology. Of course we are kidding about the patent thing, but we are serious about learning by following a series of examples of increasing complexity.
SmartFoxServer comes packed full with simple and advanced examples made in ActionScript 3, Objective-C, Java and C#, where you can learn the very basics and quickly move to the more interesting and powerful features.
Each example comes with source code for both client and server side and attempts to build on the previous examples in the serie to provide a sense of continuity.
» The Java/AS3/C# doc
Once you have gotten an idea of what the new SmartFoxServer 2X can do for you and tested some of the examples, you will be probably eager to start playing with the API and prototyping some ideas. This is of course the moment where the ActionScript/C#/etc docs (client) and Javadoc (server) will come in handy.
Below follows a list of tips to get started with API without getting lost in the host of packages and classes that you will encounter.
» The client side
The client-side API main object is the SmartFox class, found in the com.smartfoxserver.v2 (AS3), Sfs2X (C#) or sfs2x.client (Java) package. This is the main entry point of the client API. This object allows you to manage your event listeners, start a connection and send requests via the send() method.
Another important section of the client framework is thecom.smartfoxserver.v2.requests (AS3), Sfs2X.Requests (C#) or sfs2x.client.requests (Java) package. Here you will find dozens of different classes, each one representing a specific client request such as LoginRequest, JoinRoomRequest, SendPublicMessageRequest and many more. There are also two separate subpackages, game and buddylist (Game and Buddylist for C# API), where you can find advanced API for building games and managing buddy lists respectively.
» The server side
The classes that act as entry points to the server-side API are found in the com.smartfoxserver.v2.api packge. Specifically:
- SFSApi: here you find dozens of methods for the most common server operations: login, create/remove rooms, send messages, join users, set variables, etc.
- SFSGameApi: game specific API
- SFSBuddyApi: buddy list specific API
While browsing the Javadoc you might at times find fields or methods with little to no documentation. Besides a few exceptions due to the current state of the documentation, this is done on purpose to indicate that these methods shouldn't be used directly. The API classes already use these lower level methods for you behind the scenes and you don't have to deal with them directly. Using them might break the proper SFS2X functioning.
» Programming to interfaces
In general, throughout the client and server API, you will notice that all important classes of the framework are backed by an interface.
- SFSZone implements Zone
- SFSRoom implements Room
- SFSUser implements User
- SFSBuddy implements Buddy
- SFSObject implements ISFSObject
- SFSArray implements ISFSArray
- SFSRoomVariable implements RoomVariable
- SFSUserVariable implements UserVariable
You will also notice that the whole framework uses these interfaces in almost each and every method signature or return type.
We would like to encourage and emphasize the use of these interfaces in your code too. The reason is that this helps swapping different implementations easily and without side effects. In future release we might introduce new implementations to these interfaces which will affect your code minimally if you stick to this habit as much as possible.