Pull to refresh

Comments 48

Чекбоксы больше бы подошли. Ибо у многих по нескольку устройств с разными версиями андроида.
А за что вы человека минусуете? У меня вот несколько устройств с разными версиями и теперь я не знаю как проголосовать…
я не минусовал, щас уже не поправить на чекбоксы
btw на секунду вылез баг хабра (после обновления страницы исчез)
см 2й вариант ответа
image

Графики хорошие, но не согласен с большинством выводов.
Это не такие большие проблемы для разработчиков (говорю как разработчик), особенно это касается физических размеров экрана и уж тем более фрагментация брендов. Просто разработка под Android подразумевает другой подход, чем под iOS, где в порядке вещей указывать размеры в пикселях или использовать не тянущиеся фоны страниц, которые поехали на iPhone 5 после изменений пропорций экрана. Просто при разработке под Android изначально лейауты делаются тянущимися, что не сильно увеличивает сложность, зато представляет пользоваться приложением без проблем на огромном числе устройств различных форм-факторов.
В Android никто не пытается до пикселя высчитать размеры например ActionBar, или делать лейауты под каждый размер экрана.
Даже не уверен что следует использовать тут термин «фрагментация», т.к. это изначальное свойство системы и ее преимущество.
Кстати очень странно сравнивать физические размеры экрана, намного важнее их разрешение и плотность.

Не понятно откуда взялся странный тезис про проблему с кастомными оболчками: «Первая, бренды имеют тенденцию производить собственные системные UI (например, Touchwhizz для Samsung и HTC Sense), которые могут поменять вид многих стандартных элементов».
Максимум на что может повлиять измененный UI это на отображение уведомлений (и то это касается только Android 2.3), но в самом приложение подобные элементы напрямую не используются, а на Android > 4.0 это совсем не проблема, т.к. всегда есть стандартная тема Holo, вне зависимости от производителя и оболочки.

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

Единственный важный момент может заключаться в фрагментации версии Android, но с учетом множества библиотек (включая Android Support Library, holoeverywhere и т; п;) этот момент далеко не так важен, как пару лет назад и большинство возможных проблем обратной совместимости легко решается.

По моему вся статья больше похожа на спекуляции на статистике, хотя повторюсь, сама статистика довольно интересна. Большинство якобы серьезных проблем при разработке, на которые упирает статья, вовсе не проблемы, т.к. система изначально архитектурно заточена для разработки приложений под разные устройства и предоставляет инструменты для этого.
Статью я только перевел, это не мои тезисы, а так мне давно было интересно узнать доли версий на рынке, чтобы понять какое API использовать для своего проекта. Спасибо за замечания.
А что вы подразумеваете под «понять какое API использовать для своего проекта»?
Всегда используется последняя версия API, просто оставляя обратную совместимость, пусть даже с урезанным функционалом. Например сейчас Android 2.1 можно уже не поддерживать, там всего 1.5% пользователей и он не поддерижвает новый API карт и in-app billing v3, но если вы не используете ни то, ни другое, то оставить для него обратную совместимость не проблема.
Она международная и общая. Могу предположить, что опрос на хабре нацелен на оценку фрагментированности андроидов среди русскоговорящей и (даже без «или») айтишной аудитории. Может анализатор реестра РКН например :)
Согласен полностью. На мой взгляд про проблему фрагментации на андроид кричат либо за деньги, либо люди без абсолютного понимания предмета. Что-то я ни разу не слышал про проблему фрагментации на ПК. Все как-то берут и верстают страницы, без разглагольствования как это дико сложно, так как мониторы у всех разные.

Кстати, скажите, а под IOS есть возможность писать «растягивающиеся» интерфейсы? Если есть, то почему каждые пару лет случается тупняк с приложениями на половина экрана и черными полосами?
Я лично под iOS не пишу, но насколько я знаю возможность есть, но нет встроенных инструментов для этого, как например 9-patch или ресурсы для разных устройств.
То что вы перечислили есть.
Да. В iOS7 добавили еще автоматическое определение областей.
Вы не делали игры под ПК, вот там фрагментация доставляет дикую головную боль. Уверен что и разработка 3Д под Андроид тоже то еще удовольствие, хотя бы тем небольшим примером, что каждый производитель GPU поддерживает какой-то свой формат сжатых текстур.

Про растягивающиеся интерфейсы — такое есть в iOS конечно. Просто это еще совсем недавно не было нужно, т.к. по сути был только один вариант для телефона, и один для планшета. Это позволяло интерфейс создавать с идеальной по-пиксельной точностью. Сейчас у телефонов два варианта разрешения, что не добавило сложности, но интерфейс даже древних приложений обычно растягивается нормально без изменений.
Не могу с вами согласиться. Головная боль от производителей GPU не больше, чем от фрагментации ОС. Я бы даже сказал что производители GPU гораздо жестче придерживаются спецификации API, нежели производители ОС. Здесь основные проблемы — интелы, потому что много чего не поддерживают, а то что поддерживают — делают это так медленно, что по неволе думаешь «лучше бы не поддерживали». ATI раньше часто имели проблемы с драйверами, в особенности для новых видеокарт, но на сегодняшний день этой проблемы уже практически нет. И наконец Matrox-ы — вот эти звери брыкаются очень сильно, но для разработчика игр данной картой можно пренебречь.
Рад что ситуация изменилась. Я застал еще времена, когда в OpenGL расширения для шейдеров были разные у Ati и Nvidia, плюс разные возможности. ARB расширения еще не было, но и его появление не всегда спасало. С выходом OpenGL 2 стало лучше конечно. Это просто пример того, как собственные спецификации производителей усложняют жизнь разработчикам Для Андроида тут пример — свои форматы сжатых текстур у разных производителей.
Просто при разработке под Android изначально лейауты делаются тянущимися

Тянущийся лэйаут это примитивная адаптация под разные размеры. Хочется видеть действительно адаптивные дизайны. Скажем на 3" экране видеть несколько табов с настройками, а на 10" — все на одном экране.

Кстати очень странно сравнивать физические размеры экрана, намного важнее их разрешение и плотность.
При плотности больше 100 dpi лично для меня, как для пользователя, важны прежде всего физические размеры контролов (чтобы не промахиваться пальцем) и шрифтов. По крайней мере в случае ручных девайсов, которыми пользуюсь на плюс-минус постоянном расстоянии от глаз, в то время как монитор десктопа может быть и в нескольких метров от них.
Адаптивный дизайн конечно важен и он поддерживается даже из коробки например через ActionBar. Тут конечно проблема больше, требуется больше работы для оптимизации например под планшеты.

Физические размеры контролов может контролировать производитель устройства просто меняя такой софтварный параметр как размеры экрана в dpi, которые и следует использовать в своем коде. А еще производитель устройства может указать sp, т.е. относительный размер шрифта.
Соответсвено производитель например тв приставки может установить такие размеры в конфиге системы, что бы контролы и весь интерфейс был крупнее. Поэтому это не проблема, если приложение сделано нормально, без привязки к пикселам,
Давайте сойдемся на том, что важны параметры: физический размер экрана и расстояние до пользователя, проще говоря, угловые размеры экрана. А плотность пикселей на физический дюйм имеет значение, только если она принимает совсем неприличные значения (грубо: больше угловой минуты — средней разрешающей способности человеческого глаза). А если приложение заточено под смартфоны и планшеты (а не под телевизоры, очки, проекторы, вживляемые в глаз экраны и т. п.), то есть под более-менее постоянное расстояние до глаз (где-то от локтя до кончика пальцев — провел натурный эксперимент :), то размер контрола, шрифта и т. д. вполне можно задавать физическими единицами.
плотность пикселей на физический дюйм имеет значение, только если она принимает совсем неприличные значения

Не соглашусь, т.к. разница в плотности пикселей только для телефонов в данный момент может отличаться в 3 и более раз. Да и физический размер экрана телефона может отличается в 2 раза.
Задать например размер шрифта в пикселах — прямой путь к нечитабельным шрифтам в том или ином случае.
Требую такую же картинку для «фрагментации» платформы PC. Включая соотношения сторон и разрешения мониторов.
Она всётаки не дотянет до картинки фрагментации пользователей. Включая уровень intelекта и размер бюста.
Мне кажется, что вариация размера бюста меньшая, чем разрешений. По крайней мере я с трудом себе представляю эквивалентное соотношению 640(x480) к 5120 x 1440 (соотношение 1:8, для бюста это экивалент (при минимуме в 40см) 3.2 метра).
Можно глянь статистику Steam, но думаю будет ожидаемый перевес в сторону «играющих», и явно офисные машинки в неё не входят.
store.steampowered.com/hwsurvey?l=russian
Заметил довольно сильное расхождение в статистике версий Android по сравнению с нашей собственной статистикой и официальной статистикой — developer.android.com/about/dashboards/index.html
Наши данные близки к официальным, и расходятся с теми, что указаны в статье. Очень инетересно узнать откда данные и их структура.
Надо было сделать «чекбоксовую» голосовалку — у меня Nexus на 4.3 и LG на 2.3.3.
Простое правило: нужно всегда ставить чекбоксы. Не помню, чтобы кто-то писал «я хотел проголосовать всего за один пункт, а голосовалка позволяет отметить три».
Не всегда. Некоторые вопросы прямо подразумевают один ответ. Хотя это не тот случай.
Мне непонятен график фрагментации версий ОС, точнее, принцип построения белой линии на нём (которая показывает рыночную долю топовой версии ОС). В моём понимании с выходом очередной версии андроида этот график должен резко падать в ноль, после чего постепенно расти вплоть до выхода очередной версии.
Тоже непонятно.
В оригинале там «The white line shows the market share of the leading API level at any time», то есть доля рынка самой популярной(?) версии API, а не самой свежей.
Из этого графика в принципе можно понять, что «топовый» тут — по популярности. Например вышел 2.3.3-2.3.7, топовый в то время 2.2 начал падать, потом 2.2 и 2.3.3-2.3.7 сровнялись, затем 2.3.3-2.3.7 растет до какого-то момента, пока у него не начинает отбирать долю рынка 4.х. Как-то так.
Это график доли самой популярной версии ОС в каждый момент времени, а не самой последней версии ОС.
Хорошая статья!
Добавили бы еще версию API (хотя бы в опрос), а то почти два десятка версий сложно в уме соотносить.
Почему в опросе нет варианта «У меня нет устройств на Android»?
Кнопка «Воздержаться» — для тех, кто не хочет высказывать своё мнение вообще. Это нарушает статистику.
В данном опросе статистику использования версий Андроида нарушит ответ «У меня нет устройств на Android».
Xperia U четвертая по популярности среди SE, вышла в 2012 году, но Сони не делает на неё даже 4.1.
Возобновляю голосование, прошу обновить ваш голос
Sign up to leave a comment.

Articles