pyrogram/docs/source/start/updates.rst

107 lines
3.8 KiB
ReStructuredText
Raw Normal View History

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
: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
Registering a Handler
---------------------
2019-05-10 14:14:10 +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
Using Decorators
^^^^^^^^^^^^^^^^
2019-05-10 14:14:10 +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
from pyrogram import Client
2019-05-10 14:14:10 +00:00
app = Client("my_account")
@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
app.run()
2019-05-10 14:14:10 +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
^^^^^^^^^^^^^^^^^^^^^
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
.. code-block:: python
2019-05-10 14:14:10 +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
.. 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
Using add_handler()
^^^^^^^^^^^^^^^^^^^
2019-05-10 14:14:10 +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
.. code-block:: python
2019-05-10 14:14:10 +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")
my_handler = MessageHandler(my_function)
app.add_handler(my_handler)
2019-05-10 14:14:10 +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
.. 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.