Задачи по android разработке

Ш кодим под Android

Спасибо всем, кто поддержал сайт в прошлом месяце своими пожертвованиями.

Изучаем Android. Первый курс

День 1. Подготовка

Инструменты для разработки под Android. Среда разработки — Android Studio

День 2. Hello Kitty!

Пишем первое приложение для Android Hello Kitty! Поздоровайся с котом

День 3. Щелчок

Щёлчкаем кнопки и пишем полезную программу для подсчёта ворон

День 4. Смена цветов

Управляем фоновым цветом экрана — Светофор

День 5. Наташ, ты спишь?

Создадим интерактивный мем с вечно спящей Наташей

День 6. На другой экран

Часто приложение состоит из нескольких экранов. Как переключаться между ними?

День 7. Ориентация

Телефоны можно вращать — узнаем, как писать программы для подобных случаев

День 8. Темы и стили

Чтобы приложение было стильным, можно применить специальные приёмы

День 9. Toast (Kotlin)

Выводим всплывающие сообщения для привлечения внимания

День 10. Шаблон «Basic Activity»

Базовый пример с применением разных компонентов

День 11. Меню

Мы научимся создавать меню для вызова различных команд

День 12. PopupMenu

Продолжим работу с меню и познакомимся с всплывающим меню

День 13. Экран

Настройки экрана устройства

День 14. Уведомления

Выводим уведомления, которые не исчезнут, пока сам пользователь не закроет их

День 15. Конвертер

Напишем универсальную программу перевода одних единиц в другие — Конвертер «38 попугаев»

День 16. Кто сказал Мяу?

Используем звуковые эффекты, чтобы привлечь внимание

День 17. Графика

Рассмотрим приёмы работы с графикой. У нас есть отдельная категория для графики

День 18. Анимация

Android имеет богатые возможности работы с анимацией

День 19. Браузер

Создадим свой браузер внутри своего приложения

День 20. Клавиатура

Изучаем возможности клавиатуры и аппаратных кнопок

День 21. Локализация

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

День 22. Жизненный цикл активности

Приложение живёт своей жизнью.

День 23. Справочник

Напишем справочник. Полезная информация всегда в цене

День 24. Камера

Чтобы сфотографировать котика, нужно уметь обращаться с камерой

День 25. Настройки

Иногда необходимо сохранять настройки — имена, рекорды, результаты игры и т.п.

День 26. Экран настроек

Создаём экраны настроек, используя готовые шаблоны

День 27. Блокнот

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

День 28. Карты и StreetView

Запускаем Карты Google и Просмотр улиц для поиска котов

День 29. Шаблон Google Maps Activity

Интегрируем карты Google в приложение

День 30. Broadcast

Отправляем и принимаем широковещательные сообщения

День 31. Фрагменты

Создаём модульные компоненты для разных типов экранов

День 32. AlertDialog

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

День 33. RecyclerView

Универсальные списки для отображения имён котов

День 34. База данных

Современное программирование не может обойтись без базы данных

День 35. Публикация

Публикуем программу в Google Play, чтобы заработать свой первый миллион

Дополнительные уроки

Второй курс (закрытая зона)

Люди, не пишите в письме » Доброго времени суток «. Пишите просто — «Здравствуйте» или «Добрый день (утро, вечер)». Обещаю, что не обижусь, если утром прочитаю ваше письмо со словами «Добрый вечер!». Уважайте русский язык.

Третий курс (закрытая зона)

Четвёртый курс (закрытая зона)

5-й, 6-й, 7-й курс и т.д. (закрытая зона)

Отзывы

Большое спасибо Вам и вашего кота! Я уверен, что много людей благодарят Вам и, наверное это надоело. Я начинающий в Андроид и мне ваш кот очень помог. Никола, Болгария (орфография сохранена)

Источник

Идеальное (наверное) собеседование мобильного разработчика-мидла

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

Диспозиция

Маленькая продуктовая команда (30-40 человек) внутри крупной компании (несколько тысяч человек). В команду входят все, кто занимается проектом: фуллстек разработчики и фронтедеры, дизайнеры и интерфейсологи, тестировщики, спецы по пиару, аналитики, авторы текстов и т.п. В общем, мы стараемся поменьше аутсорсить профильную работу в другие проекты, и мобильная разработка — не исключение.

Мобильное приложение у нас кроссплатформенное, написано на Xamarin Native под iOS и Android. При этом мы полностью готовы брать в меру опытного разработчика, писавшего только под одну платформу, при условии, что он готов изучать разработку под вторую ОС.

Этап 0 — встретились два одиночества

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

Эти вопросы — минимальный фильтр на адекватность, никаких технических вопросов не будет. Дальше резюме и ответы передаются уже разработчику со стороны нанимателя, и тот принимает решение, идём дальше или нет. За последний месяц я посмотрел пару десятков резюме, и понятия не имею, что должен написать и ответить кандидат, чтобы мне пришлось сказать «нет» уже на этом этапе. Написать на вакансию Android-разработчика «пишу только под iOS, потому что Android – полный отстой»?

Этап 1 — тестовое задание или пример кода

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

• три экрана: два связанных списка + форма ввода данных, которую при желании можно заменить на модальное окно
• работа с сетью
• работа с хранилищем данных (задание подразумевает БД, если разработчик сможет обосновать другой вывод — милости просим)

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

• приложение слишком маленькое, код не показателен или вызывает слишком много вопросов просим таки сделать наше тестовое
• приложение подходящее, но есть нюансы — просим сделать небольшие доработки (меньше чем на вечер)

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

• кандидат получает код, который потом можно переиспользовать на другом собеседовании с подобными принципами, а также обратную связь для работы над собой. Работает ли оно? Ну, как минимум к нам присылали тестовые задания, изначально написанные для других компаний, так что похоже, что работает;
• работодатель экономит время на опросниках и прочей фигне. А уж как радуется собеседующий-интроверт, которому не нужно проводить по 1-2 собеседованию в неделю, если б вы только знали!

Этап 2 — собеседование

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

Далее будет 1-2 небольшие практические задачки, они зависят от тестового задания. Опять таки даём в руки клавиатуру (подключенную к компьютеру, компьютер с монитором!) и просим что-нибудь написать или отредактировать. Одна из моих любимых вещей — дать рабочую, но плохо написанную функцию строчек на 10-20 и предложить её отрефакторить. Сразу становится понятно, есть ли у кандидата чуйка на «плохой код», что он знает о конструкциях языка, умеет ли читать чужой код и далее по списку.

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

Но ведь кандидат мог и обмануть

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

Так, стоп! Я узнал команду, о которой идёт речь, собеседовался в неё пару лет назад, и там схема сильно отличалась

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

Но я и в компанию узнал! Устраивался в другой проект, и там тоже всё не так!

А вот тут ситуация с хитринкой. К нам в компанию идёт приличный поток бэкендеров/фулл-стек разработчиков, и таких разработчиков в компании несколько сотен. Поэтому процесс их набора уже достаточно устаканился и стандартизировался. Мобильных же разработчиков в компании пока что мало, так что нам легче экспериментировать с подходами к собеседованиею.

Источник

Примеры тестовых заданий для Android и iOS

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

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

Задача 1. Приложение «Погода»

На 1-м экране (отображение) должно быть:

1. Возможность выбрать город (3-4 города)
2. Возможность выбрать сезон года
3. В зависимости от п.1 и п.2 — отображение средней температуры за сезон в городе
4. В зависимости от п.1 — отображать тип города (малый, средний, большой)

На 2-м экране (настройки) должно быть:

1. Управление списком городов (город, тип)
2. Управление температурой по месяцам

Приложение на первом экране должно отображать информацию, введенную пользователем на втором экране. Например, на втором экране вводим: город «Минск», тип «средний», температура июнь «23», июль «28», август «25». На первом экране в списке городов, должен отобразится Минск, тип «средний» и температура за сезон «лето» = 25,3 (среднее арифметическое 3-х месяцев).

Обязательно использовать паттерны:

• Lazy singleton
• Factory: получать тип города в зависимости от его названия
• Decorator: При запросе средней температуры за сезон в городе — должна быть возможность получить строку для логирования
• Observer: Дополнительно выводить сообщение, о температуре, через Snackbar
• Strategy: В зависимости от стратегии — выводить температуру в необходимом формате (градус Цельсия, градус Фаренгейта, Кельвин)

Условия:

• Без использования сети
• БД: SQLite
• Мы ожидаем выполнения задания без применения сторонних библиотек, кроме официальных (таких как AndroidX, Android Architectural Components, CoreData и т.д.)
• Результат выложить на Github.com

Задача 2. Репозитории GitHub

1. При помощи GitHub API отобразить список репозиториев у организации xxx (github.com/xxx)
2. Дизайн — полностью на ваше усмотрение
3. Код разместить на GitHub и прислать нам ссылку

Обязательно:

• Код на Kotlin/Swift
• Задействовать RxJava/RxSwift
• Покрыть юнит-тестами (UI не стоит)

Желательно:

• Обработка сетевых ошибок
• Поиск репозиториев в рамках организации по названию (просто фильтр списка подойдёт)
• MVI, MVVM, MVP — на ваше усмотрение, будет интересно посмотреть, но лучше без сторонних библиотек

Задача 3. Пользователи GitHub

Главный экран:

1. Users (список всех Github пользователей). Использовать API https://developer.github.com/v3/users/#get-all-users
2. В элементе списка отрисовать avatar, login (title), id (subtitle)
3. По нажатию на элемент списка реализовать переход на UserDetails
4. Реализовать pagination и Pull-to-refresh

UserDetails (экран с информацией о пользователе):

1. Использовать API https://developer.github.com/v3/users/#get-a-single-user
2. Поля: Avatar, Name, Email, Organization (если есть), Following count, Followers count, Дата создания аккаунта

Требования:

• Структурированный код (архитектурный паттерн на усмотрение кандидата)
• Язык Java/Kotlin/Swift
• Код поместить в репозиторий на GitHub/Bitbucket/GitLab
• Неоднозначности задания трактуются на усмотрение разработчика

Задача 4. Приложение «Вечеринка»

На экране располагаются:

1. Картинка (загружается по URL)
2. Название вечеринки
3. Имя пригласившего
4. Фото пригласившего (извлекается по URL)
5. Список гостей с фото, которые идут вместе с текущим пользователем. Фото загружаются по URL

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

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

Задача 5. Приложение из 1-го экрана

1. Необходимо создать приложение состоящее из 1 экрана
2. Реализовать данное задание с применением RxJava/RxSwift, любого DI (например Dagger 2) и MVP.

Реализовать:

• База данных 5 полей и заполнить любыми данными
• Вывод в активити или фрагмент в виде списка
• Live search по базе данных
• Реализовать сортировку, любой параметр

Задача 6. Приложение «Авто»

Приложение, должно иметь следующие функции:

1. Отображение списка автомобилей с характеристиками (10-12 автомобилей, 3 производителя, 1-3 марки у каждого производителя)
2. Добавление нового автомобиля
3. Редактирование деталей автомобиля

Желательно:

• Фильтрация по производителю и марке
• Сортировка по цене

Задача 7. Проверка адреса email

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

Требования:

1. Проверка формата электронной почты. Пример: [email protected] не является действительным адресом электронной почты
2. Пользовательский интерфейс должен показывать, действителен или нет адрес электронной почты. При необходимости интерфейс должен указать, что не так с адресом
3. Автозаполнение и проверка доступности домена. Пользователи часто опечатываются при вводе адреса. Например, указывают неправильно доменное имя (gmail.con вместо gmail.com)
4. Проверка пароля. Нет ограничения на вводимые символы. Есть ограничение минимальной и максимальной длины
5. При необходимости, интерфейс должен указать, что неправильно
6. Проверить, что заполнены все поля, и указать, какое именно не заполнено

Для автозаполнения необходимо:

• Проверить существование введённого домена
• Указать, что неправильно в введённом имени
• Предложить Автозаполнение доменного имени самыми вероятными и популярными доменными именами. Пример: если пользователь вводит «[email protected]», то продолжениями могут быть «[email protected]», «[email protected]» и т.д. Если пользователь уточняет «[email protected]», то продолжениями могут быть популярные домены, начинающиеся с «g». Например: «[email protected]», «[email protected]»

Источник