DEV Community: Justine Lopez

I Built an Android App That Tracks Screens Using Computer Vision

Justine Lopez — Thu, 13 Aug 2026 21:58:00 +0000

I Built an Android App That Tracks Screens Using Computer Vision

Most of my earlier projects were fairly conventional applications.

They had screens.

They had data.

They had buttons.

They had users interacting with information.

Then I wanted to build something different.

I wanted the application to look at the physical world through a camera and actually understand something about what it was seeing.

That became ScreenFrame, also called Warp_Flow.

The Idea

ScreenFrame is an Android application focused on real-time screen detection and alignment.

The basic idea is:

Camera
↓
Analyze Frames
↓
Find Edges
↓
Find Corners
↓
Track Screen
↓
Calculate Perspective

The application attempts to identify the boundaries of a display in the camera view.

This sounds straightforward until you realize that the camera doesn't always see a perfect rectangle.

The Screen Isn't Always a Rectangle

Point a phone directly at a monitor and the geometry looks relatively simple.

Move the phone to the side and perspective changes everything.

The physical screen is still rectangular.

But the camera sees something closer to:

  __________
 /         /
/         /

/_________/

The four corners have shifted.

That's where homography becomes useful.

It allows the application to reason about how points in one plane relate to another perspective.

For ScreenFrame, that means using detected screen corners to help understand and align the display.

Edge Detection

The application uses edge detection to find possible boundaries.

But a camera frame contains much more than the screen.

There can be:

Reflections
Text
Images
Furniture
Objects
Lighting changes

So simply detecting every edge isn't enough.

ScreenFrame exposes Canny low and high thresholds that can be calibrated to help identify useful edges while filtering some unwanted visual information.

That turned image processing into a much more practical problem.

Real-World Lighting Is Messy

Computer vision works very differently on a controlled image compared with a real camera.

A screen might be bright.

It might be dim.

It might reflect the room.

The surrounding environment might be darker.

To deal with these conditions, ScreenFrame includes an adaptive compensation filter designed to help with ambient and low-light conditions.

That made one thing very clear to me:

Computer vision isn't just about getting the algorithm to work once.

It's about getting it to continue working when the environment changes.

Real-Time Means Real Performance

This was probably the biggest difference from my other Android applications.

A normal app might do something after a user action.

A camera application can be processing continuously.

Frame → Analyze
Frame → Analyze
Frame → Analyze
Frame → Analyze
Frame → Analyze
...

At 60 FPS, that's a lot of incoming data.

A small performance problem can happen dozens of times every second.

So I had to think about performance much earlier.

Compose and Real-Time State

The interface uses Jetpack Compose and Material 3.

The application uses reactive state with Kotlin StateFlow inside a ViewModel.

The simplified architecture looks like:

Vision Pipeline
↓
ViewModel
↓
StateFlow
↓
Compose HUD

I also use techniques such as remember, state hoisting, and controlled recomposition to avoid unnecessary UI work.

This was interesting because the computer vision pipeline and the UI aren't separate performance problems.

They affect each other.

Battery Is Part of Performance

There's another constraint on mobile devices:

battery.

Running camera analysis continuously isn't free.

ScreenFrame therefore includes an automatic battery-saving mode.

When the battery becomes low, such as below 20%, the application can reduce the analysis refresh frequency.

So instead of thinking:

Maximum performance all the time.

the application can think:

How much performance does the device actually need right now?

That's a much more practical approach for mobile software.

30 FPS vs 60 FPS

ScreenFrame supports both 30 FPS and 60 FPS workflows.

That difference matters.

At 30 FPS:

30 frames per second

At 60 FPS:

60 frames per second

The application potentially has twice as many frames to process.

That means performance problems become much easier to expose.

Building the HUD

I also wanted the UI to match the technical nature of the project.

Instead of creating a traditional Android interface, I designed a dark HUD-style control deck using Jetpack Compose and Material 3.

The application uses centralized design tokens for:

Spacing
Shapes
Typography
Visual accents

There are also multiple neon-inspired themes, including:

Neon Green
Cyber Orange
Hot Pink
Electric Purple
Electric Blue
Amber Gold

The UI is intentionally designed to feel more like a technical instrument than a typical Android application.

What I Learned

ScreenFrame changed how I think about Android development.

Before this project, I mostly thought about:

How do I make this screen work?

Now I also think about:

How many frames am I processing?

How often does this state change?

What causes recomposition?

What happens when the battery gets low?

What happens when lighting changes?

How expensive is this operation when repeated 60 times per second?

Those are very different questions.

And they pushed me toward thinking more about systems rather than individual screens.

Why I Like Building Projects

This is probably the biggest lesson I got from ScreenFrame.

When you build something from scratch, the problems aren't neatly organized into lessons.

You discover them.

You start with:

"I want to detect a screen."

Then you discover:

"I need edge detection."

Then:

"Perspective is a problem."

Then:

"I need homography."

Then:

"The camera is processing too much."

Then:

"Now I have a performance problem."

And eventually the project becomes much more technically interesting than the original idea.

That's one of the reasons I enjoy building.

The project forces you to learn things you didn't initially know you needed.

What's Next?

ScreenFrame pushed me into computer vision, real-time processing, geometry, and Android performance.

For the next project, I wanted to take everything I've been learning about application architecture and apply it to another real-world problem.

That's where the next project in my portfolio begins.

I Built HackForPinas to Make Philippine Hackathons Easier to Discover

Justine Lopez — Thu, 13 Aug 2026 06:34:00 +0000

In my previous article, I talked about Train Track, the transit app I built around Metro Manila's railway systems.

This project started with a completely different problem.

I kept thinking about how difficult it can be to discover hackathons and coding competitions.

Not because they don't exist.

They do.

The problem is that they're scattered everywhere.

A university might announce one.

A government agency might host another.

A private company might run one.

A developer community might post another.

And suddenly you're checking multiple websites just to figure out:

What can I actually join?

So I built HackForPinas.

What is HackForPinas?

HackForPinas is a free, public, and open-source directory for Philippine:

Hackathons
Coding challenges
Technology competitions

The idea is pretty straightforward:

Make opportunities easier to discover.

Events can be filtered by:

Region
Format
Organizer type
Status

Organizers are categorized as:

Government
University
Private

Instead of browsing through unrelated websites, users can explore opportunities in one place.

But the more I worked on it, the more I realized that the directory itself wasn't the hardest part.

The data was.

The Data Problem

Imagine trying to collect hackathons from different websites.

One might have an RSS feed.

Another might use WordPress.

Another might expose an API.

Another might have an ordinary HTML page.

And another might not have anything structured at all.

So HackForPinas uses multiple scraping strategies:

WordPress REST API
RSS
GDG Community
Eventbrite
HTML + Cheerio

The scraper runs through a background endpoint and collects events from different Philippine technology sources.

The interesting part wasn't:

"Can I scrape a website?"

It was:

Can I turn information from completely different sources into one consistent dataset?

That became a much more interesting engineering problem.

I Didn't Want Anyone to Publish Directly

There's another problem with a public directory.

If anyone can submit an event, what stops someone from submitting spam?

Or a malicious link?

Or incorrect information?

That's why I designed the submission flow around moderation.

Submission
↓
Zod validation
↓
Security checks
↓
Rate limiting
↓
pending_review
↓
Admin review
↓
Approve / Reject
↓
Published

A community submission doesn't automatically become a public event.

It goes through review first.

Security Is Part of the Architecture

This project also forced me to think more seriously about security.

There are several types of user-controlled input.

The application therefore uses:

Zod schema validation
Open-redirect protection
HTML sanitization
API rate limiting
Supabase Row Level Security
Controlled admin workflows

One of the interesting things I've learned about security is that the most important features aren't always visible.

A user might immediately notice an animation.

They probably won't notice that a malicious redirect was blocked.

But the second one can matter much more.

Building an Admin Workflow

The admin panel became an important part of the application.

Administrators can:

Review submitted events
Verify organizers
Edit event information
Approve submissions
Reject submissions

I also added an audit trail.

The submissions_audit_log table records moderation activity such as:

Who performed the action
What action was performed
When it happened

That gives the platform a history of how submissions were handled.

Making the Interface Less Boring

I also wanted HackForPinas to feel different from a typical directory.

So I experimented with several visual effects.

There's a generative SVG mesh background.

There's a retro split-flap animation.

There's a letter glitch effect.

There are animated counters.

These don't make the scraper work better.

But they make the product feel like an actual product rather than a database with a frontend attached to it.

And honestly, that distinction matters to me.

The Stack

The project is built using:

Next.js 16
React 19
Tailwind CSS v4
Supabase / PostgreSQL
Motion
Cheerio
Zod
Lucide React
Iconify
date-fns

The interesting part is that the application combines automated data collection with user-generated submissions.

That means the system has to deal with two very different sources of data:

Machine-generated data

and

Human-generated data.

Both can fail in different ways.

What This Project Taught Me

Train Track taught me to think about the user's journey.

HackForPinas taught me to think about the system behind the interface.

I started asking questions like:

Where does this data come from?
Can I trust it?
What happens if the source changes?
What happens if someone submits something malicious?
Who gets permission to publish?
How do I track administrative actions?
What happens when automation fails?

Those questions weren't necessarily part of my original idea.

But they became some of the most valuable parts of building the project.

Why I Wanted to Build This for the Philippines

There's also a personal reason behind the project.

I wanted to build something specifically around the Filipino technology community.

Not another generic tutorial project.

Not another clone.

Something that could potentially help Filipino developers, students, designers, and technology enthusiasts find opportunities to participate and build things.

That's what makes HackForPinas more meaningful to me than simply saying:

"I built a Next.js website."

The framework is just the implementation.

The problem is the interesting part.

What's Next?

HackForPinas made me interested in building software around local problems.

For the next project, I went in a completely different direction.

Instead of hackathons and developer opportunities, I started thinking about something much more familiar:

Filipino food.

That's where Lutong Simmer comes in.

I Built a Filipino Cooking App That Recommends Food Based on the Weather

Justine Lopez — Wed, 12 Aug 2026 19:50:00 +0000

One question gets asked in Filipino households all the time:

"Ano ang lulutuin natin?"

Sometimes you already know.

Sometimes you don't.

And sometimes the weather gives you a pretty good idea.

Rainy afternoon?

Maybe Sinigang.

Cold weather?

Maybe Bulalo.

Hot afternoon?

Maybe Halo-Halo.

That simple observation became the idea behind one of my projects:

Lutong Simmer.

What Is Lutong Simmer?

Lutong Simmer is a Filipino cooking companion application that uses weather and time of day to recommend Pinoy food.

Instead of simply searching for recipes, the application uses context.

It considers things like:

Current weather
Local time
Dietary needs
Ingredients
Filipino recipes

The basic idea is:

Weather + Time + User Context
↓
Recommendation
↓
Filipino Food

It's a simple concept, but building it introduced me to several interesting Android development problems.

Why Use Weather?

Weather isn't usually the first thing you associate with a recipe application.

But it makes sense when you think about how people actually choose food.

A rainy day can make a warm soup more appealing.

A hot day can make something refreshing more attractive.

So I decided to make weather part of the application's experience instead of treating it as unrelated information.

The app integrates weather data and uses it as part of the context for its recommendations.

Building It With Kotlin

Lutong Simmer is a native Android application built entirely with Kotlin.

The stack includes:

Kotlin
Jetpack Compose
Material 3
Room
Coroutines
Flow
Coil
Google Gemini API SDK

The architecture follows an MVVM approach with Unidirectional Data Flow.

The general flow looks like:

Data
↓
Repository
↓
ViewModel
↓
StateFlow
↓
Compose UI

This keeps the UI focused on displaying state while the underlying logic stays separated.

Offline-First

One of the things I wanted from the beginning was for the app to remain useful without a constant internet connection.

That's why Lutong Simmer uses Room SQLite for local persistence.

Saved and locally stored recipe information can remain accessible even when the network isn't available.

This matters more than it might seem.

Imagine you're already cooking.

You open the app.

The Wi-Fi doesn't work.

You shouldn't lose access to your recipes.

So offline support became part of the product design.

Search Optimization

The application also has local SQLite search with a debounce mechanism.

Without debouncing, typing something like:

Sinigang

could result in multiple database operations:

S
Si
Sin
Sini
Sin...

Instead, the application waits briefly for the user to stop typing before performing the search.

It's a small optimization.

But these small optimizations add up when you're trying to make an application feel responsive.

Kitchen Studio

Lutong Simmer also lets users create their own recipes.

I called this feature Kitchen Studio.

Users can create custom Filipino recipes and save them locally.

They can also attach photos using:

Camera
Gallery

The cooking instructions can then be interacted with through a checklist.

So instead of simply reading:

Step 1
Step 2
Step 3

the user can actually track their progress while cooking.

Making It Feel Filipino

I didn't want to build a generic recipe app and simply replace the recipes with Filipino dishes.

I wanted the application to have its own identity.

The interface uses a custom culinary-inspired palette:

Terracotta Orange
Golden Honey
Sage Green

It also includes localized greetings such as:

Magandang Gabi, Ka-simmer!

These details are small.

But together, they make the application feel more intentional.

The UI

The application is built using Jetpack Compose and Material 3.

I also experimented with custom animations.

One of them is an animated empty state.

Instead of simply showing an empty screen when a search returns nothing, the UI displays:

A pulsing icon
Rotating dashed ring
Centered messaging
Clear-search action

I also paid attention to recipe card layouts.

Long recipe names can easily break grid interfaces, so the cards use:

maxLines = 1
TextOverflow.Ellipsis

This keeps the layout consistent.

Where Gemini Comes In

Lutong Simmer also integrates Google's Gemini API.

The AI component helps with contextual recipe generation and recommendations, particularly around ingredients.

This was another lesson for me.

I don't think every application needs AI.

Adding an AI API doesn't automatically make a product better.

The better question is:

Where can AI actually solve a problem for the user?

For Lutong Simmer, that problem is generating useful recipe-oriented results from context and ingredients.

What I Learned

This project taught me to think about context.

My previous projects taught me different things.

Train Track made me think about user journeys.

HackForPinas made me think about data aggregation, security, and automation.

Lutong Simmer made me think about how software can react to a user's situation.

The application isn't only asking:

"What recipes do we have?"

It's asking:

"What might make sense for this person right now?"

That changed how I think about recommendation systems.

More Than a Recipe App

Technically, Lutong Simmer could be described as:

A Kotlin Android application using Jetpack Compose, Room, weather data, and Gemini.

But that's not really how I think about it.

I see it as an experiment in combining:

local culture + contextual data + mobile technology + AI.

The technology is important.

But the idea behind the technology matters more.

What's Next?

After working on food, I wanted to move into something completely different.

My next project explores cameras, image processing, and visual computing.

That's ScreenFrame.

Instead of asking:

"What should I cook?"

the next application asks:

"What can software understand from an image?"

And that introduced me to a completely different set of engineering problems.

I Built a Transit App for Metro Manila. Here's What It Taught Me

Justine Lopez — Wed, 12 Aug 2026 07:24:00 +0000

I've always found transportation applications interesting.

Not because I particularly enjoy looking at maps, but because commuting is one of those situations where too much information can be just as bad as too little.

You don't want to study a transportation system.

You just want to get somewhere.

That was the idea behind one of my projects:

Train Track.

It's a native Android application I built around Metro Manila's rail systems.

The Problem

Metro Manila has multiple major railway systems:

LRT-1
LRT-2
MRT-3

For someone who regularly commutes, knowing the stations isn't necessarily the difficult part.

The difficult part is putting everything together.

Where do I start?

Where do I transfer?

How many stations are left?

What's happening on my route?

So instead of thinking:

"I'm going to build a train database."

I started thinking:

"I'm going to build something that helps a commuter understand their trip."

That small change in thinking affected almost everything else.

Building It With Kotlin

I decided to make Train Track a native Android application.

The project uses:

Kotlin
Jetpack Compose
Material 3
Room
Kotlin Coroutines
Flow

I wanted to use the project as an opportunity to go deeper into native Android development.

Compose was particularly interesting because the UI is driven by state.

Instead of thinking:

"Change this UI element."

I could think:

"The state changed, so the UI should represent the new state."

That mental model made more sense for an application dealing with dynamic information.

The UI Problem I Didn't Expect

At first, I thought more information would automatically make the application better.

It doesn't.

Imagine opening a transit app and immediately seeing:

station information
train specifications
alerts
crowding
route data
schedules
track information

Everything might be useful.

But not necessarily right now.

That's when I started thinking about progressive disclosure.

Show the important information first.

Let the user dig deeper when they need it.

A commuter checking their route shouldn't have to understand the entire system before they can answer:

"Where do I get off?"

That became one of the design principles behind the project.

Offline Matters More Than I Initially Thought

Train Track also uses Room for local persistence.

That allows the application to keep useful information locally, such as favorites, searches, settings and cached information.

This might seem like a normal Android implementation detail.

But I started seeing it differently.

A commuter might be underground.

They might have a weak signal.

They might have no connection.

And that's exactly when they may need the application.

So offline support isn't just a technical feature.

It's part of the user experience.

The Interesting Part: Thinking About the Journey

The biggest shift happened when I stopped thinking about individual features.

Instead, I thought about the entire journey.

Imagine:

Station A
   ↓
Train
   ↓
Transfer
   ↓
Train
   ↓
Station B

The user doesn't want five different screens explaining each part.

They want the application to help answer:

"What's happening now?"

"What's next?"

"What do I need to do?"

That made me realize something:

An application can contain complicated information while providing a simple experience.

That's a principle I want to carry into future projects.

What I Learned

Train Track taught me that building software isn't just about choosing technologies.

It's about translating complexity.

The transportation network can be complicated.

The application shouldn't make the commuter feel like they're navigating the complexity themselves.

That's probably my favorite lesson from this project.

When I'm building something now, I try to ask:

"What decision is the user actually trying to make?"

rather than:

"What features can I add?"

Those questions lead to very different products.

What's Next?

Train Track is only Part 2 of my project series.

Next, I'm moving from transportation to something completely different:

HackForPinas.

The problem there isn't navigating trains.

It's navigating information.

Hackathons, coding competitions and technology opportunities can be scattered across different websites and communities.

So I started building a platform to bring those opportunities together.

And that's where things get considerably more interesting from an engineering perspective.

Automation.

Scraping.

Validation.

Security.

Admin workflows.

Things I Built While Figuring Out What Kind of Engineer I Want to Become

Justine Lopez — Sun, 09 Aug 2026 11:56:11 +0000

I Don't Want to Be Known for Knowing Technologies

I've been thinking about something recently.

As an IT student, it's easy to look at what other developers are doing and feel like you need to know everything.

React.

Next.js.

Flutter.

Kotlin.

AI.

IoT.

Cloud.

Databases.

And then another framework appears.

So I started asking myself a different question:

What do I actually want people to remember me for?

I don't have a perfect answer yet.

But I think my projects are starting to give me one.

I'm calling this series "Things I Built While Figuring Out What Kind of Engineer I Want to Become."

1. subukAn: The Project I Haven't Built Yet

This might sound like a strange project to start with.

I haven't actually built the application.

And that's intentional.

subukAn is my idea for a user-testing platform for the Filipino tech community.

The idea is that developers can pay real testers to evaluate their applications against specific tasks, while testers earn money for completing those tasks.

My first instinct was to build it.

Then I stopped.

I realized I could spend weeks building authentication, dashboards, payments, databases and APIs without knowing whether the basic idea worked.

So version 0.1 is currently a planning and validation phase.

I'm trying to answer questions before writing the code.

Would developers pay for this?

Would testers participate?

How should tasks be priced?

What happens when a tester rejects a task?

How should disputes work?

That's probably one of the most useful things I've learned recently:

Coding isn't always the first step.

Sometimes the first step is finding out what you don't know.