все итемы схожи по полям

есть свои различия

Там вроде есть метод

Типо getTypeId(int position)

Типо getTypeId(int position)

getItemViewType

getViewType

разные холдеры и погнал

Можно даже один холдер

Если элементы более-менее схожи

потом в одном решишь добавить что то

и начнется холдер из 20 полей

и в onBind ифы

сделай один скопируй и назови по другому и будет тебе счастье)

зато потом не пожалеешь

Могу рассказать, что да как там, ибо за свою жизнь на*бался с ними более чем достаточно

о, хочу подробностей. а у тебя опенсорс какой-нибудь на эту тему есть?

Ребят, у кого 7ка - можете это проверить

adb shell pm list packages -3 -e

в интернете кто-то писал, что на 6 и выше уже не работает, но на 6ке работает

Э, никто не знает - ссылка на донат страничку в приложении это легально или нет со стороны гугл плей? а то там очень двоякие трактовки нашел

Сделай просто инапп донат

И 100% легально будет, хоть и придется отстегивать гуглу

Акк без платежей

невкрутить это туда

adb shell pm list packages -3 -e

работает на 7.1.2

Насколько помню - легально только если ты продаешь физический контент а-ля пицца или футболки

А просто донаты ворде как нет, но не гарантирую

работает на 7.1.2

Благодарю

@Ivanivanov21 судя по https://play.google.com/about/monetization-ads/

можно

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

Э, никто не знает - ссылка на донат страничку в приложении это легально или нет со стороны гугл плей? а то там очень двоякие трактовки нашел

если обратят внимание - забанят, но скорее всего не обратят

Нет, если ты не чарджишь за функционал или контент за пределами приложения

А это просто "донат" добровольный

то по идее не забанят

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

ну ясно что для коммерческих такое обычно и не используют ;-D

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

я пейпал юзал

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

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

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

на такой вопрос думаю нет одназначного ответа ;-D как говорят tdd фанатики, должно быть 100% покрытие с первого дня приложения

на такой вопрос думаю нет одназначного ответа ;-D как говорят tdd фанатики, должно быть 100% покрытие с первого дня приложения

Не, к TDD я и близко это подвести не смогу, тут уже до мультидекса недалеко. А вот обычные coverage сделать время и возможность есть.

Я офигею тут все тестами покрывать :)

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

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

некоторые люди вообще за проект без тестов браться не будут

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

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

Ни разу не получил пользы от тестов, кроме проверки SQLiteStatement-ов на работоспособность и самописного фреймворка - на корректность возвращаемых из базы результатов

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

Если тесты которые ты пишешь этой задачи не решают то они не нужны

кто нибудь устанавливал pybox2d?

Но я так понял что в мобильной разработке тесты это какое то западло для всех

Когда на тех же бекендах у тебя код без тестов даже не примут

и ты не думаешь нужны они ил нет.. без них просто не рассматривается вариант ?

Если тесты которые ты пишешь этой задачи не решают то они не нужны

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

логируется, но не факт что твои логи отражают реальные проблемы

У меня такая ситуация. Есть spinner, в котором указываются единицы измерения товара (кг/л/шт). И мне нужно сделать так, чтобы при выбранных килограммах ввод в поле веса умножался на ходу на поле весНаКилограмм, а при остальных выбранных значениях - нет. Меня настораживает, что метод называется addTextChangedListener, вместо setTextChangedListener. Значит добавление нового слушателя не будет отменять старого?

на такой вопрос думаю нет одназначного ответа ;-D как говорят tdd фанатики, должно быть 100% покрытие с первого дня приложения

На то они и фанатики. Умпутун неплохо расписал в радио-т, практичный все таки мужик. Обычно покрывают тестами биз. логику (и хорошо когда она из pure функций), а остальное вскроется функциональными тестами и автоматизированными-UI

То что ты описал это почти идеальный кейс по тестированию

я думаю на андроиде нужно минимум хотя бы покрыть тестами весь свой код в отрыве от андроида

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

если как в пингвиненке все в одной активити то он нетестируемый уже по умолчанию

ну и мне кажется чем больше твой код тестируем, тем лучше архитектура как сайд эффект

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

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

банально > 1 разработчика на проект и от тестов уже дофига толку

если 1 тоже дофига толку

О да как раз сдк как раз легко тестировать

ERROR: S client not available

банально > 1 разработчика на проект и от тестов уже дофига толку

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

Ну хз, недавно делал один проект на Go, сразу начал с tdd, оно не только временя не ело, я его раза в 2 быстрей как раз засчет тестов и сделал

в итоге 100% покрытие и полгода в продакшене без багов

QA нормальные есть? sanity/regression тесты, которые QA делают? Если да, то зачем еще тратить время на юнит тесты? Если нет, то сочувствую :-)

Ну хз, недавно делал один проект на Go, сразу начал с tdd, оно не только временя не ело, я его раза в 2 быстрей как раз засчет тестов и сделал

ты про юнит тесты ведь только?

интеграционные, e2e тоже писал?

юнит, функциональные, интеграционные

я их особо не разделяю, либо код оттестирован либо нет

код может быть по разному оттестирован

вообще "оттестирован" - это ложная уверенность

понятно что даже 100% покрытие тебя не спасет от 100% багов

в этом плане, елси вообще нет тестов, то хоть очковать будешь менять и более аккуратно стараться это делать :-)

могут быть разные факторы

но такой код в 100 раз надежнее кода без тестов

100% и не нужно)

это точно

не факт)

Ну хз, недавно делал один проект на Go, сразу начал с tdd, оно не только временя не ело, я его раза в 2 быстрей как раз засчет тестов и сделал

ну там там же логика разработки вообще другая. я не очень понимаю как можно писать для Андроид tdd учитывая UI и его сложности, но я плохо умею в аджайло-подобные системы

вообще "оттестирован" - это ложная уверенность

странное утверждение, если тестирование - это лишь о рисках

странное утверждение, если тестирование - это лишь о рисках

тестирование это ведь о поисках багов? риски - это к страховым компаниям

в общем это был пока вот реальный опыт с нуля с tdd и я остался доволен

А в какой слой логично запихнуть Firebase аналитику, data?

вы пишете сферические тесты в вакууме?

или для какой-то цели? в том числе и баги ищите для каких то целей

в итоге 100% покрытие и полгода в продакшене без багов

Без багов можно писать и без тестов

;-D

можно, если ты бог

и приложение мелкое

и ты понимаешь все входящие и выходящие данные

и можешь держать все в голове

возьмите QA и не тратьте время на тестирование "кликнул туда", "кликнул сюда".

и ты еще точно знаешь как поведет твое приложение на всех китайских девайсах))) ггг