"Как создавать кастомные виджеты? Ответ: Компоновать виджеты внутри одного (вместо наследования)." И тут стало интересно :)

Давно хотел спросить. Какой резон делать все классы, более-менее похожие на модели, data class? Что, прям они все постоянно копируются, сравниваются и toString()-ятся? У нас в большом проекте всего два data class, потому что они расщепляются на компоненты или явно копируются.

Там же генерится туева хуча кода. Типа, авось когда-нибудь пригодится или прогардом отрежется?

Или я чего-то не знаю?

Там же генерится туева хуча кода. Типа, авось когда-нибудь пригодится или прогардом отрежется?

это че за туча такая?

гетеры сеттеры, tostring и copy

ну и функции сравнения

это че за туча такая?

componentX для каждого поля, toString, hashCode, copy и прочее

поле то вроде одно, через свойство оно достается

если декомпильнуть любой датакласс, можно неслабо удивиться

Давно хотел спросить. Какой резон делать все классы, более-менее похожие на модели, data class? Что, прям они все постоянно копируются, сравниваются и toString()-ятся? У нас в большом проекте всего два data class, потому что они расщепляются на компоненты или явно копируются.

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

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

а еще то что деструкцию удобно писать val (x,y,z) = A(x=1,y=2,z=3)

это кстати поможет когда в дата 10+ полей к примеру и сомневаешься все ли они используются

деструктурировав по отдельным val - в коде увидишь подсветку что некоторые не используются (если реально в коде не используются), оченб удобно

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

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

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

я на названия пакетов обращаю внимание только при создании, при работе буквально никогда (разве что если рефакторинг)

деструктурировав по отдельным val - в коде увидишь подсветку что некоторые не используются (если реально в коде не используются), оченб удобно

Ого, а это давно добавили?

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

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

Ого, а это давно добавили?

ну год назад вроде было уже

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

ну и блин, экономить пару килобайт кода когда .so яндекс карт весит под 15 мегабайт - такое себе )

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

Уверен, что нужно думать о результате компиляции не в последнюю очередь. Постоянно вижу тут примеры аля data class(val a: Int) без явного использования этих data.

Уверен, что нужно думать о результате компиляции не в последнюю очередь. Постоянно вижу тут примеры аля data class(val a: Int) без явного использования этих data.

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

ну и блин, экономить пару килобайт кода когда .so яндекс карт весит под 15 мегабайт - такое себе )

Странное сравнение, ну ок

читаемость кода - это самая первая очередь о чем надо заботиться

читаемость кода - это самая первая очередь о чем надо заботиться

И как data добавляет читаемости? Ну ок, этот класс хранит данные. А вон тот класс, не data, не хранит что ли?

И как data добавляет читаемости? Ну ок, этот класс хранит данные. А вон тот класс, не data, не хранит что ли?

нет, он их обрабатывает или отображает или в сеть за ними ходит

И как data добавляет читаемости? Ну ок, этот класс хранит данные. А вон тот класс, не data, не хранит что ли?

все свойства класса в одном конструкторе vs все свойства расписаны ко строкам. К тому же data class подразумевает отсутствие логики. Вот я встречу такой класс в коде и пойму что он нужен для хранения инфы и всё

было дело находил статью с прикольной темой

мы, говорит, выпилили дата классы из проекта т.к. <какая то там надуманая причина>, и среди прочего - пихали логику в них и что то не взлетело. я например в дата классах вообще логику не пишу, и получается что они просто как dto используются для передачи данных между слоями приложения, и как то проблем вообще не ощутил ниразу

все свойства класса в одном конструкторе vs все свойства расписаны ко строкам. К тому же data class подразумевает отсутствие логики. Вот я встречу такой класс в коде и пойму что он нужен для хранения инфы и всё

class SomeNonDataClass(val field1: Int, val field2: String) Тоже хранит данные, тоже никак не обрабатывает их, не может быть отнаследован

class SomeNonDataClass(val field1: Int, val field2: String) Тоже хранит данные, тоже никак не обрабатывает их, не может быть отнаследован

как он поведет себя при сравнении?

а мне не нужно сравнение, мне нужно хранение данных

не нужны компоненты и копирование. Но всё равно по логике это должен быть data class

ну ради бога) это экономия на спичках У тебя может быть в разработке некоторый стандарт. Если ты определишь какие классы делать data, а какие нет и почему, то можешь использовать и коллегам своим рассказать

Ключевое слово data добавляет реализации хэшкода, equals вот и всё

ну ради бога) это экономия на спичках У тебя может быть в разработке некоторый стандарт. Если ты определишь какие классы делать data, а какие нет и почему, то можешь использовать и коллегам своим рассказать

Т.е. так и напиши. Генерирует кучу мусора, которая может быть вырежется прогардом, не используем. НО! в тех двух случаях когда мы использовали data, мы добились ...

Ребят кто как вычисляет и устраняет проблемы в скорости UI?

ну ради бога) это экономия на спичках У тебя может быть в разработке некоторый стандарт. Если ты определишь какие классы делать data, а какие нет и почему, то можешь использовать и коллегам своим рассказать

Ради интереса декомпильнул data class с тремя полями. 120 строк. Ладно, 20 строк мусора, но всё остальное компилируемый код. Тот же класс без data - 12 строк.

Ребят кто как вычисляет и устраняет проблемы в скорости UI?

профайлер студии, ежжи

Ради интереса декомпильнул data class с тремя полями. 120 строк. Ладно, 20 строк мусора, но всё остальное компилируемый код. Тот же класс без data - 12 строк.

и чем это мешает?

профайлер студии, ежжи

да, я просто собрать хочу варианты, ещё layout inspector, если говорить о студии

и чем это мешает?

Умножаем на количество data class в проекта, на количество полей (плюс-минус). Грубо: сотня модельных классов - пара мегабайт потенциально мёртвого кода

да, я просто собрать хочу варианты, ещё layout inspector, если говорить о студии

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

Умножаем на количество data class в проекта, на количество полей (плюс-минус). Грубо: сотня модельных классов - пара мегабайт потенциально мёртвого кода

100 строк по 10 символов в среднем ~ 1кб. чтобы достичь пару мегабайт лишнего кода это надо пару тысяч дата классов завести

Умножаем на количество data class в проекта, на количество полей (плюс-минус). Грубо: сотня модельных классов - пара мегабайт потенциально мёртвого кода

пара мегов в бинарном виде?

Умножаем на количество data class в проекта, на количество полей (плюс-минус). Грубо: сотня модельных классов - пара мегабайт потенциально мёртвого кода

Мегабайт)

в бинаре, да

программы ты для людей пишешь а не для машин

чего их жалеть, каждый год ускоряются железяки и память растет

если жалеешь - пиши на ассемблере, чо уж там )

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

да но иерархия тоже может подсказать какие-то вещи, но и профайлер не самая удобная штука, можно посмотреть что и как долго делалось в конкретном потоке, но не всегда очевидны причины, допустим почему тот или иной метод отрабатывал так долго, конечно можно копать метод, но и тут есть подводные камни когда происходит переключение потоков и и прочее, поэтому хотел узнать весь спектр инструментов, возможно, кто-то занимался серьезным перфомансом, плюс есть же SurfaceView, merge, ViewStub и другие фичи, которые могут помочь

Умножаем на количество data class в проекта, на количество полей (плюс-минус). Грубо: сотня модельных классов - пара мегабайт потенциально мёртвого кода

А что там внутри в этих классах?

программы ты для людей пишешь а не для машин

кстати, где-то недавно была статейка как писать на ассемблере под андроид)))

автор наверное упрт )

автор наверное упрт )

просто он знал ассемблер, а учить другие языки не очень хотелось)))

чего их жалеть, каждый год ускоряются железяки и память растет

Кэши тоже жмоты придумали) Сложность O(n2)? Пох, быстродействие процов же растёт)

Кэши тоже жмоты придумали) Сложность O(n2)? Пох, быстродействие процов же растёт)

https://medium.com/@urish/writing-your-first-android-app-in-assembly-30e8e0f8c3fe вот верный путь

Её тоже критиковать нельзя? 😉

Я наследовался от FrameLayout, как мне программно добавить к LayoutParams ?android:attr/actionBarSize?

Memory leak 🙈

Я наследовался от FrameLayout, как мне программно добавить к LayoutParams ?android:attr/actionBarSize?

public static int[] getColors(Context context, int[] attrs, int[] defaultColors) { TypedArray tArray = null; try { TypedValue tValues = new TypedValue(); tArray = context.obtainStyledAttributes(tValues.data, attrs); int[] colors = new int[attrs.length]; for (int i = 0; i < colors.length; i++) { colors[i] = tArray.getColor(i, defaultColors[i]); } return colors; } catch (Exception e) { return defaultColors; } finally { if (tArray != null) { tArray.recycle(); } } }

Я наследовался от FrameLayout, как мне программно добавить к LayoutParams ?android:attr/actionBarSize?

тоже самое только к dimensions напиши

dp в пиксели надо конвертить?

Раз уж просите: почему Model знает о Presenter?

Раз уж просите: почему Model знает о Presenter?

Да, новичкам это сломает голову, ппц

dp в пиксели надо конвертить?

наверняка да

пруфы?

В ViewPager лежит recycler. как при скроле прятать хедер? пробовал layout behavior, не помогло(

стрелоски там это не зависимости, а data flow. Так что нет)

Ну, согласись, та статья для новичков. Стоило всё же привести такой пример кода, который у новичка будет формировать правильный подход к кодингу.

В ViewPager лежит recycler. как при скроле прятать хедер? пробовал layout behavior, не помогло(

хедер лежит в родительском фрагменте

Надо обрабатывать onDestroy, и модель, наверное, должна была быть синглтоном. Как-то так

да не важно, прост надо было на изменения модели как-то подписаться, а не так чтобы модель презентером управляла. новичкам не рикамендую

Бес сидит в мелочах. Нюансы в примерах важны.

да не важно, прост надо было на изменения модели как-то подписаться, а не так чтобы модель презентером управляла. новичкам не рикамендую

Ну да. Модель вообще не должна знать о презентере.

не за просто так

Да, ладно! В общем, я всё. Мир, дружба, жевачка! 🤝

Может коллективно пильнуть курс по разработке?