Как бороться с низкокачественными Android приложениями

от автора

Все согласны, что Google Play переполнен некачественными приложениями, но никто не хочет брать вину на себя — принято винить абстрактный Android или просто Google, который выпустил систему без строгих гайдланов, создал маркет без модерации и дал возможность производителям, делать свои оболочки с разноцветными иконками и градиентами.

Но каждый день выходят новые приложения с дизайном из iOS, темами из 2.3, не адаптированные для планшетов и с размытыми картинками на HD-экранах. И в этом виноват не Google, а разработчики. Кто-то не пытается спорить, когда заказчик присылает макеты от iOS версии, кто-то пытается, но сдается. Кто-то разрабатывает приложение ради опыта, откладывая «неважное» на потом, и так оно и остается. Стартапы делают приложения «за день», а потом лихорадочно фиксят баги, создавая снежный ком, который уже никто не перепишет с нуля. Крупные социальных сети, имея деньги и время, каким-то образом умудряются выпускать ужасные клиенты…

Вариантов очень много, и во многих из них нельзя ничего исправить или вообще сделать изначально правильно. Но если хотя-бы один разработчик из десяти, при возможности, уделить внимание мелочам, описанным ниже — 10% от новых приложений станут удобнее для пользователя.

Это статья не только для новичков — многие разработчики отлично знают вещи, описанные ниже, но не уделяют должного внимания, а кто-то отлично знает Java и пишет красивейшую архитектуру, но не знает этих мелочей. Это статья-просьба к разработчикам от пользователя.

Пожалуйста, используйте Holo

Очень часто попадаются приложения с хорошим функционалом, но встречающие пользователя виджетами из 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"> <!-- [...] --> 

Это было описано в блоге разработчиков очень давно, но приложения с устаревшим дизайном продолжают появляться.

Пожалуйста, используйте ActionBarSherlock

Многие думают, что паттерн Action Bar — это всего лишь заголовок окна с иконками и даже не читали официальной документации.

Даже если весь функционал Action Bar в вашем приложении сводится к заголовку окна — все равно используйте ActioBarSherlock. Написав самодельный заголовок — вы не станете потом добавлять поддержку меню, управление видимостью иконок и их подписей при разных размерах экранах, split view для маленьких экранов, индикатор загрузки и прочий функционал.

ActionBarSherlock использует родной Action Bar для ICS и выше, и портирует весь функционал для версий не поддерживающих его, или поддерживающих частично. Демо всех возможностей находится здесь.

Начать использовать его очень просто:

  • Добавить проект как библиотеку к своему приложению
  • Подправить темы для старых версий API, чтобы использовали Theme.Sherlock.xxx как базовую
  • Унаследовать Activity от SherlockActivity или SherlockFragmentActivity
  • И можно общаться с Action Bar через getSupportActionBar()

Пожалуйста, используйте фрагменты

Во многих проектах поддержка планшетов откладывается на потом, как что-то особенное и дополнительное. Хотя на самом деле приложение под Android должно быть изначально адаптивным и не отличать телефоны и планшеты. Для приложения это просто устройства с разными размерами экранов и оно должно максимально удобно для пользователя эти экраны заполнять.

Даже если времени на переписывание через FragmentManager нет, или это крайне сложно в существующей архитектуре — можно вынести код из Activity во фрагменты и организовать простейшую поддержку планшетов.

Например у вас есть уже реализованное приложение с двумя окнами — список и детальный просмотр.

  • Выносим код в два фрагмента
  • Вставляем эти фрагменты в 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>  
  • Создаем специальную разметку для экранов, например длинной больше 800dp:
    <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 {    //запускаем активити    ... } ... 

После таких нехитрых манипуляций получаем отличную разметку для большого экрана:

Пожалуйста, старайтесь использовать xml и nine-patch для графики

Очень часто встречаются приложения, в которых даже простейший градиент реализован с помощью растянутого png. И когда такой графики на экране много — причины тормозов начинают искать в логике приложения.
Даже если очередной дизайнер прислал очередной растровый макет из Фотошопа, сделанный по гайдлайнам iOS — перед тем, как порезать это все в картинки, подумайте о каждом элементе:

  • Можно ли реализовать это с помощью простых примитивов, заливок, градиентов и скругленных углов в XML?
  • Можно ли реализовать это с помощью Nine Patch?

Отличный редактор Nine Patch находится здесь — http://habrahabr.ru/company/alee/blog/136667/. И не стоит забывать, что создание графических ресурсов для xhdpi, hdpi, mdpi также относится и к nine-patch. Не стоит перекладывать эту работу на девайс пользователя.

Заключение

Кто-то скажет, что это все не обязательно, ведь среднестатистический пользователь не знает где новый, а где устаревший интерфейс, и большинство не знают, где заканчивается TouchWiz и начинается Android… Но если делать все как-попало потому, что Google не запрещает, а заказчик не разбирается — Google Play будет продолжать наполняться низкокачественными приложениями, о чем будут продолжать писать «аналитики». И как итог — разработка под Android менее выгодна, чем под iOS.
Конечно, я все упрощаю и сгущаю краски — но хочется вселить некую ответственность в разработчиков.

ссылка на оригинал статьи http://habrahabr.ru/post/178673/


Комментарии

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *