Может быть наоборот?))

Почему это наоборот? Хотите сказать, что Glide весит меньше Picasso?

Почему это наоборот? Хотите сказать, что Glide весит меньше Picasso?

Хотел, да. Всегда считал именно так, но оказать наоборот “Glide vs. Picasso” https://medium.com/@multidots/glide-vs-picasso-930eed42b81d

А, я с Фреско попутал

Picasso deprecated так по мне)

А почему?

Хотел, да. Всегда считал именно так, но оказать наоборот “Glide vs. Picasso” https://medium.com/@multidots/glide-vs-picasso-930eed42b81d

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

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

Не знаю насчёт Пикассо, но Глайд тоже самое делает

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

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

Нет

Ладно, всем спасибо за ответы

Нет

А какой тогда передавать для аймейдж лоадера? Или передать в адаптер прямо пикассо?

itemView.getContext()

Ай, точно, спасибо :)

То есть юзать пикасо в адаптере -- норм? Просто сколько я его не использовал, все время в логах висит gc, который что-то там подчищал

Тоже с эти сталкивался, заменил на glide и расход памяти снизился

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

Храниь картинки в локальной БД — вообще бред. Любая загружалка картинок имеет кэш.

То есть юзать пикасо в адаптере -- норм? Просто сколько я его не использовал, все время в логах висит gc, который что-то там подчищал

Для адаптера лучше глайд в виду его механизма кеширования.

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

да, эта реализация

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

https://github.com/TakahikoKawasaki/nv-websocket-client https://github.com/TooTallNate/Java-WebSocket

ты обе испотльзовал?

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

Ээээ. В Пикассо есть кеширование

Но механизм кеширования отличается от глайда. У Пикассо он медленее, но занимает меньше памяти.

Ээээ. В Пикассо есть кеширование

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

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

Раньше это когда?) Год назад точно была)

Там Пикассо кеширует фуллсайз и в момент выгрузки в imageview делает ресайз, в то время как глайд кеширует для каждого imageview свой размер, что быстрее работает.

Т.е. у Пикассо будет 1 картинка, а у глайда может быть 2+ разных размеров одной и той же картинки.

Кто делал авторизацию по GitHub? Токен получить по Api OAuth?

ты обе испотльзовал?

Обе, одна не понравилась, другая норм.

Обе, одна не понравилась, другая норм.

вторая где больше звезд понравилась?

Там Пикассо кеширует фуллсайз и в момент выгрузки в imageview делает ресайз, в то время как глайд кеширует для каждого imageview свой размер, что быстрее работает.

Мне казалось, что у пикассо это настраивается.

Спасибо всем

Я думал Пикассо кэширует после ресайза

давайте все пойдём читать доки

Гг

О, кстати, еще вопрос: Как вы реализуете master-detail flow? В доках к arch components есть решение с использованием shared viewmodel для двух фрагментов Это норм?

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

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

Так кидай проект прямо сюда.

Так кидай проект прямо сюда.

Хорошо, будут серьезные проблемы обязательно воспользуюсь Вашем предложением =)

Хорошо, будут серьезные проблемы обязательно воспользуюсь Вашем предложением =)

Какие ещё проблемы? Если проект опенсорсный, почему не кинуть сюда ссылку? Если нет — вам в @mobile_jobs.

Ребят,всем привет, такой вопрос, нормальная практика в проде dimensions под каждый экран свой указывать? Или есть какой либо более правильный способ решения, разных экранов?

Ребят,всем привет, такой вопрос, нормальная практика в проде dimensions под каждый экран свой указывать? Или есть какой либо более правильный способ решения, разных экранов?

Я отдельные dimens делаю под планшеты только

Ребят,всем привет, такой вопрос, нормальная практика в проде dimensions под каждый экран свой указывать? Или есть какой либо более правильный способ решения, разных экранов?

Как правило хватает одной общей разметки

Я отдельные dimens делаю под планшеты только

а для мобилок с 420х800 и 2560х1440?

а для мобилок с 420х800 и 2560х1440?

Разрешение не имеет значения, есть же dp и sp.

Ну вообще бывают различия на разных аппаратах, потому как вендоры сами определяют подходящий density multiplier

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

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

Какие ещё проблемы? Если проект опенсорсный, почему не кинуть сюда ссылку? Если нет — вам в @mobile_jobs.

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

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

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

Мне кажется чаще всего различие будет не очень огромным. Если различие большое (вендор сделал абы как лишь бы работало) то должен помогать констрейнт лейаут, там можно выставлять гайдлайны, и указывать их bias в процентах

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

> по мере обучение проектировать по тематики Что это значит — не понял. > Пока только учусь. Тогда, наоборот, стоит искать ментора, который будет следить за качеством кода. Если создать команду из одних начинающих, будет жесть.

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

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

Мне кажется чаще всего различие будет не очень огромным. Если различие большое (вендор сделал абы как лишь бы работало) то должен помогать констрейнт лейаут, там можно выставлять гайдлайны, и указывать их bias в процентах

ну про bias и гайдлайны согласен, вобщем констрэйнтом можно разрулить данные проблемы при должной реализации, и не обращаться к созданию dimens файлом под разные экраны?

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

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

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

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

Понял, спасибо)

Только сам констрейнт и wysiwyg редактор не очень люблю)

> по мере обучение проектировать по тематики Что это значит — не понял. > Пока только учусь. Тогда, наоборот, стоит искать ментора, который будет следить за качеством кода. Если создать команду из одних начинающих, будет жесть.

По тематики- имею ввиду учим плюшки API level 15 выучили применяем в проект потом API level 16, API level 19 и т.д.

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

Оно -> stack overflow ?

Разрешение не имеет значения, есть же dp и sp.

👍👍👍👍👍

надо мерять не пикселями и не килограммами - а общепринятыми единицами 😂

есть три основные категории для телефонов 360 - пиздюки 380 - средненькие (опционально - можно забить встречаются не часто) 400 - нормальные такие 411 - большой экран (но ещё телефон) всё что дальше - фаблеты и таблеты

мы ща пришли к тому что sw360dp - отдельно не объявляется (just "values")- его считать минимальным и дефолтным а дальше есть папки - sw400dp и sw411dp и иногда - если прям оч важно можно воткнуть еще sw380dp

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

У гугла тонна доков по Support Diferent Screen Sizes и Resource Qulifiers (order of resolving в том числе). Более того сейчас очень много открытых источников со статистиками популярности. А-ля Global Market of Smartphone Vendors (2017/18, etc) и им подобные (гугл в помощь) Всё это можно один раз сесть - проресёрчить сопоставить, лечь поспать с этой мыслью, встать еще раз хорошо всё обдумать, увязать в одно правило ))) и прийти к каким-то "удовлетворяющим золотым серединам" - для вашей разработки 😁👍

По тематики- имею ввиду учим плюшки API level 15 выучили применяем в проект потом API level 16, API level 19 и т.д.

Знать фишки современных апи нужно и полезно, но, скорее всего, на работе Вы будете писать код покрывающий большую часть аппаратов на рынке, т.е. например под апи 15. Я в «домашних» проектиках ставлю минимальное апи 21

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

Знать фишки современных апи нужно и полезно, но, скорее всего, на работе Вы будете писать код покрывающий большую часть аппаратов на рынке, т.е. например под апи 15. Я в «домашних» проектиках ставлю минимальное апи 21

🤔 Хорошая мысль. Я не для спора - но позвольте другую сторону медали ... покажу

Мне кажется логичным наоборот идти "сверху-вниз"... почему... вот смотрите:

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

У гугла есть инструмент чтобы обеспечить совместимость приложения с более ранними версиями Android. Если я неправ поправьте.

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

я уже 8 минут смотрю )

я уже 8 минут смотрю )

))) сорян... отвлёкся

Всё таки люди (юзеры/заказчики/руководили) ожидают от андроида примерно того же что и от айфона (то есть качество, плавность, поддержка современных фич, скорость разработки) - их за это нельзя винить - это нормальная конкуренция.

я уже 8 минут смотрю )

Извините, не хотели Вас по тревожить.

У гугла есть инструмент чтобы обеспечить совместимость приложения с более ранними версиями Android. Если я неправ поправьте.

Да, конечно, есть суппорт библиотека, которая унифицирует апи, но такие вещи как динамические пермишены - системные штуки, и ниже андроида 6.0 их просто не добавить, поэтому надо знать как обрабатывать одни и те же вещи в разных версиях системы

Но таких моментов в андроиде немного

Поэтому, если вы учитесь, то лучше, на мойвзгляд, учить «базовые» вещи, а когда стоокнетесь с чем нибудь специфичным для высокого апи, то без труда разберетесь самостоятельно

Всё таки люди (юзеры/заказчики/руководили) ожидают от андроида примерно того же что и от айфона (то есть качество, плавность, поддержка современных фич, скорость разработки) - их за это нельзя винить - это нормальная конкуренция.

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

если посмотреть на поддержку устройств производителем (апдейты для айфонов, пикселей и нексусов) - то как правило их срок жизни 2 года. Гугл н-р уже не выпустил oreo для nexus 9 и тд Далее - интервал в 2 года - нас уравнивает с айфоном по фичам, по покрываемой аудитории и скорости разработки - и это справедливо. Хотите больший рынок, большее покрытие - платите В андроиде в среднем апи повышается на единицу два раза в год - значит вилка в (minApi = target - 4) - получается в полне себе оправданой

Да, нам мобильщикам как ни крути приходится учить специфику кучи апи под разные версии)