image

Я ясно помню тот день в далеком 2014 году, когда я решил заняться программирование под Android. Это оказалось лучшим решением, которое я принял в моей жизни. Уже прошло почти два с половиной года, и за это время у меня возможность кое-чему научиться.

Когда я только начал, я не знал никого, кто мог бы научить меня, показать, как правильно нужно делать. И я совершил МНОЖЕСТВО ошибок, в так же потратил кучу времени на то, чтобы потом их исправить.

Полтора года спустя, мне выпал шанс поработать с очень талантливыми и опытными Android-разработчиками, которые направляли меня и помогли мне привести все в порядок. Эти две составляющие научили меня многому. Я понял, что надо ДЕЛАТЬ, а самое главное, что НЕ НАДО.

И уже какое-то время я, как могу, стараюсь помогать другим разработчикам — прямо или косвенно. Вот мои профили: StackOverflow и Github.

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

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

Поддержка публикации — компания EDISON, которая реализовала систему распознавания большегрузных ТС и ведение цифрового протокола, а так же разработала графический пользовательский интерфейс для микротомографа.

1. Не нужно заново изобретать колесо


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

Если у вас возникает какая-то проблема во время улучшения вашего приложения, и если эту проблему уже до вас кто-то решил, то почему бы не воспользоваться этим? Так вы сможете сэкономить много времени.

Лучше сконцентрируйтесь на бизнес логике приложения. Если вы хотите совершать вызовы в приложении, то для этого вам не нужно изобретать Retrofit.

Бонус: В Android Arsenal содержатся почти все Android библиотеки, созданные когда-либо. Проверьте.

2. Выбирайте библиотеки грамотно.


Множество библиотек с открытым кодом доступно на Github бесплатно. Но не стоит этому сильно радоваться, и тут же начинать ими пользоваться.

Проверьте сколько звезд у библиотеки, чем больше звезд, тем лучше. Посмотрите, если у создателя библиотеки еще какие-нибудь популярные работы. И проверьте обсуждения (открытые и закрытые), они могут дать вам лучшее представление о том, насколько стабильна и устойчива библиотека в действии.

Если вы располагаете временем, то стоит проверить код этой библиотеки и понять, стоит ли это того.

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

Подсказка: вы можете проверить любую библиотеку прямо из командной строки, используя Dryrun.

image

3. Сделайте себе кофе, присядьте и почитайте коды


Мы тратили больше времени на чтение чужих кодов, а не написание своих. Если вы так не делайте, то НАЧНИТЕ сегодня.

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

Одна из самый замечательных вещей в Android — это то, что это полностью открытая платформа. Откройте код и посмотрите, как они воплотили его. На сайте Github представлены тысячи библиотек с открытым кодом. Просто выберите одну и посмотрите, как разработчик ее сделал.

Бонус: Вот список лучших библиотек, а здесь список почти всех приложений для Android с открытым кодом. Не благодарите.

4. Ради бога, поддерживайте стандарты кодирования на должном уровне


Если вы сравнивайте написание кода с написанием, тогда стандарты кодирования — это почерк.
Так же как вы читаете коды, созданные другими, так же и другие люди будут читать ваш код. А вы же не хотите напугать их? И если вы работаете вместе с другими разработчиками, то вам точно стоит обратить на это внимание.

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

Код словно поэзия.

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

Бонус: И еще вам стоит прочитать это и это.

5. Вам нужен ProGuard, да вам он точно нужен!


Никогда, никогда не выкладывайте приложения в Play Store, не используя ProGuard. ProGuard не только сократит ваш код, но так же запутает код, т.е. затруднит анализ, понимание алгоритмов работы при обратной разработке (реверс-инжиниринг).

Это бесплатно и идет в комплекте с Android SDK. И нет никаких причин, чтобы не воспользоваться этим.

Я видел, как несколько разработчиков загрузили свои приложения в Play Store без ProGuard. И у не таких уж и умелых хакеров заняло не больше нескольких часов, чтобы воспользоваться ситуацией.

Подсказка: Но если вам нужна защита получше, то стоит воспользоваться не ProGuard, а DexGuard.

6. Используйте продуманную архитектуру


Поверьте, вы будете долго благодарить себя, если сначала выберете нормальную архитектуру.
Вы можете использовать MVP (Model-View-Presenter), это разделит код на уровни, тем самым увеличит гибкость кода и уменьшит время обслуживания.

Вот демо-проект для начала. И если вы уже помучились с этим, но у вас ничего не вышло, то вот подробная инструкция для новичков.

Бонус: Почитайте это, это и обратите внимание на это. Это все может помочь вам с MVP.

image

7. Пользовательский интерфейс как шутка. Если вам приходится его объяснять, то это плохой интерфейс


Если вы работаете на компанию, и ваша должность — простой Android — разработчик, то, скорее всего, вам не нужно переживать из-за этого, т.к. в компании наверняка есть UI/UX дизайнеры, которые отвечают за интерфейс.

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

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

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

Лучше уж удалить какие-либо элементы дизайна, чем добавить лишние. Дизайн должен быть простым и минималистичным.

Бонус: Вы всегда можете найти вдохновение, просмотрев работы популярных дизайнеров Dribble или MaterialUp. Так же есть книга, которую вы, возможно, захотите прочитать, если вы заинтересованы.

8. Аналитика — ваш лучший друг


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

Под аналитикой я имею ввиду и отчеты об ошибках, и отслеживание посещений, т.к вам понадобится эта информация.

Что бы вы ни делали, у вас никогда не получится созвать совершенное приложение. Когда пользователи начнут пользоваться вашим приложением на разных устройствах с операционной системой Android, и даже разными версиями Android, вы увидите, что даже самые лучшие коды «рухнут».

Отчеты об ошибках помогут вам отслеживать и исправлять их вовремя.

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

Подсказка: Воспользуйтесь Firebase Crash Reporting and Analytics и вы еще поблагодарите меня за это.

9. Станьте ниндзей маркетинга


Если вы индивидуальный разработчик, то вам нужно не только «разрабатывать», но и так же разбираться в маркетинге.

Я видел, как действительно хорошая продукция не была популярна только из-за плохого маркетинга, в то время как посредственная была востребована.

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

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

Подсказка: вот доступный сайт для анализа рынка. Мне он нравится

10. Настало время оптимизации


Это как раз то, что большинство из нас не делает, но это необходимо.

Есть большая разница между «написанием кода» и «написанием оптимизированного кода».

Пишите код, который быстро работает и занимает меньше памяти.

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

Проверьте, сколько памяти занимает ваше приложение и не происходит ли утечка памяти.

Помните, что даже маленькая течь топит большой корабль. Потратьте время и разберитесь со сборщиком мусора (Garbage Collector) и дампы куч (heap dumps).

Подсказка: воспользуйтесь Leak Canar для поиска утечки памяти. Это может сэкономить вам кучу времени

11. Экономьте по 5 и более часов в неделю с Gradle


Скорее всего, вы пользуетесь Android Studio для улучшения приложений, и Gradle в качестве системы автоматической сборки. Gradle безусловно хорош, но он очень медленный. И становится даже медленнее улитки, когда размер вашего приложения начинает увеличиваться.

Я помню бесконечные часы, которые я провел в ожидании, пока Gradle завершить работу. Во время загруженных будней у меня уходило около часа только ожидание. А это 5 часов в неделю.

Но всегда есть возможность ускориться.

Вы можете последовать этому совету, а так же этому, и ускорить скорость сборки. Раньше у меня занимало 4 минуты, а после оптимизации у меня уходит около 30 секунд.

12. Тестируйте, тестируйте, и еще раз тестируйте!


Нет ничего более важного, чем тестирование. Это вообще то, что должно быть первым в списке.

Тестируйте свое приложение так тщательно, как это возможно. Потратьте время на написание тестовых случаев. Придумайте разные стрессовые ситуации для приложения и посмотрите, справится ли оно.

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

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

Никогда не делайте что-либо в спешке, всему свое время. Мыслите долгосрочными перспективами. Время сеять и время пожинать

13. Фрагментация в Android — Дьявол под прикрытием



image

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

Множество устройств работают на Android, и у них у всех разный размер экрана и технические характеристики. Изобилие производителей, которые подгоняют операционную систему под техническое оснащение устройства.

К этому еще стоит добавить различные версии Android, в которые Google добавляет/убирает интерфейс прикладного программирования (Application Programming Interface), что еще больше увеличивает нагрузку (вот наглядный пример).

Например, ни один Android-разработчик не закончил создание приложения без использования SharedPreferences API. Это так распространено, хотя это не подошло Samsung Galaxy S на Android 2.2 (вот отчет об ошибке).

Потратьте время на создание разных макетов для экранов разного размера. Протестируйте на разных устройствах с разной версией Android и т.д.

Никогда не думайте, что программа будет работать, только потому что так кажется.

14. Начните пользоваться Git!


Если вы еще не пользуетесь Git, то самое время начать.

Когда я только занялся программирование под Android, то я, к несчастью, не знал, что такое Git. Мне приходилось копировать полностью версии своей программы каждый день, и хранить одну копию на жестком диске, и еще одну в «облаке». Глупо, да? Да.

Git может улучшить ваш поток работ (workflow). Если кто-то попросит меня назвать программу, которой я пользуюсь каждый день, и, которую я бы не смог перестать использовать, то это определенно будет Git.

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

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

Бонус: если вы только начали, и еще не можете позволить себе ежемесячную плату за личное хранилище на GitHub, то вам стоит воспользоваться BitBucket — он совершенно бесплатный.

15. Усложните жизнь хакерам


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

Вы же не хотите, чтобы это произошло с вашим приложением?

Тогда вам следует знать, как защитить приложение при помощи API ключей. Если вы имеете дело с уязвимыми данными, то вы должны знать, как зашифровать их, какой именно алгоритм выбрать (безопасный, а не быстрый).

Вы так же должны хранить ключи шифрования или на сервере, или на локальном диске (если необходимо). Так же вам стоит защитить приложение от копирования при помощи ADB (Android Debug Bridge). Если же вы храните уязвимые данные в базе данных, убедитесь, что запутали код.

А что если премиум версия вашего приложения будет взломана и выставлена бесплатно? Вы понесете убытки.

Есть несколько вещей, которые вы может сделать, чтобы не допустить подделки своего приложения. Конечно, нет 100% защиты. Любой опытный хакер с необходимой информацией, приложениями, и наличием желания сможет взломать ваше приложение.

Все, что вы можете сделать — это усложнить задачу. Защитите приложение, чтобы хакеру было не просто взломать его.

Бонус: Почитайте эту и эту статьи. Это положет хорошее начало.

16. Разрабатывайте программы и на бюджетном девайсе


Мне, как и всем нравится пользоваться дорогими смартфонами. Но таким устройством стоит пользоваться только в личных целях, а никак не для разработки программы.

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

Старый, бюджетный смартфон с кучей установленных приложений — лучший вариант.

image

17. Вкладывайте в изучение Design Patterns


Такое вложение будет окупаться постоянно.

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

Начните тратить по немного времени с сегодняшнего дня на изучение Java Design Patterns. Вот проект Github, который демонстрирует все шаблоны проектирования известные человечеству.

Лучше всего начать с изучения таких важных, как Одиночка (Singleton), Адаптер (Adapter), Фабричный метод ( Factory Method), Итератор (Iterator), Внедрение зависимости (Dependency Injection), Строитель (Builder), Стратегия (Strategy).

Кажется, что их слишком много? На самом деле, нет. Вам они точно понравятся.

Подсказка: почитайте книги, вроде, Джошуа Блох «Java. Эффективное программирование» и Мартин Фаулер «Рефакторинг».

18. Время отдавать


Нам всем помогали окружающие нас люди. Давайте это признаем.

image

Если у вас какая-то проблема, то первое, что вы делаете — это ищите ответ в Google и на сайте StackOverflow. Иногда, когда у вас нет времени, вы просто копируете и вставляете уже готовое решение из ответа, который набрал большее количество лайков.

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

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

И вот пришло время отплатить. Чем большим вы поделитесь, тем больше вы получите взамен
Мы все заняты собственной работой, и нам так трудно управлять временем и сделать что-то для других. Но можно попытаться найти немного времени, и сделать это Android сообщество лучше.

Я попытался поделиться некоторыми вещами, которые я понял за время этого короткого путешествия с Android. Но я продолжу этот путь, узнаю больше, и мне будет чем поделиться. Надеюсь, что это поможет кому-нибудь, и упростит жизнь.
Поделиться с друзьями
-->

Комментарии (17)


  1. HotIceCream
    12.11.2016 14:41
    +8

    В 13 пункте имеется ввиду все же фрагментация, а не фрагменты.

    По поводу 1 пункта, выскажу, возможно, не популярное мнение, но по-моему оно имеет смысл. Если вы только начинаете программировать и пишете приложение «для себя», то, наоборот, постарайтесь не использовать библиотек. Используйте для запросов UrlConnection, парсите json стандартным api андроида, напишите свою «вьюху», вместо того, что бы спереть ее с Android Arsenal. Изобретите свой MVP, orm.
    И только потом начинайте использовать библиотеки. В этом случае, при использовании библиотек будет намного проще найти причину, по которой что-то идет не так.


    1. edogs
      12.11.2016 23:16

      По поводу 1 пункта — тут все зависит от того, в чем первичная цель.
      Если цель научится — да, стоит минимальное время потратить на то что бы набить своих шишек и потом понимать что и как работает. Так же неплохо бы закончить универ для начала, вызубрить всего д.кнута, разобраться со smali и вообще:)
      Если же цель «фигак и в продакшен», то все же только библиотеки. Выбор хороших библиотек избавит от избыточного количества случаев когда надо искать проблему. А поиск возникших проблем заставит разобраться в том как работает правильный код, вместо набивания своих ошибок.

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


  1. GreyCat
    12.11.2016 15:40
    +2

    Про ProGuard и DexGuard улыбнуло :) Все боятся «умелых хакеров», которые «воспользуются ситуацией». И, интересно, что же случится? ;)


    1. Nagg
      13.11.2016 05:33

      Хорошо когда ты выпускаешь такой классный и нужный продукт, что кому-то будет не лень лезть и "хакать". Правда если он настолько крут — то и вряд ли pro/dex guard спасут.


    1. jehy
      13.11.2016 12:44

      Таки есть куча практик, когда авторы зашивают в приложение ключи, пароли и прочие sensitive данные. А потом это добро героически пытаются защитить. Вот недавно на хабре был пост про Android приложение, которое работает с шифрованной СУБД. Плохие практики приводят к боязни хакеров и к закономерным взломам.


      1. CoolMind
        13.11.2016 18:33
        +1

        Простите, вы не могли бы привести ссылку? (Мой первый комментарий за много лет)


        1. jehy
          13.11.2016 18:43

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


  1. GLaDosSystem
    12.11.2016 21:25
    -2

    И сейчас самое время поделиться и прибавить кармы автору :)


  1. nitrocaster
    13.11.2016 00:51

    в которые Google добавляет/убирает интерфейс прикладного программирования (Application Programming Interface)

    Здесь, наверное, подразумевалось, что Google меняет API?


  1. dzhidzhoev
    13.11.2016 09:35

    Автор не знает, как можно нормально использовать Proguard со всякими Google Services и Admob, чтобы не было проблем с обфускацией их классов?


    1. jehy
      13.11.2016 12:42
      +1

      Не обфусицировать классы, которые не нужно обфусицировать?


      1. dzhidzhoev
        14.11.2016 13:18

        Так у них же там есть какие-то внутренние классы, которые уже обфусцированы?


        1. jehy
          14.11.2016 13:45

          Так я и говорю — просто не надо их обфусцировать по второму разу:

          -keep class javax.** { *; }
          -keep class org.** { *; }
          -keep class twitter4j.** { *; }


  1. jehy
    13.11.2016 12:41
    +1

    Пункт 5 и 15 показывает, что автор никогда не пробовал сам реверсить Android приложения. Мне это приходилось делать довольно много, и вывод — как-то защитить можно только при использовании native библиотек — да и то если они у вас не генерируют трафик, который потом будет перехвачен. Так что гораздо корректнее при выкладывании приложения считать, что вы сразу выкладываете его исходники в open source. В исходниках просто **не должно быть** ничего, что требуется защищать. Иначе вы просто становитесь Неуловимым Джо.


  1. lAgitAl
    13.11.2016 12:48
    +1

    Большое спасибо за раздел про бустинг Gradle — раньше время сборки принимал как данность, и это было ошибкой!


    1. jawaharlalnehru
      13.11.2016 18:33
      +1

      Если у Вас много подключенных библиотек из репозиториев, то идёте в File -> Settings -> Build, Execution, Deployment -> Compiler. Там в Command-line Options вписываете --offline и время сборки сократится раза в два.


  1. zhigar
    14.11.2016 11:46
    -1

    Бонус: Вот список лучших библиотек… линк, кажется, битый