Это тот Space, который есть в Support Library v7
View хуже тем, что работает медленнее, а Space специально облегчен для использования в качестве отступов.
Мне кажется, что использовать подобные конструкции в методах подобных onScrollChanged не лучшая идея, слишком много бесполезных вызовов методов findViewById, да и getActionBar
final int headerHeight = findViewById(R.id.image_header).getHeight() - getActionBar().getHeight();
плотность пикселей на физический дюйм имеет значение, только если она принимает совсем неприличные значения
Не соглашусь, т.к. разница в плотности пикселей только для телефонов в данный момент может отличаться в 3 и более раз. Да и физический размер экрана телефона может отличается в 2 раза.
Задать например размер шрифта в пикселах — прямой путь к нечитабельным шрифтам в том или ином случае.
Адаптивный дизайн конечно важен и он поддерживается даже из коробки например через ActionBar. Тут конечно проблема больше, требуется больше работы для оптимизации например под планшеты.
Физические размеры контролов может контролировать производитель устройства просто меняя такой софтварный параметр как размеры экрана в dpi, которые и следует использовать в своем коде. А еще производитель устройства может указать sp, т.е. относительный размер шрифта.
Соответсвено производитель например тв приставки может установить такие размеры в конфиге системы, что бы контролы и весь интерфейс был крупнее. Поэтому это не проблема, если приложение сделано нормально, без привязки к пикселам,
Я лично под iOS не пишу, но насколько я знаю возможность есть, но нет встроенных инструментов для этого, как например 9-patch или ресурсы для разных устройств.
Заметил довольно сильное расхождение в статистике версий Android по сравнению с нашей собственной статистикой и официальной статистикой — developer.android.com/about/dashboards/index.html
Наши данные близки к официальным, и расходятся с теми, что указаны в статье. Очень инетересно узнать откда данные и их структура.
А что вы подразумеваете под «понять какое API использовать для своего проекта»?
Всегда используется последняя версия API, просто оставляя обратную совместимость, пусть даже с урезанным функционалом. Например сейчас Android 2.1 можно уже не поддерживать, там всего 1.5% пользователей и он не поддерижвает новый API карт и in-app billing v3, но если вы не используете ни то, ни другое, то оставить для него обратную совместимость не проблема.
Графики хорошие, но не согласен с большинством выводов.
Это не такие большие проблемы для разработчиков (говорю как разработчик), особенно это касается физических размеров экрана и уж тем более фрагментация брендов. Просто разработка под 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 и т; п;) этот момент далеко не так важен, как пару лет назад и большинство возможных проблем обратной совместимости легко решается.
По моему вся статья больше похожа на спекуляции на статистике, хотя повторюсь, сама статистика довольно интересна. Большинство якобы серьезных проблем при разработке, на которые упирает статья, вовсе не проблемы, т.к. система изначально архитектурно заточена для разработки приложений под разные устройства и предоставляет инструменты для этого.
Да, только на планшете. Проблема с патентами, кажется Nokia нечто подобное запатентовало для телефонов. Но если у вас root, то вроде есть способы разблокировать эту возможность и на телефонах (я про разных пользователей, посмотрим смогут ли пользователи такое сделать и для профилей)
И причем тут OS и цена? Android тоже бесплатный, железки одинаковые. Например Huawei Ascend Y201 на той же платформе и при почти идентичных характеристиках стоит меньше 4 тыс руб в России.
В цене, тем более учитывая что он продается под брендами сотовых операторов, нет ничего особенного, обычный бюджетник, которых множество на Android.
Firefox OS не может выйграть за счет цены, просто у них пока такое позиционирование «Очень бюджетный смартфон».
Точность взялась со страницы www.flickr.com/new — «That's 500,000 photos* to share and enjoy in their original, brilliant quality. To be exact, 537,731.»
Они просто пересчитывают средний размер фотографии и делят на него терабайт.
Роман Нурик из Google рекомендует делать для устройств с <4.0 аналогичный дизайн как и для >=4.0, используя соответсвующие библиотеки для обратной совместимости
View хуже тем, что работает медленнее, а Space специально облегчен для использования в качестве отступов.
final int headerHeight = findViewById(R.id.image_header).getHeight() - getActionBar().getHeight();Не соглашусь, т.к. разница в плотности пикселей только для телефонов в данный момент может отличаться в 3 и более раз. Да и физический размер экрана телефона может отличается в 2 раза.
Задать например размер шрифта в пикселах — прямой путь к нечитабельным шрифтам в том или ином случае.
Физические размеры контролов может контролировать производитель устройства просто меняя такой софтварный параметр как размеры экрана в dpi, которые и следует использовать в своем коде. А еще производитель устройства может указать sp, т.е. относительный размер шрифта.
Соответсвено производитель например тв приставки может установить такие размеры в конфиге системы, что бы контролы и весь интерфейс был крупнее. Поэтому это не проблема, если приложение сделано нормально, без привязки к пикселам,
Наши данные близки к официальным, и расходятся с теми, что указаны в статье. Очень инетересно узнать откда данные и их структура.
Всегда используется последняя версия API, просто оставляя обратную совместимость, пусть даже с урезанным функционалом. Например сейчас Android 2.1 можно уже не поддерживать, там всего 1.5% пользователей и он не поддерижвает новый API карт и in-app billing v3, но если вы не используете ни то, ни другое, то оставить для него обратную совместимость не проблема.
Это не такие большие проблемы для разработчиков (говорю как разработчик), особенно это касается физических размеров экрана и уж тем более фрагментация брендов. Просто разработка под 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 и т; п;) этот момент далеко не так важен, как пару лет назад и большинство возможных проблем обратной совместимости легко решается.
По моему вся статья больше похожа на спекуляции на статистике, хотя повторюсь, сама статистика довольно интересна. Большинство якобы серьезных проблем при разработке, на которые упирает статья, вовсе не проблемы, т.к. система изначально архитектурно заточена для разработки приложений под разные устройства и предоставляет инструменты для этого.
В цене, тем более учитывая что он продается под брендами сотовых операторов, нет ничего особенного, обычный бюджетник, которых множество на Android.
Firefox OS не может выйграть за счет цены, просто у них пока такое позиционирование «Очень бюджетный смартфон».
Они просто пересчитывают средний размер фотографии и делят на него терабайт.