diff --git a/data/core.telegram.org/tdlib/docs.html b/data/core.telegram.org/tdlib/docs.html index 7830ff3297..a6dad42d1a 100644 --- a/data/core.telegram.org/tdlib/docs.html +++ b/data/core.telegram.org/tdlib/docs.html @@ -83,7 +83,6 @@ $(function() {
TDLib
has many advantages. Notably TDLib
is:
TDLib
can be used on Android, iOS, Windows, macOS, Linux, FreeBSD, OpenBSD, NetBSD, Windows Phone, WebAssembly, watchOS, tvOS, Tizen, Cygwin. It should also work on other *nix systems with or without minimal effort.TDLib
can be used on Android, iOS, Windows, macOS, Linux, FreeBSD, OpenBSD, NetBSD, illumos, Windows Phone, WebAssembly, watchOS, tvOS, Tizen, Cygwin. It should also work on other *nix systems with or without minimal effort.TDLib
can be easily used with any programming language that is able to execute C functions. Additionally it already has native Java (using JNI
) bindings and .NET (using C++/CLI
and C++/CX
) bindings.TDLib
takes care of all network implementation details, encryption and local data storage.TDLib
instance handles more than 24000 active bots simultaneously.The simplest way to build TDLib
is to use our TDLib build instructions generator. You need only to choose your programming language and target operating system to receive complete build instructions.
In general, you need to install all TDLib
dependencies as described in Installing dependencies. Then enter directory containing TDLib
sources and compile them using CMake:
In general, you need to install all TDLib
dependencies, enter directory containing TDLib
sources and compile them using CMake:
To build TDLib
on low memory devices you can run SplitSource.php script before compiling main TDLib
source code and compile only needed targets:
In our tests clang 6.0 with libc++ required less than 500 MB of RAM per file and GCC 4.9/6.3 used less than 1 GB of RAM per file.
-xcode-select --install
.TDLib
with CMake as explained in building. You will likely need to manually specify path to the installed OpenSSL to CMake, e.g., TDLib
dependencies using vcpkg: TDLib
with CMake as explained in building, but instead of cmake -DCMAKE_BUILD_TYPE=Release ..
use To build 32-bit/64-bit TDLib
using MSVC, you will need to additionally specify parameter -A Win32
/-A x64
to CMake. To build TDLib
in Release mode using MSVC, you will need to additionally specify parameter --config Release
to the cmake --build .
command.
For C++ projects that use CMake, the best approach is to build TDLib
as part of your project or to install it system-wide.
There are several libraries that you could use in your CMake project:
For example, part of your CMakeLists.txt may look like this:
Or you could install TDLib
and then reference it in your CMakeLists.txt like this:
See example/cpp/CMakeLists.txt.
+For example, part of your CMakeLists.txt may look like this:
Or you could install TDLib
and then reference it in your CMakeLists.txt like this:
See example/cpp/CMakeLists.txt.
TDLib
provides native Java interface through JNI. To enable it, specify option -DTD_ENABLE_JNI=ON
to CMake.
See example/java for example of using TDLib
from Java and detailed build and usage instructions.
TDLib
provides native .NET interface through C++/CLI
and C++/CX
. To enable it, specify option -DTD_ENABLE_DOTNET=ON
to CMake. .NET Core supports C++/CLI
only since version 3.1 and only on Windows, so if older .NET Core is used or portability is needed, then TDLib
JSON interface should be used through P/Invoke instead.
See example/csharp for example of using TDLib
from C# and detailed build and usage instructions. See example/uwp for example of using TDLib
from C# UWP application and detailed build and usage instructions for Visual Studio Extension "TDLib for Universal Windows Platform".
When TDLib
is built with TD_ENABLE_DOTNET
option enabled, C++
documentation is removed from some files. You need to checkout these files to return C++
documentation back:
TDLib
provides efficient native C++, Java, and .NET interfaces. But for most use cases we suggest to use the JSON interface, which can be easily used with any programming language that is able to execute C functions. See td_json_client and td_log documentation for detailed JSON interface description, the td_api.tl scheme or the automatically generated HTML documentation for a list of all available TDLib
methods and classes.
TDLib
provides efficient native C++, Java, and .NET interfaces. But for most use cases we suggest to use the JSON interface, which can be easily used with any programming language that is able to execute C functions. See td_json_client documentation for detailed JSON interface description, the td_api.tl scheme or the automatically generated HTML documentation for a list of all available TDLib
methods and classes.
TDLib
JSON interface adheres to semantic versioning and versions with the same major version number are binary and backward compatible, but the underlying TDLib
API can be different for different minor and even patch versions. If you need to support different TDLib
versions, then you can use a value of the version
option to find exact TDLib
version to use appropriate API methods.
See example/python/tdjson_example.py for an example of such usage.
Returns a string representation of the TDLib API object.
Returns a string representation of a TDLib API object.
[in] | value | The object. |
Returns a string representation of the TDLib API object.
Returns a string representation of a TDLib API object.
T | Object type, auto-deduced. |
std::string td::td_api::to_string | +( | +const std::vector< object_ptr< T >> & | +values | ) | ++ |
Returns a string representation of a list of TDLib API objects.
T | Object type, auto-deduced. |
[in] | values | The objects. |
C interface for interaction with TDLib via JSON-serialized objects. Can be used to easily integrate TDLib with any programming language which supports calling C functions and is able to work with JSON.
-The JSON serialization of TDLib API objects is straightforward: all API objects are represented as JSON objects with the same keys as the API object field names. The object type name is stored in the special field "@type" which is optional in places where type is uniquely determined by the context. Fields of Bool type are stored as Boolean, fields of int32, int53, and double types are stored as Number, fields of int64 and string types are stored as String, fields of bytes type are base64 encoded and then stored as String, fields of array type are stored as Array. The main TDLib interface is asynchronous. To match requests with a corresponding response a field "@extra" can be added to the request object. The corresponding response will have an "@extra" field with exactly the same value.
+The JSON serialization of TDLib API objects is straightforward: all API objects are represented as JSON objects with the same keys as the API object field names. The object type name is stored in the special field "@type" which is optional in places where type is uniquely determined by the context. Fields of Bool type are stored as Boolean, fields of int32, int53, and double types are stored as Number, fields of int64 and string types are stored as String, fields of bytes type are base64 encoded and then stored as String, fields of array type are stored as Array.
+The main TDLib interface is asynchronous. To match requests with a corresponding response, the field "@extra" can be added to the request object. The corresponding response will have an "@extra" field with exactly the same value. Each returned object will have an "@client_id" field, containing the identifier of the client for which a response or an update was received.
+A TDLib client instance can be created through td_create_client_id. Requests can be sent using td_send and the received client identifier. New updates and responses to requests can be received through td_receive from any thread after the first request has been sent to the client instance. This function must not be called simultaneously from two different threads. Also note that all updates and responses to requests must be applied in the order they were received for consistency. Some TDLib requests can be executed synchronously from any thread using td_execute. TDLib client instances are destroyed automatically after they are closed. All TDLib client instances must be closed before application termination to ensure data consistency.
+General pattern of usage:
Alternatively, you can use old TDLib JSON interface, which will be removed in TDLib 2.0.0.
+Objects and functions serialization to JSON is the same for both JSON interfaces.
+The main TDLib interface is asynchronous. To match requests with a corresponding response a field "@extra" can be added to the request object. The corresponding response will have an "@extra" field with exactly the same value.
A TDLib client instance can be created through td_json_client_create. Requests then can be sent using td_json_client_send from any thread. New updates and request responses can be received through td_json_client_receive from any thread. This function must not be called simultaneously from two different threads. Also note that all updates and request responses must be applied in the order they were received to ensure consistency. Given this information, it's advisable to call this function from a dedicated thread. Some service TDLib requests can be executed synchronously from any thread by using td_json_client_execute. The TDLib client instance can be destroyed via td_json_client_destroy.
General pattern of usage:
Go to the source code of this file.
+Typedefs | |
typedef void(* | td_log_message_callback_ptr) (int verbosity_level, const char *message) |
Functions | |
int | td_create_client_id () |
void | td_send (int client_id, const char *request) |
const char * | td_receive (double timeout) |
const char * | td_execute (const char *request) |
void | td_set_log_message_callback (int max_verbosity_level, td_log_message_callback_ptr callback) |
void * | td_json_client_create () |
void | td_json_client_send (void *client, const char *request) |
void | td_json_client_destroy (void *client) |
int | td_create_client_id () |
void | td_send (int client_id, const char *request) |
const char * | td_receive (double timeout) |
const char * | td_execute (const char *request) |
typedef void(* td_log_message_callback_ptr) (int verbosity_level, const char *message) | +
A type of callback function that will be called when a message is added to the internal TDLib log.
+verbosity_level | Log verbosity level with which the message was added (-1 - 1024). If 0, then TDLib will crash as soon as the callback returns. None of the TDLib methods can be called from the callback. |
message | Null-terminated string with the logged message. |
int td_create_client_id | +( | +) | ++ |
Returns an opaque identifier of a new TDLib instance. The TDLib instance will not send updates until the first request is sent to it.
void td_send | +( | +int | +client_id, | +
+ | + | const char * | +request | +
+ | ) | ++ |
Sends request to the TDLib client. May be called from any thread.
[in] | client_id | TDLib client identifier. |
[in] | request | JSON-serialized null-terminated request to TDLib. |
const char* td_receive | +( | +double | +timeout | ) | ++ |
Receives incoming updates and request responses. Must not be called simultaneously from two different threads. The returned pointer can be used until the next call to td_receive or td_execute, after which it will be deallocated by TDLib.
[in] | timeout | The maximum number of seconds allowed for this function to wait for new data. |
const char* td_execute | +( | +const char * | +request | ) | ++ |
Synchronously executes a TDLib request. A request can be executed synchronously, only if it is documented with "Can be called synchronously". The returned pointer can be used until the next call to td_receive or td_execute, after which it will be deallocated by TDLib.
[in] | request | JSON-serialized null-terminated request to TDLib. |
void td_set_log_message_callback | +( | +int | +max_verbosity_level, | +
+ | + | td_log_message_callback_ptr | +callback | +
+ | ) | ++ |
Sets the callback that will be called when a message is added to the internal TDLib log. None of the TDLib methods can be called from the callback. By default the callback is not set.
+[in] | max_verbosity_level | The maximum verbosity level of messages for which the callback will be called. |
[in] | callback | Callback that will be called when a message is added to the internal TDLib log. Pass nullptr to remove the callback. |
int td_create_client_id | -( | -) | -- |
Returns an opaque identifier of a new TDLib instance. The TDLib instance will not send updates until the first request is sent to it.
void td_send | -( | -int | -client_id, | -
- | - | const char * | -request | -
- | ) | -- |
Sends request to the TDLib client. May be called from any thread.
[in] | client_id | TDLib client identifier. |
[in] | request | JSON-serialized null-terminated request to TDLib. |
const char* td_receive | -( | -double | -timeout | ) | -- |
Receives incoming updates and request responses. Must not be called simultaneously from two different threads. The returned pointer can be used until the next call to td_receive or td_execute, after which it will be deallocated by TDLib.
[in] | timeout | The maximum number of seconds allowed for this function to wait for new data. |
const char* td_execute | -( | -const char * | -request | ) | -- |
Synchronously executes a TDLib request. A request can be executed synchronously, only if it is documented with "Can be called synchronously". The returned pointer can be used until the next call to td_receive or td_execute, after which it will be deallocated by TDLib.
[in] | request | JSON-serialized null-terminated request to TDLib. |
C interface for managing the internal logging of TDLib. By default TDLib writes logs to stderr or an OS specific log and uses a verbosity level of 5. These functions are deprecated since TDLib 1.4.0 in favor of the setLogVerbosityLevel, setLogStream and other synchronous requests for managing the intrenal TDLib logging.
-Go to the source code of this file.
--Typedefs | |
typedef void(* | td_log_fatal_error_callback_ptr) (const char *error_message) |
-Functions | |
TDJSON_DEPRECATED_EXPORT int | td_set_log_file_path (const char *file_path) |
TDJSON_DEPRECATED_EXPORT void | td_set_log_max_file_size (long long max_file_size) |
TDJSON_DEPRECATED_EXPORT void | td_set_log_verbosity_level (int new_verbosity_level) |
void | td_set_log_fatal_error_callback (td_log_fatal_error_callback_ptr callback) |
typedef void(* td_log_fatal_error_callback_ptr) (const char *error_message) | -
A type of callback function that will be called when a fatal error happens.
-error_message | Null-terminated string with a description of a happened fatal error. |
TDJSON_DEPRECATED_EXPORT int td_set_log_file_path | -( | -const char * | -file_path | ) | -- |
Sets the path to the file where the internal TDLib log will be written. By default TDLib writes logs to stderr or an OS specific log. Use this method to write the log to a file instead.
-[in] | file_path | Null-terminated path to a file where the internal TDLib log will be written. Use an empty path to switch back to the default logging behaviour. |
TDJSON_DEPRECATED_EXPORT void td_set_log_max_file_size | -( | -long long | -max_file_size | ) | -- |
Sets the maximum size of the file to where the internal TDLib log is written before the file will be auto-rotated. Unused if log is not written to a file. Defaults to 10 MB.
-[in] | max_file_size | The maximum size of the file to where the internal TDLib log is written before the file will be auto-rotated. Should be positive. |
TDJSON_DEPRECATED_EXPORT void td_set_log_verbosity_level | -( | -int | -new_verbosity_level | ) | -- |
Sets the verbosity level of the internal logging of TDLib. By default the TDLib uses a log verbosity level of 5.
-[in] | new_verbosity_level | New value of logging verbosity level. Value 0 corresponds to fatal errors, value 1 corresponds to errors, value 2 corresponds to warnings and debug warnings, value 3 corresponds to informational, value 4 corresponds to debug, value 5 corresponds to verbose debug, value greater than 5 and up to 1024 can be used to enable even more logging. |
void td_set_log_fatal_error_callback | -( | -td_log_fatal_error_callback_ptr | -callback | ) | -- |
Sets the callback that will be called when a fatal error happens. None of the TDLib methods can be called from the callback. The TDLib will crash as soon as callback returns. By default the callback is not set.
-[in] | callback | Callback that will be called when a fatal error happens. Pass NULL to remove the callback. |