A digital pillbox Android app designed to help people manage medications with scheduled reminders, inventory tracking, and optional SMS updates for a designated family contact.
| Field | Details |
|---|---|
| Type | Android mobile app prototype |
| Context | University project (second iteration on the same problem space) |
| Role | Solo developer |
| Year |
| 2020 |
| Status | Academic prototype |
| Main focus | Medication inventory, recurring reminders, local alarms, Firebase-backed sync, and family SMS notifications |
iMedibox is a medication reminder app I built in 2020 as a fuller Android implementation of the digital pillbox idea I had already explored in an earlier university project. Where the first pass stayed closer to documentation and modeling, this version focused on a working mobile experience: sign-in, cloud-backed data, structured modules, and end-to-end reminder flows on a real device.
The app was never intended as a production health product. It is an academic prototype that shows how I approached a familiar problem a second time with clearer architecture, Firebase integration, and more complete user flows. I keep it in my portfolio because it marks a step from concept write-ups toward implementable mobile software.
Many people struggle to take medications on time, especially when treatments involve multiple drugs, changing quantities, or schedules that are easy to forget. For older adults or anyone relying on a caregiver, missed doses are not only inconvenient; they can affect treatment adherence and peace of mind for family members who want simple confirmation that a dose was taken.
I owned the project end to end: Android UI, MVP module structure, Firebase authentication and Realtime Database integration, local alarm scheduling, SMS notification flow, and profile or settings screens. I organized the codebase by feature modules (login, medicines, reminders, profile, familiar, alarm) and wired each screen through presenter and interactor layers with EventBus for async feedback.
iMedibox acts as a personal digital pillbox. After signing in with Google through Firebase, users register medicines with type and quantity, create reminders with custom intervals, and receive full-screen alarms when it is time to take a dose. Completing an alarm can trigger an SMS to a stored family contact. Medicines and reminders stay synced per user in Firebase Realtime Database under a predictable path structure.
AlarmManager alerts that open a dedicated alarm screenUsers add medicines with name, type, and starting quantity. The medicines screen listens to Firebase child events so lists update when data changes, and the UI warns when supply is running low.
Reminders link to an existing medicine and define how often to administer a dose. Creating a reminder both writes to Firebase and registers a repeating local alarm so notifications still fire on the device.
Intent alarmf = new Intent(getActivity(), ReminderReceiver.class);
alarmf.putExtra(Reminder.QUANTITY, Integer.parseInt(tvAddMedicineAmount.getText().toString()));
alarmf.putExtra("medicine" + Medicine.NAME, mMedicineList.get(typeSelection).getName());
alarmf.putExtra("medicine" + Medicine.TYPE, mMedicineList.get(typeSelection).getType());
PendingIntent mPendingIntent = PendingIntent.getBroadcast(getActivity(), alarmid, alarmf, PendingIntent.FLAG_UPDATE_CURRENT);
AlarmManager mAlarmManager = (AlarmManager) getActivity().getSystemService(ALARM_SERVICE);
mAlarmManager.setRepeating(AlarmManager.RTC_WAKEUP, System.currentTimeMillis() + timeMill, timeMill, mPendingIntent);I paired cloud persistence with on-device scheduling so reminders stayed actionable even when the UI was closed, accepting that alarm IDs and Firebase records had to be kept in sync manually in this prototype.
A broadcast receiver launches AlarmActivity with the medicine context, plays the default ringtone, and prompts the user to confirm the dose.
@Override
public void onReceive(Context context, Intent intent) {
Bundle bundle = intent.getExtras();
if (bundle != null) {
Intent alarm = new Intent();
alarm.setClassName("com.giusniyyel.imedibox", "com.giusniyyel.imedibox.alarmModule.view.AlarmActivity");
alarm.setFlags(Intent.FLAG_ACTIVITY_NEW_TASK);
alarm.putExtra(Reminder.QUANTITY, intent.getExtras().getInt(Reminder.QUANTITY));
alarm.putExtra("medicine" + Medicine.NAME, intent.getExtras().getString("medicine" + Medicine.NAME));
alarm.putExtra("medicine" + Medicine.TYPE, intent.getExtras().getInt("medicine" + Medicine.TYPE));
context.startActivity(alarm);
}
}I used an explicit activity launch from the receiver so the alarm UI could stay focused and readable at dose time, separate from the bottom-navigation shell.
Users can register one familiar with name and phone number. When they mark a dose as completed, the app sends a short SMS if permissions allow and a familiar exists.
private void configMessage(String message) {
SmsManager smsManager = SmsManager.getDefault();
smsManager.sendTextMessage(mFamiliar.getPhone(), null, message, null, null);
Toast.makeText(this, getString(R.string.alarm_success_message, mFamiliar.getUsername()), Toast.LENGTH_SHORT).show();
}chose direct SMS because it matched the caregiver use case without building a backend notification service, knowing it depended on device permissions and carrier behavior.
The profile section supports updating display data, managing the familiar contact, viewing about information, submitting an in-app rating with comments stored under Firebase comments, and sharing the app via a standard share intent.
The app targets API 29 with Java 8 and Material components. Authentication uses Firebase UI Auth with Google as the primary provider. After sign-in, the login flow checks whether the user node exists in Realtime Database and registers a profile when needed.
Data is scoped per authenticated user:
public DatabaseReference getMedsReference(String uid) {
return getUserReferenceByUid(uid).child(PATH_MEDS);
}
public DatabaseReference getRemindersReference(String uid) {
return getUserReferenceByUid(uid).child(PATH_REMINDERS);
}
public DatabaseReference getFamiliarReference(String uid) {
return getUserReferenceByUid(uid).child(PATH_FAMILIARS);
}I centralized Firebase paths in a singleton API class so each module’s data-access layer stayed thin and consistent.
Presentation follows MVP across modules. Views implement narrow interfaces; presenters subscribe to EventBus events from interactors; interactors call Firebase or system services. For example, the reminders home presenter registers for events on create, subscribes to reminder child listeners on resume, and unsubscribes on pause to avoid leaks.
@Override
public void onResume(User user) {
mInteractor.subscribeToReminders(user);
}
@Subscribe
public void onEventListener(ReminderEvent event) {
switch (event.getType()) {
case ReminderEvent.ON_CHILD_ADDED:
mView.add(event.getReminder());
break;
// ...
}
}This pattern repeated across login, medicines, profile, familiar, and add flows, which made the academic codebase easier to navigate at the cost of some boilerplate.
The main shell uses bottom navigation across reminders, medicines, and profile fragments. ButterKnife handles view binding, Glide loads profile images, and release builds enable ProGuard shrinking. Automated tests are limited to default template unit and instrumented stubs; most validation was manual on devices.
The interface is Spanish-first and organized around three daily tasks: see upcoming reminders, manage medicines, and adjust account settings. Visual cues differentiate medicine types with dedicated icons, and the alarm screen uses large type and a single completion action to reduce friction during interruptions.
AlarmManager schedules and Firebase reminder records could drift if reminders were edited or removed without canceling pending intentsBuilding iMedibox as a second pass taught me that repeating a project idea can be more valuable than starting from zero, as long as the scope shifts toward implementation quality. I learned to separate Firebase access, presenters, and Android system APIs, and I saw firsthand how reminder apps need clear ownership of both cloud state and on-device scheduling.
This project is no longer maintained and should be understood as an academic prototype from 2020. Firebase projects, signing keys, and Play Store distribution were out of scope for this version. I keep it in my portfolio because it shows a deliberate second iteration on medication management: from an earlier university concept to a working Android build with sync, alarms, and family notifications.
WorkManager or alarm cancellation APIs so database edits always match scheduled alarms