Forem: Azeem Hassan

GPS Camera App - Geo Tagging

Azeem Hassan — Sun, 12 Apr 2026 20:45:51 +0000

When a “Simple” GPS Camera App Wasn’t Simple at All

I remember sitting late one night, testing the app on a low-end Android phone. I tapped the capture button, waited… and the photo came out late, with slightly wrong GPS coordinates. I tried again, and it lagged even more.

That’s when I stopped and thought — something isn’t right.

The moment everything changed

I went into this project thinking I was building a simple GPS camera app. You know… open camera, take photo, stamp location, done.

But that assumption didn’t last long.

Because once you start combining camera capture + GPS timing + image processing, you’re no longer building a simple app. You’re dealing with coordination between multiple systems that don’t naturally sync well.

And if you’ve ever worked on something like this, you probably know exactly what I mean.

Here’s the thing

When you rely fully on a framework, you’re trusting it to handle complexity for you. And most of the time, that works.

But when you need precise control — like capturing GPS at the exact moment of image capture — you start to notice limitations.

I learned this the hard way.

You can’t treat every part of your app equally. Some parts are UI-driven. Others are performance-critical. And you have to make that distinction early, or you’ll feel it later.

Rethinking the approach

So I changed direction.

I kept Flutter for the UI because it’s fast, flexible, and honestly great for building product screens. But I moved the core pieces — camera handling, GPS synchronization, and image processing — into native Kotlin.

And that decision changed everything.

Actually… let me rephrase that.

It didn’t make things easier immediately. But it gave me control. And that control is what allowed me to fix the real problems.

What the numbers actually said

I didn’t want to rely on “it feels faster,” so I started tracking things using Flutter DevTools and some internal logging.

Here’s what I saw after restructuring the architecture:

Camera startup time

Before: ~1.8s – 2.4s
After: ~0.7s – 1.1s

Capture latency (tap → saved image)

Before: ~450ms – 700ms
After: ~120ms – 220ms

Preview performance (low-end devices)

Before: frequent drops below ~40 FPS
After: stable ~55–60 FPS

Memory behavior after multiple captures

Before: noticeable spikes and GC pauses
After: much more stable usage

GPS accuracy at capture moment

Before: slight delay or drift
After: consistent and aligned with capture timing

These weren’t lab tests. Just real-world usage across different Android devices.

What you should take from this

If you’re building something that involves real-time data, especially camera or GPS, you can’t just assume it’ll behave consistently across devices.

You need to:

test on low-end devices, not just your own phone
question delays and inconsistencies early
measure performance instead of guessing
separate UI concerns from system-level work

Because if you don’t, you’ll end up chasing bugs that are actually architectural decisions.

A few real examples

There were moments where everything “worked”… but didn’t feel right.

The capture felt slightly delayed
GPS data was just a bit off
Memory usage increased after repeated photos

Individually, they didn’t seem critical. But together, they broke the experience.

And that’s the tricky part.

Small issues in isolation don’t look serious. But combined, they define how your app actually feels.

One thing I didn’t expect

Simple-looking apps are often the most deceptive.

Because you’re not solving what the user sees. You’re solving what happens underneath — timing, memory, hardware interaction.

It’s a bit like trying to take a perfectly timed photo while multiple systems are slightly out of sync. Everything works… just not when it should.

If you’re building something similar

If you’re working on a camera, GPS, or real-time app, take a step back and ask yourself:

Are you solving the visible problem… or the actual one?

If you’re curious how this approach turned out in a real project, you can take a look here (just for reference, not a pitch):

Spare some time and try it: GPS Camera App

Disclaimer: The link is shared purely to experience Flutter performance in a real-world scenario—it’s nearly on par with native (~98%). This project was developed for a client.

Final thought

The biggest takeaway for me wasn’t just performance improvements.

It was learning where abstraction helps… and where it gets in your way.

And once you understand that, you start building very differently.

I Made It Rain on Your Flutter Screen (Literally)

Azeem Hassan — Thu, 09 Apr 2026 13:23:22 +0000

It was raining. I had nothing specific to work on. I had this idea for a rain-on-glass effect — drops with reflections, physics, wind — and thought: this doesn't exist for Flutter.

Six nights later, it does.

rainy_day is a Flutter package that renders a hyper-realistic rain-on-glass effect over any background image you give it. Falling drops. Reflections inside every drop. Collisions. Wind gusts. Accelerometer-driven parallax. One widget, one line.

This is the story of how I built it and what actually made it hard.

What it looks like

Drop this into your widget tree:

RainWidget(
  backgroundAsset: 'assets/images/background.jpg',
  blur: 10,
  fps: 60,
  enableCollisions: true,
  gravityThreshold: 3,
  windIntensity: 1.5,
  rainPresets: [
    RainPreset(3, 3, 0.88),
    RainPreset(5, 5, 0.90),
    RainPreset(6, 2, 1.00),
  ],
)

And your screen becomes this:

That's the whole API surface. Everything has sensible defaults. You don't need to manage a ticker, handle images, or touch a single canvas method.

But building that API took several nights of genuinely frustrating debugging. Here's what actually tripped me up.

Challenge 1: Reflections

This was the thing I underestimated the most.

Real drops on glass act like convex lenses — they refract what's behind them. So each drop in the scene shows a tiny, slightly distorted version of the background. Not the blurred version. The sharp version, at scale.

Flutter's Canvas doesn't have a CSS-style background-clip shortcut. You can't just say "fill this path with a section of this image." You have to do it manually.

What I ended up doing:

At startup, scale down a copy of the original background image by a factor (default 5×). This is the "reflection image."
At paint time, for every single drop, calculate where in the reflection image this drop's position maps to.
Clip the canvas to the drop's Bézier path.
Draw the mapped portion of the reflection image inside that clip region.
Unclip, move to the next drop.

The math to get the reflection coordinate mapping right was where I spent most of my time. Parallax offset bleeds into it. Image scaling bleeds into it. Get either one slightly wrong and every drop reflection looks like it's sampling from the wrong part of the scene.

Challenge 2: Drop Shapes

I assumed drops were circles. They're not.

A bead sitting still is roughly circular. But a drop that's moving fast is a teardrop — elongated in the direction of travel, compressed at the sides. And a drop mid-collision briefly shifts sideways and deforms before stabilizing.

Three different Bézier path shapes depending on state:

if (r < 3) {
  // tiny static bead — plain oval
  path.addOval(Rect.fromCircle(center: Offset(x, y), radius: r));

} else if (colliding != null || (ySpeed ?? 0) > 2) {
  // fast or colliding — stretched teardrop
  final c = 1 + 0.1 * (ySpeed ?? 0);
  path.moveTo(x - r / c, y);
  path.cubicTo(x - r, y - 2 * r, x + r, y - 2 * r, x + r / c, y);
  path.cubicTo(x + r, y + c * r, x - r, y + c * r, x - r / c, y);
  path.close();

} else {
  // slow-moving — softer teardrop with asymmetric arcs
  final rr = 0.9 * r;
  path.moveTo(x - rr * 0.85, y);
  path.cubicTo(x - rr * 0.5, y - rr * 1.6, x + rr * 0.5, y - rr * 1.6, x + rr * 0.85, y);
  path.cubicTo(x + rr, y + rr * 1.1, x - rr, y + rr * 1.1, x - rr * 0.85, y);
  path.close();
}

These paths are recomputed every frame for every visible drop. When you're running 600+ drops at 60fps, that adds up.

Challenge 3: Performance

My first version just called setState on a timer. Rebuilds the entire widget tree 60 times per second. With hundreds of drops and canvas operations per frame.

It was, generously: not great.

The fix was a CustomPainter that listens to a ValueNotifier directly:

class GlassPainter extends CustomPainter {
  GlassPainter({required Listenable repaint}) : super(repaint: repaint);

  @override
  bool shouldRepaint(GlassPainter _) => false; // never rebuild the painter
}

shouldRepaint returns false — always. The painter structure doesn't change; only the data does. Flutter skips the full widget rebuild and just calls paint() directly on the canvas each tick.

Beyond that:

Spatial collision grid: drops only check cells adjacent to them, not every other drop (O(n) instead of O(n²))
Background blur via ImageFilter: applied at draw time on the canvas, not pre-blurred into a new image in memory
Reflection image pre-rendered once: not recomputed per frame

After all of this: smooth 60fps on a mid-range Android device.

Bonus: Wind That Feels Real

Once physics was solid, I wanted wind. Not a constant sideways push — actual gusts.

The implementation sums three sine waves at different frequencies and phases:

double _windForce(double t) {
  return options.windIntensity *
      (0.6 * math.sin(t * 0.0008) +
       0.3 * math.sin(t * 0.0021 + 1.2) +
       0.1 * math.sin(t * 0.0053 + 2.7));
}

The result isn't random and isn't mechanical — it builds, peaks, recedes, and comes back differently each time. Exactly like actual gusts. Watching drops slowly drift sideways and then fall back down is probably my favorite thing in the whole package.

Getting Started

# pubspec.yaml
dependencies:
  rainy_day: ^1.0.1

Don't forget to declare your image asset:

flutter:
  assets:
    - assets/images/background.jpg

Then:

import 'package:rainy_day/rainy_day.dart';

// Minimal usage
RainWidget(backgroundAsset: 'assets/images/background.jpg')

// Stormy
RainWidget(
  backgroundAsset: 'assets/images/background.jpg',
  windIntensity: 3.0,
  gravityAngleVariance: 0.04,
  onControllerReady: (ctrl) {
    ctrl.speedMultiplier = 2.0;
    ctrl.spawnMultiplier = 4;
  },
)

Works on Android and iOS. MIT licensed.