mirror of
https://github.com/InsanusMokrassar/TelegramBotAPI.git
synced 2025-09-02 22:59:48 +00:00
update readmes with updates handling
This commit is contained in:
@@ -60,13 +60,80 @@ val filter = FlowsUpdatesFilter(64)
|
||||
Alternative way to use the things below:
|
||||
|
||||
```kotlin
|
||||
val filter = bot.startGettingUpdates(
|
||||
val filter = bot.startGettingFlowsUpdatesByLongPolling(
|
||||
scope = CoroutineScope(Dispatchers.Default)
|
||||
) {
|
||||
// place code from examples here with replacing of `filter` by `this`
|
||||
}
|
||||
```
|
||||
|
||||
### Updates
|
||||
|
||||
As mentioned in [Telegram Bot API reference](https://core.telegram.org/bots/api#getting-updates), there are two ways for
|
||||
updates retrieving:
|
||||
|
||||
* Webhooks
|
||||
* Long Polling
|
||||
|
||||
Both of them you could use in your project using [TelegramBotAPI](../TelegramBotAPI/README.md), but here there are
|
||||
several useful extensions for both of them:
|
||||
|
||||
#### Long polling
|
||||
|
||||
The most simple way is Long Polling. The most simple way was mentioned above:
|
||||
|
||||
```kotlin
|
||||
val filter = bot.startGettingFlowsUpdatesByLongPolling(
|
||||
scope = CoroutineScope(Dispatchers.Default)
|
||||
) {
|
||||
// place code from examples here with replacing of `filter` by `this`
|
||||
}
|
||||
```
|
||||
|
||||
Extension `startGettingFlowsUpdatesByLongPolling` was used in this example, but there are a lot of variations of
|
||||
`startGettingOfUpdatesByLongPolling` and others for getting the same result. Usually, it is supposed that you already
|
||||
have created `filter` object (or something like this) and will pass it into extension:
|
||||
|
||||
```kotlin
|
||||
val filter = FlowsUpdatesFilter(64)
|
||||
bot.startGettingOfUpdatesByLongPolling(
|
||||
filter
|
||||
)
|
||||
```
|
||||
|
||||
But also there are extensions which allow to pass lambdas directly:
|
||||
|
||||
```kotlin
|
||||
bot.startGettingOfUpdatesByLongPolling(
|
||||
{
|
||||
println("Received message update: $it")
|
||||
}
|
||||
)
|
||||
```
|
||||
|
||||
Anyway, it is strictly recommended to pass your `CoroutineScope` object to this method at least for more comfortable
|
||||
management of updates.
|
||||
|
||||
#### WebHooks (currently JVM-only)
|
||||
|
||||
For webhooks there are less number of functions and extensions than for Long Polling (but it is still fully automated):
|
||||
|
||||
```kotlin
|
||||
startListenWebhooks(
|
||||
8081,
|
||||
CIO // require to implement this engine dependency
|
||||
) {
|
||||
// here will be all updates one by one in $it
|
||||
}
|
||||
```
|
||||
|
||||
Besides, there are two additional opportunities:
|
||||
|
||||
* Extension `Route#includeWebhookHandlingInRoute`, which allow you to include webhook processing inside your ktor
|
||||
application without creating of new one server (as it is happening in `startListenWebhooks`)
|
||||
* Extension `RequestsExecutor#setWebhookInfoAndStartListenWebhooks`. It is allow to set up full server (in fact, with
|
||||
`startListenWebhooks`), but also send `SetWebhook` request before and check that it was successful
|
||||
|
||||
### Filters
|
||||
|
||||
There are several filters for flows.
|
||||
|
Reference in New Issue
Block a user