На мой скромный взгляд, Uber не является хорошим примером приложения. Как и многие от крупных брендов.
Примеры- сервисы синхронизации, аутентикаторы, камеры различной насыщенности с кучей точек входа, приложения с широким функционалом шаринга, чатики с быстрым ответом, навороченные радио и плееры… В общем примеров много, и перечислил далеко не все. В основном те приложения, которые часто контактируют с пользователем посредством точек входа ОС, нежели напрямую
Согласен. Но, разработка в принципе состоит из проблем и их решений.
Если покопаться, такие проблемы есть и с single activity. И потому, что оба этих подхода имеют проблемы разного характера, они оба имеют право на существование в продакшене. Что из этого выбирать- вопрос опыта разработчика.
Однако, согласитесь, что заголовок и некоторые доводы из статьи весьма провокационны. Вы сравниваете умение применять повсеместно single activity с правами F1, что, всё-таки, расходится с реальностью. Я прочитал статью с удовольствием, но такие моменты смущают.
Лично я (как, думаю, и многие) вижу это так- «Либо ты пишешь только single activity, либо ты- плохой разраб»
И ладно, если в это верят отдельные разрабы- это вопрос доверчивости и опыта каждого. Но, читая подобные статьи на хабре, в это начинает верить техническое руководство. А это- уже проблема…
Согласен, надо. Не хотел приводить пример потому, что коммент был и без того слишком развернутый.
Если просто- activity, которые есть в backstack, android может выгружать из памяти при ее нехватке, оставляя в памяти только ту, на которою Вы смотрите (и ближайшие к ним), а при возврате восстановить из saved state. Таким образом ресурсы, которые выделены на Ваше приложение, со стороны UI (ну или view/presentation-слоя, смотря что используете) не залочены.
В случае подхода с single activity в backstack все фрагменты держатся в памяти. И то, на что Вы ссылаетесь жесткими ссылками из фрагментов- тоже. Да, в простых случаях это- спички. Но когда в стэке лежит что-то тяжелое, да еще и много инстансов (например, карты, или другие тяжелые элементы/api)- то потребление памяти сильно подскакивает, а вместе с ним падает оперативность и отзывчивость приложения из-за частых вызовов GC и нагрузки в принципе.
Да, Вы можете сказать, что «вот на моем флагмане (или мощном B-бренде) всё хорошо». Однако, часто, бОльшая часть ЦА не располагает достаточно мощными устройствами. И современные low-end устройства с 2-3гб оперативы всё равно испытывают нехватку, и там этот вопрос стоит острее.
Да, конечно, это можно решить\обойти в рамках Single Activity- это вопрос навыков. Однако, по моему опыту, такие решения весьма не тривиальны и многие просто на это забивают.
Спасибо. Статья интересная. Особенно по поводу статусбара.
Однако, утверждение, что все приложения должны быть Single Activity- спорное. Этот подход хорош, когда у Вас типичное «конвейерное приложение» а-ля веб-клиента. Если писать что-то по-сложнее или добавить к существующему Single Activity-приложению действительно тяжелый, с точки зрения ресурсов устройства, функционал- с этого момента могут возникнуть проблемы.
Надо ли говорить, что Single Activity-приложение, чаще всего, представляет собой изобилие рукотворных утечек. Потому работа с таким подходом, если всё делать по совести, вызывает не меньше сложностей в сравнении с multiple activity.
Потому важно иметь права как на болид F1, так и на старый добрый вездеход. И понимать, на чем ехать в конкретном случае. Иногда комбинировать.
Иначе это- просто мода. По типу «asynctask- зло» или «dagger нужен везде». Каждому инструменту- своё применение.
Если вы знаете красивое решение, то напишите в комментариях.
Взять ViewModel из Android Architecture Components, использовать в качестве презентера, и bind производить на старте, а unbind в onCleared? Если честно, не пробовал конкретно с bindService, но первое, что приходит в голову- сделать презентер независимым от поворота и коммуникацию с сервисом производить именно там. В итоге чище и более предсказуемо.
Можно еще через moxy это реализовать, но, на мой взгляд, AAC гибче и стабильнее
Простите, но не соглашусь с Вами. Каждой задаче- свой инструмент.
RecyclerView больше для реализации view-логики на ячейку\холдер. И сам по себе предполагает, что контент будет структурно повторяться, для чего и (в дефолтных вариантах) кеширует вьюхи.
View Pager же- именно страничный механизм и предполагает реализацию подобия presentation-логики на страницу. В основном тяжелой логики или хранения в памяти большого количества данных на страницу. FragmentStatePagerAdapter позволяет осуществлять, по факту, менеджмент памяти из коробки благодаря ЖЦ фрагментов. В некоторых случаях можно вообще взять базовый адаптер и реализовывать прямо на вьюхах (без фрагментов) и брать менеджмент на себя.
Да, я понимаю, что бизнес-требования не всегда просты и не всегда адекватны. И что, иногда, проще «отверткой отковырять гвоздь». Но я бы поостерегся называть ViewPager неэффективными и сложным- он не сложнее ListView и много проще RecyclerView.
Поймите правильно, в Вашей статье много полезного. Но не все решения стоит рекомендовать на повседневное использование.
Кстати, на станицах гомеопатических препаратов нет, на данный момент, ни одного упоминания того, что они таковыми являются. Как и отдельного раздела. Лично я бы не рассматривал сервис, который не предоставляет подобной информации, в качестве полезного. И, как мне кажется, многие люди тоже.
Ладно люди, если сервис раскрутится- им начнут пользоваться медики в качестве справочника. А это уже страшно…
Вы это пишите тому, у кого на смартфоне нет приложений от гапсов.
И как Вам живется без порядочной навигации, гуглокарт в приложениях, хранения учеток, push-уведомлений (да, можно организовать пушки руками, но ценой того, что они не будут работать в спящем режиме. А если и будут- то ценой слива батареи)? Может, конечно, для Вас это привычно, но для подавляющего большинства- нет. Очень многое зашито именно в гапсах, и сегодня минимум каждое второе приложение функционировать без них не будет.
Ничего, всё нормально работает
Во-первых это невозможно по описанным выше причинам. Если приложение ограничивает свой функционал по причине отсутствия гапсов- это уже не штатная работа.
Во-вторых- я щупал кит, когда он появился в продаже, на предмет возможности публикации. Отсутствие порядочной замены гапсам- это одна боль. Другая в том, что (если не углубляться в тех. детали) некоторые второстепенные api самого android framework работали некорректно на пробных запусках. Да, всё можно обойти и подобное встречалось ранее. Но зачем? Аудитории мало, тратить время на адаптацию никто не хотел.
На мой личный взгляд — нет, не основная. Тех марок устройств, с которыми продавался Кит лично я больше в продаже не видел. И до начала продаж тоже)
ИМХО, если бы устройства на Ките покупали- то вендорам, которые на нем выпускались, было бы всё равно. А известные вендоры под это дело организовывали бы дочек. Был бы спрос. С такими то низкими ценниками. Но кому нужен тормознутый смартфон\планшет, у которого в маркете нет нужного приложения?.. А даже если поставить apk- не факт, что работать будет нормально (чаще- нет). А без нужных приложений- зачем оно вообще надо?..
А по поводу жалоб о монополии- если бы могли сделать конкурентоспособный продукт- то и жаловаться не пришлось бы
Ничего, что в Китае сервисы гугла были законодательно заблокированы?
Ключевое слово- были. Сейчас не все, но доступны.
Перечислите еще парочку игроков уровня Самсунг?
Сам Самсунг производит больше половины всего объема смартов и планшетов на андроид. Этого уже достаточно.
В догонку- один из лидеров телекоммуникационного оборудования- Huawei. Продажи у них тоже не маленькие. В недавних скандалах тоже часто мелькали.
свалил бы только если совсем были бы невыполнимые условия
Потому и не свалил, что выполнимы. А выполнимы потому, что самсунг- член OHA
Публичного- да. Есть не публичная часть. Например, оборона. Да, samsung строит танки, турели и много чего. Никто не будет это афишировать)
Насколько я понял, доходы от постройки крупногабаритных кораблей туда тоже не входят.
UPD. Почитал. Скорее всего речь именно о мобильном подразделении, а не уточняется во имя маркетинга. Слабо верится в то, что apple дороже корпорации, которая занимается если не всем, то очень многим (текстиль, автопром, фармацевтика, можно долго перечислять).
Никто никому не запрещал делать форки. MiUI как была, так и есть. И Sense\TouchWiz\Flyme- это, по сути, тоже форки. В Китае вообще далеко не на каждом смартфоне есть play services ибо не надо. И ничего, живут себе. Только проблем там больше, поскольку API не всегда реализован верно. А это уже опаснее, чем баги с дровами.
А вот заставить их поддержку вменяемую — не, не мог. Это слишком дорого?
Нет, не дорого. Опасно. Потерей доли рынка. Как писал выше, игрокам вроде samsung вообще сложно что-либо указывать.
Собственно, они пытаются. Android One, Project Treble и тд. Помимо совместимости еще и решить несколько других. Да и сейчас есть требования к вендорам по api драйверов. И, надо сказать, стало в разы лучше, чем на 4.х или 2.х. Ответ на Ваш вопрос — вендоры мешают.
Дело в том, что samung- самый крупный производитель смартфонов и планшетов на сегодняшний день. Да, их мобильное подразделение имеет бюджеты скромнее, чем у компании из Купертино. Но, однако, сам samsung в разы крупнее и дороже apple (возможно, крупнее любой корпорации, которая производит микроэлектронику и комплектующие). Такому игроку сложно что-либо указывать. И если какая-либо сертификация не пропустит какие-либо маркетинговые фишки (некоторые завязаны на драйверах и ядре. Пример- KNOX) по любой причине- это может привести к тому, что огромный пласт устройств перейдет, например, на Tizen (который лежит у самсуга в кармане). Может пару раз вендор и пойдет на уступки, но терпение не бесконечно. Гуглу этого перехода не надо по понятным причинам. Да и пользователям тоже.
Потому стараются причесывать платформу мягко и постепенно
Ну наверно то, что Android всё еще open source. Драйвер для него может писать кто угодно и устанавливать куда угодно. Проприетарны и закрыты здесь только google play services- они устанавливаются в прошивку по желанию вендора и договоренности с гуглом. Работу именно сервисов гугл и проверяет, к драйверам это не имеет отношения.
Например, китайские android-смартфоны прекрасно существуют без play services (всё таки там baidu монополист). И вот там с совместимостью проблем в разы больше.
В то же время ранее существовал покойный Яндекс.Кит. Андроид, сервисов гугла не было, на замену ему пришли сервисы от Яндекса. Покойный потому, что
1. Не смогли обеспечить достойной замены сервисам гугла (говорят, что там даже push было сделать проблемно)
2. Проблемы с софтовой совместимостью (ту не понятно, кто больше виноват- вендоры или оболочка Кит, драйверы вообще вряд ли кто-то проверял)
3. Ценовая политика- девайсы были дешевые (но, правда, очень лагучие), а вот цены на софт и место в магазине Яндекса были не очень привлекательными.
Если резюмировать- проблемы с драйвером еще не самое страшное…
А вот с (возможным в качестве замены) выходом фуксии всё может измениться.
Если говорить о простеньком варианте приложения (который Вы, как я понял, подразумеваете)- то да, тут Вы правы. Но ведь такие rest-клиенты никто (ну или почти никто) в продакшене не ждет?
Добавим сюда кеширование или возможность работы оффлайн, пуши, авторизацию, обновляемые токены. Возможно даже простенький чат на rest. И вот это уже похоже на определенный минимум, который (на мой взгляд) вполне укладывается в RESS, и бизнес-логика там не такая уж и копеечная. Так или иначе придем к тому, что минимум 1-2 компонента надо тестировать
Тоже поддерживаю автора. Плюсанул бы, да кармы нет)
Вообще за 5 лет тоже пришел к тому, что существующие решения переусложнены. Сам часто делаю на упрощенной clean, да и только потому, что заказчик непредсказуем, а чистого rest становится всё меньше.
Не понимаю всего фана по архитектуре- многие воспринимают mvp\viper как стандарт де-факто. Ни шагу в сторону. На практике- да, знать их надо, но использовать надо как базу, а не идентичное решение. Как паттерны. Потому чем больше типовых архитектур- тем лучше.
И вообще, всё чаще прихожу к тому, что миром девелоперов сегодня больше управляет мода нежели здравый смысл.
На мой взгляд, RESS (как бы его не называли) выглядит вполне рабочим решением для определенного круга проектов (не только rest).
Два вопроса:
1. Я не против асинктасков, но Вам не кажется, что сегодня ходить в веб через HttpUrlConnection банально опасно, например, отказом нормальной работы? Например, у OkHttp свое обращение с сокетами- бесшовный реконнект, более грамотная работа с heartbeat, нет проблем с gzip и много еще чего. От того HttpUrlConnection, начиная с 5го андроида, основан на OkHttp в кишках.
Пример из практики- надо закачать файл на сервак. Реализация на HttpUrlConnection. На 4.4+ всё норм, на 4.3 возвращалась ошибка. Как выяснилось- рано закрывался сокет, на 4.3 и ниже HttpUrlConnection не умеет его переоткрывать. Решилось переделкой на OkHttp.
На мой взгляд, асинктаски можно использовать в ряде задач вместе с грамотным управлением потоками (экзекуторы), но внутри от HttpUrlConnection лучше отказаться.
2. А что с тестированием на моках? Получается, так или иначе, придем к DI на Gradle Flavours\Dagger и репозиториям? а там уже «привет clean architecture»?
Еще и подорожают с таким раскладом девайсы средней ценовой категории- часть прибыли вендоры получают от встроенных сервисов.
HTC мы давно не интересны- они смотрят на азию и америку. Самому жаль- уважаю их девайсы. Здесь люди готовы покупать сяоми и делиться с дядюшкой ляо личной инфой.
На самом деле всё проще- скоро на рынке со второго подхода появится еще один игрок, для него готовят почву.
Лично я так не делаю и никому не советую коммитить .idea в git. Где-то слышал, что считается плохим тоном привязывать проект\исходники к ide подобным образом. Нет, конечно, есть специфичные проекты, которым это нужно, но это скорее исключения. В остальном за всё время существования студии было много раз проблемно открыть старый проект новой (иногда даже минорной) версией студии, импорт тоже помогает не всегда. Синхронизацию стилей можно иначе решить, но ИМХО- штатных стилей хватает за глаза
Примеры- сервисы синхронизации, аутентикаторы, камеры различной насыщенности с кучей точек входа, приложения с широким функционалом шаринга, чатики с быстрым ответом, навороченные радио и плееры… В общем примеров много, и перечислил далеко не все. В основном те приложения, которые часто контактируют с пользователем посредством точек входа ОС, нежели напрямую
Если покопаться, такие проблемы есть и с single activity. И потому, что оба этих подхода имеют проблемы разного характера, они оба имеют право на существование в продакшене. Что из этого выбирать- вопрос опыта разработчика.
Однако, согласитесь, что заголовок и некоторые доводы из статьи весьма провокационны. Вы сравниваете умение применять повсеместно single activity с правами F1, что, всё-таки, расходится с реальностью. Я прочитал статью с удовольствием, но такие моменты смущают.
Лично я (как, думаю, и многие) вижу это так- «Либо ты пишешь только single activity, либо ты- плохой разраб»
И ладно, если в это верят отдельные разрабы- это вопрос доверчивости и опыта каждого. Но, читая подобные статьи на хабре, в это начинает верить техническое руководство. А это- уже проблема…
Если просто- activity, которые есть в backstack, android может выгружать из памяти при ее нехватке, оставляя в памяти только ту, на которою Вы смотрите (и ближайшие к ним), а при возврате восстановить из saved state. Таким образом ресурсы, которые выделены на Ваше приложение, со стороны UI (ну или view/presentation-слоя, смотря что используете) не залочены.
В случае подхода с single activity в backstack все фрагменты держатся в памяти. И то, на что Вы ссылаетесь жесткими ссылками из фрагментов- тоже. Да, в простых случаях это- спички. Но когда в стэке лежит что-то тяжелое, да еще и много инстансов (например, карты, или другие тяжелые элементы/api)- то потребление памяти сильно подскакивает, а вместе с ним падает оперативность и отзывчивость приложения из-за частых вызовов GC и нагрузки в принципе.
Да, Вы можете сказать, что «вот на моем флагмане (или мощном B-бренде) всё хорошо». Однако, часто, бОльшая часть ЦА не располагает достаточно мощными устройствами. И современные low-end устройства с 2-3гб оперативы всё равно испытывают нехватку, и там этот вопрос стоит острее.
Да, конечно, это можно решить\обойти в рамках Single Activity- это вопрос навыков. Однако, по моему опыту, такие решения весьма не тривиальны и многие просто на это забивают.
Однако, утверждение, что все приложения должны быть Single Activity- спорное. Этот подход хорош, когда у Вас типичное «конвейерное приложение» а-ля веб-клиента. Если писать что-то по-сложнее или добавить к существующему Single Activity-приложению действительно тяжелый, с точки зрения ресурсов устройства, функционал- с этого момента могут возникнуть проблемы.
Надо ли говорить, что Single Activity-приложение, чаще всего, представляет собой изобилие рукотворных утечек. Потому работа с таким подходом, если всё делать по совести, вызывает не меньше сложностей в сравнении с multiple activity.
Потому важно иметь права как на болид F1, так и на старый добрый вездеход. И понимать, на чем ехать в конкретном случае. Иногда комбинировать.
Иначе это- просто мода. По типу «asynctask- зло» или «dagger нужен везде». Каждому инструменту- своё применение.
Можно еще через moxy это реализовать, но, на мой взгляд, AAC гибче и стабильнее
RecyclerView больше для реализации view-логики на ячейку\холдер. И сам по себе предполагает, что контент будет структурно повторяться, для чего и (в дефолтных вариантах) кеширует вьюхи.
View Pager же- именно страничный механизм и предполагает реализацию подобия presentation-логики на страницу. В основном тяжелой логики или хранения в памяти большого количества данных на страницу. FragmentStatePagerAdapter позволяет осуществлять, по факту, менеджмент памяти из коробки благодаря ЖЦ фрагментов. В некоторых случаях можно вообще взять базовый адаптер и реализовывать прямо на вьюхах (без фрагментов) и брать менеджмент на себя.
Да, я понимаю, что бизнес-требования не всегда просты и не всегда адекватны. И что, иногда, проще «отверткой отковырять гвоздь». Но я бы поостерегся называть ViewPager неэффективными и сложным- он не сложнее ListView и много проще RecyclerView.
Поймите правильно, в Вашей статье много полезного. Но не все решения стоит рекомендовать на повседневное использование.
Ладно люди, если сервис раскрутится- им начнут пользоваться медики в качестве справочника. А это уже страшно…
Во-первых это невозможно по описанным выше причинам. Если приложение ограничивает свой функционал по причине отсутствия гапсов- это уже не штатная работа.
Во-вторых- я щупал кит, когда он появился в продаже, на предмет возможности публикации. Отсутствие порядочной замены гапсам- это одна боль. Другая в том, что (если не углубляться в тех. детали) некоторые второстепенные api самого android framework работали некорректно на пробных запусках. Да, всё можно обойти и подобное встречалось ранее. Но зачем? Аудитории мало, тратить время на адаптацию никто не хотел.
ИМХО, если бы устройства на Ките покупали- то вендорам, которые на нем выпускались, было бы всё равно. А известные вендоры под это дело организовывали бы дочек. Был бы спрос. С такими то низкими ценниками. Но кому нужен тормознутый смартфон\планшет, у которого в маркете нет нужного приложения?.. А даже если поставить apk- не факт, что работать будет нормально (чаще- нет). А без нужных приложений- зачем оно вообще надо?..
А по поводу жалоб о монополии- если бы могли сделать конкурентоспособный продукт- то и жаловаться не пришлось бы
Сам Самсунг производит больше половины всего объема смартов и планшетов на андроид. Этого уже достаточно.
В догонку- один из лидеров телекоммуникационного оборудования- Huawei. Продажи у них тоже не маленькие. В недавних скандалах тоже часто мелькали.Потому и не свалил, что выполнимы. А выполнимы потому, что самсунг- член OHA
Насколько я понял, доходы от постройки крупногабаритных кораблей туда тоже не входят.
UPD. Почитал. Скорее всего речь именно о мобильном подразделении, а не уточняется во имя маркетинга. Слабо верится в то, что apple дороже корпорации, которая занимается если не всем, то очень многим (текстиль, автопром, фармацевтика, можно долго перечислять).
Нет, не дорого. Опасно. Потерей доли рынка. Как писал выше, игрокам вроде samsung вообще сложно что-либо указывать.
Ответ на Ваш вопрос — вендоры мешают.
Дело в том, что samung- самый крупный производитель смартфонов и планшетов на сегодняшний день. Да, их мобильное подразделение имеет бюджеты скромнее, чем у компании из Купертино. Но, однако, сам samsung в разы крупнее и дороже apple (возможно, крупнее любой корпорации, которая производит микроэлектронику и комплектующие). Такому игроку сложно что-либо указывать. И если какая-либо сертификация не пропустит какие-либо маркетинговые фишки (некоторые завязаны на драйверах и ядре. Пример- KNOX) по любой причине- это может привести к тому, что огромный пласт устройств перейдет, например, на Tizen (который лежит у самсуга в кармане). Может пару раз вендор и пойдет на уступки, но терпение не бесконечно. Гуглу этого перехода не надо по понятным причинам. Да и пользователям тоже.
Потому стараются причесывать платформу мягко и постепенно
Например, китайские android-смартфоны прекрасно существуют без play services (всё таки там baidu монополист). И вот там с совместимостью проблем в разы больше.
В то же время ранее существовал покойный Яндекс.Кит. Андроид, сервисов гугла не было, на замену ему пришли сервисы от Яндекса. Покойный потому, что
1. Не смогли обеспечить достойной замены сервисам гугла (говорят, что там даже push было сделать проблемно)
2. Проблемы с софтовой совместимостью (ту не понятно, кто больше виноват- вендоры или оболочка Кит, драйверы вообще вряд ли кто-то проверял)
3. Ценовая политика- девайсы были дешевые (но, правда, очень лагучие), а вот цены на софт и место в магазине Яндекса были не очень привлекательными.
Если резюмировать- проблемы с драйвером еще не самое страшное…
А вот с (возможным в качестве замены) выходом фуксии всё может измениться.
Добавим сюда кеширование или возможность работы оффлайн, пуши, авторизацию, обновляемые токены. Возможно даже простенький чат на rest. И вот это уже похоже на определенный минимум, который (на мой взгляд) вполне укладывается в RESS, и бизнес-логика там не такая уж и копеечная. Так или иначе придем к тому, что минимум 1-2 компонента надо тестировать
Вообще за 5 лет тоже пришел к тому, что существующие решения переусложнены. Сам часто делаю на упрощенной clean, да и только потому, что заказчик непредсказуем, а чистого rest становится всё меньше.
Не понимаю всего фана по архитектуре- многие воспринимают mvp\viper как стандарт де-факто. Ни шагу в сторону. На практике- да, знать их надо, но использовать надо как базу, а не идентичное решение. Как паттерны. Потому чем больше типовых архитектур- тем лучше.
И вообще, всё чаще прихожу к тому, что миром девелоперов сегодня больше управляет мода нежели здравый смысл.
На мой взгляд, RESS (как бы его не называли) выглядит вполне рабочим решением для определенного круга проектов (не только rest).
Два вопроса:
1. Я не против асинктасков, но Вам не кажется, что сегодня ходить в веб через HttpUrlConnection банально опасно, например, отказом нормальной работы? Например, у OkHttp свое обращение с сокетами- бесшовный реконнект, более грамотная работа с heartbeat, нет проблем с gzip и много еще чего. От того HttpUrlConnection, начиная с 5го андроида, основан на OkHttp в кишках.
Пример из практики- надо закачать файл на сервак. Реализация на HttpUrlConnection. На 4.4+ всё норм, на 4.3 возвращалась ошибка. Как выяснилось- рано закрывался сокет, на 4.3 и ниже HttpUrlConnection не умеет его переоткрывать. Решилось переделкой на OkHttp.
На мой взгляд, асинктаски можно использовать в ряде задач вместе с грамотным управлением потоками (экзекуторы), но внутри от HttpUrlConnection лучше отказаться.
2. А что с тестированием на моках? Получается, так или иначе, придем к DI на Gradle Flavours\Dagger и репозиториям? а там уже «привет clean architecture»?
HTC мы давно не интересны- они смотрят на азию и америку. Самому жаль- уважаю их девайсы. Здесь люди готовы покупать сяоми и делиться с дядюшкой ляо личной инфой.
На самом деле всё проще- скоро на рынке со второго подхода появится еще один игрок, для него готовят почву.