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

Часть UI

Это общее представление, пока нет GIF-анимации для отдельных частей. Давайте рассмотрим реализацию.

Часть вступления

Вступительная часть использует VerticalViewPager, который получен путем модификации ViewPager из пакета v4. Методы использования такие же. Заслуживает внимания вставка фрагмента на начальной странице, что позволяет разделить вступление и начальную страницу, а также оставляет место для будущей вставки рекламы.

Кнопка в конце части использует анимацию.

Основная страница

Основная страница состоит из 4 фрагментов, и переход между ними осуществляется через hide, а не replace. Это гарантирует быстрое переключение между четырьмя основными страницами. В отличие от календаря 365 дней, два из этих четырёх фрагментов совпадают с ним, а именно календарь и страница настроек. Другие два фрагмента требуют взаимодействия с сервером и будут использовать трекинг и шагомер в качестве замены. На данный момент реализована функция определения местоположения

Страница настроек

Использует метод размещения из календаря 365 дней, который был переработан в коде. Это хорошая практика.## Календарная визуализация

Календарная визуализация является самой сложной частью пользовательского интерфейса (UI) в приложении. Здесь используется подход дизайна календаря на 365 дней, хотя конкретная реализация несколько отличается.

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

Все редактируемые страницы

Все редактируемые страницы находятся в одном AllEditActivity, а уникальные размещения являются фрагментами. Чтобы обеспечить передачу значений между Activity, используется механизм рефлексии Java, что позволяет избежать необходимости конфигурации в манифесте, а также позволяет использовать общие компоненты, что значительно уменьшает объем кода.

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

Пользовательские диалоговые окна и Picker

Диалоговые окна используют sweet-alert-dialog.Time-picker использует прокручиваемый выбор в стиле iOS, три типа Picker используются в DialogFragment, что позволяет использовать их в горизонтальном режиме. Эти компоненты могут быть извлечены и использованы как отдельные элементы управления.Стили выбора диалоговых окон также основаны на iOS, но размещение основано на QQ. Эти элементы управления также могут быть использованы как отдельные компоненты. Всплывающие диалоги снизу основаны на базовом классе DialogFragmentBase, который содержит общие методы и общие макеты.

Полная реализация MVP и соответствующие ей unit-тесты

В проекте для всех разделов пользовательского интерфейса, требующих unit-тестирования, используется подход MVP. Также в проекте используется фреймворк для unit-тестирования Roboletric.

Важность unit-тестирования для продукта не подлежит сомнению, однако из-за специфики unit-тестирования активностей в Android это может быть сложной задачей. Метод MVP является одним из наиболее популярных подходов. Для тех, кто не знаком с MVP, рекомендуется ознакомиться с этим подходом, чтобы лучше понять структуру проекта.

Фреймворк для unit-тестирования использует Roboletric, который прост в использовании и заслуживает внимания.

ВниманиеВ проекте используется локализация от Baidu, и настроена служба локализации. Однако функция загрузки не была добавлена. Эта служба локализации предназначена для личных нужд, так как приложение разработано для удовлетворения личных требований. Для тех, кто заинтересован в этой службе, рекомендуется оставить её при сборке. Для тех, кто не нуждается в ней, рекомендуется самостоятельно изменить конфигурацию. В этом месте сделано упоминание, чтобы избежать недоразумений.# Другое

Регулярное обслуживание календаря основывается на встроенных функциях управления календарем в Android.

Недостатки

• В управлении событиями в настоящее время не реализован просмотр фотографий и получение адреса при создании нового события.
• Анимация прокрутки календаря выглядит жесткой (может быть улучшена путем изменения времени анимации и других параметров).
• Важная информация повторяется трижды: этот проект является результатом декомпиляции исходного кода и не должен использоваться для коммерческих целей.
• Этот README был создан с помощью org-mode, и здесь также рекомендуется использовать emacs -_-;