2019-05-12 17:26:55 +00:00
|
|
|
Handling Updates
|
|
|
|
================
|
2019-05-10 14:14:10 +00:00
|
|
|
|
2022-01-07 09:18:51 +00:00
|
|
|
Calling :doc:`API methods <invoking>` sequentially is one way to use Pyrogram, but how to react when, for example, a
|
|
|
|
new message arrives? This page deals with updates and how to handle such events in Pyrogram.
|
2019-05-10 14:14:10 +00:00
|
|
|
|
2020-04-01 18:08:46 +00:00
|
|
|
.. contents:: Contents
|
|
|
|
:backlinks: none
|
2020-08-22 06:05:05 +00:00
|
|
|
:depth: 1
|
2020-04-01 18:08:46 +00:00
|
|
|
:local:
|
|
|
|
|
|
|
|
-----
|
|
|
|
|
2019-05-13 16:04:44 +00:00
|
|
|
Defining Updates
|
|
|
|
----------------
|
|
|
|
|
2022-01-07 09:18:51 +00:00
|
|
|
As hinted already, updates are simply events that happen in your Telegram account (incoming messages, new members join,
|
|
|
|
bot button presses, etc.), which are meant to notify you about a new specific state that has changed. These updates are
|
|
|
|
handled by registering one or more callback functions in your app using :doc:`Handlers <../api/handlers>`.
|
2019-05-10 14:14:10 +00:00
|
|
|
|
|
|
|
Each handler deals with a specific event and once a matching update arrives from Telegram, your registered callback
|
2019-05-17 23:45:01 +00:00
|
|
|
function will be called back by the framework and its body executed.
|
2019-05-10 14:14:10 +00:00
|
|
|
|
2019-05-20 17:19:26 +00:00
|
|
|
Registering a Handler
|
|
|
|
---------------------
|
2019-05-10 14:14:10 +00:00
|
|
|
|
2020-08-22 06:05:05 +00:00
|
|
|
To explain how handlers work let's examine the one which will be in charge for handling :class:`~pyrogram.types.Message`
|
2020-08-22 14:09:38 +00:00
|
|
|
updates coming from all around your chats. Every other kind of handler shares the same setup logic and you should not
|
|
|
|
have troubles settings them up once you learn from this section.
|
2019-05-10 14:14:10 +00:00
|
|
|
|
2020-08-22 06:05:05 +00:00
|
|
|
Using Decorators
|
|
|
|
^^^^^^^^^^^^^^^^
|
2019-05-10 14:14:10 +00:00
|
|
|
|
2020-08-22 06:05:05 +00:00
|
|
|
The most elegant way to register a message handler is by using the :meth:`~pyrogram.Client.on_message` decorator:
|
2019-05-10 14:14:10 +00:00
|
|
|
|
|
|
|
.. code-block:: python
|
|
|
|
|
2020-08-22 06:05:05 +00:00
|
|
|
from pyrogram import Client
|
2019-05-10 14:14:10 +00:00
|
|
|
|
|
|
|
app = Client("my_account")
|
|
|
|
|
2020-08-22 06:05:05 +00:00
|
|
|
@app.on_message()
|
2022-01-07 09:18:51 +00:00
|
|
|
async def my_handler(client, message):
|
|
|
|
await message.forward("me")
|
2019-05-10 14:14:10 +00:00
|
|
|
|
2020-08-22 06:05:05 +00:00
|
|
|
app.run()
|
2019-05-10 14:14:10 +00:00
|
|
|
|
2020-08-22 06:05:05 +00:00
|
|
|
The defined function ``my_handler``, which accepts the two arguments *(client, message)*, will be the function that gets
|
|
|
|
executed every time a new message arrives.
|
2019-05-10 14:14:10 +00:00
|
|
|
|
2022-01-07 09:18:51 +00:00
|
|
|
In the last line we see again the :meth:`~pyrogram.Client.run` method, this time used without any argument.
|
|
|
|
Its purpose here is simply to automatically :meth:`~pyrogram.Client.start`, keep the Client online so that it can listen
|
|
|
|
for updates and :meth:`~pyrogram.Client.stop` it once you hit ``CTRL+C``.
|
|
|
|
|
|
|
|
Synchronous handlers
|
2020-08-22 06:05:05 +00:00
|
|
|
^^^^^^^^^^^^^^^^^^^^^
|
2019-05-10 14:14:10 +00:00
|
|
|
|
2022-01-07 09:18:51 +00:00
|
|
|
You can also have synchronous handlers; you only need to define the callback function without using ``async def`` and
|
|
|
|
call API methods by not placing ``await`` in front of them:
|
2019-05-10 14:14:10 +00:00
|
|
|
|
2020-08-22 06:05:05 +00:00
|
|
|
.. code-block:: python
|
2019-05-10 14:14:10 +00:00
|
|
|
|
2020-08-22 06:05:05 +00:00
|
|
|
@app.on_message()
|
2022-01-07 09:18:51 +00:00
|
|
|
def my_handler(client, message):
|
|
|
|
message.forward("me")
|
2019-05-10 14:14:10 +00:00
|
|
|
|
2020-08-22 06:05:05 +00:00
|
|
|
.. note::
|
2019-05-10 14:14:10 +00:00
|
|
|
|
2022-01-07 09:18:51 +00:00
|
|
|
You can mix ``def`` and ``async def`` handlers as much as you like, Pyrogram will still work concurrently and
|
|
|
|
efficiently regardless of what you choose. However, it is recommended to use Pyrogram in its native, asynchronous
|
|
|
|
form at all times, unless you want to write something without the boilerplate or in case you want to combine
|
|
|
|
Pyrogram with other libraries that are not async.
|
2019-05-10 14:14:10 +00:00
|
|
|
|
2020-08-22 06:05:05 +00:00
|
|
|
Using add_handler()
|
|
|
|
^^^^^^^^^^^^^^^^^^^
|
2019-05-10 14:14:10 +00:00
|
|
|
|
2020-08-22 06:05:05 +00:00
|
|
|
The :meth:`~pyrogram.Client.add_handler` method takes any handler instance that wraps around your defined callback
|
2022-01-07 09:18:51 +00:00
|
|
|
function and registers it in your Client. It is useful in case you want to programmatically add handlers.
|
2019-05-10 14:14:10 +00:00
|
|
|
|
2020-08-22 06:05:05 +00:00
|
|
|
.. code-block:: python
|
2019-05-10 14:14:10 +00:00
|
|
|
|
2020-08-22 06:05:05 +00:00
|
|
|
from pyrogram import Client
|
|
|
|
from pyrogram.handlers import MessageHandler
|
2019-05-10 14:14:10 +00:00
|
|
|
|
2022-01-07 09:18:51 +00:00
|
|
|
async def my_function(client, message):
|
|
|
|
await message.forward("me")
|
2019-05-10 14:14:10 +00:00
|
|
|
|
|
|
|
app = Client("my_account")
|
|
|
|
|
2020-08-22 06:05:05 +00:00
|
|
|
my_handler = MessageHandler(my_function)
|
|
|
|
app.add_handler(my_handler)
|
2019-05-10 14:14:10 +00:00
|
|
|
|
2020-08-22 06:05:05 +00:00
|
|
|
app.run()
|
2019-05-10 14:14:10 +00:00
|
|
|
|
2022-01-07 09:18:51 +00:00
|
|
|
The same about synchronous handlers applies for :meth:`~pyrogram.Client.add_handler`:
|
2019-05-10 14:14:10 +00:00
|
|
|
|
2020-08-22 06:05:05 +00:00
|
|
|
.. code-block:: python
|
|
|
|
|
2022-01-07 09:18:51 +00:00
|
|
|
def my_function(client, message):
|
|
|
|
message.forward("me")
|
2020-08-22 14:09:38 +00:00
|
|
|
|
|
|
|
.. note::
|
|
|
|
|
|
|
|
From now on, you'll see examples using synchronous code (i.e.: without ``async`` and ``await``, unless when actually
|
|
|
|
relevant). This is done to keep snippets concise and more readable. Once you get the idea behind a feature, you can
|
|
|
|
easily turn examples asynchronous later on.
|