вон, тот же метод setVisible принимает в качестве параметра инт

Стремишься в бесконечность)

пишу такой себе код смотрю вроде всё круто, потом нарываюсь на видео про енумы и начинаю везде выпиливать их, подобные ситуации со мной случались, но не на продакшен проектах на работе, а когда писал приложения для себя с выкладкой в маркет.

но код читается без проблем, т.к. в компайлТайм проверяется допустимое значение

на самом деле, ничего сложного нету в андройде в том, чтобы писать всё без енумов

Прекрасно обхожусь без них. Константы рулят

конечно, нету смысла бросать всё и переписывать

просто новые не за чем писать)

я тоже использую в основном статик файнал, иногда к ним аннотацию IntDef, StringDef и т д применяю

Всем упарывающимся по поводу енумов предлагаю упороться ещё сильнее http://stackoverflow.com/questions/39106109/creating-a-constant-but-local-array/39106675#39106675

конкретно эта ссылка немного не к Android но чуваки проблема есть, можно заоптимизировать создание локальных интов и массивов –> берётесь?)

конкретно эта ссылка немного не к Android но чуваки проблема есть, можно заоптимизировать создание локальных интов и массивов –> берётесь?)

андройд гайды таких рекомендаций не дают )) А про енумы они написали, значит оно имеет смысл

От проблему нашли. Года четыре назад даже вьюхолдер не все использовали, а тут срач по енумам устроили)

андройд гайды таких рекомендаций не дают )) А про енумы они написали, значит оно имеет смысл

ок, ты победил ?

От проблему нашли. Года четыре назад даже вьюхолдер не все использовали, а тут срач по енумам устроили)

я всегда его использовал. самый первый пример списка увидел и он был ещё на ListView но с viewholder

ок, ты победил ?

гдез-то был видеодоклад от Джейка Вортана, он там показывал такие прелести как например внутри класса лучше создать локальную переменную, ссылающуюся на член класса, если используете в методе несколько раз. Т..к доступ к локальной переменной происходит быстрее чем к члену класса. Тоже спички но всё же

А есть кто реально использовал синглтон из Enum? есть подозрение что он существует только для собиседований?

или типичный цикл: for(int i=0;i<list.size();i++) лучше размер вынести в переменную: int size = list.size(); for(int i=0;i<size;i++) так будет чутка быстрее, ибо на каждой итерации не будет вызываться метод size()

ещё я полностью избавился от использования итераторов, цикл по i от 0 до size работает быстрее и эффективнее по памяти чем итераторы

стараюсь не пользоваться итераторами списков в андроид

А я люблю в котлине форыч заебашить)

в котлине мне еще lazy понравились очень

С лэйзи там прикол есть, помню нулл ловил, когда с фрагментами работал

или типичный цикл: for(int i=0;i<list.size();i++) лучше размер вынести в переменную: int size = list.size(); for(int i=0;i<size;i++) так будет чутка быстрее, ибо на каждой итерации не будет вызываться метод size()

цикл в обратном порядке ещё быстрее, но врядли код компилится именно в то, что тынаписал

ещё я полностью избавился от использования итераторов, цикл по i от 0 до size работает быстрее и эффективнее по памяти чем итераторы

По памяти да, везде так

Енумы вообще не признаю )

цикл в обратном порядке ещё быстрее, но врядли код компилится именно в то, что тынаписал

цикл в обратном порядке может нарушать логику если тебе важно в каком порядке будут обрабатываться элементы цикла

В пхп хорошо есть массивы с ключами текстовыми, а тут хз даже, мап какой нить?)

Ну тогда пиши код так, чтобы цикл в обратном порядке не нарушал логику

В пхп хорошо есть массивы с ключами текстовыми, а тут хз даже, мап какой нить?)

есть Map интерфейс и разные его реализации

Ну тогда пиши код так, чтобы цикл в обратном порядке не нарушал логику

не всегда это возможно

Ну тогда пиши код так, чтобы цикл в обратном порядке не нарушал логику

Делать перед циклом реверс чтобы сэкономить на цикле ??

или типичный цикл: for(int i=0;i<list.size();i++) лучше размер вынести в переменную: int size = list.size(); for(int i=0;i<size;i++) так будет чутка быстрее, ибо на каждой итерации не будет вызываться метод size()

И насколько такой цикл быстрее ?

И сколько с экономил ?

Привет

Не так надо спрашивать. А чем ты занимаешься в сэкономленное время?)

?

Как думаете, чем лучше сверстать данный экран?

Какими лейаутами?

Какими лейаутами?

линейный лаяут

Была подобная задача у нас. Можно сделать фон и по позиции последнего нижнего красного пикселя расставлять вьюхи

А как на кнопке поиска сделать стрелочку? Канвасом рисовать?

Можно и так. Или сделай лупу имейджбаттон и бэкгаунд будет с полосочкой твоей

Не так надо спрашивать. А чем ты занимаешься в сэкономленное время?)

:D:D

А как на кнопке поиска сделать стрелочку? Канвасом рисовать?

вот эту черточку с клювиком? проси картинку у дизайнеров

Спасибо за ответы)

ну да кастом EditText можно и там в реализации затолкнуть картинку лупы и этой полоски с клювиком или возможно получиться через стили или drawableRight

Или взять RelativeLayout и положить в него все нужные элементы, edittext, imageview для стрелки и imageview для лупы

Или взять RelativeLayout и положить в него все нужные элементы, edittext, imageview для стрелки и imageview для лупы

только бахнуть это отдельным компонентом

+

добавить нужные методы и юзай, где захочется

ещё и атрибуты кастомные прикрутить можно

а потом на гитхаб залить

красивенький виджет для поиска

?

я думаю там уже есть

тогда можно просто скачать, и не пытаться сделать самому :D

http://cs8.pikabu.ru/images/big_size_comm_an/2016-05_1/1462053871181063275.gif

ребзя, а вот есть адаптер

а можно как-нить не напрямую значения вставлять а назначать функции для форматирования перед вставкой в итем вью

?

Да

Паттерн viewholder

И recyclerview лучше чем listview

Спасиб, буду читать, а потом на ресиклер заменэю

Или сейчас...

ERROR: S client not available

Паттерн viewholder

Ммм это тоесть просто адаптер свой писать для каждого случая?))

В жс с безымянными функциями по проще все выглядит...

Ммм это тоесть просто адаптер свой писать для каждого случая?))

Лучше сразу ресайкл. Листвью это легаси уже, его надобность по пальцам пересчитать можно

В жс с безымянными функциями по проще все выглядит...

ну пиши безымянный адаптер

у меня уже есть ранабл на все случаи жизни ))

переобределяем, вызываем -> профит ))

И ловим мемлики с падениями

Мемори леак

утечка памяти

Наверное это имелось ввиду

И ловим мемлики с падениями

По слову мемлик нашел только тагиева мемлика фарихад оглы

Блин не успел с этой шуточкой, позвонили не успел дописать ))

Утечки утечками но кодить так проще, не надо по милиарду раз что то наследовать да переопределять, а в смарты китайцы вон уже по 6 гб вставляют ))

Для Memory Leak много памяти не бывает ;)

LeakCanary можно подюзывать иногда)

только бахнуть это отдельным компонентом

Relativelayout довольно тяжелый насколько я помню у него 2 прохода для определения child'oв по вертикали и горизонтали, лучше его по возможности не использовать

Это про LinearLayout помоему

Relativelayout довольно тяжелый насколько я помню у него 2 прохода для определения child'oв по вертикали и горизонтали, лучше его по возможности не использовать

компенсируем отсутствием енумов и циклами в обратном порядке

компенсируем отсутствием енумов и циклами в обратном порядке

ЛОЛ

на заре моей андроид карьеры я юзал только RelativeLayout потому что удобно, а потом джедаи андроида сказали не надо так, юзай LinearLayout если можно ибо релатив тяжелый, ну я и послушал отцов

А я вот с пол года назад читал и слышал что LL пересчитывает не скрытые вью по несколько раз

Наоборот гугл пишет избегать вложенностей

Большие экраны в RelativeLayout - анальная боль

"measures can be expensive - and avoiding extra work is always great! this is especially relevant when you consider nested LinearLayouts - let’s suppose that a nested LinearLayout will be measured 3 times, and has children that it would ordinarily measure 3x - those children now get measured 7 times!"

Даже средних размеров

http://helw.net/2016/01/27/on-linearlayout-measures/ вот про LL

У меня на релайтивах норм пока) Самое главное расставить правильно)

А если изменение надо внести? Один элемент убираешь или перемещаешь - и всё к чертям летит

Сложности бывают везде)

по моему всё таки гугл говорил, что relativelayout надо использовать, чтобы уменьшить вложенность