Project Case Studies

01. The Problem Space

During an emergency—a street accident, neighborhood hazard, or safety threat—people need to share what is happening quickly and precisely. Traditional voice calls to emergency dispatch frequently suffer from congested lines, difficulty articulating exact street coordinates, and a lack of situational awareness for people nearby who might walk straight into danger.

I built SafeAlert to solve a specific need: giving users an instantaneous, one-tap emergency mechanism that broadcasts verified incident data and device coordinates to nearby community members without requiring complicated manual input.

02. Architecture & Implementation

SafeAlert is built as a native Android application using modern Java 17 and structured around clear separation of responsibilities:

• Instant 1-Tap SOS Dispatch: Pulls device GPS coordinates directly through Android Location Services and packages an alert payload in under 2 seconds.
• Live Incident Discovery Feed: Reads from a synchronized Firebase Realtime Database node, ordering incidents by proximity and recency.
• OpenStreetMap (OSMDroid) Integration: Displays local street-level cartography using open map data, with customizable incident pins and radius overlays.
• Media Evidence Upload: Compresses on-scene camera capture and uploads directly to Firebase Storage with secure reference keys.

03. Key Engineering Decisions

Why Firebase Realtime Database over Cloud Firestore: For an emergency notification loop, raw socket synchronization latency matters more than complex querying. Firebase Realtime DB provides immediate low-overhead listener callbacks and robust offline caching on mobile devices when network packets drop in cellular dead zones.

Why OSMDroid over Google Maps SDK: Eliminating proprietary commercial map dependencies removed billing requirements and API key restrictions, while allowing cached map tiles to remain readable during spotty data connectivity.

Safety-First UI Decisions: High-contrast color hierarchy with oversized tactile buttons prevents mis-taps during stressful situations. The primary SOS button is physically separated from navigation elements to avoid accidental triggers.

04. What I Learned & Next Steps

Building SafeAlert taught me how to manage Android foreground services, asynchronous network calls under unstable connectivity, and the importance of defensive error handling in applications where failure is not an option.

Current Roadmap: The core reporting and map viewing workflows are fully built. Next steps include implementing background push notifications via Firebase Cloud Messaging (FCM) and a fallback SMS dispatch protocol for zero-data scenarios.

01. The Problem in Academic Libraries

University research libraries provide shared Windows terminals across multiple floors. Librarians face regular challenges: students exceeding allocated time limits, terminals left abandoned in locked states, and the tedious requirement at closing hours for staff to physically walk to dozens of desks to log off or shut down terminals.

Commercial cyber-cafe or enterprise management suites are prohibitively expensive, heavy on memory consumption, and often package invasive surveillance tools that violate student privacy.

02. Dual-Tier System Architecture

Library Control is architected as a lean, privacy-conscious dual-tier system:

• Zero Cloud Reliance: The entire stack communicates over the library's local area network (LAN), ensuring total privacy and immunity to external internet outages.
• Single & Global Actions: Librarians can lock/unlock individual terminals by workstation ID or trigger a global "Closing Time Curfew" lockdown with one click.
• Minimal Footprint: The background agent consumes negligible system resources (<15MB RAM), preserving full workstation performance for student research.

03. Security & Fail-Safe Logic

A critical design requirement is fail-safe resilience. If a student disconnects the Ethernet cable to bypass the daemon, the client agent enters a disconnect grace period (e.g. 60 seconds) before automatically enforcing a local lock screen until reconnection.

Current Status: The librarian web console and coordinator API are built and functional (shown below), covering the live workstation grid, active sessions, session history, audit logging, and user administration against seeded terminal data. The per-workstation lock/unlock agent is the next integration milestone.

01. Project Overview

Dansamdolly is a Spring Boot web application for inventory and stock management, covering products and categories, stock valuation and low-stock alerts, sales and invoicing, customers and suppliers, warehouses, purchase orders, and reporting. The goal was not just functional code, but disciplined engineering: rigorous specification analysis, modular decoupling, and verifiable implementation against strict constraints.

02. Engineering Principles Applied

• Requirements Engineering: Translating ambiguous user stories into precise functional requirements, boundary conditions, and test cases.
• Separation of Concerns: Isolating core business logic from input handling and data presentation, allowing individual modules to be modified without cascading bugs.
• Collaborative Version Control: Managing branch structures, resolving merge conflicts, and conducting structured peer code reviews across a small team.

03. Key Takeaway

Building Dansamdolly reinforced that maintainability, clear naming, edge-case validation, and structured documentation matter just as much as raw functionality—especially in software that manages real inventory and stock data.