Dashboard

QuickBlox Dashboard enables you to create new apps and manage your existing apps using Chat, Content, Push Notifications, Custom Objects, and Users modules. Get your application credentials (Application ID, Authorization Key, Authorization Secret, and Account Key) from here to launch the framework.

Application

QuickBlox application includes all you need to add real-time messaging and voice/video calling to your app including users, push notifications, file storage, etc. A user logs in to the app, reviews a list of dialogs, chooses a dialog, or creates their own, writes a message, and sends it to the dialog. Along with that, they can view chat history, configure pushes, and many more.

Each QuickBlox application has a unique Application ID used for the integration with your app. Along with Application ID you get Authorization Key, Authorization Secret, and Account Key required for initialization. These data are stored in the QuickBlox server database and can be subsequently identified on the server as a result of the successful initialization procedure.

📘

Keep in mind the points below:

All users in your QuickBlox application can communicate across multiple platforms. In other words, your iOS, Android, or web users can communicate with each other.

Each QuickBlox application is associated with its own users' database. Thus, users are not mixed up between different applications.

Only one QuickBlox application can be integrated into your app. This means that there is no need to create a single QuickBlox application for each platform individually.

Authentication

To access QuickBlox APIs a user needs to authenticate your application with the QuickBlox server. A token-based authentication is used to provide secure access to QuickBlox APIs. When the authenticity is verified, the server responds to the request with the access token that becomes a part of each subsequent request to the QuickBlox server.

A token is a piece of data identifying a user or application and providing temporary access to QuickBlox APIs. The token is valid only within the session it was generated. The session gets expired in 2 hours after the last request to the REST API.

There are two types of tokens: application session token and user session token. The application session token is limited to read-only permissions preventing changes to application data while the user session token is not restricted in permissions and allows for making edits to application data.

Users

Users are managed via the User module. A user is the one who can access all chat features of a QuickBlox application with their own unique ID. QuickBlox server authorizes a user by the user ID. When the user sends a login request to the server, the server queries the database to check for a match upon the request for connection.

A user can be assigned multiple tags. Set up user tags and address users separately in your app through the API or Dashboard. Tags can be managed via the user profile.

There are two user roles in QuickBlox API:

• Account owner is a user who has registered the application.
• API user is a user having the access to QuickBlox API and authorized to make requests to the QuickBlox server.

Chat

QuickBlox Chat runs over the XMPP protocol. To be able to use it, you should establish a real-time connection with the QuickBlox server. If the connection to the server is lost, the application gets automatically connected to the Chat server in order to receive messages in real-time.

Dialogs are the basis of chat activity. Users send messages to the dialog from where they get distributed to the opponent users. There are 3 dialog types:

• Private. A dialog for two participants. Created automatically upon the first message.
• Group. A dialog involving more than two participants. To start a group dialog, the user should create a group dialog and add a new participant in the new group dialog. A user who is invited to the group dialog can either accept or decline the invitation.
• Public. A dialog involving more than two participants. Any user can access this dialog without a preliminary invitation.

Messages are data pools that get published in the dialogs. They can contain any data - arrays, objects, numbers, and strings. They also can acquire read and delivered statuses. There are supported three types of messages:

• Text. By default, a message is considered as text.
• Media. There are available any types of attachments, audio, video, image, or other.
• Custom. A message can be extended with custom data such as location coordinates.

📘

Your application should be constantly connected to the Chat server to ensure that messages are always delivered efficiently.

Video Calling

In addition to messaging, QuickBlox allows you to add high-quality video calls to your apps. Our video calling API is built on WebRTC principles providing a simplified, secure communication channel including audio and video for web and mobile apps.

The communication is happening between peers representing camera devices. There are two peer types:

• Local peer is a device running the app right now.
• Remote peer is an opponent device.

Establishing real-time video communication between two peers involves 3 phases:

• Signaling. At this phase, the peers’ local IPs and ports where they can be reached (ICE candidates) are exchanged as well as their media capabilities and session control messages.
• Discovery. At this phase, the public IPs and ports at which endpoints can be reached are discovered by STUN/TURN server.
• Establishing a connection. At this phase, the data are sent directly to each party of the communication process.

The signaling is implemented over the XMPP protocol using QuickBlox Chat. So before starting to work with the Video Calling API, a connection to the QuickBlox Chat server is required to be established first.

To call users, you should initiate a call. As a result, a call session is created. A call session represents a room for real-time audio/video, data, and/or screen-share session, and is the basic building block for your video calling app.

To receive events associated with the call session and peer connection, the event listener is required to be set up. Thus, when your app gets disconnected from the server and tries to re-establish the XMPP connection with the QuickBlox server, the server notifies the app of the event through the event listener.

Each particular audio/video call has a unique session ID. This allows you to have more than one independent audio/video calls. QuickBlox SDK supports one-to-one calls and group calls with up to four peers.

If you want to make group calls, you can do it between a few users. Using WebRTC your device connects with each user in the call. It means that each device must handle as many connections as there are users in the current call.

This table shows how many connections your device must establish to make a group call with a different number of users in the call.

So as you can see, to make a call with 4 other participants each device has to handle 8 different connections to send and receive audio and video tracks to each other call participant. It requires high-performance devices.

The other solution we provide requires only 1 output and 1 input connection to make up to 10 users multi-user call.

🚧

Please use this WebRTC Video Calling to make the Group Calls with 4 or fewer users. Because of Mesh architecture we use for multi-point where every participant sends and receives its media to all other participants, the current solution supports group calls with up to 4 people.

You can also set up a connection with up to 12 people in the call at the same time. This feature is available only for Enterprise plans only. If you need to make group calls with more than 4 users, please contact us for more details on the feature.

Video Conference

QuickBlox provides a Multiparty Video Conferencing solution allowing to set up a video conference between 10-12 people. It is built on top of WebRTC SFU technologies.

To call users, you should create a conference session. To process events associated with the session state, the event listener is required to be implemented. Once a session is created, you can interact with the video conferencing API.

Each particular conference session has a unique session ID. This allows you to have more than one independent conference calls.

QuickBlox Video Conferencing API is based on top of regular Video Calling API, so we recommend getting familiar with it first.

🚧

This feature is available for customers on the Enterprise plan only. Take advantage of Enterprise features to unlock new value and opportunities for users. For more information and if you want to request a Demo, please contact us by mail: [email protected].

Content

With the QuickBlox content module, a user can store rich chat attachments, app content, and settings without having to re-publish it.

A file is a dedicated entity within the system. It has a unique file ID that is generated automatically by the server upon file creating. The file gets uploaded to a cloud storage. After a file is declared as uploaded, a URL of the file is returned by the server. Following the URL, the file can be subsequently downloaded. There are two types of file URLs that can be obtained:

• Public URL allows anyone to access the file, no authorization token is needed.
• Private URL can be accessed only by the QuickBlox user with a session token.

You can upload, delete, edit files as well as view the list of all available files via the Dashboard or API requests.

Push Notifications

Our SDK allows you to build an app that can receive push notifications. As a result, your users will always be informed with timely content even though the app is closed or running in the background. QuickBlox provides a way to set up offline messaging for your app. This means that a push notification will be automatically delivered to the opponent device only when it is fully offline.

Push notifications for your apps are sent using FCM (Google's Firebase Cloud Messaging) or APNs (Apple Push Notification service). When a message is sent to the QuickBlox server through the SDK, the server communicates with APNs or FCM regarding the message. The logic is built around two main concepts:

• Subscription. A device should be subscribed to APNs and FCM services. The subscription parameters (device id, private id, app id, notification channel, etc.) are sent by the QuickBlox server within a push subscription request to the Google server and Apple server. Once the device is subscribed for the services, the APNs or FCM delivers a notification to it.

• Event. The event is a dedicated entity within the system. Each event has a unique event ID generated automatically by the server after event creation. Once the event is created, the server initiates sending a push notification.

Custom Objects

QuickBlox Custom Objects module represents a key-value storage enabling you to create any data structure using the Dashboard or API. There are two key concepts in Custom Objects:

• Class represents your schema and contains field names and types.
• Record represents data you put into your schema.

You will be able to create classes containing different field types (integer, string, float, boolean, etc.) as well as set relations between different classes. You can also set access control for the class to define who can access the records in the class and make edits to it.