В связи со стремительным развитием мобильных технологий, IT-компаниям все больше требуются разработчики мобильных приложений для своих продуктов. Наша компания не стала исключением. В моем распоряжении оказалось два падавана, которых надо было обучить премудростям разработки на Android (к слову сказать, парни были умные и способные, но практически без опыта). Было решено написать им небольшую памятку касательно основных аспектов разработки. Выкладываю ее на суд хабрапользователей.
Описания своих рассуждений выложу под спойлеры.
Во-первых, не пользуйтесь визуальным конструктором. Никогда. Исключение – совсем уж начинающий разработчик, который не знает основ xml разметки Android, и то, при условии, что он потом вручную пройдется по разметке и вычистит весь мусор.
Во-вторых, не используйте RelativeLayout где попало. Если вы хотите поставить View по порядку, то LinearLayout к вашим услугам. Если все ваши View строго позиционированы, то всегда можно прибегнуть к FrameLayout.
В-третьих. Margin или padding? Если вы хотите сделать удобный кликабельный элемент, то padding и только он! Если вам необходим отступ, который будет у неактивного элемента, то тогда допускается использование margin.
В-четвертых. Не забывайте, xml ничуть не менее код, чем та часть которую вы пишите на Java. Поэтому следите за тем что бы дублирование xml разметки было сведено к минимуму, по возможности создавайте свои элементы управления, если они будут использованы в нескольких местах (да и если не в нескольких, то тоже лучше создать отдельно).
Тут будет только один пункт, касательно самой распространенной БД на Android – SQLite. Она медленная. Очень. Не пренебрегайте ее оптимизацией и асинхронной работой с ней.
Ни для кого не секрет, что хорошее приложение — протестированное приложение. Поэтому не следует пренебрегать такими вещами, как комплексное и модульное тестирование, рецензирование кода другим разработчиком. Стесняться тут нечего, хороший программист не тот, кто не допускает ошибок, а тот, кто их находит и учитывает в будущем.
Говоря о советах могу сказать, что лучше использовать интерфейсы для всего, что работает не только с внутренним устройством вашего приложения (например, адаптеры для работы с сетью, для работы с другим приложением, бд). Потом при тестировании себе «спасибо» скажете.
Никогда не используйте захардкоденные строки. Используйте ресурсы (R.string.your_string). Даже если у вас нет и никогда не будет поддержки нескольких языков.
Обратите внимание, насколько большое существует количество различных группировок ресурсов: по языку, по разрешению экрана, его ориентации и размеру, по стране и пр. Довольно большая часть этого, возможно, вам никогда не потребуется, но ознакомиться с ними надо. В будущем при проблемах отрисовки/расположения элементов на различных устройствах это сэкономит вам уйму времени.
Описания своих рассуждений выложу под спойлеры.
UI
Во-первых, не пользуйтесь визуальным конструктором. Никогда. Исключение – совсем уж начинающий разработчик, который не знает основ xml разметки Android, и то, при условии, что он потом вручную пройдется по разметке и вычистит весь мусор.
Спойлер
Проблема заключается в том, что визуальный конструктор – это не Android, а отображаемый там View – это не все ваше приложение, поэтому при попытке выставить его правильно конструктор может использовать отступы вместо центрирования, LinearLayout вместо FrameLayout или вообще, просто излишнюю вложенность. Как-то раз наткнулся на такой кусок верстки (сокращу атрибуты для наглядности), никогда так не делайте:
А надо было всего две картинки нарисовать друг под другом.
<RelativeLayout> <LinearLayout android:orientation=”vertical” > <LinearLayout android:orientation=”horizontal” > <FrameLayout> <!—Какой-то контент --> </FrameLayout> </LinearLayout> <LinearLayout android:orientation=”horizontal” > <FrameLayout> <!—Какой-то контент --> </FrameLayout> </LinearLayout> </LinearLayout> </RelativeLayout>
А надо было всего две картинки нарисовать друг под другом.
Во-вторых, не используйте RelativeLayout где попало. Если вы хотите поставить View по порядку, то LinearLayout к вашим услугам. Если все ваши View строго позиционированы, то всегда можно прибегнуть к FrameLayout.
Спойлер
Встречаю практически повсеместно, но почему-то не все понимают, что разные типы View грузятся разное время. RelativeLayout самый тяжелый и долгий, FrameLayout один из самых легких (из элементов, которые могут содержать в себе дочерние View). И если для root-элемента Activity это никак не скажется, то для списков это будет заметное подтормаживание.
P.S. Это не призыв отказаться от RelativeLayout, в некоторых случаях без него действительно никак. Но только в некоторых. Не во всех!
P.S. Это не призыв отказаться от RelativeLayout, в некоторых случаях без него действительно никак. Но только в некоторых. Не во всех!
В-третьих. Margin или padding? Если вы хотите сделать удобный кликабельный элемент, то padding и только он! Если вам необходим отступ, который будет у неактивного элемента, то тогда допускается использование margin.
Спойлер
Истина проста. Чем элемент больше, тем его удобнее нажимать. Margin – отъедает место у самого элемента, padding – у окружения. Не даром отступы есть даже у изображений, причем строго указанные и задокументированные для всех разрешений. Пожалуйста придерживайтесь этих правил, они сильно облегчат жизнь вам и вашим пользователям.
В-четвертых. Не забывайте, xml ничуть не менее код, чем та часть которую вы пишите на Java. Поэтому следите за тем что бы дублирование xml разметки было сведено к минимуму, по возможности создавайте свои элементы управления, если они будут использованы в нескольких местах (да и если не в нескольких, то тоже лучше создать отдельно).
Спойлер
Этот совет скорее для пользы разработчику а не пользователю, так как рано или поздно все равно придется менять поведение или представление у различных контролов вашего приложения. Вам же будет легче если все они будут в одном месте и аккуратно отсортированы.
База данных
Тут будет только один пункт, касательно самой распространенной БД на Android – SQLite. Она медленная. Очень. Не пренебрегайте ее оптимизацией и асинхронной работой с ней.
Спойлер
Этот факт не заметен на проектах с маленьким или статичным набором данных, но если приложение требует постоянных синхронизаций больших объемов данных (например, offline клиент для большого склада), то одновременное обновление и работа приложения могут быть затруднены или даже невозможны. Связано это с одной простой особенностью SQLite: она либо читает из БД, либо пишет, никак не враз (не учитываем такую вещь как грязное чтение, потому что новичку лучше к ней не прибегать кроме крайне необходимых случаев).
Тестирование
Ни для кого не секрет, что хорошее приложение — протестированное приложение. Поэтому не следует пренебрегать такими вещами, как комплексное и модульное тестирование, рецензирование кода другим разработчиком. Стесняться тут нечего, хороший программист не тот, кто не допускает ошибок, а тот, кто их находит и учитывает в будущем.
Говоря о советах могу сказать, что лучше использовать интерфейсы для всего, что работает не только с внутренним устройством вашего приложения (например, адаптеры для работы с сетью, для работы с другим приложением, бд). Потом при тестировании себе «спасибо» скажете.
Спойлер
Вся соль в том, что при модульном тестировании намного проще писать тест, если ты гарантировано знаешь что тебе придет на определенный запрос. В случае работы с внешними источниками (даже если они 100% доступны) всегда можно испортить их набор данных предыдущим тестом. В случае работы с интерфейсом можно просто создавать в тесте класс-заглушку, которая будет возвращать то, что вам нужно.
Локализация и ресурсы
Никогда не используйте захардкоденные строки. Используйте ресурсы (R.string.your_string). Даже если у вас нет и никогда не будет поддержки нескольких языков.
Спойлер
Во-первых, когда ваши строки выгружены в отдельный файл — с ними намного проще работать — и вам, и человеку, который будет проверять их на грамотность написания (да-да, за программистами есть такой грешок, что после написания тысяч строк кода родной язык начинает забываться, да и о банальных опечатках забывать нельзя).
Во-вторых, даже если вы считаете, что поддержки нескольких языков приложения никогда не будет — вы ошибаетесь. Если проект хоть что-то стоит, то его имеет смысл перевести хотя-бы на английский. Захардкоденные строки в этом случае потом вытащить крайне сложно.
Во-вторых, даже если вы считаете, что поддержки нескольких языков приложения никогда не будет — вы ошибаетесь. Если проект хоть что-то стоит, то его имеет смысл перевести хотя-бы на английский. Захардкоденные строки в этом случае потом вытащить крайне сложно.
Обратите внимание, насколько большое существует количество различных группировок ресурсов: по языку, по разрешению экрана, его ориентации и размеру, по стране и пр. Довольно большая часть этого, возможно, вам никогда не потребуется, но ознакомиться с ними надо. В будущем при проблемах отрисовки/расположения элементов на различных устройствах это сэкономит вам уйму времени.
