CU
Пусть зрители развлекаются)
Size: a a a
2021 March 01
AY
Смерть, киилер, прослушка. Что это? В это дети должны играть? Серьезно?
Пипл ест :)
ms
Нужен толковый разработчик ios/android для платной консультации по вопросам распознавания голоса, в л.с.
k
Где тестируете?
описывал поведение на телефоне
поиском сейчас воспользовался, много написано, судя по всему, команда бесполезная для универсального навыка
поиском сейчас воспользовался, много написано, судя по всему, команда бесполезная для универсального навыка
A
описывал поведение на телефоне
поиском сейчас воспользовался, много написано, судя по всему, команда бесполезная для универсального навыка
поиском сейчас воспользовался, много написано, судя по всему, команда бесполезная для универсального навыка
Чат на смартфоне не закроется, это фича.
k
ну фича так фича. бесполезная фича :)
A
ну фича так фича. бесполезная фича :)
Почему. Я выше писал, если я вышел из навыка, то вполне возможно, мне всё ещё нужно перечитать информацию.
k
Выход из навыка мне кажется более полезным. Возможно, это должна быть какая-то отдельная команда
A
Выход из навыка мне кажется более полезным. Возможно, это должна быть какая-то отдельная команда
Это выход. Но с сохранением истории на экране.
k
Заметил еще странность при работе со state. application state можно очищать, просто отправив null, но для user state надо очищать явно каждое поле, записав в него null
DD
Заметил еще странность при работе со state. application state можно очищать, просто отправив null, но для user state надо очищать явно каждое поле, записав в него null
Так и задумано
k
Какие-то странные у вас задумки, куда ни глянь :(
DD
В user state могут писать параллельно из нескольких диалогов на разных устройствах, и поэтому null надо отправлять в явном виде, чтобы уменьшить возможные конфликты.
k
Т.е. одно устройство может поломать диалог на другом устройстве? Прикольно
A
Т.е. одно устройство может поломать диалог на другом устройстве? Прикольно
Не поломать, а бесшовно использовать
DD
Т.е. одно устройство может поломать диалог на другом устройстве? Прикольно
Иначе может быть такое, что в одном диалоге, с телефона, присылают user state типа {a:1}, а во втором, с колонки, одновременно присылают user state типа {b:2}
При текущей схеме итоговый стейт будет равен {a:1, b:2}.
А если бы поля, не присланные в этот раз, стирались бы сами, то было бы либо {a:1}, либо {b:2}, смотря чей ответ вторым пришёл, и одна из этих переменных бы удалилась.
При текущей схеме итоговый стейт будет равен {a:1, b:2}.
А если бы поля, не присланные в этот раз, стирались бы сами, то было бы либо {a:1}, либо {b:2}, смотря чей ответ вторым пришёл, и одна из этих переменных бы удалилась.
DD
Т.е. одно устройство может поломать диалог на другом устройстве? Прикольно
Да, может.
Именно поэтому user state довольно опасная штука, и его надо использовать реально только для долговременных настроек, а для остального - session или application state.
Именно поэтому user state довольно опасная штука, и его надо использовать реально только для долговременных настроек, а для остального - session или application state.
k
То есть, application state есть всегда, как при наличии пользователя, так и без него? Наверное, тогда мне лучше его всегда использовать
МЗ
Пипл ест :)
Не факт, что надо кормить пипл всем, что он может съесть. Я считаю что все эти "зверские" названия — точно для той же цели что и в бульварной прессе заголовки ("Посмотрите, что они с ним... сделали!!!).