2019-05-12 17:26:55 +00:00
|
|
|
Handling Updates
|
|
|
|
================
|
2019-05-10 14:14:10 +00:00
|
|
|
|
2019-05-28 14:41:55 +00:00
|
|
|
Calling :doc:`API methods <invoking>` sequentially is cool, but how to react when, for example, a new message arrives?
|
|
|
|
This page deals with updates and how to handle such events in Pyrogram. Let's have a look at how they work.
|
2019-05-10 14:14:10 +00:00
|
|
|
|
2019-05-13 16:04:44 +00:00
|
|
|
Defining Updates
|
|
|
|
----------------
|
|
|
|
|
2019-05-12 17:26:55 +00:00
|
|
|
First, let's define what are these updates. As hinted already, updates are simply events that happen in your Telegram
|
2019-05-16 19:28:34 +00:00
|
|
|
account (incoming messages, new members join, bot button presses, etc...), which are meant to notify you about a new
|
2019-05-17 23:45:01 +00:00
|
|
|
specific state that has changed. These updates are handled by registering one or more callback functions in your app
|
2019-05-28 14:41:55 +00:00
|
|
|
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
|
|
|
|
2019-05-28 14:41:55 +00:00
|
|
|
To explain how handlers work let's have a look at the most used one, the :class:`~pyrogram.MessageHandler`, which will
|
|
|
|
be in charge for handling :class:`~pyrogram.Message` updates coming from all around your chats. Every other handler shares
|
|
|
|
the same setup logic; you should not have troubles settings them up once you learn from this section.
|
2019-05-10 14:14:10 +00:00
|
|
|
|
|
|
|
Using add_handler()
|
|
|
|
-------------------
|
|
|
|
|
2019-05-28 14:41:55 +00:00
|
|
|
The :meth:`~pyrogram.Client.add_handler` method takes any handler instance that wraps around your defined callback
|
|
|
|
function and registers it in your Client. Here's a full example that prints out the content of a message as soon as it
|
|
|
|
arrives:
|
2019-05-10 14:14:10 +00:00
|
|
|
|
|
|
|
.. code-block:: python
|
|
|
|
|
|
|
|
from pyrogram import Client, MessageHandler
|
|
|
|
|
|
|
|
|
|
|
|
def my_function(client, message):
|
|
|
|
print(message)
|
|
|
|
|
|
|
|
|
|
|
|
app = Client("my_account")
|
|
|
|
|
|
|
|
my_handler = MessageHandler(my_function)
|
|
|
|
app.add_handler(my_handler)
|
|
|
|
|
|
|
|
app.run()
|
|
|
|
|
2019-06-04 14:10:32 +00:00
|
|
|
#. Let's examine these four new pieces. First one: a callback function we defined which accepts two arguments -
|
|
|
|
*(client, message)*. This will be the function that gets executed every time a new message arrives and Pyrogram will
|
|
|
|
call that function by passing the client instance and the new message instance as argument.
|
2019-05-10 14:14:10 +00:00
|
|
|
|
2019-06-04 14:10:32 +00:00
|
|
|
.. code-block:: python
|
2019-05-10 14:14:10 +00:00
|
|
|
|
2019-06-04 14:10:32 +00:00
|
|
|
def my_function(client, message):
|
|
|
|
print(message)
|
2019-05-10 14:14:10 +00:00
|
|
|
|
2019-06-04 14:10:32 +00:00
|
|
|
#. Second one: the :class:`~pyrogram.MessageHandler`. This object tells Pyrogram the function we defined above must
|
|
|
|
only handle updates that are in form of a :class:`~pyrogram.Message`:
|
2019-05-10 14:14:10 +00:00
|
|
|
|
2019-06-04 14:10:32 +00:00
|
|
|
.. code-block:: python
|
2019-05-10 14:14:10 +00:00
|
|
|
|
2019-06-04 14:10:32 +00:00
|
|
|
my_handler = MessageHandler(my_function)
|
2019-05-10 14:14:10 +00:00
|
|
|
|
2019-06-04 14:10:32 +00:00
|
|
|
#. Third: the method :meth:`~pyrogram.Client.add_handler`. This method is used to actually register the handler and let
|
|
|
|
Pyrogram know it needs to be taken into consideration when new updates arrive and the internal dispatching phase
|
|
|
|
begins.
|
2019-05-10 14:14:10 +00:00
|
|
|
|
2019-06-04 14:10:32 +00:00
|
|
|
.. code-block:: python
|
2019-05-10 14:14:10 +00:00
|
|
|
|
2019-06-04 14:10:32 +00:00
|
|
|
app.add_handler(my_handler)
|
2019-05-10 14:14:10 +00:00
|
|
|
|
2019-06-04 14:10:32 +00:00
|
|
|
#. Last one, the :meth:`~pyrogram.Client.run` method. What this does is simply call :meth:`~pyrogram.Client.start` and
|
|
|
|
a special method :meth:`~pyrogram.Client.idle` that keeps your main scripts alive until you press ``CTRL+C``; the
|
|
|
|
client will be automatically stopped after that.
|
2019-05-10 14:14:10 +00:00
|
|
|
|
2019-06-04 14:10:32 +00:00
|
|
|
.. code-block:: python
|
2019-05-10 14:14:10 +00:00
|
|
|
|
2019-06-04 14:10:32 +00:00
|
|
|
app.run()
|
2019-05-10 14:14:10 +00:00
|
|
|
|
|
|
|
Using Decorators
|
|
|
|
----------------
|
|
|
|
|
|
|
|
All of the above will become quite verbose, especially in case you have lots of handlers to register. A much nicer way
|
2019-05-28 14:41:55 +00:00
|
|
|
to do so is by decorating your callback function with the :meth:`~pyrogram.Client.on_message` decorator.
|
2019-05-10 14:14:10 +00:00
|
|
|
|
|
|
|
.. code-block:: python
|
|
|
|
|
|
|
|
from pyrogram import Client
|
|
|
|
|
|
|
|
app = Client("my_account")
|
|
|
|
|
|
|
|
|
|
|
|
@app.on_message()
|
|
|
|
def my_handler(client, message):
|
|
|
|
print(message)
|
|
|
|
|
|
|
|
|
|
|
|
app.run()
|