А
Ааа
Size: a a a
2020 August 06
А
Да, коробочных не видел, но реализовать своё проще же
Тоже интересно
АК
Создай объект пользователя, иквелс/хешкод, и объект сообщения, это всё в Map<User, TreeSet<ChatMSG>> вот тебе уже хранение в памяти, а трисет дает возможность ходить по сообщениям последовательно или брать первое/последние только
2020 August 07
Н
ID:0
Вы когда-нибудь разрабатывали Telegram-ботов?
Анонимный опрос
28%
Да, на JVM
18%
Да, на чём-то другом
54%
Неа
На Го писал. Всё просто и интересно
Н
Не нужно хранить весь диалог. Нужно хранить текущее состояние, чтобы понимать контекст следующего сообщения.
Если юзеры хранятся в бд просто сохраняешь ему текущий статус 🙃
QH
Если юзеры хранятся в бд просто сохраняешь ему текущий статус 🙃
как-то нифига не просто :)
QH
вот пользователь находится в каком-то сценарии. На какие-то вопросы он ответил, какие-то ещё бот должен задать. Как это хранить?
Н
Яб сделал какие-то стейты флоу енамчиком и при получении сообщения юзера смотрел на текущее состояние - скармливал его фабрике состояний какой-то, в ней бы резолвилось как сохранить/обработать эти данные и возвращал новый Стейт с соотв сообщением
Н
Немного оверхед, но будет полный контроль за флоу - минимизация багов и потенциальных ошибок
QH
Яб сделал какие-то стейты флоу енамчиком и при получении сообщения юзера смотрел на текущее состояние - скармливал его фабрике состояний какой-то, в ней бы резолвилось как сохранить/обработать эти данные и возвращал новый Стейт с соотв сообщением
у энамов нет состояния. sealed class тогда уж
Н
Ну я имел ввиду что каждый элемент енамчика был бы статусом флоу) и потом через when() разные методы вызывать
QH
Ну я имел ввиду что каждый элемент енамчика был бы статусом флоу) и потом через when() разные методы вызывать
а где держать ответы на заданные ранее вопросы?
Н
Условно у юзера флоу поиска музыки:
Search_Music -> берём текст что юзер ввёл -> ищем результат, записываем в юзера статус search_result -> отправляем сообщение
Search_Music -> берём текст что юзер ввёл -> ищем результат, записываем в юзера статус search_result -> отправляем сообщение
Н
а где держать ответы на заданные ранее вопросы?
В БД. Самый надёжный способ. Чтоб если код крашнулся, не потерять ничего
QH
В БД. Самый надёжный способ. Чтоб если код крашнулся, не потерять ничего
дак это было в условии задачи. Вопрос — как
QH
допустим
— хочу послушать нирвану
— угу, а какую песню?
(на этом месте бот должен помнить, что ему сейчас ответят название песни, а также какую группу запросили)
— хочу послушать нирвану
— угу, а какую песню?
(на этом месте бот должен помнить, что ему сейчас ответят название песни, а также какую группу запросили)
Н
Хмм. Отдельной таблицей answers c userId, answer, flow, action
Потом собирать по флоу ответы, по экшнам доставать результаты и после ответа, если надо - чистить
Потом собирать по флоу ответы, по экшнам доставать результаты и после ответа, если надо - чистить
Н
"В лоб" решение слегка, но это достаточно надёжно будет, как мне кажется
Н
Я пытался текстовую РПГ сделать и при регистрации надо было указывать ник, класс, расу и ещё что то. Вот примерно так сделал. Правда потом я забил, т.к. оказалось что существует 100500 проектов и продумать флоу игры сложно и долго 🙃
AD
допустим
— хочу послушать нирвану
— угу, а какую песню?
(на этом месте бот должен помнить, что ему сейчас ответят название песни, а также какую группу запросили)
— хочу послушать нирвану
— угу, а какую песню?
(на этом месте бот должен помнить, что ему сейчас ответят название песни, а также какую группу запросили)
а нельзя просто в БД положить json-ом контекст?