- PVSM.RU - https://www.pvsm.ru -
Все согласны, что Google Play переполнен некачественными приложениями, но никто не хочет брать вину на себя — принято винить абстрактный Android или просто Google, который выпустил систему без строгих гайдланов, создал маркет без модерации и дал возможность производителям, делать свои оболочки с разноцветными иконками и градиентами.
Но каждый день выходят новые приложения с дизайном из iOS, темами из 2.3, не адаптированные для планшетов и с размытыми картинками на HD-экранах. И в этом виноват не Google, а разработчики. Кто-то не пытается спорить, когда заказчик присылает макеты от iOS версии, кто-то пытается, но сдается. Кто-то разрабатывает приложение ради опыта, откладывая «неважное» на потом, и так оно и остается. Стартапы делают приложения «за день», а потом лихорадочно фиксят баги, создавая снежный ком, который уже никто не перепишет с нуля. Крупные социальных сети, имея деньги и время, каким-то образом умудряются выпускать ужасные клиенты…
Вариантов очень много, и во многих из них нельзя ничего исправить или вообще сделать изначально правильно. Но если хотя-бы один разработчик из десяти, при возможности, уделить внимание мелочам, описанным ниже — 10% от новых приложений станут удобнее для пользователя.
Это статья не только для новичков — многие разработчики отлично знают вещи, описанные ниже, но не уделяют должного внимания, а кто-то отлично знает Java и пишет красивейшую архитектуру, но не знает этих мелочей. Это статья-просьба к разработчикам от пользователя.
Очень часто попадаются приложения с хорошим функционалом, но встречающие пользователя виджетами из 2.х. Использование таких приложений оставляет ощущение некой инородности у пользователя. И очень часто такое встречается в официальных клиентах всяких банков и служб, у которых нет альтернатив.
А ведь сделать так, чтобы в каждой системе отображалась своя тема — совсем не сложно. Достаточно лишь организовать базовую тему, от которой будет наследоваться тема приложения и переопределить ее для v11+ (3.0 и выше).
/res/values/styles.xml (или themes.xml):
<resources>
<style name="BaseTheme" parent="@android:style/Theme">
<!-- Костыли и фичи для версий ниже 3.0 писать здесь -->
</style>
<style name="MyTheme" parent="BaseTheme">
<!-- Общие костыли и фичи для все версий -->
</style>
</resources>
/res/values-v11/styles.xml (или themes.xml):
<resources>
<style name="BaseTheme" parent="@android:style/Theme.Holo">
<!-- Костыли и фичи для версий от 3.0 и выше писать здесь -->
</style>
</resources>
/AndroidManifest.xml:
<!-- [...] -->
<application android:name="MyApplication"
android:label="@string/application_label"
android:icon="@drawable/app_icon"
android:hardwareAccelerated="true"
android:theme="@style/MyTheme">
<!-- [...] -->
Это было описано в блоге разработчиков [1] очень давно, но приложения с устаревшим дизайном продолжают появляться.
Многие думают, что паттерн Action Bar — это всего лишь заголовок окна с иконками и даже не читали официальной документации [2].
Даже если весь функционал Action Bar в вашем приложении сводится к заголовку окна — все равно используйте ActioBarSherlock [3]. Написав самодельный заголовок — вы не станете потом добавлять поддержку меню, управление видимостью иконок и их подписей при разных размерах экранах, split view для маленьких экранов, индикатор загрузки и прочий функционал.
ActionBarSherlock использует родной Action Bar для ICS и выше, и портирует весь функционал для версий не поддерживающих его, или поддерживающих частично. Демо всех возможностей находится здесь [4].
Начать использовать [5] его очень просто:
Во многих проектах поддержка планшетов откладывается на потом, как что-то особенное и дополнительное. Хотя на самом деле приложение под Android должно быть изначально адаптивным и не отличать телефоны и планшеты. Для приложения это просто устройства с разными размерами экранов и оно должно максимально удобно для пользователя эти экраны заполнять.
Даже если времени на переписывание через FragmentManager нет, или это крайне сложно в существующей архитектуре — можно вынести код из Activity во фрагменты и организовать простейшую поддержку планшетов.
Например у вас есть уже реализованное приложение с двумя окнами — список и детальный просмотр.
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
xmlns:tools="http://schemas.android.com/tools"
xmlns:app="http://schemas.android.com/apk/res-auto"
android:layout_width="match_parent"
android:layout_height="match_parent" >
<fragment
android:id="@+id/SomeFragment"
android:layout_width="match_parent"
android:layout_height="match_parent"
class="com.example.SomeFragment"/>
</LinearLayout>
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
xmlns:tools="http://schemas.android.com/tools"
xmlns:app="http://schemas.android.com/apk/res-auto"
android:layout_width="match_parent"
android:layout_height="match_parent"
android:orientation="horizontal" >
<fragment
android:id="@+id/listFragment"
android:layout_width="400dp"
android:layout_height="fill_parent"
class="com.example.ListFragment" />
<View
android:layout_width="10dp"
android:layout_height="fill_parent"
android:background="@color/FragmentDivider" >
</View>
<fragment
android:id="@+id/detailsFragment"
android:layout_width="match_parent"
android:layout_height="match_parent"
class="com.example.DetailsFragment"/>
</LinearLayout>
...
if (getActivity().findViewById(R.id.listsFragment) != null) {
//меняем содержимое фрагмента
ListFragment fragment = (ListFragment) getActivity().getSupportFragmentManager().findFragmentById(R.id.listsFragment);
fragment.setDetails(...);
} else {
//запускаем активити
...
}
...
После таких нехитрых манипуляций получаем отличную разметку для большого экрана:
Очень часто встречаются приложения, в которых даже простейший градиент реализован с помощью растянутого png. И когда такой графики на экране много — причины тормозов начинают искать в логике приложения.
Даже если очередной дизайнер прислал очередной растровый макет из Фотошопа, сделанный по гайдлайнам iOS — перед тем, как порезать это все в картинки, подумайте о каждом элементе:
Отличный редактор Nine Patch находится здесь — http://habrahabr.ru/company/alee/blog/136667/ [6]. И не стоит забывать, что создание графических ресурсов для xhdpi, hdpi, mdpi также относится и к nine-patch. Не стоит перекладывать эту работу на девайс пользователя.
Кто-то скажет, что это все не обязательно, ведь среднестатистический пользователь не знает где новый, а где устаревший интерфейс, и большинство не знают, где заканчивается TouchWiz и начинается Android… Но если делать все как-попало потому, что Google не запрещает, а заказчик не разбирается — Google Play будет продолжать наполняться низкокачественными приложениями, о чем будут продолжать писать «аналитики». И как итог — разработка под Android менее выгодна, чем под iOS.
Конечно, я все упрощаю и сгущаю краски — но хочется вселить некую ответственность в разработчиков.
Автор: itspers
Источник [7]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/android-development/33584
Ссылки в тексте:
[1] блоге разработчиков: http://android-developers.blogspot.com/2012/01/holo-everywhere.html
[2] официальной документации: http://developer.android.com/design/patterns/actionbar.html
[3] ActioBarSherlock: http://actionbarsherlock.com/
[4] здесь: https://play.google.com/store/apps/details?id=com.actionbarsherlock.sample.demos
[5] использовать: http://actionbarsherlock.com/usage.html
[6] http://habrahabr.ru/company/alee/blog/136667/: http://habrahabr.ru/company/alee/blog/136667/
[7] Источник: http://habrahabr.ru/post/178673/
Нажмите здесь для печати.