{"_id":"57e0dbe2082ddd1900622663","__v":0,"parentDoc":null,"project":"5703d527bb69fc1700553ce0","category":{"_id":"57e0db616a1c2e0e0081fe64","__v":0,"project":"5703d527bb69fc1700553ce0","version":"5703d527bb69fc1700553ce3","sync":{"url":"","isSync":false},"reference":false,"createdAt":"2016-09-20T06:46:57.444Z","from_sync":false,"order":2,"slug":"tl-module","title":"TL module"},"user":"5631f962c3b04b0d00ba9bf1","version":{"_id":"5703d527bb69fc1700553ce3","hasDoc":true,"__v":6,"hasReference":true,"project":"5703d527bb69fc1700553ce0","createdAt":"2016-04-05T15:09:27.620Z","releaseDate":"2016-04-05T15:09:27.620Z","categories":["5703d527bb69fc1700553ce4","5703d8b7aceacc17003ef303","5703e60b6116142000db25f6","57e0db616a1c2e0e0081fe64","57e0f141ff540c22007b45fa","57e0f14b8929550e00f1d9bc"],"is_deprecated":false,"is_hidden":false,"is_beta":true,"is_stable":true,"codename":"","version_clean":"0.0.6","version":"0.0.6"},"githubsync":"","updates":[],"next":{"pages":[],"description":""},"createdAt":"2016-09-20T06:49:06.859Z","link_external":false,"link_url":"","sync_unique":"","hidden":false,"api":{"results":{"codes":[]},"settings":"","auth":"required","params":[],"url":""},"isReference":false,"order":1,"body":"[block:callout]\n{\n  \"type\": \"warning\",\n  \"title\": \"TL-Language\",\n  \"body\": \"In this article, it's assumed that you know how the TL Language works (via binary serialization).\\nFor more info, see [Telegram documentation](https://core.telegram.org/mtproto/TL).\"\n}\n[/block]\nWhen 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).\nFrom this constructor id, we can then find the appropriate `TLObject` subclass implementing the type, and call the `deserialize` method.\n\nNow, we had the following choice to resolve this:\n- Have a huge (and ugly) switch\n- Use an Map where the key would be the constructor id, and the value the java `Class` object.\n\nThe 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.\n[block:callout]\n{\n  \"type\": \"info\",\n  \"title\": \"Android implementation\",\n  \"body\": \"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.\\n\\nThe impact on performance on a desktop should not be too dramatic though, but is definitely a bad point if you target Android.\\n\\nIn the future, it could be a good point to switch from a Map to a SparseArray implementation (from Android source code).\"\n}\n[/block]\nThe `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).\n\nIt's possible to use more than one context if for some reason it's needed (or appropriate) to separate classes in different \"context\".\n\nThe 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.","excerpt":"","slug":"tlcontext","type":"basic","title":"TLContext"}
[block:callout] { "type": "warning", "title": "TL-Language", "body": "In this article, it's assumed that you know how the TL Language works (via binary serialization).\nFor more info, see [Telegram documentation](https://core.telegram.org/mtproto/TL)." } [/block] 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. [block:callout] { "type": "info", "title": "Android implementation", "body": "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.\n\nThe impact on performance on a desktop should not be too dramatic though, but is definitely a bad point if you target Android.\n\nIn the future, it could be a good point to switch from a Map to a SparseArray implementation (from Android source code)." } [/block] 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.