Update content of files

This commit is contained in:
GitHub Action 2022-03-03 17:18:59 +00:00
parent 2cae08fde5
commit 8b7bb1a6ef
12 changed files with 33 additions and 22 deletions

View file

@ -63,7 +63,7 @@
</ul>
<p>The sent message will contain a <a href="/constructor/messageMediaGame">messageMediaGame</a> with a <a href="/constructor/game">game</a>, that can then be used by users to forward the game using sendMedia with <a href="/constructor/inputGameID">inputGameID</a>.</p>
<h3><a class="anchor" href="#starting-a-game" id="starting-a-game" name="starting-a-game"><i class="anchor-icon"></i></a>Starting a game</h3>
<p>Games are started clicking on the button, which triggers an callback query that returns the game URL, for more info <a href="/api/bots/buttons#callback-queries">see here &amp;raquo</a>.<br>
<p>Games are started clicking on the button, which triggers an callback query that returns the game URL, for more info <a href="/api/bots/buttons#callback-queries">see here »</a>.<br>
The game should then be opened in a WebView or in native UI (specified by the <code>native_ui</code> flag), exposing the <a href="/api/web-events">appropriate HTML5 APIs</a> in order to receive various JS game events directly from the code of the game, as described <a href="/api/web-events">here »</a>. </p>
<h3><a class="anchor" href="#setting-highscores" id="setting-highscores" name="setting-highscores"><i class="anchor-icon"></i></a>Setting highscores</h3>
<pre><code>---functions---

View file

@ -4,10 +4,10 @@
<meta charset="utf-8">
<title>account.takeout</title>
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<meta property="description" content="Takout info">
<meta property="description" content="Takeout info">
<meta property="og:title" content="account.takeout">
<meta property="og:image" content="">
<meta property="og:description" content="Takout info">
<meta property="og:description" content="Takeout info">
<link rel="shortcut icon" href="/favicon.ico?4" type="image/x-icon" />
<link href="/css/bootstrap.min.css?3" rel="stylesheet">
@ -39,7 +39,7 @@
<div class="dev_page_bread_crumbs"><ul class="breadcrumb clearfix"><li><a href="/api" >API</a></li><i class="icon icon-breadcrumb-divider"></i><li><a href="/schema" >TL-schema</a></li><i class="icon icon-breadcrumb-divider"></i><li><a href="/constructor/account.takeout" >account.takeout</a></li></ul></div>
<h1 id="dev_page_title">account.takeout</h1>
<div id="dev_page_content"><p>Takout info</p>
<div id="dev_page_content"><p>Takeout info</p>
<p><div class="clearfix">
<ul class="dev_layer_select slightly-pull-right nav nav-pills">
<li class="dropdown">

View file

@ -79,7 +79,7 @@
<p><a href="/type/ImportedContact">ImportedContact</a></p>
<h3><a class="anchor" href="#related-pages" id="related-pages" name="related-pages"><i class="anchor-icon"></i></a>Related pages</h3>
<h4><a class="anchor" href="#inputcontact" id="inputcontact" name="inputcontact"><i class="anchor-icon"></i></a><a href="/type/InputContact">InputContact</a></h4>
<p>Object defines a contact from the user's phonebook.</p></div>
<p>Object defines a contact from the user's phone book.</p></div>
</div>

View file

@ -4,10 +4,10 @@
<meta charset="utf-8">
<title>inputMediaContact</title>
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<meta property="description" content="Phonebook contact">
<meta property="description" content="Phone book contact">
<meta property="og:title" content="inputMediaContact">
<meta property="og:image" content="">
<meta property="og:description" content="Phonebook contact">
<meta property="og:description" content="Phone book contact">
<link rel="shortcut icon" href="/favicon.ico?4" type="image/x-icon" />
<link href="/css/bootstrap.min.css?3" rel="stylesheet">
@ -39,7 +39,7 @@
<div class="dev_page_bread_crumbs"><ul class="breadcrumb clearfix"><li><a href="/api" >API</a></li><i class="icon icon-breadcrumb-divider"></i><li><a href="/schema" >TL-schema</a></li><i class="icon icon-breadcrumb-divider"></i><li><a href="/constructor/inputMediaContact" >inputMediaContact</a></li></ul></div>
<h1 id="dev_page_title">inputMediaContact</h1>
<div id="dev_page_content"><p>Phonebook contact</p>
<div id="dev_page_content"><p>Phone book contact</p>
<p><div class="clearfix">
<ul class="dev_layer_select slightly-pull-right nav nav-pills">
<li class="dropdown">

View file

@ -39,13 +39,24 @@
<div class="dev_page_bread_crumbs"><ul class="breadcrumb clearfix"><li><a href="/api" >API</a></li><i class="icon icon-breadcrumb-divider"></i><li><a href="/schema" >TL-schema</a></li><i class="icon icon-breadcrumb-divider"></i><li><a href="/constructor/updates.channelDifferenceTooLong" >updates.channelDifferenceTooLong</a></li></ul></div>
<h1 id="dev_page_title">updates.channelDifferenceTooLong</h1>
<div id="dev_page_content"><p>The provided <code>pts + limit &lt; remote pts</code>. Simply, there are too many updates to be fetched (more than <code>limit</code>), the client has to resolve the update gap in one of the following ways:</p>
<div id="dev_page_content"><p>The provided <code>pts + limit &lt; remote pts</code>. Simply, there are too many updates to be fetched (more than <code>limit</code>), the client has to resolve the update gap in one of the following ways (assuming the existence of a persistent database to locally store messages):</p>
<ol>
<li>Delete all known messages in the chat, begin from scratch by refetching all messages manually with <a href="/method/messages.getHistory">getHistory</a>. It is easy to implement, but suddenly disappearing messages looks awful for the user.</li>
<li>Save all messages loaded in the memory until application restart, but delete all messages from database. Messages left in the memory must be lazily updated using calls to <a href="/method/messages.getHistory">getHistory</a>. It looks much smoothly for the user, they will need to redownload messages only after client restart. Unsynchronized messages left in the memory shouldn't be saved to database, results of <a href="/method/messages.getHistory">getHistory</a> and <a href="/method/messages.getMessages">getMessages</a> must be used to update state of deleted and edited messages left in the memory.</li>
<li>Save all messages loaded in the memory and stored in the database without saving that some messages form continuous ranges. Messages in the database will be excluded from results of getChatHistory and searchChatMessages after application restart and will be available only through getMessage. Every message should still be checked using getHistory. It has more disadvantages over 2) than advantages.</li>
<li>Save all messages with saving all data about continuous message ranges. Messages from the database may be used as results of getChatHistory and (if implemented continuous ranges support for searching shared media) searchChatMessages. The messages should still be lazily checked using getHistory, but they are still available offline. It is the best way for gaps support, but it is pretty hard to implement correctly. It should be also noted that some messages like live location messages shouldn't be deleted.</li>
<li>Delete all known messages in the chat, begin from scratch by refetching all messages manually with <a href="/method/messages.getHistory">messages.getHistory</a>.
It is easy to implement, but suddenly disappearing messages look awful to the user.</li>
<li>Save all messages loaded in the memory until application restart, but delete all messages from the database.
Messages left in the memory must be lazily updated using calls to <a href="/method/messages.getHistory">messages.getHistory</a>.<br>
It will look much smoother to the user, they will need to redownload messages only after client restart.<br>
Unsynchronized messages left in memory shouldn't be saved to the database, results of <a href="/method/messages.getHistory">messages.getHistory</a> and <a href="/method/messages.getMessages">messages.getMessages</a> must be used to update the state of deleted and edited messages left in the memory. </li>
<li>Save all messages loaded in the memory and stored in the database without saving that some messages form continuous ranges.<br>
Messages in the database will be excluded when paginating through or searching the local message history after application restart and will be available only through individual message queries.<br>
Every message should still be checked using <a href="/method/messages.getHistory">messages.getHistory</a>.<br>
It has more disadvantages over 2) than advantages. </li>
<li>Save all messages with saving all data about continuous message ranges.<br>
Messages from the database may be used when paginating through or searching the local message history.<br>
The messages should still be lazily checked using <a href="/method/messages.getHistory">messages.getHistory</a>, but they are still available offline.<br>
It is the best way for gaps support, but it is pretty hard to implement correctly. </li>
</ol>
<p>It should be also noted that some messages like live location messages shouldn't be deleted. </p>
<p><div class="clearfix">
<ul class="dev_layer_select slightly-pull-right nav nav-pills">
<li class="dropdown">

View file

@ -4,10 +4,10 @@
<meta charset="utf-8">
<title>InputContact</title>
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<meta property="description" content="Object defines a contact from the user&#39;s phonebook.">
<meta property="description" content="Object defines a contact from the user&#39;s phone book.">
<meta property="og:title" content="InputContact">
<meta property="og:image" content="">
<meta property="og:description" content="Object defines a contact from the user&#39;s phonebook.">
<meta property="og:description" content="Object defines a contact from the user&#39;s phone book.">
<link rel="shortcut icon" href="/favicon.ico?4" type="image/x-icon" />
<link href="/css/bootstrap.min.css?3" rel="stylesheet">
@ -39,7 +39,7 @@
<div class="dev_page_bread_crumbs"><ul class="breadcrumb clearfix"><li><a href="/api" >API</a></li><i class="icon icon-breadcrumb-divider"></i><li><a href="/schema" >TL-schema</a></li><i class="icon icon-breadcrumb-divider"></i><li><a href="/type/InputContact" >InputContact</a></li></ul></div>
<h1 id="dev_page_title">InputContact</h1>
<div id="dev_page_content"><p>Object defines a contact from the user's phonebook.</p>
<div id="dev_page_content"><p>Object defines a contact from the user's phone book.</p>
<p><div class="clearfix">
<ul class="dev_layer_select slightly-pull-right nav nav-pills">
<li class="dropdown">

View file

@ -94,7 +94,7 @@
</tr>
<tr>
<td><a href="/constructor/inputMediaContact">inputMediaContact</a></td>
<td>Phonebook contact</td>
<td>Phone book contact</td>
</tr>
<tr>
<td><a href="/constructor/inputMediaUploadedDocument">inputMediaUploadedDocument</a></td>

View file

@ -39,7 +39,7 @@
<div class="dev_page_bread_crumbs"><ul class="breadcrumb clearfix"><li><a href="/api" >API</a></li><i class="icon icon-breadcrumb-divider"></i><li><a href="/schema" >TL-schema</a></li><i class="icon icon-breadcrumb-divider"></i><li><a href="/type/SecureValue" >SecureValue</a></li></ul></div>
<h1 id="dev_page_title">SecureValue</h1>
<div id="dev_page_content"><p>Secure tgpassport value</p>
<div id="dev_page_content"><p>Secure Telegram Passport value</p>
<p><div class="clearfix">
<ul class="dev_layer_select slightly-pull-right nav nav-pills">
<li class="dropdown">

View file

@ -39,7 +39,7 @@
<div class="dev_page_bread_crumbs"><ul class="breadcrumb clearfix"><li><a href="/api" >API</a></li><i class="icon icon-breadcrumb-divider"></i><li><a href="/schema" >TL-schema</a></li><i class="icon icon-breadcrumb-divider"></i><li><a href="/type/SendMessageAction" >SendMessageAction</a></li></ul></div>
<h1 id="dev_page_title">SendMessageAction</h1>
<div id="dev_page_content"><p>User actions. Use this to provide users with detailed info about their chat partners' actions: typing or sending attachments of all kinds.</p>
<div id="dev_page_content"><p>User actions. Use this to provide users with detailed info about their chat partner's actions: typing or sending attachments of all kinds.</p>
<p><div class="clearfix">
<ul class="dev_layer_select slightly-pull-right nav nav-pills">
<li class="dropdown">

View file

@ -68,7 +68,7 @@
<tbody>
<tr>
<td><a href="/constructor/account.takeout">account.takeout</a></td>
<td>Takout info</td>
<td>Takeout info</td>
</tr>
</tbody>
</table>

View file

@ -83,7 +83,7 @@
<tbody>
<tr>
<td><a href="/method/help.getSupport">help.getSupport</a></td>
<td>Returns the support user for the 'ask a question' feature.</td>
<td>Returns the support user for the "ask a question" feature.</td>
</tr>
</tbody>
</table></div>

View file

@ -74,7 +74,7 @@
</tr>
<tr>
<td><a href="/constructor/updates.channelDifferenceTooLong">updates.channelDifferenceTooLong</a></td>
<td>The provided <code>pts + limit &lt; remote pts</code>. Simply, there are too many updates to be fetched (more than <code>limit</code>), the client has to resolve the update gap in one of the following ways:<br><br>1. Delete all known messages in the chat, begin from scratch by refetching all messages manually with <a href="/method/messages.getHistory">getHistory</a>. It is easy to implement, but suddenly disappearing messages looks awful for the user.<br>2. Save all messages loaded in the memory until application restart, but delete all messages from database. Messages left in the memory must be lazily updated using calls to <a href="/method/messages.getHistory">getHistory</a>. It looks much smoother for the user, they will need to redownload messages only after client restart. Unsynchronized messages left in the memory shouldn't be saved to database, results of <a href="/method/messages.getHistory">getHistory</a> and <a href="/method/messages.getMessages">getMessages</a> must be used to update state of deleted and edited messages left in the memory.<br>3. Save all messages loaded in the memory and stored in the database without saving that some messages form continuous ranges. Messages in the database will be excluded from results of getChatHistory and searchChatMessages after application restart and will be available only through getMessage. Every message should still be checked using getHistory. It has more disadvantages over 2) than advantages.<br>4. Save all messages with saving all data about continuous message ranges. Messages from the database may be used as results of getChatHistory and (if implemented continuous ranges support for searching shared media) searchChatMessages. The messages should still be lazily checked using getHistory, but they are still available offline. It is the best way for gaps support, but it is pretty hard to implement correctly. It should be also noted that some messages like live location messages shouldn't be deleted.</td>
<td>The provided <code>pts + limit &lt; remote pts</code>. Simply, there are too many updates to be fetched (more than <code>limit</code>), the client has to resolve the update gap in one of the way indicated in the <a href="/constructor/updates.channelDifferenceTooLong">constructor page</a>.</td>
</tr>
<tr>
<td><a href="/constructor/updates.channelDifference">updates.channelDifference</a></td>