A reminder app has a simple promise: help you remember something when it matters.
That makes it an interesting app to redesign. A polished home screen is useful, but the experience also depends on what happens after you save a reminder, put the phone down, and leave the app alone.
For DotReminder 0.0.7, I worked on both sides: a glass-inspired interface built with Jetpack Compose, and the scheduling, account, and AI flows behind it.
DotReminder is an Android project from FreeRave (DotSuite). The source is available under Apache License 2.0:
A visual language shared across screens
The redesign started with the screens people use most: the reminder overview, the creation form, the calendar, and the AI conversation. It then extended to templates and account settings.
The goal was a calmer interface with translucent-looking surfaces, rounded cards, clear grouping, and light and dark appearances. Those choices needed to feel consistent across the app, rather than becoming a separate styling exercise for every screen.
Shared Compose components made that practical. Screens use the same glass surfaces and theme foundations, while their state and actions stay in ViewModels, controllers, and service or repository boundaries.
That division also helped with screenshots: I could render the actual production screen content using local demonstration state, without signing into an account or writing sample reminders to Firestore.
Saving a reminder is only the beginning
One of the most useful findings during device review was also one of the simplest: a saved reminder could exist while notification permission was denied.
The app needed to explain that dependency at the point where it mattered. The updated save flow checks notification access, blocked reminder channels, and precise-alarm access. If the user leaves to grant access, the form keeps its draft and validates the time again when they return.
Reminder scheduling also has to survive more than the current process. Device-local alarm records now keep the information needed to restore registrations after reboot, an app update, or relevant clock and access changes, without first fetching the reminder from the network.
Recurring reminders needed a related correction: after one occurrence, their next occurrence should be scheduled and shown as upcoming. A recurring task should not remain stuck in an overdue state just because its first date passed.
Notification delivery and task completion remain separate concepts. A one-time reminder can sound and still appear overdue until the task is completed.
There are still real device constraints. Permissions, notification-channel settings, Do Not Disturb, and power settings can affect alerts. I tested delivery on the review device, but that does not turn Android scheduling into a universal timing guarantee.
AI suggests; the user saves
The assistant supports a different way to start a reminder. Someone can write:
Remind me to call Mum tomorrow at 6 pm.
The result is a draft, not an automatically saved task. The user reviews the title, date, time, and other details in the regular reminder form before saving.
This keeps the same validation and permission flow for both manual entry and AI-assisted entry. It also gives the user a chance to correct an interpretation before it becomes a notification.
The AI request path changed in this version too. Android calls an authenticated DotSuite gateway, while the provider key stays in the server environment. The gateway verifies the signed-in account's Firebase token, validates request sizes and shapes, and applies account and network usage limits.
On the client, requests are tied to the account that started them. Signing out or switching accounts discards an old result, and cancelling a request cancels its network call.
These are specific controls around credentials and requests. They do not make AI output inherently correct, which is why draft review remains part of the product.
Giving account controls clear meanings
Account work surfaced another distinction that needed to be visible in the interface: biometric app lock and account MFA serve different purposes.
Biometric app lock protects access to an existing signed-in session when returning to the app. Authenticator-based verification remains a separate account sign-in step for enrolled accounts.
The privacy and deletion controls also needed plain wording. DotReminder provides a request pathway for deleting an account and its associated data. Support verifies ownership and processes verified requests within 30 days. Opening the request page or an email draft does not itself erase the account.
These details are less visible than the home screen, but they shape whether people understand what an action will actually do.
What I wanted to keep maintainable
The Android stack is Kotlin, Jetpack Compose, Hilt, Firebase, and DataStore. Version 0.0.7 targets Android 16 / API 36, while retaining Android 10 / API 29 as its minimum.
For this update, the useful boundaries were concrete:
- Screen rendering can accept demonstration state without live services.
- Reminder drafts pass through a shared review and save flow.
- Alarm restoration has device-local records it can use without a network fetch.
- Authentication challenges and biometric locking stay separate from visual components.
- Provider credentials belong in the backend environment.
The repository includes focused tests and review notes for these flows, along with the localized store artwork sources. The native UI currently uses English labels; the assistant supports Arabic and English requests.
Try the source and tell me what you would change
This release is a useful checkpoint for the project: the screens share a visual language, and the less visible flows received attention alongside them.
I'd like feedback on the reminder form, the calendar, and the AI draft review. What would make a reminder app easier for you to trust and use every day?
Google Play: DotReminder on Google Play
Source: github.com/kareem2099/DotReminder
Project: DotSuite
Support: support@dotsuite.dev
