DEV Community: Flutter with Caio

Stop Relying on MediaQuery for Sizing in Flutter! Here's What to Use Instead

Flutter with Caio — Thu, 17 Oct 2024 22:32:47 +0000

MediaQuery is not the best tool for responsive design in Flutter. Actually, it's far from it.

I know, it’s tempting to scale widgets based on the percentage of screen size and call it a day. But using MediaQuery for sizing, while seemingly simple, is a slippery slope that often leads to weird and problematic layouts.

Unfortunately, many beginners fall into the trap of using fractional sizing because it seems like an easy solution at first.

But if you’re serious about creating responsive apps, it’s time to reconsider how you approach this.

What is Fractional Sizing?

Fractional sizing means sizing UI elements by a fraction of the screen size.

It’s like saying, “I’ll make this button take up 20% of the screen width, no matter what the actual size is.”

Flutter's MediaQuery is the go-to for this kind of approach. Because it provides access to the screen size through MediaQuery.sizeOf(context) and MediaQuery.of(context).size.

For example, you might use code like this:

Container(
  width: MediaQuery.of(context).size.width * 0.2, // or MediaQuery.sizeOf(context).width
  child: Text('Click me!'),
)

It might seem practical—the button size changes depending on the device. But here’s where it gets messy.

Why Fractional Sizing Hurts Your Layouts

The problem is that fractional sizing often leads to a rigid, uninspired layout that doesn’t fully take advantage of each device’s strengths.

Responsiveness isn’t just about making an app fit into the available space—it’s about making your UI adapt to each device's strengths and weaknesses.

By using fractional sizing, you’re essentially making everything fit within the available space, but at the cost of meaningful adaptability. For example, look at this image:

Image from [ping’s notes](https://notes.tst.sh/flutter/media-query/#wouldnt-text-look-too-small-on-large-screens)

Bigger displays allow a larger field of view for the user. Don’t ditch that by just scaling your text up and calling it a day. Let larger screens breathe with more content or features.

Here's a better layout for the tablet:

Image from [ping’s notes](https://notes.tst.sh/flutter/media-query/#wouldnt-text-look-too-small-on-large-screens)

The key point is: what fits great on a small phone might feel unnecessarily large or cramped on a tablet or desktop.

Widgets may occupy a smaller fraction of the screen, but larger displays give more real estate—so why not take advantage of it?

You Don't Need Your Text to Be Bigger

You don't need to size your font based on the screen size. For example:

Image from [ping’s notes](https://notes.tst.sh/flutter/media-query/#wouldnt-text-look-too-small-on-large-screens)

It is noticeable that the text is as visible to the tablet user as it is for the smartphone user. It's perfectly fine to use static values for font sizes.

A responsive layout shouldn’t just be resized—it should reorganize and realign itself to make the most out of each device's capabilities.

Overflow Errors? Not If You Manage Your Constraints Right

Now, you might be thinking, "If I don't size elements based on device size, won’t I run into overflow issues?"

Overflow errors are less about using fractional sizing and more about not respecting the given constraints.

The real secret to avoiding overflow isn’t about scaling elements—it’s about managing constraints effectively.

When you’re working with Rows or Columns, use Flexible or Expanded to ensure children adjust to the space allowed by their parent widgets. Flutter's built-in layout widgets are great for managing how much space each child takes.

Take a look at this example:

Row(
  children: [
    Flexible(
      child: Container(color: Colors.blue),
    ),
    Flexible(
      child: Container(color: Colors.red),
    ),
  ],
)

With Flexible, the children are set to adjust their size based on the available space, ensuring they fill the Row without causing overflow issues. This way, you can avoid common layout problems while letting Flutter handle the details.

Conclusion

To sum it up: responsiveness is about adapting your layout to the strengths of each device—not just making everything look the same.

Avoid the pitfalls of fractional sizing with MediaQuery and, instead, let Flutter's layout widgets do the heavy lifting. Trust your constraints, leverage Flexible and Expanded, and design with LayoutBuilder to create adaptive UIs.

The next time you find yourself reaching for MediaQuery to scale your widgets, take a step back. Think: is this making the most of the device's characteristics, or am I just trying to make everything look identical? Start building layouts that respect the user’s device, and your apps will be better for it.

What’s holding you back from ditching fractional sizing today? Give it a go—your users (and future self) will thank you.

Design Patterns vs. Architectural Patterns: Stop the Confusion

Flutter with Caio — Fri, 11 Oct 2024 17:10:12 +0000

Do you know the difference between design patterns and architectural patterns?

If you're unsure about the answer, relax—you're not alone. By the end of this, you'll know clear-cut difference, and maybe you'll get a chance to show off your knowledge in a round of friends.

However, if you want to be ahead of most developers, this is a must.

Knowing when to use each can help you build applications faster and make them easier to manage.

Let's dive in and clear up the mystery.

What Are Design Patterns?

Design patterns are essential, reusable solutions to recurring coding problems.

They help solve smaller, specific problems you often face during coding—like managing object creation or decoupling components.

Categories of Design Patterns

The concept of design patterns was popularized by the "Gang of Four" (GoF) in their classic book Design Patterns: Elements of Reusable Object-Oriented Software.

In this book, they introduced three main categories of design patterns: Creational, Structural, and Behavioral.

Creational Patterns provide techniques for creating objects in a flexible and controlled way, reducing complexity. Examples include Singleton and Factory.
Structural Patterns help organize objects and classes to form larger, more efficient structures. Examples include Adapter and Composite.
Behavioral Patterns manage communication between objects to ensure flexible interactions. Examples include Observer and Strategy.

Over the past decades, new design patterns have been discovered as the software development landscape has evolved. Examples are Dependency Injection, Event Sourcing, and CQRS (Command Query Responsibility Segregation).

Purpose and Benefits

Solve coding problems by providing targeted solutions.
Make code consistent by using common approaches.
Make components reusable for efficient development.
Simplifies the understanding of your team coworkers about your code with common patterns.
Reduce complexity in specific parts of your code.

When to Use Design Patterns

Design patterns are used during the coding phase of development.

What Are Architectural Patterns?

Architectural patterns are essential, reusable solutions to recurring system-level problems.

While design patterns handle lower-level problems, architectural patterns take a broader view.

They focus on organizing your application's overall architecture—they’re the blueprints for how your system functions as a whole.

Examples of Architectural Patterns

Layered Architecture separates the system into layers like presentation, business logic, and data.
MVC (Model-View-Controller) organizes code to separate data, UI, and control logic.
Microservices split the system into smaller, independent services.

Purpose and Benefits

Shape the system's structure with high-level solutions.
Make your project foundation scalable so it's ready for growth.
Set clear boundaries to make system management easier.
Improve interactions between different system parts.
Provide stability as your app evolves over time.

When to Use Architectural Patterns

Architectural patterns are used during the planning phase, before you even start coding, to shape how different parts of your system will interact.

The Clear-Cut Differences You Need to Know

You must have noted some differences between them already. Let's clarify these points.

Abstraction Level

Design Patterns work at a low level to solve specific implementation problems.
Architectural Patterns operate at a high level to organize the system.

Scope

Design Patterns affect specific sections of code.
Architectural Patterns impact the entire system.

Development Stage
Design Patterns are applied during the development stage.
Architectural Patterns are decided in the planning phase.

Example

Imagine you're starting a project from scratch and need to figure out how to organize the entire system.

You might decide to use MVC (architectural pattern) to lay the foundation—breaking up the user interface, business logic, and data layer to keep everything organized and manageable as the project grows.

During the coding phase, you come across a problem: you need to notify multiple parts of your app when an event happens.

This is where a design pattern like the Observer pattern (design pattern) comes into play. It helps you efficiently update multiple views whenever data changes.

Why Are They So Easy to Confuse?

It’s no wonder developers often confuse design and architectural patterns—they do have some similarities in practice.

Terminology Confusion

Patterns like MVC can be used as an architectural pattern or a design pattern, depending on the context.

When structuring the entire system, MVC acts as an architectural pattern to organize components.

When coding a specific feature, MVC can also serve as a design pattern to manage interactions in an OOP context between parts of that feature.

Same Goals

Both design and architectural patterns are typical solutions to common problems. When a solution is repeated across projects, it eventually gets a name and becomes a pattern.

The key here is scope: architectural patterns work on the macro level, while design patterns focus on the micro.

Conclusion

So, now you know the difference between design patterns and architectural patterns.

Not just the definition, but when and why to use each one.

Remember, it’s not just about having the right tools, but knowing when to reach for each one. Next time you're working on a project, take a second to think—is this a design pattern moment, or do you need to step back and consider the architecture?

Mastering both approaches will make you develop systems better and faster.

Ready to put this into practice and level up your skills? Start here and now. You've got this.

Stop Using MediaQuery.of! Try These 15 More Efficient Alternatives Instead

Flutter with Caio — Sun, 06 Oct 2024 18:47:41 +0000

MediaQuery.of should no longer be a default tool in your Flutter toolbox.

Why? Well, if you’ve been using MediaQuery.of(context) religiously, you might be introducing unnecessary rebuilds into your app. This leads to inefficiencies that can slow down your app and cause performance hiccups, especially in complex UIs.

Instead of falling into this trap, I’m going to show you 15 more efficient alternatives that will streamline your code and optimize your app’s performance.

By the end of this article, you'll have learned how to write cleaner and more efficient Flutter code with the latest context-specific getters. Ready to optimize your app? Let’s dive in!

What Is MediaQuery?

MediaQuery is a class in Flutter that gives you access to essential device information such as screen size, device orientation, text scaling factor, and more. It’s often used in Flutter apps to make your UI adaptive across various devices.

Some typical use cases of MediaQuery include:

Screen Size: Detecting the device's width and height.
Device Orientation: Checking if the device is in portrait or landscape mode.
Text Scaling: Adjusting text size based on user preferences.
Insets (e.g., Keyboard): Knowing when the keyboard is shown or system bars are present.
Dark Mode Detection: Identifying whether the system is in light or dark mode.
Accessibility Navigation: Understanding if accessibility features, like VoiceOver, are active.
Reduced Animations: Determining if users prefer reduced animations.

But here's the problem: using MediaQuery.of(context) can trigger widget rebuilds unnecessarily, especially if you're using it across multiple widgets.

Why does this happen? MediaQuery.of(context) returns a MediaQueryData object containing multiple device properties (e.g., screen size, orientation). When any property in this object changes, Flutter rebuilds the widget, even if you're only using one specific property. This can cause unnecessary rebuilds and performance issues.

It’s time to move beyond MediaQuery.of and try these newer, more efficient alternatives.

15 Better Alternatives to MediaQuery.of

1. Retrieving Screen Size

Use MediaQuery.sizeOf(context) instead of MediaQuery.of(context).size.

Example:

final size = MediaQuery.sizeOf(context);
final width = size.width;
final height = size.height;

return Container(
  width: width * 0.8, // 80% of screen width
  height: height * 0.3, // 30% of screen height
  color: Colors.blue,
);

Benefit: It rebuilds the widget only when the screen size changes.

(For responsive layouts, a better option might be using LayoutBuilder. Learn more on https://api.flutter.dev/flutter/widgets/LayoutBuilder-class.html)

And if you want to avoid exceptions when no MediaQuery ancestor exists, use maybeSizeOf(context).

2. Device Orientation

Use MediaQuery.orientationOf(context) instead of MediaQuery.of(context).orientation.

Example:

final orientation = MediaQuery.orientationOf(context);

return orientation == Orientation.portrait
  ? Column(children: [...])
  : Row(children: [...]);

Benefit: Rebuilds only when the device orientation changes.

For cases without a MediaQuery ancestor, use maybeOrientationOf(context).

3. Text Scaling Factor

Use MediaQuery.textScalerOf(context) instead of MediaQuery.of(context).textScaleFactor.

Example:

final textScaleFactor = MediaQuery.textScalerOf(context);

return Text(
  'Responsive Text',
  style: TextStyle(fontSize: 16 * textScaleFactor),
);

Benefit: It listens only to changes in the text scaling factor, preventing unnecessary rebuilds.

Use maybeTextScalerOf(context) if you don’t want it to throw an error.

4. System Padding (Insets)

Use MediaQuery.viewInsetsOf(context) instead of MediaQuery.of(context).viewInsets.

Example:

final insets = MediaQuery.viewInsetsOf(context);

return Padding(
  padding: EdgeInsets.only(bottom: insets.bottom),
  child: TextField(),
);

Benefit: Reacts only when insets like the keyboard visibility change.

For a null-safe alternative, use maybeViewInsetsOf(context).

5. Dark Mode Detection (Brightness)

Use MediaQuery.platformBrightnessOf(context) instead of MediaQuery.of(context).platformBrightness.

Example:

final brightness = MediaQuery.platformBrightnessOf(context);

return brightness == Brightness.dark
  ? ThemeData.dark()
  : ThemeData.light();

Benefit: Rebuilds only when the system changes between dark and light mode.

Use maybePlatformBrightnessOf(context) for additional safety.

6. Handling Accessibility Navigation

Use MediaQuery.accessibleNavigationOf(context) instead of MediaQuery.of(context).accessibleNavigation.

Example:

final accessibleNavigation = MediaQuery.accessibleNavigationOf(context);

return accessibleNavigation
  ? Text('VoiceOver is enabled')
  : Text('Normal mode');

Benefit: Detects accessibility navigation changes without triggering unwanted rebuilds.

Use maybeAccessibleNavigationOf(context) to return null when no MediaQuery ancestor is found.

7. Handling Device Pixel Ratio

Use MediaQuery.devicePixelRatioOf(context) instead of MediaQuery.of(context).devicePixelRatio.

Example:

final pixelRatio = MediaQuery.devicePixelRatioOf(context);

return Container(
  width: 100 * pixelRatio,
  height: 100 * pixelRatio,
);

Benefit: Updates only when the pixel density changes.

For a null-safe version, use maybeDevicePixelRatioOf(context).

8. Handling Bold Text Accessibility

Use MediaQuery.boldTextOf(context) instead of MediaQuery.of(context).boldText.

Example:

final boldText = MediaQuery.boldTextOf(context);

return Text(
  'Accessible Text',
  style: TextStyle(fontWeight: boldText ? FontWeight.bold : FontWeight.normal),
);

Benefit: Detects changes in bold text accessibility without unnecessary rebuilds.

For safer handling, use maybeBoldTextOf(context).

9. Detecting Animation Preferences

Use MediaQuery.disableAnimationsOf(context) instead of MediaQuery.of(context).disableAnimations.

Example:

final disableAnimations = MediaQuery.disableAnimationsOf(context);

return disableAnimations
  ? Container()
  : AnimatedOpacity(
      opacity: 1.0,
      duration: Duration(seconds: 2),
      child: Text('Animation'),
    );

Benefit: Rebuilds the widget only when the user’s animation preferences change.

Use maybeDisableAnimationsOf(context) for null safety.

10. Detecting High Contrast Mode

Use MediaQuery.highContrastOf(context) instead of MediaQuery.of(context).highContrast.

Example:

final highContrast = MediaQuery.highContrastOf(context);

return highContrast
  ? Text('High Contrast Text', style: TextStyle(color: Colors.black))
  : Text('Normal Contrast Text', style: TextStyle(color: Colors.grey));

Benefit: Updates only when high contrast mode changes.

For a null-safe version, use maybeHighContrastOf(context).

11. Handling Inverted Colors

Use MediaQuery.invertColorsOf(context) instead of MediaQuery.of(context).invertColors.

Example:

final invertColors = MediaQuery.invertColorsOf(context);

return ColorFiltered(
  colorFilter: invertColors
    ? ColorFilter.mode(Colors.white, BlendMode.difference)
    : ColorFilter.mode(Colors.transparent, BlendMode.multiply),
  child: Image.asset('image.png'),
);

Benefit: Reacts only when color inversion changes.

For null safety, use maybeInvertColorsOf(context).

12. Handling Gesture Settings

Use MediaQuery.gestureSettingsOf(context) instead of MediaQuery.of(context).gestureSettings.

Example:

final gestureSettings = MediaQuery.gestureSettingsOf(context);

return gestureSettings.touchSlop > 0
  ? Text('Gesture Detected')
  : Text('No Gesture Detected');

Benefit: Listens for changes in gesture settings without triggering unnecessary rebuilds.

Use maybeGestureSettingsOf(context) if you need null safety.

13. Detecting Display Features

Use MediaQuery.displayFeaturesOf(context) instead of MediaQuery.of(context).displayFeatures.

Example:

final displayFeatures = MediaQuery.displayFeaturesOf(context);

return Text(displayFeatures.isNotEmpty ? 'Cutout Detected' : 'No Cutout');

Benefit: Updates only when display features like cutouts or foldables change.

For null safety, use maybeDisplayFeaturesOf(context).

14. Handling System Padding

Use MediaQuery.paddingOf(context) instead of MediaQuery.of(context).padding.

Example:

final padding = MediaQuery.paddingOf(context);

return Padding(
  padding: EdgeInsets.all(padding.top),
  child: Text('Padded Text'),
);

Benefit: Rebuilds only when system UI padding changes.

To avoid exceptions, use maybePaddingOf(context).

15. Detecting System Gesture Insets

Use MediaQuery.systemGestureInsetsOf(context) instead of MediaQuery.of(context).systemGestureInsets.

Example:

final systemGestureInsets = MediaQuery.systemGestureInsetsOf(context);

return Padding(
  padding: systemGestureInsets,
  child: Text('Gesture Insets Applied'),
);

Benefit: Reacts only when system gesture insets change.

For a safer implementation, use maybeSystemGestureInsetsOf(context).

Conclusion

There you have it! 15 better alternatives to using MediaQuery.of(context) that can significantly improve your app’s performance by preventing unnecessary widget rebuilds. These new methods are more specific and efficient, and they’ll help you build Flutter apps with ease.

Try them out and let me know how they work for you! As always, feel free to reach out if you have any questions or want to share your results. Happy coding! 🚀

6 Critical Flutter Development Mistakes That Cause App Crashes (and How to Avoid Them)

Flutter with Caio — Thu, 03 Oct 2024 17:43:51 +0000

The most common cause of app crashes is simple mistakes that developers often ignore.

You’ve been there. You launch your Flutter app, excited to see it in action—only to have it crash right before your eyes. Frustrating, right?

App crashes are the silent killer of user satisfaction. A single crash can make users abandon your app and, as a developer, nothing feels worse than hours of hard work unraveling in a few seconds.

The good news? Most crashes are preventable.

Here are six common Flutter development mistakes that lead to crashes—and more importantly, how you can avoid them.

1. Neglecting Error Handling in Async Operations

One of the most common Flutter mistakes? Ignoring error handling in asynchronous operations. Silent failures in async functions can result in crashes without clear explanations.

For instance, imagine you're calling an API, and the request fails:

Future<void> fetchData() async {
  await http.get('https://example.com/data');
}

Here’s the problem: if the request fails, nothing is caught. The app will crash, and the user will see nothing. To fix this, you should always handle errors with a try-catch block:

Future<void> fetchData() async {
  try {
    await http.get('https://example.com/data');
  } catch (e) {
    // Handle the error
    print('Error fetching data: $e');
  }
}

By handling errors properly, you can display a friendly message to your users instead of letting the app crash.

2. Using Heavy Build Methods with Complex UI

A common cause of performance dips or crashes is placing too much logic inside the build() method, especially for complex UIs. This leads to unnecessary re-renders, causing slow performance and potential crashes.

Here’s an example of an overloaded build() method:

@override
Widget build(BuildContext context) {
  return Column(
    children: [
      Text(fetchDataFromApi()), // Complex logic here
      HeavyWidget(), // Another performance-heavy widget
    ],
  );
}

Instead, keep your build() methods lightweight by moving complex logic to helper functions, controllers, or state management solutions. Also, use the const keyword wherever possible to optimize rebuilds:

@override
Widget build(BuildContext context) {
  return Column(
    children: const [
      SimpleWidget(), // Using const here improves performance
      HeavyWidget(),
    ],
  );
}

By keeping your build methods lean, you’ll ensure your UI remains smooth and responsive.

3. Overloading the Main Thread with Heavy Operations

Blocking the main thread by running heavy operations on it can lead to frozen UIs and frustrated users. For example, reading a large file directly on the main thread is a recipe for disaster:

void readLargeFile() {
  final file = File('large_file.txt');
  final contents = file.readAsStringSync(); // Blocking operation
  print(contents);
}

Instead, you can offload this operation to a background thread using Flutter’s compute() function:

Future<void> readLargeFile() async {
  final contents = await compute(_readFile, 'large_file.txt');
  print(contents);
}

String _readFile(String path) {
  final file = File(path);
  return file.readAsStringSync();
}

This way, you keep the UI thread responsive while performing the heavy file operation in the background.

4. Ignoring Proper Memory Management with Streams

Streams are fantastic for handling data in Flutter, but failing to close them properly can cause memory leaks, leading to crashes over time. A common mistake is forgetting to close streams when they’re no longer needed:

StreamSubscription<int> _subscription;

void initState() {
  super.initState();
  _subscription = myStream.listen((data) {
    // Do something with data
  });
}

@override
void dispose() {
  // Forgetting to close the stream!
  super.dispose();
}

Make sure you close your streams:

@override
void dispose() {
  _subscription.cancel();
  super.dispose();
}

This prevents unnecessary memory buildup and ensures your app stays stable.

5. Overusing Global Variables Across the App

Global variables might seem like a quick solution, but overusing them creates conflicts and hard-to-track crashes. Here’s an example of global overuse:

int globalCounter = 0;

Instead of using global variables, a better solution is to implement Dependency Injection (DI) like Provider or use service locators like get_it.

Here’s how you can use Provider for DI:

class MyService {
  void doSomething() {
    print('Doing something');
  }
}

void main() {
  runApp(
    MultiProvider(
      providers: [
        Provider(create: (_) => MyService()),
      ],
      child: MyApp(),
    ),
  );
}

class MyHomePage extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    final myService = Provider.of<MyService>(context);

    return Scaffold(
      appBar: AppBar(title: Text('Home')),
      body: Center(
        child: ElevatedButton(
          onPressed: () {
            myService.doSomething();
          },
          child: Text('Call Service'),
        ),
      ),
    );
  }
}

Using DI or service locators keeps your codebase clean and helps avoid the chaotic behavior that globals can introduce.

6. Skipping Comprehensive Testing on Different Platforms

Testing your Flutter app only on a single platform is a recipe for disaster. Flutter runs on iOS, Android, Web, and more, but platform-specific quirks can cause crashes if you don’t test thoroughly.

For example, file paths may work differently on iOS versus Android. Make sure to write platform-aware code:

if (Platform.isAndroid) {
  // Handle Android-specific logic
} else if (Platform.isIOS) {
  // Handle iOS-specific logic
}

To avoid platform-specific crashes, test on all target platforms and use Flutter’s Device Preview to catch potential issues early.

That's it!

By avoiding these six common Flutter mistakes, you’ll reduce crashes, optimize performance, and deliver a smooth experience for your users.

Your app deserves to shine—and it will, with a few careful tweaks.

Ready to take your Flutter skills to the next level? Start refactoring today, and feel free to reach out with any questions.

DEV Community: Flutter with Caio

Stop Relying on MediaQuery for Sizing in Flutter! Here's What to Use Instead

What is Fractional Sizing?

Why Fractional Sizing Hurts Your Layouts

You Don't Need Your Text to Be Bigger

Overflow Errors? Not If You Manage Your Constraints Right

Conclusion

Design Patterns vs. Architectural Patterns: Stop the Confusion

What Are Design Patterns?

Categories of Design Patterns

Purpose and Benefits

When to Use Design Patterns

What Are Architectural Patterns?

Examples of Architectural Patterns

Purpose and Benefits

When to Use Architectural Patterns

The Clear-Cut Differences You Need to Know

Abstraction Level

Scope

Development Stage

Example

Why Are They So Easy to Confuse?

Terminology Confusion

Same Goals

Conclusion

Stop Using MediaQuery.of! Try These 15 More Efficient Alternatives Instead

What Is MediaQuery?

15 Better Alternatives to MediaQuery.of

1. Retrieving Screen Size

Example:

2. Device Orientation

Example:

3. Text Scaling Factor

Example:

4. System Padding (Insets)

Example:

5. Dark Mode Detection (Brightness)

Example:

6. Handling Accessibility Navigation

Example:

7. Handling Device Pixel Ratio

Example:

8. Handling Bold Text Accessibility

Example:

9. Detecting Animation Preferences

Example:

10. Detecting High Contrast Mode

Example:

11. Handling Inverted Colors

Example:

12. Handling Gesture Settings

Example:

13. Detecting Display Features

Example:

14. Handling System Padding

Example:

15. Detecting System Gesture Insets

Example:

Conclusion

6 Critical Flutter Development Mistakes That Cause App Crashes (and How to Avoid Them)

1. Neglecting Error Handling in Async Operations

2. Using Heavy Build Methods with Complex UI

3. Overloading the Main Thread with Heavy Operations

4. Ignoring Proper Memory Management with Streams

5. Overusing Global Variables Across the App

6. Skipping Comprehensive Testing on Different Platforms

That's it!