DEV Community: Phone Operator Team

Expiry Dates and Plant Care Are Not the Same Kind of Reminder

Phone Operator Team — Mon, 10 Aug 2026 08:44:45 +0000

When I started building Ruqi (DueNest), a household inventory app for Android, it was tempting to represent every reminder with the same fields: title, date, and completed.

That model works until the product needs to support both medicine expiry and plant watering.

An expiry date is a fixed boundary. Completing a watering task should schedule another care window. Finishing an expiry reminder usually means the item was used, discarded, renewed, or archived. Those transitions are not interchangeable.

Model the domain before the notification

The notification is only a projection of domain state. A fixed-expiry item needs a date, warning window, quantity, and resolution action. A recurring care task needs a cadence, last-completed time, next due time, and a completion transition that advances the schedule.

Keeping the two models separate prevents several subtle bugs:

A plant does not become “expired” because watering is late.
Completing a medicine expiry warning should not silently create another identical deadline.
Changing a recurrence interval should recompute future care without rewriting the history of completed tasks.
A weekly home filter can combine attention items without erasing their different meanings.

Build presentation from attention windows

Users usually do not need the entire state machine on the home screen. They need a small number of attention windows: due today, due this week, and later. The UI can combine expiry items and care tasks in those windows while preserving category-specific wording and actions.

This is also a useful testing boundary. The calculation layer should accept a reference clock and return deterministic attention status. Notification scheduling can then be tested separately from date classification and UI rendering.

Keep failure honest

Android background work is not an alarm clock. Battery policy, notification permission, OEM restrictions, and delayed work execution can all affect delivery. The product copy should describe reminders as assistance, not as a guaranteed safety mechanism — especially for medicine.

Ruqi now uses separate expiry and recurring-care paths, with inventory, calendar, filters, custom fields, photos/scanning, QR labels, and local reminders built around them.

The free version allows 10 additions per day, with 10 more after a rewarded ad. A low-cost lifetime Pro purchase removes ads and unlocks unlimited additions.

Disclosure: I am the developer of Ruqi. This article describes the design trade-off behind the product; it is not an independent review.

Google Play: https://play.google.com/store/apps/details?id=com.duenest.app&utm_source=devto&utm_medium=technical_article&utm_campaign=ruqi%2Adevto%2A2026-08-10

A small Android accessibility automation pattern for repetitive office taps

Phone Operator Team — Mon, 10 Aug 2026 03:06:19 +0000

When office work repeats the same tap sequence, a small user-configured accessibility macro can remove friction without pretending to be a full RPA suite. I built Phone Operator for this narrow use case. The free version supports unlimited single-point actions. Pro is a one-time purchase, and rewarded ads can temporarily unlock Pro features. The app uses Android Accessibility Service only to execute actions the user configures; it is not intended to read private messages, collect credentials, or bypass security controls. For admins, keep macros short, visible, and easy to stop; document the manual fallback; and never automate a workflow that handles secrets unless the surrounding process explicitly permits it. Play link: https://play.google.com/store/apps/details?id=com.zidongdianjiqi.app&utm_source=devto&utm_medium=office_soft_article&utm_campaign=phone-operator*devto*2026-08-10

Designing failure-tolerant no-root tap automation on Android

Phone Operator Team — Sun, 09 Aug 2026 17:47:45 +0000

Repeated taps and swipe sequences sound simple until the screen sleeps, a dialog shifts the layout, battery optimization stops the process, or a coordinate lands on the wrong element. Building a useful Android automation tool is mostly a failure-handling problem.

Make the stop path obvious

Any tool that can repeat gestures needs a stop control the user can reach quickly. That matters more than adding another pattern type. A visible floating control, a clear running state, and predictable cancellation reduce the chance that a mistaken coordinate becomes a long sequence of mistaken taps.

Treat coordinates as fragile state

A coordinate is not intent. Rotation, display scaling, navigation bars, split screen, popups, and app redesigns can all move the target. The product should explain that limitation instead of implying it understands the screen. Before running a saved sequence, users should be able to review its points, delays, and repeat count.

Accessibility access needs a narrow explanation

On Android, no-root gesture automation normally uses an Accessibility Service. That permission is sensitive, so the purpose should be stated in plain language: perform gestures the user configured. It should not be presented as a way to bypass another app's policies, simulate engagement, cheat in games, or automate prohibited activity.

Design for interruption

Real phones interrupt workflows. A robust sequence should tolerate cancellation, avoid silently restarting after a crash, and make timing adjustable for slower devices. Battery optimization, overlay permissions, and screen timeout are not edge cases; they are normal Android conditions that belong in onboarding and troubleshooting.

I applied these principles while building Phone Operator, a no-root Android tap-and-swipe automation app for repetitive personal workflows and mobile testing. The free version supports unlimited single-point tapping. Advanced features are unlocked with a one-time Pro purchase, and rewarded ads can temporarily unlock Pro capabilities.

I am looking for feedback from Android power users and mobile QA testers, especially about stopping behavior and reliability across devices. The official Google Play listing is here:

https://play.google.com/store/apps/details?id=com.zidongdianjiqi.app&utm_source=devto&utm_medium=app_directory&utm_campaign=phone_operator*devto*20260810

Disclosure: I am the developer of the app mentioned above. I am sharing it for relevant technical feedback, not requesting votes, ratings, or incentivized reviews.

Building an on-device AI journal that does not confuse the prompt with the user's voice

Phone Operator Team — Mon, 03 Aug 2026 15:59:12 +0000

A journaling assistant has a deceptively hard job: it must respond to a person's meaning, not simply react to emotional keywords.

While building Rixin Mind Journal, a private Android journal with on-device AI, I learned that a small local model can sound fluent while still making a basic semantic mistake: treating the system's daily question as if the user had asked it.

For example:

System prompt: "When did you feel most peaceful today?"

User answer: "After everyone went to sleep, I worked alone."

A shallow pipeline may focus on "worked alone" and immediately warn about overwork. A better response first notices what solitude provided: uninterrupted attention, autonomy, relief from social pressure, or simply a quiet room.

That distinction changed the architecture.

1. Keep the system prompt and user answer in separate fields

Do not concatenate everything into an undifferentiated paragraph and hope the model infers the roles.

The analysis input explicitly labels:

Question asked by the app
Answer written by the user
Optional free-form diary text
Prior patterns, when generating a weekly or monthly report

The instruction also states that the question is context, not a claim or request made by the user.

This sounds obvious, but it eliminated an entire class of confidently wrong responses.

2. Analyze the whole entry before generating prose

Keyword matching is useful as a safety net, but it is not understanding.

"Lazy" can mean shame, fatigue, avoidance, rebellion, depression, humor, or a temporary loss of routine. "Fine" can mean genuine calm or emotional shutdown. "Alone" can mean loneliness or freedom.

The pipeline therefore separates analysis from writing:

Identify the concrete situation.
Estimate emotional valence and intensity.
Look for mixed emotions and negation.
Infer the likely need or tension.
Select one relevant psychological frame.
Generate one small, behaviorally specific next step.
Write the final response in a warm voice.

The final prose is not allowed to expose the internal labels or repeat large pieces of the diary.

3. Receive emotion before offering advice

Advice given too early feels like correction.

The response order is deliberately constrained:

Recognition: show that the experience was understood.
Insight: name one useful pattern, conflict, or need.
Action: suggest one small step that could survive an ordinary day.
Closing line: end with warmth, not another question the user cannot answer.

This matters for positive emotion too. A reflection engine should not treat every joyful entry as hidden pathology. Relief, pride, affection, playfulness, gratitude, and calm are information about what supports the person.

4. Use expert rules as guardrails, not as the final writer

Early versions relied too heavily on templates. They were safe, but different diary entries produced suspiciously similar responses.

The current approach uses expert rules to control:

role separation
emotion-negation checks
crisis language
medical boundaries
response order
repetition limits
banned meta phrases such as "the user answered..."
action specificity

The local model is still responsible for most of the wording. Rules shape the lane; they do not write every sentence.

5. Evaluate semantic fit, not only grammatical quality

A fluent answer can still be useless.

Our test cases cover different ages, jobs, relationships and emotional states. Each output is reviewed against questions such as:

Did it identify the actual situation?
Did it preserve positive emotion instead of turning it negative?
Did it acknowledge mixed feelings?
Is the advice concrete enough to attempt?
Could the same response be pasted under a different diary entry?
Does it sound like a person, or like a classification report?

The most valuable failure metric is replaceability. If an insight could fit twenty unrelated entries, it is too generic.

6. Privacy is part of the product behavior

On-device processing is not only an infrastructure decision. It changes what users are willing to write.

Rixin keeps diary writing local-first and performs AI reflection on the device. It supports guided questions, free-form journaling, daily insights, and longer weekly/monthly letters. The app is for self-reflection, not diagnosis or therapy.

The tradeoff is real: a small local model has less raw capability than a large cloud model. The way forward is not to pretend otherwise, but to narrow the task, provide expert structure, test diverse failure cases, and make the output earn its place.

If you are building any AI product that handles personal writing, I would recommend testing role confusion, negation, mixed emotion, positive emotion, and generic-response reuse before polishing the UI.

Rixin Mind Journal on Google Play:

https://play.google.com/store/apps/details?id=com.rixin.app

I would especially value feedback from Android and local-AI developers on the balance between privacy, model size, and semantic accuracy.

Designing Reliable No-Root Android Tap and Swipe Automation

Phone Operator Team — Mon, 03 Aug 2026 11:19:59 +0000

Repeated taps look simple until you try to automate them reliably across real Android devices. A gesture that works in a test screen can miss its target inside another app, drift after rotation, stop when the display sleeps, or become impossible to cancel when an overlay loses state.

I am building Phone Operator, a no-root Android automation utility, and these are the design rules that made the biggest difference. The goal here is not to automate purchases, CAPTCHA solving, fake engagement, or game-rule bypasses. It is to make user-configured, local gesture sequences predictable for repetitive personal workflows and testing.

1. Separate the control plane from the execution plane

A robust automation app has two different jobs:

The control plane lets a user create actions, change intervals, move markers, save scripts, and start or pause a run.
The execution plane validates the script, resolves coordinates, dispatches gestures, tracks cancellation, and reports progress.

Mixing both jobs inside an overlay service creates subtle failures. Dragging the floating menu can mutate gesture state. Rebuilding the overlay can cancel a scheduled action. A configuration edit can race with the currently executing action.

A safer model is to compile the editable script into an immutable runtime plan before execution. The runner reads that snapshot only. Later edits affect the next run, not the current one.

2. Make touch geometry visible and honest

If the UI says a tap has a 50 px random range, the marker should show that same range. Users should not have to imagine an invisible sampling area.

The useful model is:

marker center = configured target
visible radius = configured random radius
generated point = always inside that circle
final point = clamped to the usable display bounds

Uniform random sampling inside a circle needs area correction. If u and v are random values in [0, 1), use:

radius = maxRadius * sqrt(u)
angle = 2 * PI * v
x = centerX + radius * cos(angle)
y = centerY + radius * sin(angle)

Without the square root, points cluster near the center. If you sample X and Y independently in a square, some points fall outside the circle the UI promised.

The marker itself should not intercept the gesture. On Android overlays, visual layers and touchable control layers should be separated deliberately. A common cause of taps landing above the marker is subtracting the status-bar inset twice or mixing screen coordinates with window coordinates.

3. Treat every action as its own configuration

A real script is not “choose one global gesture and repeat it.” Each step needs its own data:

action type: tap, double tap, or directional swipe
start point and optional end point
random range
fixed or randomized interval
delay before the next action
repeat count, with unlimited as a first-class value

This lets a sequence combine tap, left swipe, another tap, and an upward swipe without inheriting accidental settings from a previous step.

For swipes, the overlay should display direction and configured distance, but the indicator should not animate along the swipe path. Moving the marker while a script is running makes users think the configured start point changed and can also trigger layout updates at the worst time.

4. Cancellation is part of the gesture protocol

“Pause” should not just change a button label. It should invalidate every scheduled continuation.

One practical approach is a monotonically increasing run token:

start: token += 1; runner receives token
pause: token += 1
before every delay or dispatch: stop if local token != current token

That makes stale callbacks harmless. It also prevents the classic bug where an old timer restarts the script after the user has already paused it.

Android gesture dispatch is asynchronous, so every action also needs a completion path, a cancellation path, and a timeout fallback. The queue must advance exactly once. Put that guarantee in one scheduler component instead of duplicating it across tap and swipe implementations.

5. Keep overlays stable across apps and rotations

The floating control surface has to survive app switches without becoming a fragile second activity.

Important details include:

use the appropriate application overlay window type
keep window updates on the main thread
clamp dragged controls to the current display bounds
recalculate bounds after rotation or configuration changes
persist only the final drag position, not every movement event
catch invalid window-token and already-removed-view states

Dragging should update only the menu window. Gesture markers should keep their configured coordinates unless the user explicitly moves them.

Opacity is also a usability feature. Markers need enough contrast to identify “tap,” “double tap,” or swipe direction, but they cannot cover the content users are trying to target. A global opacity setting with a readable minimum works better than fully opaque controls.

6. Plan for Android power management

Gesture automation does not automatically guarantee that the display remains awake. Device vendors also apply different battery and background restrictions.

The app should explain this before a long run, not after it stops. Depending on the use case, a user may need to adjust screen timeout, battery optimization, background activity, or vendor-specific autostart settings. The app should link users into the closest relevant system settings page while leaving the final change under user control.

A foreground service can keep a user-visible task alive, but it is not a license to run invisibly. The notification should clearly state that an automation session is active and provide a stop action.

7. Design permission disclosure as product UI

A no-root solution typically relies on Android AccessibilityService for gesture dispatch and overlay permission for controls above other apps. These are sensitive capabilities.

A good permission flow explains, before opening system settings:

what capability is requested
why the feature cannot work without it
what data is and is not collected
how to disable the capability later

The service should execute only actions the user configured and explicitly started. Script data can remain local. The app should also make prohibited or risky uses clear instead of presenting automation as unlimited.

8. Debug failures with a deterministic checklist

When an action misses or stops, log the inputs that explain the result:

compiled action ID and type
raw configured coordinates
window insets and display size
final sampled and clamped coordinates
dispatch start, callback, cancellation, and timeout
current run token
AccessibilityService and overlay state

That turns “the tap did nothing” into a reproducible geometry or lifecycle problem.

Further practical checklists

Two device-level issues deserve their own checklists because they are easy to miss during implementation:

Both guides are based on the same implementation work behind Phone Operator, and they keep the safety and disclosure constraints explicit.

Closing thought

Reliable Android automation is less about dispatching gestures quickly and more about keeping configuration, geometry, lifecycle, and user trust consistent. The best default is still the simplest one: one fixed tap, unlimited repeats, and an obvious stop control. Advanced mixed scripts should build on that model without making the first run harder.

I am applying these ideas in Phone Operator on Google Play. I also published practical guides for no-root setup and why auto clickers stop. Feedback about device-specific edge cases is welcome.