Кажется, там есть ссылка

Вы по ней ходили?

Ходил

Там нужно класс писать и генерить это не подходит. Нашел другой вариант

Ок:)

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

Я думаю, что получив объект, нужно сложить его в базу. Со всеми его списочками и данными. Вернуть во вью айдишник этого объекта. В самой модельке объекта прописать специализированные сеттеры или методы, которые занимаются раздачей данных в зависимости от условий. И вот когда вью получает от ретрофита айди объекта, она обращается в базу, по id получает объект, у объекта получает данные через разные методы.

Готово. Вы великолепны.

Помогите написать UI тесты, не понимаю как написать так, чтобы они действительно были полезны Есть кнопка, у которой есть 3 состояния: обычное, нажата, мигает В каждом из состоянии меняется цвет картинки, цвет текста и цвет фона Цвета задаются через ColorStateList, не напрямую, а цвета меняются, когда меняется состояние вьюшек (activated или нет) Как это протестить?

Надо ли проверять цвет каждого элемента при смене состояния или достаточно проверить, что состояние действительно изменилось и не проверять текст?

Как быть в случае с изображением, если оно у меня векторное? Надо ли проверять цвета вектора?

Надо ли проверять цвет каждого элемента при смене состояния или достаточно проверить, что состояние действительно изменилось и не проверять текст?

Какова вероятность того что цвет не изменится? И каковы бизнес- риски от того что цвет не поменялся?

Какова вероятность того что цвет не изменится? И каковы бизнес- риски от того что цвет не поменялся?

По сути это библиотека UI элементов и внутри неё уже заданы дефолтные цвета, которые я и хотел тестить, но любой, кто использует эту либу может поменять цвета В основном приложении менять цвета будут крайне редко

Какова вероятность того что цвет не изменится? И каковы бизнес- риски от того что цвет не поменялся?

Если цвет не поменяется, будут ругать)

Как написать UI тесты для мигающей кнопки?

Как написать UI тесты для мигающей кнопки?

Делайте свой матчер вроде. https://gist.github.com/Aracem/a596c40f9750f02f4e606dad170925e7 Или используйте screenshot tests. https://facebook.github.io/screenshot-tests-for-android/

Ребят, подскажите с чего начать изучение котлин, сколько времени на его освоение уйдет?

Сейчас я знаю JavaScript и PHP.

С Java дело не имел.

С Java дело не имел.

лучше начни с джава

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

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

То есть без Джава никак?

То есть без Джава никак?

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

999999999999 раз спрашивали

Поищи

Ок.

Юнит тестирование с Robolectric занимает 5.7 секунд Интеграционные тесты занимают 5.1 секунду В чём тогда преимущество Robolectric ?

Ребят, подскажите с чего начать изучение котлин, сколько времени на его освоение уйдет?

tl;dr; https://play.kotlinlang.org/koans/overview

Юнит тестирование с Robolectric занимает 5.7 секунд Интеграционные тесты занимают 5.1 секунду В чём тогда преимущество Robolectric ?

Вероятно, вы имели в виду инструментальные тесты? Robolectric позволяет запускать платформо-зависимые юнит тесты на JVM.

Вероятно, вы имели в виду инструментальные тесты? Robolectric позволяет запускать платформо-зависимые юнит тесты на JVM.

Да, инструментальные) А зачем это делать на JVM, если я могу это сделать на Android за гораздо меньшее кол-во секунд ? Ведь одно из основных правил тестов (F.I.R.S.T.) - скорость

Я бы вообще выкинул этот Robolectric, но раз уж его продвигает Гугл и его многие используют, значит в нём есть какой-то смысл

Да, инструментальные) А зачем это делать на JVM, если я могу это сделать на Android за гораздо меньшее кол-во секунд ? Ведь одно из основных правил тестов (F.I.R.S.T.) - скорость

У вас не всегда есть девайс и средства его поднятия. Например, на CI эмулятор не так просто завести.

и на большем количестве тестов прирост в скорости таки должен быть ощутимым.

и на большем количестве тестов прирост в скорости таки должен быть ощутимым.

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

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

Мне кажется, вы что-то перепутали. Есть чистые unit-тесты, для вашей чистой логики. Есть инструментальные (robolectric) unit-тесты, для тестирования всё ещё логики, но уже той, которая использует какие-то части Android Framework. Есть интеграционные тесты, которые технолгически те же юниты, просто охватывают больше компонентов. А есть UI тесты, которые тестируют именно UI вашего приложения, и запускаются только на девайсе. Тестирование кнопочек больше похоже на последнюю категорию.

Да, инструментальные) А зачем это делать на JVM, если я могу это сделать на Android за гораздо меньшее кол-во секунд ? Ведь одно из основных правил тестов (F.I.R.S.T.) - скорость

Обычно, тесты на Robolectric подходят быстрее. Особенно, если их больше, чем несколько.

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

время "офигительных" вопросов Когда я запускаю приложение, OS создаёт под него процесс и выделяет ему память, которую берёт под контроль Dalvik. Верно ли, что Dalvik разделяет предоставленную ему память на кучу и стек? Я так понимаю что это разделение внутри процесса, не внутри OS? Разбираюсь со сборщиком мусора, и из контекста вроде как следует то что GB работает с кучей каждого процесса. Не уверен что это так, и пояснений нигде нет, видимо ответ на этот вопрос очевиден всем кроме меня 🧐

Вроде стека нет

То есть стек на уровне OS?

Где - то же он есть)

Насколько я понимаю, система (linux) выделяет процессу память, а процесс уже делает что хочет, так что по сути VM сама управляет регистрами/кучей

Зачем тебе стек?

Мне он не нужен. А вот процессу - нужен, я так понимаю в стеке хранятся ссылки на объекты из кучи.

Мне он не нужен - в том смысле что я с ним не работаю, вопрос просто для понимания происходящего.

Что-то я запутался Вроде dalvik безстековый

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

Что-то я запутался Вроде dalvik безстековый

там регистры, вроде

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

у процесса есть свое адресное пространство, которое ничео не знает про стэк и кучу

у процесса есть свое адресное пространство, которое ничео не знает про стэк и кучу

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

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

Откуда там стек

Откуда там стек

Читал в какой - то статье про GB.

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

он register based

он register based

Не понял, если честно. Видимо опять придётся читать тонну текста( Так, ок. Пусть Dalvik не знает про стек и не оперирует им. Тогда верно ли утверждение, что память, выделяемая процессу, Dalvik воспринимается как та самая куча?

https://developer.android.com/topic/performance/memory-overview

Первоисточник :)

Не понял, если честно. Видимо опять придётся читать тонну текста( Так, ок. Пусть Dalvik не знает про стек и не оперирует им. Тогда верно ли утверждение, что память, выделяемая процессу, Dalvik воспринимается как та самая куча?

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

Dalvik основан на регистрах

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

Ну да, я понимаю что сам процесс никакими такими понятиями не оперирует. Оперирует Dalvik. Понял принял, чуть яснее стало.

https://developer.android.com/topic/performance/memory-overview

Потступался пару раз к этой ссылке, сложно для понимания, каждый раз откладываю её прочтение.)

Ну да, я понимаю что сам процесс никакими такими понятиями не оперирует. Оперирует Dalvik. Понял принял, чуть яснее стало.

Возможно, вас запутал StackOverflowException. Но этот стек, как и куча - абстракция VM'a.

Читал в какой - то статье про GB.

Garbage collector?

Andevcon-DEX.pdf

Garbage collector?

Да

Может про JVM читал? Там 100% стек

Возможно, вас запутал StackOverflowException. Но этот стек, как и куча - абстракция VM'a.

О StackOverflowException я и не думал даже)

(Есть конечно регистровые, но большинство настольных VM стековые, ибо памяти и частоты больше)

Может про JVM читал? Там 100% стек

Не исключено кстати.

Andevcon-DEX.pdf

Вроде выглядит годно, посмотрю, спс.

мой сервис виден только в кеш он нивиде рабочий приложение

Может про JVM читал? Там 100% стек

Тут не так давно проскакивало, что каких - то существенных различий в работе GB между Dalvik и , скажем так, "прочими" VM нет. Поэтому мб можно сказать, что прочитанное про GB для JVM справедливо и для Dalvik в полной мере.

Вроде выглядит годно, посмотрю, спс.

https://androiddev.apptractor.ru/android-dev-podcast-96/ https://www.youtube.com/watch?v=Zc4JP8kNGmQ вот ещё на посмотреть-послушать :)

Тут не так давно проскакивало, что каких - то существенных различий в работе GB между Dalvik и , скажем так, "прочими" VM нет. Поэтому мб можно сказать, что прочитанное про GB для JVM справедливо и для Dalvik в полной мере.

dalvik использует тот же алгоритм, что и jvm

есть детали, которые отличаются

помогите мне тоже

например, dalvik не меняет адрес объектов в куче

ох, надеюсь, что правильно помню

Тут не так давно проскакивало, что каких - то существенных различий в работе GB между Dalvik и , скажем так, "прочими" VM нет. Поэтому мб можно сказать, что прочитанное про GB для JVM справедливо и для Dalvik в полной мере.

Такес Стек ИЛИ регистры - для передачи аргументов в функцию/возврата значений Куча - и на пк, и на ведре

например, dalvik не меняет адрес объектов в куче

ты наверное про сжатие памяти

dalvik использует тот же алгоритм, что и jvm

Dalvik уже не совсем актуальный. Вы про ART тоже говорите?