Constraints in Flutter: The One Concept That Changes Everything

Ashish Tandon — Wed, 08 Apr 2026 09:29:21 +0000

Flutter layout starts feeling predictable once you understand one core idea.

Most UI issues—unexpected sizes, overflow errors, or widgets not behaving as expected—are usually not random. In most cases, they come down to a single concept:

constraints.

The Golden Rule of Flutter Layout

If you remember only one thing about Flutter layout, remember this:

Constraints go down. Sizes go up. Parent sets position.

This simple rule explains how every widget in Flutter is laid out. Once this clicks, many confusing behaviors start making sense.

How Layout Actually Works

Flutter layout is a step-by-step process between parent and child widgets. Each phase has a clear responsibility.

1. Constraints go down

The parent widget tells the child what it is allowed to do. It defines a range using minimum and maximum width and height.

In simple terms:

“You must be at least this big, but no bigger than this.”

This means a child never has complete freedom—it always operates within limits set by its parent.

2. Sizes go up

After receiving constraints, the child decides its size within those limits.

For example:

“Given your rules, I’ll be 100×100.”

A few important points:

The child cannot exceed the constraints
It must choose a size within the allowed range

3. Parent sets position

Once the child reports its size, the parent decides where to place it.

For example:

“I’ll place you at (x: 0, y: 20).”

So layout is not just about size—it also includes positioning, which is always controlled by the parent.

Tight vs Loose Constraints

Understanding this distinction makes many layout behaviors much clearer.

Tight Constraints

In tight constraints, the parent gives an exact size.

“You must be exactly this size.”

This means:

The child has no flexibility
It must strictly follow the given dimensions

Loose Constraints

In loose constraints, the parent provides a range instead of a fixed size.

“You can be any size up to this limit.”

This allows:

The child to choose a smaller size if needed
But it still cannot exceed the maximum limit

Why This Matters

Once you understand constraints, layout stops feeling unpredictable.

You no longer rely on trial and error. Instead, you can reason about what is happening.

For example, instead of asking:

“Why is this widget behaving like this?”

You start asking:

“What constraints is it receiving?”

That shift in thinking makes debugging much easier and more systematic.

Conclusion

Flutter layout is not about manually controlling sizes.

It is about understanding how constraints flow through the widget tree.

Constraints go down. Sizes go up. Parent sets position.

Once you internalize this, many common layout issues become easier to understand—and easier to fix.

Flutter Google Sign-In with google_sign_in 7: Understanding the New Authentication Flow

Ashish Tandon — Tue, 10 Mar 2026 02:29:28 +0000

Starting with google_sign_in ^7.0.0, the plugin underwent a major refactor to support the Android Credential Manager and modern Google Identity Services. This introduced several breaking changes that move away from the traditional “all-in-one” signIn() method.

If you recently upgraded your Flutter project, you may suddenly encounter multiple compilation errors or unexpected behavior.

Common issues include:

GoogleSignIn() constructor no longer exists
signIn() method is removed
accessToken missing from GoogleSignInAuthentication
Account picker not appearing unless initialize() is called

These changes can be confusing at first, but they come from an architectural shift where authentication and authorization are now handled separately.

Let’s go through the changes and how to fix them.

Fix 1 — GoogleSignIn Constructor Removed (Singleton Pattern)

The GoogleSignIn class no longer allows you to create new instances using GoogleSignIn().

To ensure compatibility with the system-level Credential Manager sheet, the plugin now uses a singleton pattern.

Replace your constructor call with:

final googleSignIn = GoogleSignIn.instance;

Fix 2 — Initialization Is Now Mandatory

In previous versions, initialization happened implicitly.
Starting with v7.0.0, you must call and await the initialize() method exactly once before using the plugin.

Call this during app startup (for example in main() or your authentication service initialization):

await GoogleSignIn.instance.initialize();

If initialization is skipped, the authentication sheet may not appear.

Fix 3 — signIn() Replaced by authenticate()

The familiar signIn() method has been replaced by authenticate().

This method triggers the new system-level account picker / Credential Manager sheet on supported Android versions.

Example:

final GoogleSignInAccount googleUser = await GoogleSignIn.instance.authenticate();

Fix 4 — accessToken Missing (Authentication vs Authorization)

This is the biggest architectural change in google_sign_in 7. Google has separated authentication (who the user is) from authorization (what permissions the app has).

After calling authenticate(), you can still obtain the idToken from googleUser.authentication. However, the accessToken is no longer returned automatically. To retrieve it, you must explicitly request scopes using the authorizationClient.

  final clientAuth =
      await googleUser.authorizationClient.authorizeScopes(['email', 'profile']);

Complete google_sign_in 7.0.0+ Implementation

If you need both tokens (for example when integrating with Firebase or other APIs), the following pattern works:

Future<UserCredential> signInWithGoogle() async {
  // 1. Ensure initialization
  final googleSignIn = GoogleSignIn.instance;

  // 2. Authentication (Identity)
  // Triggers the account picker / Credential Manager sheet
  final GoogleSignInAccount googleUser =
      await googleSignIn.authenticate();

  // 3. Authorization (Permissions)
  // Request scopes to retrieve the Access Token
  final List<String> scopes = ['email', 'profile'];
  final clientAuth =
      await googleUser.authorizationClient.authorizeScopes(scopes);

  // 4. Create Firebase Credential
  final credential = GoogleAuthProvider.credential(
    idToken: googleUser.authentication.idToken,
    accessToken: clientAuth.accessToken,
  );

  // 5. Sign in to Firebase
  return await FirebaseAuth.instance.signInWithCredential(credential);
}

IMPORTANT: Make sure GoogleSignIn.instance.initialize() is called once during app startup before invoking signInWithGoogle().

Final Thoughts
If you're upgrading from older versions of google_sign_in, these changes can feel confusing at first because many familiar APIs were removed or redesigned.

However, once you understand the separation between authentication and authorization, the new API flow becomes much clearer and aligns better with modern identity systems.

Hopefully this saves someone else the debugging time.

DEV Community: Ashish Tandon