Разработки яндекс для андроид

Школа мобильной разработки

Чтобы не пропустить набор на следующую Школу, оставьте заявку. Мы обязательно сообщим о начале регистрации.

Приём анкет в Школу мобильной разработки 2021 закрыт.

Летом 2021 года Яндекс запустит одновременно пять школ в Москве: Школу разработки интерфейсов, Школу бэкенд-разработки, Школу мобильной разработки, Школу дизайна и Школу менеджеров. У студентов будет возможность объединиться и вместе поработать над реальными проектами Яндекса.

Обучение пройдёт с 31 мая по 31 августа.

В школе будет представлено 2 направления:

• Разработка под Android
• Разработка под iOS

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

Мы приглашаем начинающих мобильных разработчиков, готовых получать новые знания.

Для поступления в школу iOS-разработчикам нужны базовые знания Swift. Опыт создания приложений для iOS будет преимуществом.

Мы ждем, что у Android-разработчиков есть начальный опыт написания мобильных приложений на Java или Kotlin.

Опыт программирования на других языках и знание алгоритмов будет плюсом для обоих направлений.

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

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

Занятия будут проходить очно в московском офисе Яндекса.

Мы оплатим проезд и проживание иногородним кандидатам, которые отлично справились со вступительным заданием.

Отбор в школу проходит на конкурсной основе. Чтобы поступить, нужно подать заявку и справиться со вступительным испытанием до 29 марта 23:59 по московскому времени.

Вступительное испытание состоит из двух частей:

● тестовой — за ограниченное время решить несколько задач на платформе Яндекс.Контест;

● проектной — в зависимости от выбранного направления. Android-разработчикам потребуется создать приложение на Kotlin или Java, а iOS-разработчикам — выполнить задание на выбор: создать игру в консоли на Swift или приложение (если есть возможность использовать Xcode).

Источник

Стажёр-разработ­чик

Москва, Санкт-Петербург, Минск, Новосибирск, Екатеринбург, Нижний Новгород, Сочи

Задачи

Мобильными приложениями Яндекса поль­зуются миллионы людей. Стажёры вно­сят свой вклад в развитие этих продуктов, решая реальные задачи. Это разработка интер­фейсов, проектирование новых воз­мож­ностей и поддержка существующих, анализ производительности приложений и оптими­зация кода. Среди проектов стажёров — развитие инфраструктуры и интерфейса голосового помощника Алисы, обновление встроенного переводчика и загрузчика сло­варей в Яндекс.Клавиатуре.

Что стоит изучить

Больше материалов по ссылке.

Что будет на интервью

Первая беседа пройдёт по скайпу и займёт около часа. Мы предложим простые задачи на знание кода и обсудим платформу iOS или Android — на ваш выбор. Будьте готовы рассказать, с чего начинается разработка приложения, какие есть способы анимации и что происходит, когда пользователь нажимает на экран. Не удивляйтесь, если вас спросят о коллекциях в Swift или Java — так мы проверяем знание тонкостей.

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

Последний этап — секция на знание алгоритмов и структур данных. В одной задаче нужно будет реализовать простой алгоритм. Другая может потребовать знания основных структур данных. На интервью вам точно пригодится знание хеш-таблиц.

Источник

Советы по созданию приложений к окончанию набора в Школу мобильной разработки Яндекса

Уже очень скоро завершится набор в Школу мобильной разработки, которая традиционно пройдет в Москве. Упор в ней будет сделан на практические занятия — командные мини-хакатоны, в которых помимо написания кода нужно будет принимать решения, разбираться с возникшими спорными вопросами и заниматься долгосрочным планированием. Помогать студентам — каждой команде индивидуально — будут ребята из Яндекса. Более подробно о предстоящей школе можно почитать здесь. Мы закончим принимать заявки 6 мая в 23:59 по московскому времени, а пока ещё есть время на выполнение заданий, мы решили разобрать прошлогодний вариант. Вы узнаете, какие ошибки часто допускают начинающие разработчики и чему следует уделить внимание при написании кода вашего первого приложения.

Традиционно задание построено так, чтобы мы могли обратить внимание на разные аспекты разработки. К ним относится архитектура приложения, стабильность, производительность, верстка, удобство использования. Все составляющие одинаково важны: даже идеально причесанный и разложенный на слои код с большой вероятностью не пройдет отбор, если возникнут проблемы в интерфейсе или падения в процессе выполнения базовых пользовательских сценариев. Универсального рецепта приготовления идеального приложения, которое гарантированно пройдёт отбор, нет. Есть множество подходов к разработке и разные варианты построения архитектуры, но одна из составляющих успеха — позитивные пользовательские ощущения. Продукт должен создавать впечатление законченности, независимо от того, сколько в нем полезной функциональности, экранов или элементов.

Содержание

Репозиторий и coding style

Театр начинается с вешалки, а проект — с репозитория.

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

Во время разработки следуйте золотой середине — не стоит коммитить полпроекта за раз, но и множества мелких коммитов по одной-двум строкам стоит избегать. Пишите понятные сообщения к каждому коммиту. Для отдельных фич стоит использовать ветки, чтобы разрабатывать фичи независимо и вcегда иметь актуальную (и работающую) версию приложения в master-ветке. Старайтесь сначала реализовать минимально необходимые фичи и лишь затем — все «красивости» и улучшения. Если вам нужно переключиться на другую ветку и вы не хотите коммитить незавершенный код (но и терять его не хотите), удобно использовать заначки.

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

Вот на что еще стоит обратить внимание:

• хардкод, бесполезный код, закомментированный код,
• лишние вызовы super,
• лишние аннотации,
• отсутствующие аннотации,
• попадание в Release кода, необходимого только в Debug-сборке
• отсутствующий модификатор final,
• длинные методы,
• одинаковые методы,
• unused imports,
• new Something() без присваивания,
• magic numbers,
• копипаста, использование кода, которого вы не понимаете,
• и еще — юзайте lint.

SDK и библиотеки

Использование Android SDK и библиотек часто вызывает вопросы у начинающих разработчиков. Ниже мы перечислим некоторые типичные проблемы и их решения.

Неправильная работа со списками
Использовать LinearLayout + ScrollView для отображения множества однотипных вью — значит совершить ошибку. Такой способ создает нагрузку на память, все вью находятся в ней одновременно. Скролл начинает тормозить. Правильно в таком случае использовать как минимум ListView, а лучше — более продвинутый RecyclerView. Эти контейнеры обеспечивают переиспользование вью (с помощью механизма адаптера). Вью, которые в данный момент не видны пользователю, наполняются свежими данными.

Но и тут можно совершить ошибку. RecyclerView, в отличие от ListView, заставляет разработчика пользоваться паттерном ViewHolder. Как и следует из его названия, этот паттерн состоит в создании класса, объекты которого хранят ссылки на уже найденые в иерархии вью. Не следует вызывать findViewById каждый раз, когда нужно проставить некоторое значение. Нужно сделать это один раз, во время создания холдера.

Сохранение состояния
Ещё одна большая проблема начинающих — сохранение состояния приложения при смене конфигурации (например, когда меняется ориентация, язык, размер экрана и т. д.). Часто бывает, что новички не тестируют такие случаи. Это приводит к недовольству пользователя или даже крешам. Иногда разработчики останавливаются на фиксации ориентации — что, конечно, не спасает. Существует несколько способов поддержать смену конфигурации «из коробки». Не будем углубляться в это, всегда можно почитать документацию. Главное помнить, что такая проблема существует, тестировать, обращать внимание на диалоги (лучше использовать DialogFragment, а не AlertDialog), поскольку они тоже должны восстанавливать состояние. Нужно помнить, что хранить состояние экрана в персистентом хранилище (например, SharedPreferences) не рекомендуется. В итоге «чистый» запуск может привести к уже имеющемуся состоянию, а это не особо идиоматично.

Загрузка данных и кеширование
Ни для кого не секрет, что хождение в сеть на UI-потоке в Android запрещено. Для сети есть множество библиотек, например OkHttp, если у вас REST — добавьте Retrofit, а для загрузки картинок — Glide или Picasso. Таким образом, давно уже не нужно использовать HttpUrlConnection внутри AsyncTask (особенно для загрузки картинок — что на самом деле непросто). Но многие начинающие не задумываются, что, например, чтение и запись в БД — это тоже I/O-операция, которая может сказаться на UX из-за фризов главного потока. То же самое относится к чтению файлов, доступу к ContentProviders. Все подобные операции должны происходить в отдельном потоке. Что для этого использовать — каждый решает сам, описать всё разнообразие решений в этом формате не представляется возможным.

Изменение системного поведения кнопки Back
Часто возникает соблазн повесить туда нестандартную для системы реакцию, в том числе полностью проглотить это событие (обработать, но ничего при этом не сделать). Так вот — лучше не надо. У пользователя этой ОС есть привычки, и Back должна вести на предыдущий экран или приводить к выходу из приложения.

Архитектура

Архитектура Android-приложения часто бывает больным местом даже для опытных разработчиков. В этом разделе мы дадим несколько общих советов. Следовать ли им — решаете вы.

Архитектура и декомпозиция
Отсутствие декомпозиции — признак плохой архитектуры. Платформа не дает четких указаний, как правильно писать приложения, поэтому есть большой соблазн писать весь в код в Activity или Fragment. В итоге такой код становится нетестируемым, тяжело вносить любые изменения. Чтобы этого избежать, можно применять современные архитектурные практики и шаблоны проектирования. Почитайте про MVP, MVVM, MVI. Напишите первые три класса и покройте их тестами. Вы наверняка заметите, что писать тесты сложно и нужно думать над архитектурой.

Перебор с абстракциями
В репозиториях на GitHub часто показывают «каноничную» реализацию той или иной архитектуры. Слепое копирование чужих архитектурных решений может не только не принести пользы, но и усложнить вам работу и ухудшить производительность приложения. Старайтесь не писать бессмысленный код только потому, что так «правильнее» или «чище». Соотносите пользу решения со сложностью его поддержки и понимания в каждом отдельном случае.

Неявные связи между компонентами и нечистые функции
Довольно часто значение некоторой глобальной переменной статически хранится в Application и меняется из разных частей приложения. Поскольку на исполнение, казалось бы, не связанных напрямую частей кода влияет глобальная переменная, в приложении могут возникнуть состояния, которые разработчик не ожидал получить. Самое ужасное — такие баги очень сложно отловить и воспроизвести. Старайтесь писать «чистые» методы и явно указывать зависимости в конструкторах классов или в аргументах методов.

UI (ресурсы, графика, верстка)

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

Качество верстки

Быстродействие в Android довольно сильно зависит от качества верстки. Сложные иерархии контейнеров дольше обсчитываются. Кроме того, при большой вложенности возможны падения во время обсчета и отрисовки (из-за переполнения стека). С появлением ConstraintLayout (и особенно c установкой его корневым элементом xml при создании из визарда) у новичков значительно усложнились иерархии. Чаще используются вложенные Relative/ConstraintLayout, что в корне неверно. ConstraintLayout предназначен как раз для того, чтобы делать иерархию плоской. Рекомендуем прочитать хотя бы введение в документацию. Старайтесь применять этот класс правильно и избегайте излишней вложенности ViewGroup.

Дизайн

Не у всех разработчиков есть навыки дизайнера. Часто в приложении можно увидеть неконсистентную цветовую палитру, которая нравится разработчику, но большинству пользователей — нет. Бывает, что надписи не могут прочесть не только люди с ограниченными возможностями (например, дальтоники), но и остальные пользователи. Стандартная проверка: если надписи видны в grayscale, скорее всего, большинство пользователей тоже их разглядят. Для выбора палитры цветов и общих принципов дизайна можно посмотреть две ссылки: material.io и www.materialpalette.com.

Что еще стоит сделать

Обработка ошибок

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

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

Остановимся немного подробнее на некоторых примерах таких ошибок.

try..catch. everywhere

Такая обработка, как следует из названия, состоит в заключении любого подозрительного (с точки зрения автора) кода в блок try..catch. Под раздачу попадают NPE и IndexOutOfBoundsException, IllegalArgumentException и даже OutOfMemoryError, то есть исключения, которые обычно говорят о логических ошибках в приложении, о состояниях приложения, из которых нельзя адекватно восстановить его работу. Конечно, правильным решением будет исправление логических ошибок. Кроме того, при написании кода на Java можно воспользоваться статическим анализом и проставить, как минимум, аннотации @NonNull и Nullable везде, где нужно. Это поможет отловить NPE.

WeakReference

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

Здесь в конструктор адаптера приходит ссылка на Context. Но адаптер — это часть UI, который показан в некой Activity. Следовательно, он не должен жить дольше, чем Context, а из этого следует, что WeakReference здесь не нужна.

Другой пример исопльзования WeakReference:

С виду ничего не изменилось, но AsyncTask способна пережить Activity, в которой она была создана. Следовательно, использование WeakReference здесь обосновано.

Чтобы избежать утечек памяти, в первую очередь следует понимать, каков жизненный цикл объектов, которые вы используете. Для поиска утечек памяти в существующем большом проекте можно использовать Memory Profiler и LeakCanary.

Отсутствие отмены запросов

Иногда причина ошибок кроется в отсутствии отмены асинхронных операций, сетевых запросов или таймеров. Учитывайте долговременность и периодичность этих операций, обращайте внимание на парные методы API вроде subscribe/unsubscribe, create/destroy, start/cancel.

Тесты

Отсутствие юнит-тестов

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

Каждый из перечисленных пунктов можно оспорить. Начнем с пункта про временные затраты. Возможно, в самом начале написание юнит-тестов будет отнимать много времени, но с опытом скорость будет расти. Кроме того, юнит-тесты — инвестиция в будущее, которая в дальнейшем позволит писать код быстрее. Проблема со скоростью запуска решается еще проще: достаточно один раз настроить Continuous Integration и прогонять тесты автоматически. Если юнит-тесты сложно писать, значит, вы пишете не самый качественный код. Хорошая архитектура облегчает задачу.

Бесполезные тесты

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

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

Тесты зависят друг от друга или от внешних факторов
Зависящие друг от друга тесты сложно поддерживать, так как изменение одного теста влияет на множество других. Кроме того, тестирование становится непредсказуемым, поскольку тесты могут исполняться в разном порядке.

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

Заключение

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

• Внесение исправлений в последнюю минуту без проверки работоспособности.
• Отсутствие или некорректность обработки ошибок в коде.
• Неверная трактовка описания метода API, упущение из виду каких-нибудь особенностей работы или ограничений компонентов платформы.
• Недостаточная внимательность при организации связей между компонентами, при работе со ссылками и при учете жизненного цикла объектов.
• Использование новых непроверенных технологий.

Всем поступающим в школу в этом году и тем, кто разрабатывает свое первое приложение, мы рекомендуем:

• Быть внимательнее и проверять работоспособность приложения даже после внесения безобидных с виду изменений.
• Изучать тонкости языка: принципы работы с объектами в памяти, виды ссылок.
• Использовать статический анализатор кода и дополнительные инструменты вроде LeakCanary.
• Изучать ограничения и особенности работы используемых компонентов платформы и библиотек.
• С осторожностью использовать новые технологии, не успевшие себя зарекомендовать на известных проектах. API или код может быть нестабильным, в сети может не найтись документации или разборов типовых ошибок, ответы на вопросы придется искать самостоятельно.

Полезные ссылки

Cовсем начинающему разработчику, который не написал ни единой строчки для Android, полезно начать свой путь с курсов от Google на Udacity (на английском с русскими субтитрами). Если не бросите курс после первых несколько видео и пройдёте его до конца, то получите не только хорошие теоретические знания, но и первое приложение, которые вы сделали сами!

YouTube-канал Android Developers — просто кладезь коротких обучающих видео и новостей из мира Android-разработки. Советуем посмотреть Android Perfomance Patterns, ведь производительность важна, не так ли?

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

Знакомство с Kotlin лучше всего начать с Kotlin koans — можно получить представления о базовом синтаксисе языка. А видеокурс от Computer Science Center стоит пройти, чтобы подробнее изучить язык, узнать о его плюсах и минусах, понять, почему он реализован именно так. В случае с Java также есть фундаментальный курс от Computer Science Center — теоретические знания подкрепляются с помощью большого количества практических заданий.

Посмотреть на реализации распространнёных архитектур можно в репозитории Android Architecture Blueprints.

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

Источник