TimePlanner, an Android day planner built as a timeline rather than a list

A planner whose main screen is a day as a timeline

Most task apps show a list. TimePlanner's central idea is different: the day is drawn as a timeline, with tasks placed on it at their real start and end times, and the app keeps two views of the same data, an agenda and a timeline.

The task model supports exact start and end times, and the app prevents overlapping tasks before they are saved, which is a real constraint rather than a display detail. Tasks with no fixed time are not lost; they sit in a dedicated inbox and can be converted into scheduled tasks once the time is known. Once scheduled, tasks can be moved, resized, edited, completed and reorganised across the day, and each one carries a main category, subcategory, priority, notes and its own statistics settings.

The schedule is per date, so there is no notion of one repeating template view of your week. You get a separate schedule for every date, and the timeline is the tool for arranging that day. For anyone coming from a list-based planner, that is the change to get used to, and it is the reason the app ships with both views rather than one.

Templates that generate linked occurrences and skip conflicts

Recurring work is handled through templates rather than through a repeat flag on a task. A template can repeat by weekday, by the N-th weekday of a month, by day of the month, or on an annual date, and upcoming schedules are generated automatically from it.

Two details decide whether this is pleasant or maddening in practice. Generated tasks stay linked to their source template until they are manually detached, so editing the template can propagate to the occurrences while the link holds. And occurrences that would conflict with an existing task are skipped, so the generator does not pile two tasks on top of each other the way a naive recurrence rule would.

Templates can be updated or stopped, and a user who wants one generated instance to diverge from the template has a way to detach it. The whole design treats a recurring task as a template plus generated instances, rather than as one task with an attached rule, and that choice is what makes skipping conflicts and detaching instances possible at all.

Four notification moments and a long recovery list

The notification system is layered rather than binary. The app can notify before a task starts, notify at the start of a task, notify shortly before a task ends, and show an ongoing notification while the current task is running, so a task in progress is visible in the shade rather than only at its boundaries.

The harder half is recovery. The README lists the events after which scheduled notifications are restored: reboot, application update, time change, date change, timezone change, and exact-alarm permission changes. Each of those can silently wipe scheduled alarms, and a planner whose alarms quietly stop firing is worse than one with no notifications at all.

The exact-alarm permission entry is the one that changes behaviour on recent Android versions, where the app cannot assume it holds the permission it needs to schedule reliably. The topic list includes alarmmanager, notifications and flow, which fits an app that keeps a reactive stream of the current time and derives the current task from it rather than relying on a single alarm at the start of a task.

Statistics, goals and the deliberate choice to exclude a task

The analytics side is more than a pie chart. You can explore a week, month, half-year, year or a custom calendar range, then review planned and completed time, task counts, workload trends and key metrics, compare time across categories and drill into subcategories. There is also analysis of task creation timing, planning regularity, duration structure, template usage and busiest hours.

One feature tells you the intent behind the rest: optional exclusion of individual tasks from statistics. That is a small line in the feature list with a large effect on whether the numbers mean anything, since a single long meeting recorded as work can distort every weekly total.

Goals sit on top of the same data. A goal is a duration or task-count target with a concrete calendar deadline, and it can track all statistical tasks, a category or a subcategory without manual check-ins. Targets can be minimums or maximum limits, progress is live in the Overview screen, and there is a detail view per goal. Two rules are worth noting: completed goal history is kept even when an active goal is deleted, and an expired minimum goal keeps tracking through the current local day, so it can still be reached the same day it lapses.

Material 3 with adaptive layouts for large screens

The interface is Jetpack Compose with Material 3, on Kotlin 2.3.21 and Android API 24 and above. Theming covers light, dark and system modes, Dynamic Color on supported devices, and four built-in colour schemes. Presentation is configurable between a compact and an expanded task layout, the home screen has a persistent agenda or timeline mode, and there are configurable duration presets, analytics range defaults and calendar button behaviour, plus a secure mode for sensitive content and a home-screen widget powered by Jetpack Glance.

The adaptive work is the part with real engineering in it. Compact windows get bottom navigation and larger ones get a navigation rail, and there are window-size-aware grids, supporting panes and list-detail layouts with dedicated arrangements for medium, expanded, large and extra-large windows. Foldables get book and tabletop arrangements that keep controls away from the separating hinge.

The README is explicit that the compact phone interface keeps its original navigation and content structure, which is the sensible way to handle this: the large-screen work adds layouts without changing what a phone user sees. The topics list carries material3-adaptive and adaptive-design, and the app targets tablets, split screen, ChromeOS and desktop-style Android windows.

A multi-module Kotlin project with a security policy and no library artifact

The repository layout is the architecture. At the root are app/, core/, features/, widgets/ and config/, alongside the Gradle files build.gradle.kts, settings.gradle.kts and gradle.properties, the Gradle wrapper with gradlew and gradlew.bat, and a fastlane/ directory for release automation. The topic list names the approach: clean-architecture, mvi-clean-architecture, feature-engineering and decompose, alongside room for the database, flow and kotlin-coroutines for the reactive layer, and unittest.

So the code is split by feature rather than by technical layer, with a core module underneath, and the UI follows MVI. That structure is what makes a large feature list like this one maintainable, and it is the part of the repository most worth reading if you are studying Android architecture rather than looking for a planner.

Two things are absent. There is no published library, no Maven coordinate to depend on, so this is code to read and fork rather than a crate to add to a build. And the README documents downloads, not installation from source: APKs are available from GitHub Releases, and the app is listed on AppGallery, RuStore and F-Droid, with the F-Droid listing under the package ru.aleshin.timeplanner. The licence is Apache-2.0, the repository has a SECURITY.md, and the last push to main was on 2026-08-30, with version 2.0.0 released on 2026-08-01 after 1.0.1 in November 2024.

Editorial conclusion

Adopt TimePlanner as a reference for a modern Android planning app in Kotlin, since the repository shows a Material 3 Compose interface, a feature-module layout and a testable clean architecture structure, and it is a working app you can install today. Do not adopt it as a dependency, because it is an application and publishes no library artifact, and do not expect it to satisfy a team that needs a synced, multi-device planner, since the export and import path is a backup file rather than an account system. Before you build on it, read the feature module boundaries under features/ and the core/ layer, run the unit tests the topic list implies are present, and check the notification restoration list, since the app has to recover scheduled alarms after reboot, app update and timezone changes, which is where most of the difficult behaviour sits.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. README
4. Releases
5. v1tzor/TimePlanner on GitHub