надо на ошибки смотреть, так никто не скажет
Игорь
Mike
Nikita
5 элементов при размере(ширине) Х занимают не весь экран, пусть растягиваются чтоб занимали весь экран. А если элементов 100, то все сжимаются до заданного минимума и скролятся
К сожалению никогда такого не реализовывал. По моему мнению такое можно реализовать только расчетом ширины одного элемента (максимального или минимального) и размера экрана. Исходя из этого и из количества элементов в onBindViewHolder задавать Params. Получится криво, но работать скорее всего будет
Игорь
почитай вообще, как прогардом пользоваться и что делать с ворнингами
А warnings допускаются вообще или нет?
Vishnyakov
Vishnyakov
где минимум равен 1/5 ширины экрана
Nikita
Возможно можно как-то добиться подобного с помошью ConstraitLayout, но с ним я пока не подружился
Vishnyakov
Возможно можно как-то добиться подобного с помошью ConstraitLayout, но с ним я пока не подружился
констрейнс мало что имеет поверх того, что умеют линеар, релэйтив.... совмещает их функционал и добавляет некоторые штуки типа соотношения
Nikolai
Nikita
констрейнс мало что имеет поверх того, что умеют линеар, релэйтив.... совмещает их функционал и добавляет некоторые штуки типа соотношения
Понятно. Там еще вроде анимации через ConstraintsSet можно делать.
Akb
Привет народ. Подскажите по proguard, как его настроить чтобы "защитить" только мои классы, не трогая чужие библиотеки?
Mike
Akb
Чтобы защитить — никак.
не правильно выразился, добавить костылей для тех, кто будет делать реинжиринг
Mike
не правильно выразился, добавить костылей для тех, кто будет делать реинжиринг
собственно, написать -keepы, которые сохранят все библиотечные классы.
Но это многократно упростит реверс.
Akb
собственно, написать -keepы, которые сохранят все библиотечные классы.
Но это многократно упростит реверс.
но это хоть что-то, чем ничего
Akb
почему бы не обфусцировать вместе с библиотечным кодом?
библиотеки на потом, хотя бы свои научиться обфусцировать
Mike
библиотеки на потом, хотя бы свои научиться обфусцировать
нет никакого смысла разделять код на свой и библиотечный
Kanstantsin
Привет народ. Подскажите по proguard, как его настроить чтобы "защитить" только мои классы, не трогая чужие библиотеки?
ну я обычно делал так, садишься смотришь по dependencies либы все, гуглишь их proguard и себе прописываешь(многие либы из-за аннотаций например после обфускации работать будут некоректно, поэтому надо keep писать), потом врубаешь прогуард например в дебаге, запускаешь, юзаешь, смотри крэши, разбираешься, также тестерам тоже говорим что версия с proguard уже, поэтому могут быть крэши и они очень важны ))
Kanstantsin
примерно так делаю
Сергій
Поэтому лучше включать прогард с самого начала проекта 🌚
Kanstantsin
в идеальной ситуации обфусцировать надо и либы, и свой код, не делая разделения никакого
Mike
нормальным либам нужны только всякие -dontwarn, -keep — нет
Kanstantsin
просто обычно настройка релизной версии идет не сразу, у нас
Kanstantsin
что-то может поменяться и т.д.
Kanstantsin
да и никаких сложностей потратить пару часов на proguard нету
Kanstantsin
время выделяют без проблем, на такие задачи
Kanstantsin
мне например даже нравится, не самые худшие таски )))
Kanstantsin
Поэтому лучше включать прогард с самого начала проекта 🌚
и опять же, сейчас я делаю тестовый проект свой, пишут, проверяю всякие темы, фичи на нем, обкатываю, настраивать proguard вообще нет желания сейчас, но мысли запилить потом на маркет прилажку есть, как более менее сделаю функционал и т.д.
ну вот как решу что буду релиз делать, буду настраивать proguard
Kanstantsin
вариант не самый лучший, но может быть что вообще до релиза не дойдет )
Kanstantsin
если лень будет побеждать (
Сергій
на пет проджектах включать прогард нету смысла, да )
Сергій
он может тупо не дожить
Kanstantsin
угу
Kanstantsin
есть вероятность что всё сильно поменяется, быстрее чем будет вменяемый функционал в нем, наберется функционал так сказать
Сергій
Kanstantsin
аха, это да
Kanstantsin
хотя relative давно уже rip наверно
Kanstantsin
везде где его можно сделать иначе, делали иначе, даже не помню когда последний раз делал его
Mike
relative живее живых, альтернатив нет
Kanstantsin
тоже до него не добрался нормально
Kanstantsin
похоже что нет )
Alexander
уже не помню релэйтив)
Kanstantsin
тоже
Kanstantsin
просто главная проблема, это рендеринг, relative пробегает по всему layout 2 раза, вместо стандартных разметок, поэтому если есть возможность заменить, почему бы не заменить
Konstantin
а констрэинт так плох ?
когда в дело вступает реюзабельность лэйаута со скрытием кусков ... начинается пиздец с отступами, паддингами, правильно-направлеными цепочками... кароч ад
Kanstantsin
даже констрэинт проверяли когда пару раз, всё ок
Kanstantsin
а так вообще порой хватает и без констрэинта чем-то заменить
Kanstantsin
но в основном такие что этого хватало
Kanstantsin
и линеар с весами лучше, имхо
Mike
да на линеар с весами даже, опять же зависит от таски наверн
а линеар с весами однопроходный? А с весами + wrap_content?
Kanstantsin
казалось от этого не зависит
Kanstantsin
и линеар всегда однопроходный
Anonymous
Насколько я знаю в релативе или линеаре с весами, onMeasure у вьюх вызывается дважды, если двойная вложенность четырежды итд. В констреинте 1 раз вызывается
Mike
Насколько я знаю в релативе или линеаре с весами, onMeasure у вьюх вызывается дважды, если двойная вложенность четырежды итд. В констреинте 1 раз вызывается
но constraint при этом обмеряется медленнее, разве нет?
Anonymous
ну в некотором смысле медленнее. Но для достаточно большой вложенности констреинт будет быстрее.
Anonymous
И вроде констреинт точно быстрее релатива
Mike
ну в некотором смысле медленнее. Но для достаточно большой вложенности констреинт будет быстрее.
не понятно, что с чем сравнивается
Влад
а линеар с весами однопроходный? А с весами + wrap_content?
https://youtu.be/4T3q5qXwhgY?t=15631
Александр
Сергій
Mike
Что Android Framework думает про constraint: а ничего, его там нет.
Сергій
Это просто инструментарий
Сергей
Приветствую, подскажите, пожалуйста, не сталкивались со следующей ситуацией In