mirror of
https://github.com/wiz0u/WTelegramClient.git
synced 2025-12-06 06:52:01 +01:00
Prevent "You must connect to Telegram first" during network loss
(closes #157)
This commit is contained in:
parent
131fd36106
commit
d1e583cc86
13
EXAMPLES.md
13
EXAMPLES.md
|
|
@ -491,11 +491,18 @@ A message contains those two fields/properties:
|
|||
- `peer_id`/`Peer` that identify WHERE the message was posted
|
||||
- `from_id`/`From` that identify WHO posted the message (it can be `null` in some case of anonymous posting)
|
||||
|
||||
These two fields derive from class `Peer` and can be of type `PeerChat`, `PeerChannel` or `PeerUser` depending on the nature of WHERE & WHO (private chat with a user? message posted BY a channel IN a chat? ...)
|
||||
These two fields derive from class `Peer` and can be of type `PeerChat`, `PeerChannel` or `PeerUser` depending on the nature of WHERE & WHO
|
||||
(private chat with a user? message posted BY a channel IN a chat? ...)
|
||||
|
||||
The root structure where you obtained the message (typically `UpdatesBase` or `Messages_MessagesBase`) inherits from `IPeerResolver`. This allows you to call `.UserOrChat(peer)` on the root structure, in order to resolve those fields into a `User` class, or a `ChatBase`-derived class (typically `Chat` or `Channel`) which will give you details about the peer, instead of just the ID.
|
||||
The root structure where you obtained the message (typically `UpdatesBase` or `Messages_MessagesBase`) inherits from `IPeerResolver`.
|
||||
This allows you to call `.UserOrChat(peer)` on the root structure, in order to resolve those fields into a `User` class, or a `ChatBase`-derived class
|
||||
(typically `Chat` or `Channel`) which will give you details about the peer, instead of just the ID.
|
||||
|
||||
However, in some case _(typically when dealing with updates)_, Telegram might choose to not include details about a peer because it expects you to already know about it (`UserOrChat` returns `null`). That's why you should collect users/chats details each time you're dealing with Updates or other API results inheriting from `IPeerResolver`, and use the collected dictionaries to find details about users/chats ([see previous section](#collect-users-chats) and [Program_ListenUpdates.cs](https://github.com/wiz0u/WTelegramClient/blob/master/Examples/Program_ListenUpdates.cs?ts=4#L23) example)
|
||||
However, in some case _(typically when dealing with updates)_, Telegram might choose to not include details about a peer
|
||||
because it expects you to already know about it (`UserOrChat` returns `null`).
|
||||
That's why you should collect users/chats details each time you're dealing with Updates or other API results inheriting from `IPeerResolver`,
|
||||
and use the collected dictionaries to find details about users/chats
|
||||
([see previous section](#collect-users-chats) and [Program_ListenUpdates.cs](https://github.com/wiz0u/WTelegramClient/blob/master/Examples/Program_ListenUpdates.cs?ts=4#L23) example)
|
||||
|
||||
And finally, it may happen that you receive updates of type `UpdateShortMessage` or `UpdateShortChatMessage` with totally unknown peers (even in your collected dictionaries).
|
||||
In this case, [Telegram recommends](https://core.telegram.org/api/updates#recovering-gaps) that you use the [`Updates_GetDifference`](https://corefork.telegram.org/method/updates.getDifference) method to retrieve the full information associated with the short message.
|
||||
|
|
|
|||
2
FAQ.md
2
FAQ.md
|
|
@ -205,7 +205,7 @@ You can choose to increase `MaxAutoReconnects` if it happens too often because y
|
|||
|
||||
3) If you reach `MaxAutoReconnects` disconnections, then the **OnOther** event handler will receive a `ReactorError` object to notify you of the problem,
|
||||
and pending API calls throw the network IOException.
|
||||
In this case, the recommended action would be to dispose the client and recreate one
|
||||
In this case, the recommended action would be to dispose the client and recreate one (see example [Program_ReactorError.cs](https://github.com/wiz0u/WTelegramClient/blob/master/Examples/Program_ReactorError.cs))
|
||||
|
||||
4) In case of slow Internet connection or if you break in the debugger for some time,
|
||||
you might also get Connection shutdown because your client couldn't send Pings to Telegram in the allotted time.
|
||||
|
|
|
|||
|
|
@ -161,8 +161,8 @@ See [FAQ #4](https://wiz0u.github.io/WTelegramClient/FAQ#access-hash) to learn m
|
|||
|
||||
# Other things to know
|
||||
|
||||
The Client class also offers `OnUpdate` and `OnOther` events that are triggered when Telegram servers sends Updates (like new messages or status) or other structures, independently of your API requests.
|
||||
See [Examples/Program_ListenUpdates.cs](https://github.com/wiz0u/WTelegramClient/blob/master/Examples/Program_ListenUpdates.cs?ts=4#L23)
|
||||
The Client class also offers `OnUpdate` and `OnOther` events that are triggered when Telegram servers sends Updates (like new messages or status) or other notifications, independently of your API requests.
|
||||
See [Examples/Program_ListenUpdates.cs](https://github.com/wiz0u/WTelegramClient/blob/master/Examples/Program_ListenUpdates.cs?ts=4#L23) and [Examples/Program_ReactorError.cs](https://github.com/wiz0u/WTelegramClient/blob/master/Examples/Program_ReactorError.cs?ts=4#L32)
|
||||
|
||||
An invalid API request can result in a `RpcException` being raised, reflecting the [error code and status text](https://revgram.github.io/errors.html) of the problem.
|
||||
|
||||
|
|
|
|||
|
|
@ -198,7 +198,7 @@ namespace WTelegram
|
|||
_reactorTask?.Wait(1000);
|
||||
}
|
||||
catch { }
|
||||
_reactorTask = null;
|
||||
_reactorTask = resetSessions ? null : Task.CompletedTask;
|
||||
_networkStream?.Close();
|
||||
_tcpClient?.Dispose();
|
||||
#if OBFUSCATION
|
||||
|
|
|
|||
Loading…
Reference in a new issue