In this article, it's assumed that you know how the TL Language works (via binary serialization).
For more info, see Telegram documentation.

When a response is received, it's only bytes, and we have to convert it to a TLObject. To do that, according to the TL Language specifications, we first read the constructor id (an integer).
From this constructor id, we can then find the appropriate TLObject subclass implementing the type, and call the deserialize method.

Now, we had the following choice to resolve this:

  • Have a huge (and ugly) switch
  • Use an Map where the key would be the constructor id, and the value the java Class object.

The best solution for performances is of course the second one, because in a switch, we would have to test all the constructor ids until we find the good one, with the map, we rely on the backing hashing implementation to be faster.


Android implementation

Sadly, by relying on map, it means that the key will have to be an Integer object, it means that we'll have ~500 Integer object in memory for that.

The impact on performance on a desktop should not be too dramatic though, but is definitely a bad point if you target Android.

In the future, it could be a good point to switch from a Map to a SparseArray implementation (from Android source code).

The TLContext class is a component that can register a class by it's constructor id, and then deserialize a stream/ByteArray into a Java object (subclass of TLObject more precisely).

It's possible to use more than one context if for some reason it's needed (or appropriate) to separate classes in different "context".

The base context for the generated classes is TLApiContext, this class is automatically generated with the other classes, and is registering all the classes generated in its constructor.

Did this page help you?