GSoC Coding Period Week 3:

This week was a classic GSoC rollercoaster—funny moments, frustrating bugs, and fulfilling breakthroughs!

Wrapping Up Codebase Modernization

The week began by finishing up a few pending tasks from codebase modernization. One of those tasks was commenting on Coderabbit's suggestions. Now, here's the funny part—when I saw the suggestions reacting and replying by themselves, I thought Aboo (my mentor) was responding manually.

Turns out, Coderabbit talks back.My reaction? Mild panic, major confusion, and then a chuckle.

Anyway, it's surprisingly helpful. Definitely the kind of AI pair programmer you don’t mind having around.

The Great Key-Naming Fiasco

A BIG mistake I made and I’m writing it in caps so future-me never forgets is this:

Always use unique keys when working with Flutter's localization (gen-l10n)!

For example:

• error
• profile_view_error, ib_landing_view_error, etc.

Why? Because ARB files are flat JSONs. If you use the same key name ("error": "Error") multiple times, the Flutter gen-l10n tool will crash... hard.

Facebook Auth + macOS = 🥲

Then came the big auth task: the app was looking for a macOS implementation of facebook_auth_desktop, but it wasn’t there. I tried adding it manually—ambitious, I know—but soon hit conflicts with oauth2_clientand flutter_secure_storage.

Hardik, my mentor, rightly pointed out that downgrading just to fix a conflict is not a great long-term solution. So, I went searching.

I discovered flutter_appauth, a promising alternative—but it also needed facebook_auth_desktop, and brought along security constraints due to PKCE.

What’s PKCE?

PKCE (Proof Key for Code Exchange) is a security extension to OAuth 2.0. It prevents authorization code interception attacks, especially on public clients like mobile and desktop apps. Instead of just sending a client secret, it uses a dynamically generated code verifier and challenge.

It's secure—but yeah, not simple when you're juggling conflicting packages

UI Time: Card Redesign Sprint

To cool off from the auth-heavy chaos, I shifted gears and decided to redesign the profile cards.

I went deep down the rabbit hole of UI inspiration sites. After scrolling endlessly, I landed on BoltUiX—and let me just say, what a vibe! I learned a lot about spacing, contrast, and minimal design elements just from observing how cleanly they laid things out.

Before:

After:

Frontend work can be so relaxing. It’s like gardening... but with Figma tabs open.

Weekly Discussions & Sync-ups

One of the best parts of this week was how much I talked with my mentors. Frequent discussions are underrated—they make sure you're never sailing off-course, and everyone’s on the same page.

We even had a sync-up call me, Aboo, and Hardik where we discussed upcoming work and blockers.

Funny Incident: My First Code Review (Sort of)

Okay, confession time: I noticed Aboo had requested a review from me... 9 days ago.

The PR was:

chore(deps): bump flutter_lints from 5.0.0 to 6.0.0

Me: “What do I even do in a review?”

I had no clue, so I opened the official GitHub guide like a student before exams. After a few scrolls, I figured out: I can either approve the changes or suggest changes. Got it.

The update brought in a new rule: strict_top_level_inference

This means now you must declare types for top-level variables:

// Before
final primaryColor = Colors.blue;

// After
final Color primaryColor = Colors.blue;

Options we can go for:

• Add types wherever necessary
• Disable the rule temporarily in analysis_options.yaml and add types progressively with upcoming PRs:

linter:
  rules:
    strict_top_level_inference: false

That’s a wrap for Week 3! Let’s see what Week 4 throws at me <3