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
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
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.
Sadly, by relying on map, it means that the key will have to be an
Integerobject, it means that we'll have ~500
Integerobject 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).
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.
Updated less than a minute ago