БД
вот и вопрос, как все же правильнее с точки зрении оптимизации?
Как раз вчера был спор в общей группе по андроиду на эту тему. Что самому удобнее, то и используй
Size: a a a
2020 July 28
БД
Хотя у уроке указано именно передать пустую строку
Если понадобится внести не пустую строку, а какой-то текст, то используй setText() вместо просто text =
GB
Студия предлагает поменять setText() на вариант синтаксиса котлина text
БД
Студия предлагает поменять setText() на вариант синтаксиса котлина text
Странно, в случае с EditText не должна, сам сейчас проверил в проекте
GB
И правда не предлагает. А в чем разница тогда? В оптимизации?
YR
Я об этом и спрашиваю. В котлине можно по айди обраться, под капотом findViewById и findCachedViewById при последующих вызовах.
То есть по идее потери в производительности, за счет излишнего кода под капотом, не должно быть. Но на сайте гугла по андроиду пример с findViewById
То есть по идее потери в производительности, за счет излишнего кода под капотом, не должно быть. Но на сайте гугла по андроиду пример с findViewById
Я использую aйдишники напрямую. Просто для себя изменил правила их написания с under_score (как принято в гугл) на camelCase и обязательно добавляю TextView или EditText или др., чтобы в коде все было четко и не путаться.
например
например
usernameEditText, continueButton, dividerView и т.д.GB
а я наоборот решил для читаемости воспользоваться нотацией гугла и перешел с верблюжей нотации, на нижнее подчеркивание для айдишников
БД
Честно говоря не пробовал искать инфу почему для EditText приходится писать не в Котлин стиле, видимо просто text = уже занята, поэтому приходится через setText прописывать
БД
а я наоборот решил для читаемости воспользоваться нотацией гугла и перешел с верблюжей нотации, на нижнее подчеркивание для айдишников
Кстати да, с подчеркиванием сразу в коде видно где вьюхи а где параметры, не знаю наскок это правильно, но пишу также
GB
ну это утверждено гуглом, так что думаю правильно. Лично для меня это удобнее в читаемости
GB
Слушай, а да. setText() все как надо отрабатывает, а просто text дает ошибку
GB
Спасибо)
YR
И правда не предлагает. А в чем разница тогда? В оптимизации?
У EditText есть несколько вариантов setText с разными атрибутами (т.е. с разными входными аргументами, String, Editable, @StringRes) и один getText который возвращает только Editable, а так как в котлине нельзя сделать только setOnly property, поэтому и text может быть только Editable
GB
Теперь понятно) буду знать
YR
Кстати да, с подчеркиванием сразу в коде видно где вьюхи а где параметры, не знаю наскок это правильно, но пишу также
не всегда. во-первых если вьюха из одного слова - то не понятно, а во-вторых, как по мне, under_score в котлине не по феншую, но это дело вкуса )
БД
не всегда. во-первых если вьюха из одного слова - то не понятно, а во-вторых, как по мне, under_score в котлине не по феншую, но это дело вкуса )
С названием фрагмента в начале меньше двух не бывает) Ну я и не утверждаю что так правильно, если на работе скажут писать по-другому, буду писать по-другому
GB
ну да, кому как удобнее. Просто в данном случае мои вкусы совпали с правилами гугла)
YR
С названием фрагмента в начале меньше двух не бывает) Ну я и не утверждаю что так правильно, если на работе скажут писать по-другому, буду писать по-другому
А во тут кстати я ушел от паттерна называть все с префиксом фрагмента. Как раз в коде фрагментов выглядит как масло масленное
БД
А во тут кстати я ушел от паттерна называть все с префиксом фрагмента. Как раз в коде фрагментов выглядит как масло масленное
После пары раз, когда проставлялись неправильные импорты, решил шо писать названия не такая уж плохая идея. Если быть внимательным, то конечно это излишне
2020 July 29
R
Привет. Подскажите пожалуйста кто нибудь, можно ли и как такой код из жавы на котлин переписать.