Windows 10. После установки плагина (перезапуск не спасает) не работало меню выбора добавления модели (Add Chat Model). Не работал сам селект в списке, который открывался ЗА окном... треш
Обход: выбираем тот что по умолчанию (ChatGPT) и подтверждаем. Ручками правим config.yaml на тот что у автора на скриншоте. Перезапускам - всё работает :)
Подскажите пожалуйста, как лучше организовать код:
1) Скинуть всё для одного экрана в один .kt файл или разбить на разные файлы по элементам?
с одной стороны хорошо иметь всё в одном файле, но если экран большой и сложный, то будет огромное число строк и превью дольше рисуются.
с другой стороны, когда кидаешь компоненты в другие файлы, они становятся публичными функциями и тогда при рисовке другого экрана будут показыватся при поиске компонентов по имени. Например мне нужна кнопка, и я пишу Button, тогда мне покажутся и, предположим, ButtonSpecialForScreen1... Screen2, соответственно. Чего хотелось бы избежать, но сейчас работаю именно в таком ключе.
2) Где хранить стейт для функции, в том же документе что и сама Composable функция или рядом в package models/states или где-то ещё?
Есть ещё вариант создания вложенного стейта, когда в один стейт экрана вкладывать другие стейты, из которых он состоит
Другой путь, писать отдельные стейты для функций а потом просто создать матрёшку из нужных стейтов.
Согласен со всем. Долго не мог понять зачем гугл приводит какие-то свои коэффициенты для расчётов размера, ведь на практике они не работают. Это только путало меня в начале. Но в итоге я пришёл к размеру в dp для разных размеров экрана. match_parent мне не подошёл.
Ещё болью стало обновление виджета каждые пол часа. Гугл сейчас не любит когда само что-то происходит :)
На мой взгляд это излишнее усложнение, когда для в ответе с ошибкой приходит несколько "причин". Во первых, говорить юзеру что "пароль не правильный" или "логин не правильный" не совсем секьюрно. Обычно просто просят проверить введённые данные. Во вторых, мне кажется маловероятным что юзер будет выполнять два действия если он сделал два типа ошибок. Например, при регистрации, если нет нужного кол-ва знаков и нет заглавных символов, правильно показать сообщение с паттерном пароля, а не писать что у тебя нет А и Б.
Ясли я не правильно понял, поправьте меня. Возможно у вас своё обоснование и оно аргументированно.
Windows 10. После установки плагина (перезапуск не спасает) не работало меню выбора добавления модели (Add Chat Model). Не работал сам селект в списке, который открывался ЗА окном... треш
Обход: выбираем тот что по умолчанию (ChatGPT) и подтверждаем. Ручками правим config.yaml на тот что у автора на скриншоте. Перезапускам - всё работает :)
Подскажите пожалуйста, как лучше организовать код:
1) Скинуть всё для одного экрана в один .kt файл или разбить на разные файлы по элементам?
с одной стороны хорошо иметь всё в одном файле, но если экран большой и сложный, то будет огромное число строк и превью дольше рисуются.
с другой стороны, когда кидаешь компоненты в другие файлы, они становятся публичными функциями и тогда при рисовке другого экрана будут показыватся при поиске компонентов по имени. Например мне нужна кнопка, и я пишу Button, тогда мне покажутся и, предположим, ButtonSpecialForScreen1... Screen2, соответственно. Чего хотелось бы избежать, но сейчас работаю именно в таком ключе.
2) Где хранить стейт для функции, в том же документе что и сама Composable функция или рядом в package models/states или где-то ещё?
Есть ещё вариант создания вложенного стейта, когда в один стейт экрана вкладывать другие стейты, из которых он состоит
Другой путь, писать отдельные стейты для функций а потом просто создать матрёшку из нужных стейтов.
Согласен со всем. Долго не мог понять зачем гугл приводит какие-то свои коэффициенты для расчётов размера, ведь на практике они не работают. Это только путало меня в начале. Но в итоге я пришёл к размеру в dp для разных размеров экрана. match_parent мне не подошёл.
Ещё болью стало обновление виджета каждые пол часа. Гугл сейчас не любит когда само что-то происходит :)
На мой взгляд это излишнее усложнение, когда для в ответе с ошибкой приходит несколько "причин". Во первых, говорить юзеру что "пароль не правильный" или "логин не правильный" не совсем секьюрно. Обычно просто просят проверить введённые данные. Во вторых, мне кажется маловероятным что юзер будет выполнять два действия если он сделал два типа ошибок. Например, при регистрации, если нет нужного кол-ва знаков и нет заглавных символов, правильно показать сообщение с паттерном пароля, а не писать что у тебя нет А и Б.
Ясли я не правильно понял, поправьте меня. Возможно у вас своё обоснование и оно аргументированно.
Я бы Publisher использовал и уже на него бы подписался, чтобы покрыть ваш кейс с пустым списком.