DEV Community: ekko1500

Debugging Android Backdrop Persistence: A Capacitor Story

ekko1500 — Mon, 30 Mar 2026 16:39:01 +0000

Porting a complex React app like Scratch-GUI to mobile using Capacitor can surface bugs that don't appear on desktop. Recently, we fixed a frustrating issue: backdrop edits (drawings and erasures) weren't saving in .sb3 files on Android.

Here's what went wrong and how we fixed it.

1. The Main Problem: Edits Weren't Saving

Two issues caused backdrop changes to disappear when saving.

A. Storage Configuration Typo

In storage.js, we had a typo in the asset storage config. It was trying to use invalid "create" and "update" helpers, triggering failed network requests in the Capacitor environment.

Fix: Corrected the typo and simplified addWebStore to only use the GET helper for local assets.

B. Save Button Didn't Commit Pending Edits

The Paint Editor (from scratch-paint) normally saves changes when you click away from the canvas. On Android, clicking the "Save" button didn't trigger that "focus lost" event, so the latest drawing wasn't being saved.

Fix: Added a manual sync step before saving — calling document.activeElement.blur() and waiting 100ms to ensure all edits were committed.

2. The reader.addEventListener Error

We hit a strange error: TypeError: reader.addEventListener is not a function — and it only appeared on Android.

It turns out that in some environments, FileReader doesn't fully support addEventListener. It only has onload and onerror callbacks.

Fix: Added a lightweight polyfill at app startup that adds addEventListener support to FileReader.prototype, mapping it to the existing handler properties.

3. Canvas Performance Warning

Android's WebView kept showing this warning:

Canvas2D: Multiple readback operations using getImageData are faster with the willReadFrequently attribute set to true.

This happens when the canvas is read often — like in Scratch's "touching color" blocks and paint editor fill tools.

Fix: Updated all getContext('2d') calls (in the loupe, video provider, and costume display) to include { willReadFrequently: true }. This tells the browser to optimize for frequent reads, making things much faster.

4. Touch Scrolling Felt Laggy

Chrome and WebView warn when non-passive event listeners are used on scroll-blocking events like touchstart. This can make scrolling feel sluggish.

Fix: Updated global touch handlers to use { passive: true }, letting the browser scroll immediately without waiting for JavaScript.

What We Learned

Cross-platform development isn't just about writing code — it's about understanding the subtle differences in runtime environments. A standard browser API like FileReader or Canvas2D can behave slightly differently in a WebView than in a desktop browser, and those differences can cause major issues in complex apps.

Key takeaway: Make sure your "save" logic works reliably across all input types (touch, mouse, keyboard), and don't hesitate to polyfill environment gaps to keep your libraries happy.

How I Solved Slow Page Loading Using the N+1 Query Fix (React + Laravel)

ekko1500 — Mon, 30 Mar 2026 06:24:46 +0000

When I first built my React + Laravel application, everything worked fine—until the data started growing.

Pages that used to load instantly began taking seconds. Then even longer.

At first, I thought it was a frontend issue. Maybe React was re-rendering too much. Maybe my components weren’t optimized.

I was wrong.

The real problem was happening in the backend—and it had a name: the N+1 query problem.

The Problem I Didn’t See at First

Let’s say I had something like this in my Laravel backend:

A list of students
Each student has marks
Each mark belongs to a subject

Simple, right?

But here’s what actually happened when I fetched data:

1 query to get students
Then N queries to get each student's related data

So if I had 100 students, I was running:
👉 101 queries

That’s the N+1 problem.

And it destroyed performance.

How I Discovered It

I started debugging the backend and noticed something strange:

The API response time was slow
Database queries were increasing with data size

So I used Laravel debugging tools and logs.

That’s when I saw it clearly:
👉 Queries were being executed inside loops

That’s the moment it clicked.

The Fix: Eager Loading

Laravel already has a solution for this: Eager Loading

Instead of fetching related data one-by-one, I loaded everything in a single query.

Before (Bad)

$students = Student::all();

foreach ($students as $student) {
    echo $student->marks; // triggers query every time
}

After (Good)

$students = Student::with('marks')->get();

Now:

Only 2 queries total
No matter how many students

Massive improvement.

Going Deeper: Nested Relationships

My case wasn’t that simple.

I had deeper relationships like:

students → marks → subjects

So I used nested eager loading:

$students = Student::with('marks.subject')->get();

Now everything loads efficiently in minimal queries.

Optimizing the API Response

Fixing queries wasn’t enough.

I also improved how data was sent to React.

What I changed:

Removed unnecessary fields
Used API Resources (Transformers)
Sent only what the UI actually needs

return StudentResource::collection($students);

This reduced payload size and improved speed.

React Side Optimization

After fixing Laravel, I improved React too.

1. Avoid Unnecessary Re-renders

I used:

useMemo
useCallback
Proper state structure

2. Lazy Loading Components

const Dashboard = React.lazy(() => import('./Dashboard'));

This reduced initial load time.

3. Efficient Data Fetching

Avoided duplicate API calls
Cached results when possible

The Result

After all optimizations:

Page load time dropped significantly
API became faster and more scalable
UI felt instant even with large data

What used to feel slow and heavy became smooth and responsive.

What I Learned

This experience taught me something important:

Performance problems are often not where you think they are.

I spent time looking at React—but the real issue was in the database.

Key Takeaways

Always watch for N+1 queries in backend systems
Use Eager Loading in Laravel (with())
Optimize API responses, not just queries
Frontend performance depends on backend efficiency

Final Thoughts

Fixing the N+1 query problem completely changed how I think about building applications.

Now, whenever I design a feature, I ask:

👉 How many queries will this run?

Because performance isn’t just about code—it’s about how systems interact.

And once you fix the root problem, everything becomes faster.