готовые коды для андроид студио

Интересные приложения для Android с открытым исходным кодом

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

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

1. Android-приложение с MVP архитектурой

Этот репозиторий содержит приложение, которое реализует архитектуру MVP с использованием Dagger2, GreenDao, RxJava2, Fast-Android-Networking и PlaceholderView.

2. Android-приложение с MVVM архитектурой

Этот репозиторий содержит приложение, которое реализует архитектуру MVVM с использованием Dagger2, GreenDao, RxJava2, Fast-Android-Networking и PlaceholderView.

3. Google I/O Android-приложение

Google I/O — это конференция разработчиков, которая проводится каждый год. На ней представлены сотни демонстраций технологий от разработчиков.

Этот проект — Android-приложение для конференции. Приложение поддерживает устройства под управлением Android 5.0+ и оптимизировано для телефонов и планшетов всех форм и размеров.

4. Чертежи архитектуры Google Android

Платформа Android обладает большой гибкостью, когда организует и архивирует приложение. Эта свобода может привести к приложениям с большими классами. Это может затруднить тестирование, поддержку и расширение.

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

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

5. Telegram

Telegram — это приложение для обмена сообщениями с акцентом на скорость и безопасность. Этот мессенджер супер быстрый, простой и бесплатный. Данный репозиторий содержит официальный исходный код андроид-приложения для Telegram.

6. Plaid

Приложение под Android, которое способно вдохновить своим дизайном, благодаря отличной реализации material design.

7. Wire

Это приложение чата полно картин, фильмов, GIF, музыки, эскизов и других форм мультимедиа. Также оно всегда обеспечивает безопасное сквозное шифрование.

8. Андроид-приложение ribot

Официальное приложение ribot для Android, в котором реализованы архитектура, инструменты и рекомендации, которые команда поддерживает для платформы Android.

9. Kickstarter

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

10. PocketHub

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

11. Простое андроид-приложение с MVP

Очень простое приложение, показывающее, как реализовать архитектуру MVP.

Источник

Готовые коды для андроид студио

This is a collection of Android Apps which are open source.
I believe that we can find something interesting and gain helpful skills from an open source app.
This idea comes from this project

I’ll push awesome projects when I find any.
It’s WELCOMED for you to star and fork this project.
If you know something that is not here, it’ll be great if you could make a Pull Request.
All applications are sorted in various categories.

Like this project? Why not share to your friend 🙂

Источник

Готовые коды для андроид студио

14 Способов сделать вклад в открытое программное обеспечение, не будучи Гениальным Программистом или Рок-Звездой

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

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

«Я не очень хороший программист.»
«Я не смогу выделять достаточно времени.»
«Я не знаю к какому проекту подключится.»

Существует 3 основных принципа, которые следует помнить, если вы ищете возможность внести свой вклад:

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

Среди новичков самая разрушительная мысль которую я наблюдал — мнение что для вклада в open source ты должен быть гениальным разработчиком. Это не так! Конечно, есть некоторые «рок-звёзды» в open source и они даже могут быть гениальными программистами. Тем не менее, подавляющее большинство таковыми не являются! Мы просто люди которые делают своё дело. Иногда мало, иногда много. Иногда это программирование, а иногда и нет.

Большинство из того, что делает open source это работа и время потраченное на проект. Большинство таких вещей не требуют интеллекта или взгляда как у Ларри Уолла, создателя Perl’а, или Давида Ханссона, создателя Rails. Для разработки нового языка программирования или web-фреймворка вдохновение надо, но остальное, что делает проекты уровня Perl и Rails успешными — тяжкий труд. За это вы, возможно, и не получите славу, но всё равно необходимо и через какое-то время ваш вклад будет замечен.

Прислушайтесь к другим

Всё в open source включает себя других людей. Желание присоединиться к команде значит, что ты понимаешь сообщество проекта и как в нём всё крутится. Прогулка в проект со словами «Привет! Я думаю что делать следует вот так.», как правило, не расценивается хорошим тоном. Некоторые проекты может и приветствуют такого рода подход, но если проект уже устоявшийся, такой подход имеет мало шансов на успех. Слушать — это лучший способ узнать в чём проект нуждается.

Списки рассылок: Для многих проектов, списки рассылок являются основным каналом связи по разработке проекта. У больших проектов есть много рассылок и есть из чего выбрать. К примеру, для PostgreSQL существует не менее 12 рассылок для пользователей и 6 для разработчиков. Я предлагаю подключится к основной рассылке как для пользователей, так и для разработчиков, чтобы начать слушать.

Подпишитесь на блог: Блоги которые ведут основные разработчики часто полны информацией про будущие релизы. Существуют агрегаторы новостей и блогозаписей проекта. Если такой сайт есть, к примеру planet.gnome.org или planet.mysql.com, начните оттуда. Попробуйте поискать в Google «planet ».

Подключитесь к IRC каналу: Многие open source проекты имею IRC-каналы где разработчики и пользователи зависают для обсуждения разработки и решения проблем. Посмотрите на странице проекты как называется канал и в какой сети IRC он находится. (прим. перев. Как показывает практика самой популярной сетью есть Freenode, а потом — собственные серверы проектов. Не редки случаи запуска собственных серверов Jabber и конференций.)

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

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

Диагностика ошибок: Ошибки часто имеют плохое описание. Диагностика и сортировка ошибок сильно помогут разработчикам (даже более того, сэкономят им время) в определении в чём же действительно проблема. Если пользователь сообщает, что «Приложение не работает когда я делаю X», потратьте немного время что бы уточнить что именно идёт не так. Ошибку можно воспроизвести? Можно сделать пошаговый мануал по проблеме? Можно ли сузить проблему: воспроизводится только в одном браузере, работает только в некоторых дистрибутивах? Если да, то в каких?

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

Закрывайте исправленные тикеты: Часто в коде ошибки уже исправлены, но запись в bug-трекере ещё есть. Зачистка этого «хлама» может занять уйму времени, но принесёт неоценимый вклад для всего проекта.

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

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

Программисты с любым уровнем знаний и опытом могут помочь проекту. Не думайте что надо быть настоящим гением для существенного вклада в проект.

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

К примеру для PostgreSQL процесс очень строгий: модификации кода, в виде заплатки, отправляются в список рассылок разработчикам, где они изучают каждый аспект изменений. С другой стороны, есть проекты, такие как Parrot, в которых очень просто получить привилегию делать commit в основную ветку кода. Если проект использует GitHub, вероятно рабочий процесс основан на системе pull-запросов. Нет двух одинаковых проектов!

Всякий раз когда вы изменяете код, следите что бы вы действовали как ответственный участник сообщества и ваш код соответствовал стилю всего остального проекта. Добавленный или изменённый вами код не должен отличаться от остального! Вам может и не нравится использование текущего стиля скобок или пробелов для создания отступов, но это грубо когда вы добавляете код, который не соответствует стандарту. Это тоже самое: «Мне не нравится ваш стиль, мой лучше, делайте как я.»

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

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

Исправляйте ошибки: Это, как правило, путь для людей которые хотят сразу влиться в код. Тут всё просто: ищем интересную ошибку в bug-трекере и исправляем её в коде. Документируем исправления в коде, если это принято.

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

Пишите тесты: Большинство проектов имеют наборы тестов, но сложно себе представить такой набор, в котором больше нечего тестировать. Используйте такие инструменты для исследования покрытия кода как gcov для C или Devel::Cover для Perl. А затем, добавьте тесты для улучшения покрытия.

Заставьте замолчать компилятор: Процесс сборки для проектом на C часто сопровождается странными предупреждениями компилятора. Эти предупреждения редко показывают на реальную проблему, но они могут так выглядеть! Да и слишком много предупреждений делает компилятор похожим на ноющего ребёнка.

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

Добавьте комментарии: Если вы копаетесь в чужом коде, вы часто находите места которые вас сбивают с толку. Если даже вас он сбивает, то какие чувства у остальных на этом месте? Сделайте полезный комментарий и отправьте заплатку.

Работа с документацией

Документация это важная часть любого проекта. Она может страдать от того, что была написана с точки зрения человека знакомого с проектом, а не глазами человека, который только хочет туда попасть. Если вы когда-то читали документацию с мыслью «Он что, думает что я знаю как это делать?» то вы понимаете о чём я говорю. Свежий взгляд всегда благотворно влияет на документацию и указывает на недостатки, которые остальные уже не замечают.

Создавайте примеры: Нет ни одного проекта в котором достаточно примеров. Web-API, библиотеки, графические приложения (такие как, GIMP) или командные утилиты, для всех них хороший пример лучше покажет использование, чем сухая документация.

Для API или библиотеки не лишним будет написать приложение которое её использует. Это могут быть даже куски ранее написанного кода с отсечением всего ненужного. Живой пример использования в повседневной жизни также будет не лишним! Если приложение графическое — рассмотрите создание скрин-каста разных процессов.

Работа с сообществом

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

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

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

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

В конце-концов. Прежде всего, слушайте о чём люди говорят. Смотрите, возможно именно тут вы можете чем-то помочь. Например, недавно в рассылке проекта Parrot было решено использовать GitHub и их систему bug-трекера взамен старого Trac. Некоторые люди были против — не было способа перенести всю старую базу Trac на новую платформу. После целого дня споров, я влез и сказал: «А что если я напишу преобразователь?». Люди пришли в восторг от моей идеи! Я потратил время, чтобы написать программу для преобразования 450+ тикетов. Ведь в противном случае была б потеряна история. Это был успех! Я взялся за дело, а в это время основные разработчики оставались сосредоточены на развитии Parrot.

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

Источник

Пишем MVP приложение на Kotlin под Android

Разработка приложений на Kotlin под Android набирает популярность среди разработчиков, однако статей в русскоязычном сегменте Интернета довольно мало. Я решил немного подправить ситуацию, и написать туториал по разработке приложения на Kotlin. Мы напишем полноценное приложение с использованием всех трендовых библиотек (кроме RxJava) в мире Android-разработки. В конце у нас должно получиться расширяемое и легко тестируемое приложение (сами тесты мы писать не будем).

Внимание! В статье описывается создание приложения версии 1.0. Текущий код в репозитории может отличаться от описываемого в статье.

Наверное, некоторые из вас знают, что помимо языка программирования Kotlin JetBrains также разрабатывает библиотеку Anko, для создания UI приложения, в качестве замены обычным XML-файлам. Мы не будем использовать его в нашем проекте, дабы не ставить в затруднительное положение людей не знакомых с Anko.

Настройка Android Studio

Для написания приложений на языке Kotlin, Android Studio нужен специальный плагин. Инструкцию по установке плагина можно найти здесь. Также не забудьте отключить функцию «Instant Run» в настройках Android Studio, т. к. на данный момент она не поддерживается плагином Kotlin.

Для корректной работы генерации кода нужно использовать версию плагина не ниже 1.0.1. Я использовал версию Kotlin 1.0.2 EAP. Вот так выглядит файл build.gradle приложения в моем проекте:

Что будем писать?

Итак, для начала нам нужно определиться что же мы будем писать? Недолго думая я остановился на приложении-заметках. Название тоже придумалось легко — Notelin. Приложение очень простое и состоит из двух экранов:

— Главный экран — содержит в себе список с заметками
— Экран заметки — здесь можно смотреть/редактировать содержание выбранной заметки

Требования к приложению небольшие:

— Добавление/просмотр/удаление заметки
— Просмотр информации о заметке
— Сортировка заметок по заголовку и по дате
— Поиск по заголовкам заметок

Используемые библиотеки

Для работы с базой данных я буду использовать библиотеку Android Active. Урок по работе с ней можно найти по этой ссылке. Для реализации Depency Injection была использована библиотека Dagger 2. На Хабре есть много статей по работе с ней. Основой всего приложения будет библиотека Moxy. С ее помощью мы реализуем паттерн MVP в нашем проекте. Она полностью решает проблемы жизненного цикла, благодаря чему вы можете не переживать о пересоздании компонентов вашего приложения. Также мы воспользуемся набором расширений для языка Kotlin в Android — KAndroid. Про остальные библиотеки я буду рассказывать по ходу дела.

Ниже приведен список зависимостей проекта:

А вот так выглядит список зависимостей приложения:

Обратите внимание, что вместо apt я использую kapt. Это плагин для Gradle, позволяющий аннотировать Kotlin-элементы.

Структура приложения

Вот так выглядит структура нашего проекта в конечном варианте:

Создаем Model

У заметок будет четыре поля:

Реализуем все это в коде:

По этой модели библиотекой ActiveAndroid будет создана БД, в которой будут храниться наши заметки. Если вы заметили, у нас есть два конструктора: пустой и с параметрами. Первый конструктор будем использовать мы, а второй — ActiveAndroid. Наша модель наследуется от класса Model, благодаря чему мы можем сохранять и удалять наши заметки просто вызывая методы save() и delete(), например:

Но прежде чем использовать нашу модель, нам нужно прописать кое-какие мета-данные в Manifest-файле:

Думаю, все понятно без комментариев. Осталось унаследовать класс Application от com.activeandroid.app.Application:

Чтобы приложение было менее зависимо от БД я создал обертку NoteDao над нашей моделью, в которой будут происходить все операции по созданию, сохранению, обновлению и удалению заметок:

Наверное, вы заметили, что для создания объектов мы не использовали ключевое слово new — это отличие Kotlin от Java.

Экран с заметками

Также является главным экраном приложения. На нем пользователь может добавить/удалить заметку, просмотреть информацию о заметке, отсортировать их по дате или названию, а также произвести поиск по заголовкам.

Создаем MainView и MainPresenter

Теперь нам нужно перевести все это в код. Для начала создадим интерфейс нашей View:

Далее мы реализуем созданный интерфейс в нашей активити:

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

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

Пока оставим методы пустыми. Как видите, активити наследуется от MvpAppCompatActivity. Это нужно для того, чтобы активити могла восстанавливать состояние при повороте экрана.

Создадим класс презентер:

Презентер также наследуется от MvpPresenter, которому мы указываем с какой View мы будем работать.Осталось инжектировать нашу модель в презентер. Для этого мы создаем модуль — поставщика NoteDao:

Создадим Component для инжектирования презентера:

Теперь нам нужно создать статический экземпляр класса AppComponent в классе Application:

Теперь мы можем инжектировать нашу модель в презентере:

Для взаимодействия MainView и MainPresenter нам нужно создать переменную в MainActivity:

Плагин Moxy сам привяжет View к фрагменту и произведет другие необходимые действия.

Создадим разметку экрана со списком и плавающей кнопкой. Файл activity_main.xml:

Для реализации летающей кнопки я использовал библиотеку FloatingActionButton. Google уже добавили FAB в support-библиотеку, поэтому вы можете воспользоваться их решением.

Укажем нашей Activity, какой макет она должна показывать:

Далее нам нужно связать FAB и список, чтобы при прокручивании списка вверх кнопка исчезала:

Нам не нужно писать порядком надоевший findViewById, нужно лишь прописать одну строчку в блоке с import’ами:

Как видите, последний пакет совпадает с названием нашего xml-файла. IDE автоматически инициализирует свойства (property) наших View и их имена совпадают с ID, которые мы указали в разметке.

Давайте реализуем загрузку заметок из БД. Заметки нужно загружать только один раз и использовать их в последующем. В этом нам поможет метод onFirstViewAttach класса MvpPresenter, который вызывается единожды при первой привязке View к презентеру. Далее, сколько бы мы не крутили и вертели нашу Activity, данные будут закешированы в презентере.

Создадим адаптер для нашего списка:

В адаптере мы используем метод formatDate. Он служит для форматирования даты в строку:

Данный метод находится в файле DateUtils.kt и мы можем использовать как обычный статический метод. Отличие от статического метода здесь в том, что метод принадлежит не классу, а пакету и нам не нужно писать имя класса перед названием метода. В аннотации мы указываем название класса, через который мы будем обращаться к методу из Java. Например в Java дынный метод будет вызываться так:

В методе onNotesLoaded нашей Activity мы показываем наши заметки:

Если заметок нет, то мы показываем сообщение «Нет заметок» в TextView.

Насколько я знаю, для обработки клика по элементам RecycleView не существует «официального» OnItemClickListener. Поэтому мы воспользуемся своим решением:

В методе onCreate нашей Activity пишем:

Функция with позволяет не писать каждый раз имя переменной, а только лишь вызывать методы у объекта, который мы передали в нее. Обратите внимание, что для получения Activity я использовал не просто this, а this@MainActivity. Это связано с тем, что при использовании this в блоке with, возвращается объект, который мы передали в функцию with. При обычном клике по пункту мы переходим на Activity, где мы можем просмотреть текст нашей заметки. При долгом нажатии появляется контекстное меню. Если вы заметили, перед закрывающей скобкой я не написал слово return. Это не ошибка, а особенность языка Kotlin.

Вот что происходит при нажатии на пункт меню в презентере:

Мы еще не создали класс NoteActivity, поэтому компилятор будет выдавать ошибку. Для решения этой проблемы можно создать класс NoteActivity или вовсе закомментировать код внутри метода openNote. Запись NoteActivity::class.java аналогична NoteActivity.class в Java. Также заметьте, что мы обращаемся к списку не через метод get(position), а через квадратные скобки, как к обычному массиву.

При использовании MVP-библиотеки Moxy в своем приложении, нам нужно привыкать, что все действия с View, такие как показ/закрытие диалога и другие, должны проходить через презентер. Изначально это не очень привычно и неудобно, но пользы от этого гораздо больше, т. к. мы можем быть уверены, что при пересоздании Activity наше диалоговое окно никуда не пропадет.

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

При нажатии на FAB должна создаваться новая заметка:

Для создания новой заметки мы вызываем у презентера функция openNewNote:

Метод openNewNote использует созданный нами ранее openNote, в который мы передаем Context и позицию заметки в списке.

Реализуем поиск по заметкам

Давайте добавим поиск по заметкам. Создайте в папке res/menu файл main.xml:

В MainActivity пишем:

При изменении текста в поле поиска мы передаем строку из поля в презентер, после чего показываем результаты в списке. На самом деле, у SearchView нет метода onQueryChange, его добавила библиотека KAndroid.

Реализуем поиск в презентере:

Обратите внимание, как красиво, в одну строчку мы реализовали поиск по списку с помощью метода filter и лямбд. В Java тот же функционал занял бы 6-7строк. Осталось отобразить результаты поиска:

Реализуем сортировку заметок

И последний этап в создании главного экрана, это сортировка заметок. Добавим в res/menu/main.xml следующие строки:

Теперь нам нужно обработать нажатие на пункты меню:

Оператор when является более функциональным аналогом switch-case в Java. Код сортировки в MainPresenter:

Экран с содержанием заметки

Теперь нам нужно создать экран с содержанием заметки. Здесь пользователь может просмотреть/отредактировать заголовок и текст заметки, сохранить или удалить ее, а также просмотреть информацию о заметке.

Создаем NoteView и NotePresenter

Экран содержит всего лишь три View:

-Заголовок
-Дата последнего изменения
-Текст заметки

А вот и сама разметка:

В начале статьи я мельком упомянул об Anko. Библиотека позволяет существенно сократить код, не теряя при этом в удобочитаемости. Вот так, например, выглядела бы наша разметка при использовании Anko:

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

Имплементируем NoteView в NoteActivity:

В onCreate мы извлекаем id заметки, чтобы презентер достал заметку из БД и передал данные во View. Создадим презентер:

Не забудьте добавить в класс AppComponent строку:

Покажем нашу заметку:

Реализуем сохранение заметки

Для сохранения заметки нам нужно выбрать соответствующий пункт в меню. Создайте файл res/menu/note.xml:

Опять же, я не стал приводить код удаления и вывода информации о заметке. При просмотре исходного кода, вы можете заметить, что помимо идентификатора заметки я передал в NoteActivity позицию заметки в списке. Это нужно для того, чтобы при удалении заметки на экране просмотра заметки, она также удалялась из списка. Для реализации этого функционала я использовал EventBus. И опять, я не стал приводить код.

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

Благодарности

Конечно же, нельзя забывать о людях, которые помогли мне при написании статьи. Хотел бы выразить благодарность хабраюзерам Юрию Шмакову (@senneco) за помощь с его библиотекой Moxy и за помощь по другим вопросам. Также, хочу сказать спаcибо сотруднику JetBrains Роману Белову (@belovrv) за ревью статьи и за предоставленный код на Anko.

UPD: Еще хотел сказать спасибо Sirikid за EPIC COMMIT, благодаря которому я переделал внушительную часть кода с использованием фич Kotlin’а.

Заключение

Надеюсь, эта статья смогла убедить вас в том, что писать приложения на Kotlin не трудно, а может даже и легче, чем на Java. Конечно же, могут встречаться и баги, которые сотрудники JetBrains достаточно быстро фиксят. Если у вас появились какие-либо вопросы, вы можете задать их напрямую разработчикам на Slack-канале. Также вы можете почитать статьи о разработке на Kotlin здесь.

Источник