FromUser improvements · Issue #484 · InsanusMokrassar/TelegramBotAPI
https://github.com/InsanusMokrassar/TelegramBotAPI/issues/484

A little update is on the way :)

New version 0.36.0 has been released and it contains a lot of important changes:

• As always, all deprecations have been removed
• New packages for extensions 😊 now you may write tgbotapi.api instead tgboatpi.extensions.api and similarly for all other extensions. Old packages will be available until next major release
• New keyboard DSL: say goodbye to ReplyKeyboardMarkup(matrix { row { ... } }) and hello to replyKeyboard { row { simpleButton("") } }
• New integration of FSM into Behaviour Builder in new package tgbotapi.behaviour_builder.fsm: in this realization taken attention for more closed work with FSM inside of telegram bots
• New type WithUser. Now FromUser is extending WithUser and any tgbotapi type with user implements type WithUser. It is imortant, that constructors of classes-implementors of FromUser has changed their incoming parameters names from user to from due to renames inside of FromUser, but you still may use user field for FromUser objects

Besides, I recommend you to read a small note about flows and changes of mechanisms inside of behaviour builder and full changelog if you want to know all news

Hello :) currently @djaler is preparing improvement for Entities Builder. This improvement will add separator TextSource to EntitiesBuilder which will be automatically added between incoming text sources automatically. We faced with one important moment: we want to reuse separator in sub builders, BUT we are not sure how to make it good. There are several options we found:

For some explanation:

buildEntities variant:

buildEntities {
    bold(
        buildEntities { +"Some bold" + italic("and italic") }
    )
    + "and regular"
}

Should print "Some bold and italic and regular"

Second variant mostly about renaming buildEntities extension in the example to make it more obvious (it is not very predictive on first try that the second buildEntities will reuse its parent separator)

Of course, your solutions are welcome too

Hello :) thanks to @djaler, we can meet 0.36.1 version with fixes in behaviour builder commands and new opportunity in entities builder - usage of separator and inheritage of it in subentities (like bold { })

Hello :) as you know, Telegram Bot API 5.4 has been introduced and becides I had updated FSM in my microutils libs. Due to these updates it was solved to:

• Make new major version
• Make breaking changes in FSM subproject
• Of course, implement telegram bot api 5.4 😊

Due to changes in FSM, it is not recommended to start some project with that. I plan to release new version in one week (ideally, this monday), so, I hope that the delay will not be big :)

Hello ;) I am starting preparations for new version release. Currently it is still possible for you to make some suggestions which could be included in 0.37.0 PR 😊

Version 0.37.0 is out and you may use Telegram Bot API 5.4 in your bots. Besides here:

• Improvements in Behaviour Builder FSM for more stype-strict using of states
• Dependencies updates
• Deprecations removing

P. S. See Examples migration commit for help in migration

I have added several docker-oriented files in the template project. So, now it must be easier to create your projects from template and run your bot in the docker environment

Unfortunatelly, I also wished to warren you that currently there are problems with running ktor client in Java:8 environment. That means that currently it is strongly not recommended to use it in your bots until ktor with fix of that issue will not be released.

Currently, I am using Java 11 and openjdk 11 docker image

0.37.2 is on the way :)

Hello :) with the new update of Bots API was introduced the field has_protected_content. I suppose, that this field will be added as additional interface PossiblyProtectedContentMessage, but when I tried to add it, I faced to the fact that all Possibly* interfaces could be extenders of ContentMessage instead of just Message. The problem here is that ContentMessage require generic parameter and result PossiblyReplyMessage could looks like:

* PossiblyReplyMessage when it extends ContentMessage<MessageContent>
* PossiblyReplyMessage<MessageContent> when it extends ContentMessage<T>

So, lets answer next question - what would be better?