писать код на телефоне как
Программирование на телефоне используя эмулятор терминала Termux
Приветствую читателей! В этой статье я расскажу о том, как можно, имея android телефон, писать программы. Говорю сразу — root права не нужны.
Что нам понадобится?
Первое, что нам понадобится — андроид телефон со установленным на него приложением Termux (есть в Google Play). Для полноценной работы с терминалом, нам нужно достаточно памяти. У меня с десятками установленных пакетов приложение занимает 1.5 ГБ памяти.
Так же, для комфортного кодинга желательно, чтобы телефон был с поддержкой OTG, и у вас была клавиатура с подключением по USB, чтобы писать код на клавиатуре (куда удобнее). Если уж нет этого, то качаем клавиатуру Hacker’s Keyboard. В ней есть клавиша Ctrl, что нам важно.
Почему именно Termux?
Termux имеет в арсенале достаточно пакетов для работы с языками программирования: C/C++, Python, Golang, PHP, Lua.
Так же присутствуют базы данных, я знаю только о mariadb и postgresql.
Начало
Для кодинга нам понадобится текстовой редактор. Здесь есть разные варианты, я выбирал Vim и вкратце расскажу, как с ним работать.
Установка vim:
Для примера работы с vim напишем «Hello World» на С.
После этого запустится Vim. Чтобы начать писать код, нужно нажать на клавишу «i».
Пишем код:
После этого нажимаем на клавишу «Esc», ставим двоеточие и пишем wq («:wq»). Это сохранит наш файл и изменения в нём (w — write) и закроет его (q — quit).
Важно знать!
w — сохранить изменения в файле
wa — сохранить изменения во всех файлах
q — закрыть файл
qa — закрыть все файлы
wq — сохранить изменения и закрыть файл
Теперь нам нужно скомпилировать этот код. Для начала установим компилятор:
Далее пишем следуюющее:
main.c — файл с нашим кодом
program — наша програмка.
Теперь можем запустить нашу програмку и посмотреть, работает ли она:
8 лучших редакторов кода для мобильных устройств
Зачем нужен редактор кода в смартфоне? Это свобода писать код когда и где угодно. Предугадать, когда в голову придет гениальная идея (или понадобится срочно внести исправление в проект), невозможно. Зато вполне можно заранее установить приложение-редактор в смартфоне и в случае необходимости набирать код с большим удобством, чем в блокноте.
Dcoder
Как утверждается на сайте Dcoder, это самая быстрая мобильная IDE. Она доступна в веб-версии, а также в виде приложений для iOS и Android. Поддерживает большое количество языков (больше 35), включая HTML, CSS, JavaScript, C, C++, Python и Java.
В Dcoder есть автоматическое проставление парных скобок и создание отступов, подсветка синтаксиса. Также вы сможете выбрать тему оформления приложения.
Разработчики Dcoder гордятся маленьким весом своего приложения: всего 6MB. Такую легковесность удалось достичь благодаря использованию облачных компиляторов и облачного хранилища для кода. Но тут есть и обратная сторона: чтобы использовать приложение, нужно непременно быть онлайн.
Turbo Editor
Простой, но при этом мощный текстовый редактор для Android. Имеет открытый исходный код (т. е., при желании и должном умении вы сможете его усовершенствовать по своему вкусу). В этом редакторе вы найдете подсветку синтаксиса для HTML, XHTML, CSS, LESS, JavaScript, PHP, Python и многих других языков, а также режим чтения, автосохранение файлов при выходе из приложения, просмотр результатов работы в браузере.
Quoda
Quoda это простой в использовании редактор кода для Android. Как и другие редакторы в нашем списке, Quoda поддерживает много языков, включая C, C++, C#, CSS, HTML, Java, JavaScript, Lua, Markdown, PHP, Python, Ruby. Есть подсветка синтаксиса, расширенная клавиатура, функционал поиска и замены с применением регулярных выражений и учетом регистра.
В платной версии доступны автодополнение кода, интеграция SFTP/FTP(S) и облачных хранилищ, а также предпросмотр страниц в разметке HTML/Markdown (на планшетах).
QuickEdit
Быстрый, надежный редактор, в котором есть функционал для работы как с простым текстом, так и с кодом. Как утверждают разработчики этого приложения, к его отличительным особенностям можно отнести скорость работы и отзывчивость. По этим критериям QuickEdit превосходит многие аналогичные приложения.
В этом приложении вы найдете подсветку синтаксиса для 50 с лишком языков, возможность включать и выключать нумерацию строк, поддержку физической клавиатуры, плавную прокрутку, автоматическое определение кодировки, возможность отмены действий (без ограничений). Поддерживается доступ к файлам в облачных хранилищах.
Our Code Editor Free
Как следует из названия, этот редактор бесплатный (но есть показ рекламы). А как указано в описании на Google Play, это целая IDE для Android. Причем она может работать без подключения к интернету. Правда, в таком случае вам не удастся поработать с файлами в облачных хранилищах (а вообще такая возможность есть).
Android Web Developer (AWD)
AWD — это IDE для веб-разработки. Языков и форматов поддерживает не много: PHP, CSS, JS, HTML, JSON. Есть возможность дистанционной работы с проектами (по протоколам FTP, FTPS, SFTP, WebDAV).
В AWD вы найдете (среди прочего) подсветку синтаксиса, автодополнение кода, автоопределение кодировки файла, интеграцию Git (в платной версии), функционал поиска и замены с применением регулярных выражений, поддержку физической клавиатуры.
Android Interactive Development Environment (AIDE)
AIDE — это интегрированная среда разработки для создания Android-приложений прямо на Android-устройствах. Поддерживает Java, C/C++, HTML5, CSS и JavaScript.
В этом приложении вы найдете автодополнение кода, проверку ошибок, подсветку синтаксиса для Java и XML. Есть интеграция с Dropbox. Благодаря совместимости с Eclipse можно открывать Eclipse-проекты. Для профессиональной разработки поддерживается Git.
Отличительная черта этого приложения — интерактивные уроки кодинга с пошаговыми инструкциями (курс программирования на Java, Android-разработки, создания игр).
Казалось бы, все просто отлично, но в комментариях люди жалуются на невозможность сохранять файлы в бесплатной версии и на навязчивые предложения перейти на платный вариант.
Codeanywhere
IDE для работы на Android-устройствах. Включает в себя редактор кода, FTP-клиент и терминал. Поддерживает огромное количество языков (больше 100). Есть возможность подключения к сторонним сервисам (Dropbox, Google Drive, OneDrive, Amazon S3, Github, Bitbucket).
Если у вас нет собственного сервера, Codeanywhere может запустить для вас Linux-контейнер, в котором будут доступны, к примеру, WordPress, Drupal, Magento.
По мотивам статьи «Top 8 Code Editors for Mobile Application Development».
Смартфон для программиста
Что выбрать, если хотите заняться мобильной разработкой.
Есть два вопроса: какой телефон купить, чтобы писать на нём код, и какой — чтобы тестировать там мобильные приложения. Вот ответы на эти вопросы по состоянию на февраль 2020 года.
Кое-как писать — любой смартфон
Для всех мобильных платформ есть необходимый минимум, чтобы писать код: специализированные текстовые редакторы, некоторые инструменты для работы с сетью, примитивные графические редакторы. На самом базовом уровне всё есть.
Если нужен «несгораемый» вариант, берите Андроид с поддержкой USB Host (то есть к самому устройству можно подключать флешки и другую USB-периферию). Подключаете к такому смартфону клавиатуру и пишете код.
У Самсунга есть технология Dex: она позволяет подключить смартфон к большому монитору, клавиатуре и мыши и использовать телефон как некое подобие стационарного компьютера. Отличие от обычного подключения в том, что интерфейс Андроида растягивается на большой экран, появляется поддержка многооконного режима. Технологии уже три года, но толкового софта под неё мало. Пока что не взлетело.
Хитрый вариант с Айпадом
Если вам нужно максимально мобильное решение, рассмотрите такую связку:
Подробнее вот у этого дядьки (по-английски):
Для тестов на iOS
Основной телефон — iPhone X. Если вы серьёзно решили программировать под iOS, то лучше сразу всё тестировать на телефоне с «чёлкой» и свайпами для управления. Нет смысла брать более дорогие модели, ведь технически в них будет всё то же самое, но дороже.
Исключение — когда вы пишете AR-приложение или софт для трёх камер: в этом случае лучше взять топовый аппарат и убедиться, что всё работает как нужно. Берите на Авито у брошенных парней.
Дополнительный — iPhone 6S. У большинства пользователей не будет на руках самой последней модели айфона. Скорее, это будет что-то из предыдущих поколений. Большой цикл обновлений, хорошее железо и много сервисных центров в каждом городе — всё это продлевает телефонам жизнь, а значит, нужно рассчитывать на то, что вашей программой будут в основном пользоваться на устройствах двух-трёхлетней давности.
В 2020 году стандарт — iOS 13, поэтому вам нужно минимально рабочее устройство, которое поддерживает эту операционную систему — iPhone 6S.
iPhone 6S — минимум для мобильной разработки под iOS.
Планшет. Подойдёт любой планшет с поддержкой iPadOS. На нём вы будете проверять, как выглядит ваша программа на большом экране, всё ли в порядке с масштабированием и правильно ли отображается интерфейс. С точки зрения кода отличия минимальные. С планшетами на Android, кстати, то же самое: подойдёт любой планшет, на котором можно оценить внешний вид на большом экране.
Android
Так как Android ставится на множество разных устройств, то здесь с минимальным набором будет сложнее. Для того, чтобы полностью протестировать своё приложение под Android, лучше использовать несколько устройств.
Samsung A-серии. Это линейка телефонов начального уровня, но в ней есть почти все технологии, которые Самсунг использует в других устройствах: вырез под камеру на экране, жесты, своя система уведомлений.
Samsung Galaxy A01 — стартовый аппарат в линейке, на котором можно проверять любые приложения под Android.
Huawei. Из-за разногласий компании Huawei с Google эти телефоны могут лишиться поддержки сервисов Google, а главное — магазина приложений. Чтобы убедиться, что ваше приложение будет работать, протестируйте его, например, на Huawei Mate 30 Pro. Если всё работает — можете покорять китайский рынок. Заодно потренируетесь работать с датчиком отпечатка пальца, встроенным прямо в экран.
Работать без сервисов Google — непростая задачка.
Meizu/Xiaomi. Эти аппараты попали в список из-за агрессивной работы с памятью. Даже в стандартном режиме они выгружают приложения из рабочей памяти, чтобы сократить энергопотребление устройства и увеличить время до подзарядки. Когда включается режим энергосбережения, всё становится ещё печальнее — иногда даже не приходят уведомления или сообщения в чат.
Если постоянная выгрузка из памяти может повлиять на работу вашего приложения — лучше выяснить это заранее.
Meizu M3 — классический пример странной работы с памятью и уведомлениями.
Irbis/Jinga/Fly/Digma/Vertex. Напоследок — любой китайский телефон за 3–5 тысяч рублей. Он нужен для того, чтобы понять, как будет вести себя ваша программа на непредсказуемом и слабом железе. Если всё хорошо — мы вас поздравляем, вы умеете писать качественный и стабильный код с большим запасом прочности.
Секретные коды, или как я писал свое приложение для android
Думаю все, у кого есть устройство на базе ОС Android, хотя-бы краем уха слышали о «секретных кодах».
Однако поиск по Хабру показал что здесь нет ни одной статьи на данную тему. А ведь некоторые коды довольно могущественные: например один из кодов на моем Samsung Galaxy Tab позволяет настроить GPS что ускоряет поиск спутников, другой — жестко установить режим связи с сетью(GPRS, EDGE, 3G. ) что в местах с нестабильной связью позволяет хорошо сэкономить батарею на скачках между режимами.
Но повествование я поведу не сколько про возможности кодов а про исследование механизма запуска приложений по кодам в ОС Android, как найти все коды(и приложение в которое это всё вылилось). И еще немного про то, как сделать приложение которое будет отзываться на свой код.
Под катом 6 картинок, немного кода и много текста… Самых нетерпеливых прошу сразу в конец статьи помацать результаты а уж потом — читать технологию.
Вступление
Про коды в Android я слышал давно. Наиболее распространённый — *#*#4636#*#* — это информация о телефоне, батарее, состоянии сети и т.д. 
Но недавно я установил себе программу Autostarts, сделал поиск по установленным приложениям и (О чудо!) увидел странное событие «Secret Code Entered». На него отвечала целая куча приложений! Этот факт подвигнул меня на более глубокий поиск на эту тему. Вот что я выяснил:
Часть первая. События в Android
Как известно, каждое приложение Android содержит в себе манифест. Это специально сформированный XML файл содержащий информацию какая целевая версия ОС, какие возможности разрешения требуются приложению для работы и т.д. Самое интересное в этом манифесте — секции описывающие BroadcastReceiver’ы. Это классы, которые реагируют на наступление определенных событий. Этих событий много, например: совершается исходящий звонок(android.intent.action.NEW_OUTGOING_CALL), изменилось состояние режима «полёт» (android.intent.action.ACTION_AIRPLANE_MODE_CHANGED)… Официальный список можно увидеть на сайте Android.
Однако список отнюдь не полон т.к. каждое приложение может создавать своё событие. Это вносит некоторый хаос в документацию при попытке выяснить на что может реагировать приложение.
Именно в этом хаосе удачно спряталось событие, которое представляет огромный интерес: android.provider.Telephony.SECRET_CODE
Как показало вскрытие исходных кодов штатной звонилки в Андроиде что при вводе чего-либо начинающегося на *#*# и заканчивающегося #*#* в номеронабирателе происходит поиск и передача сообщения тому BroadcastRecever’у который слушает именно этот код(то что между *#*# и #*#*)
Часть вторая. Реагируем на код
Теперь глянем что-же требуется от приложения что-бы среагировать на наступление данного события:
Как видно, добавить скрытые возможности в свои приложения Android очень даже просто.
Что делать в Receiver’е я умолчу, там уже ваш собственный путь, лично я — вызываю отладочное Activity.
Часть третья. Ищем партизанов
Теперь перейдем к поиску Receiver’ов, реагирующих на коды. Первой мыслью (и первой реализацией) был вот такой вот код:
for(int i=0;i
В точности код я не помню, он был затёрт за ненадобностью так как было найдено решение лучше. Данное же решение просто перебирает все коды с 0 до 10000, тот диапазон в котором находится значительная часть кодов. Но не все.
Именно это «не все» подвигло меня на более детальные поиски и привело к новому решению:
1) Берем список всех установленных приложений через PackageManager:
List pil = pm.getInstalledPackages(PackageManager.GET_DISABLED_COMPONENTS);
2) Из каждого пакета вытаскиваем его манифест:
AssetManager am = context.createPackageContext(p.packageName, 0).getAssets();
xml = assets.openXmlResourceParser(«AndroidManifest.xml»);
3) Простая магия с разбором манифеста и поиском нужных Receiver’ов, IntentFilter’ов, Action’ов.
4) Профит.
У этого метода есть всего один недостаток: он был замечен на приложении SuperUser от ChainsDD. Дело в том что данное приложение имеет кривой манифест который выглядит как-то так:
Как видите, в нем не указан код, на который следует реагировать и Receiver вызывается при вводе любого кода. Декомпилировав эту программу я убедился что сделано это по ошибке а не следуя желанию вести лог всех введенных кодов, т.к. в самом Receiver’е происходит проверка на равенство кода заданному значению и если код не равен заданному — то ничего не происходит 🙁 т.е. этот Receiver запускается при каждом вводе кода, чего можно было избежать указав какой именно код должен пробуждать Receiver.
Часть последняя. Для самых терпеливых.
Последнюю часть оставил для презентации результатов.
Результатом всех этих расследований стала замечательная(не побоюсь этого слова) программа, аналогов которой на маркете обнаружено не было: Секретные Коды
Кроме описанной выше возможности искать секретные коды программа также позволяет:
— Запускать найденные коды
— Комментировать/читать комментарии других пользователей о кодах. Это сделано что-бы люди которые боятся FactoryFormat’а могли удостоверится что код безопасен до его запуска, а бесшабашные экспериментаторы — написать что делает тот или иной код. Мной лично было запущенны ВСЕ доступные коды на Samsung Galaxy Tab 7″ и откомментированны все коды которые выводят хоть какую-то информацию. (Кстати успешно пережил FactoryFormat, т.к. заранее сделал backup всех приложений и данных.)
— Назначать кодам значки для большей наглядности списка кодов.
На закуску 6 ScreenShot’ов:
Главное Activity:
Activity поиска кодов:
Поиск кодов завершен:
Список кодов:
Activity кода:
Некоторые из доступных значков для обозначения кода:
P.S. на SreenShot’ах всего 3 кода т.к. они делались на эмуляторе. На моём Galaxy Tab’е их более 100-а.
P.P.S статья опубликована по просьбе Владислава Аксёнова ввиду отсутствия у него аккаунта (кому понравилась статья и не жалко инвайта, вот e-mail, высылайте: grafmailgraf@mail.ru).
Написал статью BlackSwan. Спасибо krovatti за инвайт!
Вот и QR-ка:
Как написать чистый код для Android
Дядя Боб говорил в своей книге: «Вы читаете эту статью по двум причинам. Во-первых, вы разработчик. Во-вторых, вы хотите стать лучше как разработчик».
Представьте, что вы в библиотеке и ищете книгу. Если издания рассортированы и каталогизированы, вы быстро найдёте нужное. А если у библиотеки приятный интерьер и архитектура, во время поиска вам будет особенно комфортно.
Так же и с кодом. Если вы хотите создать что-то хорошее, нужно уметь писать понятный код и организовывать его в проекте. Когда коллегам понадобится найти что-то в коде, будет достаточно посмотреть названия методов, классов и пекеджей, чтобы разобраться. И не придётся переписывать всё с нуля, махнув на вашу работу рукой.
Что такое чистый код
Как вы понимаете, недостаточно просто побыстрее написать приложение. Если другим разработчикам будет тяжело в нём разобраться, это просто увеличит технический долг.
Код можно назвать чистым, если его с ходу понимают другие разработчики. Тогда его можно читать и изменять, расширять и поддерживать.
Почему это важно
Код отражает ваш мыслительный процесс. Поэтому нужно стараться сделать код более простым и читаемым.
Основные характеристики чистого кода
Разница между умным разработчиком и профессиональным в том, что второй ставит читаемость во главу угла. Профессионалы используют весь свой опыт, чтобы писать код, который поймут остальные.
Создавайте говорящие названия
Выбор хорошего говорящего названия отнимает время, но в итоге экономит ещё больше. Название переменной, метода или класса должно отвечать на все основные вопросы. То есть объяснять, для чего этот класс (метод, переменная), что он делает и как его использовать. Если приходится пояснять что-то в комментариях — значит, название недостаточно говорящее. Посмотрим на пример:
Имена классов
Названия классов и объектов должны быть существительными типа Customer, WikiPage, Account, AddressParser. Избегайте в именах слов Manager, Processor, Data или Info, потому что они мало говорят о функциональности объекта. Не используйте глаголы.
Имена методов
В названиях методов как раз нужны глаголы типа postPayment, deletePage, save.
Используйте названия из предметной области
Если общепринятого термина нет, используйте название из предметной области. Тогда разработчик, который поддерживает ваш код, сможет спросить о его значении эксперта.
Комментарий автора статьи
Например, вы пишете софт для телекоммуникационного оборудования. Ваши области задачи (экспертизы, решения) — это текстовое и голосовое общение, видеосвязь. Неважно, на каком языке, как и на какой платформе вы пишете, — предметная область от этого не меняется. Если вы разрабатываете приложение для создания и продажи фотоконтента, то предметная область включает фотографию и e-commerce. Любой человек, который видит ваш код в первый раз, должен сразу понимать, чем занимается каждый класс, модуль или пекедж в вашем приложении. Думайте об этом, когда добавляете в название что-то из предметной области этого класса.
Пишем код, используя принципы SOLID
Эти принципы были введены в практику ООП Робертом Мартином, а SOLID — мнемоническая аббревиатура для них. Они описывают подход к проектированию простых, читаемых и надёжных программных решений не только в Android-разработке, но и в целом в объектно-ориентированном программировании.
Принцип единой ответственности (Single Responsibility Principle — SRP)
У класса должна быть одна задача. Изменить состояние класса можно только для того, чтобы выполнить конкретную задачу. Не добавляйте в класс функциональность просто потому, что можете. Если класс выполняет разные задачи — разбейте его на два или вынесите часть задач в другие классы. Избегайте божественных классов. Посмотрим на пример:
В классе RecyclerView.Adapter есть метод onBindViewHolder, который занимается посторонними задачами. Adapter должен только создавать ViewHolder и передавать в него данные. Он не должен обрабатывать эти данные в методе onBindViewHolder. Даже само название метода говорит нам об этом.
Принцип открытости-закрытости (Open-Closed Principle — OCP)
Классы должны быть открыты для расширения, но закрыты для изменения. Иными словами, если кто-то захочет внести коррективы в ваш класс А, то его можно расширить (отнаследоваться от него), но никак не менять напрямую.
Простой пример — тот же RecyclerView.Adapter. Вы можете отнаследоваться от него, чтобы создать свою имплементацию с необходимыми вам свойствами и поведением. Но вы не можете внести эти изменения непосредственно в RecyclerView.Adapter.
Принцип подстановки Барбары Лисков (Liskov Substitution Principle — LSP)
Класс-потомок никогда не изменяет поведение класса-родителя. То есть подкласс может переопределять методы родительского класса, только если это не меняет его функциональность.
Например, вы создаёте интерфейс, у которого есть метод onClick(). Затем вы имплементируете интерфейс в MyActivity, и когда onClick() вызовется — отобразите в нём Toast. Не прописывайте эту функциональность в интерфейсе. Дополняйте onClick(), только переопределяя его в классе-потомке.
Принцип разделения интерфейсов (Interface Segregation Principle — ISP)
Ни один наследник не должен имплементировать методы, которые он не использует. Если у вас есть класс или интерфейс А и вы имплементируете его в классе B, то не нужно переопределять все методы А в B.
Для примера рассмотрим имплементацию в вашей Activity SearchView.OnQueryTextListener(). Вам нужен оттуда только один метод, но там их два:
Как сделать так, чтобы вы не имплементировали ненужную функциональность? Отнаследуйтесь от SearchView.OnQueryTextListener(), создайте свой колбэк и передавайте дальше только то, что вам нужно:
Как это будет выглядеть в нашей Activity:
Или можно написать функцию-расширение, как это принято в Kotlin:
Как это будет выглядеть в Activity:
Принцип инверсии зависимостей (Dependency Inversion Principle — DIP)
Зависимости должны быть от абстракций, а не от конкретных имплементаций. Роберт Мартин приводит два аргумента:
Высокоуровневые модули, в которых прописана сложная бизнес-логика, должны легко переиспользоваться и не зависеть от изменений в низкоуровневых модулях. Чтобы это работало, вам нужно определить абстракции, которые отделяют высокоуровневые модули от низкоуровневых.
Простой пример — паттерн MVP, где вы определяете интерфейсы, которые помогают передавать данные из одного конкретного класса в другой. Это значит, что UI-часть (Activity/Fragment) не должна ничего знать о том, как именно работают методы Presenter. И если вы измените что-то в Presenter, Activity этого даже не заметит. Посмотрим на примере. Presenter имплементирует интерфейс:
То же самое в Activity:
Мы создали интерфейс, отделяющий имплементацию Presenter от Activity, которая содержит ссылку на интерфейс, а не на Presenter.
Если вы уже разрабатывали приложение, в котором были бессмысленные названия, божественные классы, спагетти-код — поверьте, я тоже такое делал. Поэтому и делюсь знаниями от Дяди Боба о чистом коде. Надеюсь, они вам помогут.
Дядя Боб говорил в своей книге: «Вы читаете эту статью по двум причинам. Во-первых, вы разработчик. Во-вторых, вы хотите стать лучше как разработчик».
Представьте, что вы в библиотеке и ищете книгу. Если издания рассортированы и каталогизированы, вы быстро найдёте нужное. А если у библиотеки приятный интерьер и архитектура, во время поиска вам будет особенно комфортно.
Так же и с кодом. Если вы хотите создать что-то хорошее, нужно уметь писать понятный код и организовывать его в проекте. Когда коллегам понадобится найти что-то в коде, будет достаточно посмотреть названия методов, классов и пекеджей, чтобы разобраться. И не придётся переписывать всё с нуля, махнув на вашу работу рукой.
Что такое чистый код
Как вы понимаете, недостаточно просто побыстрее написать приложение. Если другим разработчикам будет тяжело в нём разобраться, это просто увеличит технический долг.
Код можно назвать чистым, если его с ходу понимают другие разработчики. Тогда его можно читать и изменять, расширять и поддерживать.
Почему это важно
Код отражает ваш мыслительный процесс. Поэтому нужно стараться сделать код более простым и читаемым.
Основные характеристики чистого кода
Разница между умным разработчиком и профессиональным в том, что второй ставит читаемость во главу угла. Профессионалы используют весь свой опыт, чтобы писать код, который поймут остальные.
Создавайте говорящие названия
Выбор хорошего говорящего названия отнимает время, но в итоге экономит ещё больше. Название переменной, метода или класса должно отвечать на все основные вопросы. То есть объяснять, для чего этот класс (метод, переменная), что он делает и как его использовать. Если приходится пояснять что-то в комментариях — значит, название недостаточно говорящее. Посмотрим на пример:
Имена классов
Названия классов и объектов должны быть существительными типа Customer, WikiPage, Account, AddressParser. Избегайте в именах слов Manager, Processor, Data или Info, потому что они мало говорят о функциональности объекта. Не используйте глаголы.
Имена методов
В названиях методов как раз нужны глаголы типа postPayment, deletePage, save.
Используйте названия из предметной области
Если общепринятого термина нет, используйте название из предметной области. Тогда разработчик, который поддерживает ваш код, сможет спросить о его значении эксперта.
Комментарий автора статьи
Например, вы пишете софт для телекоммуникационного оборудования. Ваши области задачи (экспертизы, решения) — это текстовое и голосовое общение, видеосвязь. Неважно, на каком языке, как и на какой платформе вы пишете, — предметная область от этого не меняется. Если вы разрабатываете приложение для создания и продажи фотоконтента, то предметная область включает фотографию и e-commerce. Любой человек, который видит ваш код в первый раз, должен сразу понимать, чем занимается каждый класс, модуль или пекедж в вашем приложении. Думайте об этом, когда добавляете в название что-то из предметной области этого класса.
Пишем код, используя принципы SOLID
Эти принципы были введены в практику ООП Робертом Мартином, а SOLID — мнемоническая аббревиатура для них. Они описывают подход к проектированию простых, читаемых и надёжных программных решений не только в Android-разработке, но и в целом в объектно-ориентированном программировании.
Принцип единой ответственности (Single Responsibility Principle — SRP)
У класса должна быть одна задача. Изменить состояние класса можно только для того, чтобы выполнить конкретную задачу. Не добавляйте в класс функциональность просто потому, что можете. Если класс выполняет разные задачи — разбейте его на два или вынесите часть задач в другие классы. Избегайте божественных классов. Посмотрим на пример:
В классе RecyclerView.Adapter есть метод onBindViewHolder, который занимается посторонними задачами. Adapter должен только создавать ViewHolder и передавать в него данные. Он не должен обрабатывать эти данные в методе onBindViewHolder. Даже само название метода говорит нам об этом.
Принцип открытости-закрытости (Open-Closed Principle — OCP)
Классы должны быть открыты для расширения, но закрыты для изменения. Иными словами, если кто-то захочет внести коррективы в ваш класс А, то его можно расширить (отнаследоваться от него), но никак не менять напрямую.
Простой пример — тот же RecyclerView.Adapter. Вы можете отнаследоваться от него, чтобы создать свою имплементацию с необходимыми вам свойствами и поведением. Но вы не можете внести эти изменения непосредственно в RecyclerView.Adapter.
Принцип подстановки Барбары Лисков (Liskov Substitution Principle — LSP)
Класс-потомок никогда не изменяет поведение класса-родителя. То есть подкласс может переопределять методы родительского класса, только если это не меняет его функциональность.
Например, вы создаёте интерфейс, у которого есть метод onClick(). Затем вы имплементируете интерфейс в MyActivity, и когда onClick() вызовется — отобразите в нём Toast. Не прописывайте эту функциональность в интерфейсе. Дополняйте onClick(), только переопределяя его в классе-потомке.
Принцип разделения интерфейсов (Interface Segregation Principle — ISP)
Ни один наследник не должен имплементировать методы, которые он не использует. Если у вас есть класс или интерфейс А и вы имплементируете его в классе B, то не нужно переопределять все методы А в B.
Для примера рассмотрим имплементацию в вашей Activity SearchView.OnQueryTextListener(). Вам нужен оттуда только один метод, но там их два:
Как сделать так, чтобы вы не имплементировали ненужную функциональность? Отнаследуйтесь от SearchView.OnQueryTextListener(), создайте свой колбэк и передавайте дальше только то, что вам нужно:
Как это будет выглядеть в нашей Activity:
Или можно написать функцию-расширение, как это принято в Kotlin:
Как это будет выглядеть в Activity:
Принцип инверсии зависимостей (Dependency Inversion Principle — DIP)
Зависимости должны быть от абстракций, а не от конкретных имплементаций. Роберт Мартин приводит два аргумента:
Высокоуровневые модули, в которых прописана сложная бизнес-логика, должны легко переиспользоваться и не зависеть от изменений в низкоуровневых модулях. Чтобы это работало, вам нужно определить абстракции, которые отделяют высокоуровневые модули от низкоуровневых.
Простой пример — паттерн MVP, где вы определяете интерфейсы, которые помогают передавать данные из одного конкретного класса в другой. Это значит, что UI-часть (Activity/Fragment) не должна ничего знать о том, как именно работают методы Presenter. И если вы измените что-то в Presenter, Activity этого даже не заметит. Посмотрим на примере. Presenter имплементирует интерфейс:
То же самое в Activity:
Мы создали интерфейс, отделяющий имплементацию Presenter от Activity, которая содержит ссылку на интерфейс, а не на Presenter.
Если вы уже разрабатывали приложение, в котором были бессмысленные названия, божественные классы, спагетти-код — поверьте, я тоже такое делал. Поэтому и делюсь знаниями от Дяди Боба о чистом коде. Надеюсь, они вам помогут.