In Flutter, the Widget class includes a constructor that can take a Key as an

optional parameter. Here is an example

abstract class Widget extends DiagnosticableTree {
  const Widget({ this.key });
  
  final Key? key;
  // Other properties and methods...
}

In Flutter, several types of keys exist and they are mainly categorized into Local and Global Key.

Standard LocalKeys:

• ValueKey: This key uses a stable value, such as a string or an integer, to uniquely identify a widget within its parent. It’s efficient and well-suited for lists, grids, or widgets with a unique identifier.
• ObjectKey: This key relies on object reference equality to uniquely identify a widget. It’s suitable for situations where the object instance itself remains the same even if its properties change.
• UniqueKey: While commonly used, it’s not technically a LocalKey because it generates a globally unique identifier every time it’s created. However, it can be used within a specific parent context to achieve uniqueness within that scope.

Standard GlobalKeys:

• GlobalKey: This key provides a unique identifier across your entire app. This means you can access and manipulate a widget from anywhere in the widget tree, regardless of their location.

UniqueKey

A UniqueKey is a special type of Key that guarantees uniqueness within your entire app. This means no two UniqueKey instances will ever be the same. It’s essentially a random identifier generated Automatically when you create a new UniqueKey object.

It’s most commonly used when you need to uniquely identify widgets that are dynamically added, removed, or reordered within your UI.

List<String> items = ['Item 1', 'Item 2', 'Item 3'];

ListView.builder(
  itemCount: items.length,
  itemBuilder: (context, index) => Text(
    key: UniqueKey()
    items[index],
    ),
);

ValueKey

A ValueKey is a type of Key in Flutter that uses a value to uniquely identify a widget. Unlike UniqueKey, which generates random identifiers, ValueKey relies on the provided value for uniqueness.

When you have a stable, unique identifier for your widget that does not change over time. For example:

• Database IDs
• User IDs

List<Product> products = [...];

ListView.builder(
  itemCount: products.length,
  itemBuilder: (context, index) => ProductItem(
    product: products[index],
    key: ValueKey<int>(products[index].id),
  ),
);

ObjectKey

ObjectKey is another type of key you can use to uniquely identify widgets. This key suits complex data structures where the widget’s identity is tied to the object’s identity. For eg. You have a widget whose properties change over time, but you want to treat it as the same widget for state management purposes. Think of a shopping cart item whose quantity changes, but it remains the same item.

Here is an example

class User {
  final String name;
  final int age;

  User(this.name, this.age);
}

List<User> users = [...];

ListView.builder(
  itemCount: users.length,
  itemBuilder: (context, index) => UserCard(
    user: users[index],
    key: ObjectKey(users[index]),
  ),
);

In this example, each UserCard has an ObjectKey based on the specific User object instance. Even if the user’s age changes, the widget maintains its state (e.g., item selection) because it recognizes the object hasn’t truly changed.

GlobalKey

A GlobalKey is a powerful but sometimes tricky tool for accessing widgets throughout your app’s widget tree. It is unique across your entire app, unlike UniqueKey or ValueKey which are scoped within their parent widget trees. It enables you to directly access the state and properties of a widget from anywhere in your code, regardless of its location in the widget tree.

A practical use case is a form widget where you want to access its state from a different part of your app to perform actions like validation or data submission.

Here is an example

final _formKey = GlobalKey<FormState>();

Form(
  key: formKey,
  child: Column(
    childeren: [
      TextFormField(),
    ],
  ),
);

// validate form
if (formKey.currentState.validate()) {
  // Process data
}

Do you know why do we use a GlobalKey in Form? A simple answer would be to access the Form currentState and validate.

PageStorageKey

PageStorageKey plays a crucial role in preserving widget state across navigation changes. It enables widgets within app pages to store and restore their state when the user navigates back and forth between them. For example, in Flutter it helps to preserve the scroll position of scrollable widgets. This means that when you have a scrollable widget like a ListView, and you leave the page and return back to it, the ListView will scroll back to the position where it was left.

PageStorageKey uses the PageStorage, which finds the nearest PageStorage ancestor from the widget tree and accedes storage to that widget. The PageStorage is usually introduced automatically via the MaterialPage or CupertinoPage.

ListView.builder(
  key: PageStorageKey<String>('news-list'),
  itemBuilder: (BuildContext context, int index) {
    return ListTile(
      title: Text('Article $index'),
    );
  },
);

The post Keys in Flutter appeared first on WeCanCode.

Widget

In Flutter, widgets are the fundamental building blocks you use to construct your app’s user interface. They are immutable descriptions of what parts of your UI should look like and how they should behave. Think of them as the Lego bricks or building blocks of your app’s design.

Element

An element in Flutter represents a specific instance of a widget at a particular location in the widget tree. Unlike widgets which are just blueprints, elements are the actual implementations of those blueprints in the running app. They hold additional information like the state of the widget and its location in the tree.

Render Objects

Render objects play a crucial role in taking the declarative descriptions of widgets (defined in the widget tree) and translating them into actual pixels on the screen. They handle the layout, painting, and interaction of UI elements. Unlike widgets which you interact with directly in your code, render objects operate quietly in the background, responsible for the actual rendering of your UI. Each widget in the widget tree has a corresponding render object in the render object tree. This render object takes the information from the widget (size, color, positioning) and uses it to draw the element on the screen.

Flutter utilizes three distinct trees to manage its rendering process:

Widget Tree: This is the tree you directly interact with as a developer. It represents the declarative structure of your app’s UI, composed of widgets that define how elements look and behave. Imagine the Widget Tree as a blueprint for your app’s interface.

Element Tree: For each widget that you create in Widget Tree, the Flutter framework will create an element into Element Tree using the createElement() method. This tree acts as a bridge between the Widget Tree and the RenderObject Tree. It mirrors the Widget Tree but holds additional information like the state of each widget and its corresponding location in the UI hierarchy. Think of the Element Tree as a dynamic representation of the Widget Tree, reflecting any changes made to the widgets.

RenderObject Tree: This tree is responsible for the actual rendering of the UI on the screen. It translates the information from the Element Tree into instructions for the underlying graphics system. For each element in the Element Tree, the Flutter framework creates a RenderObject using the createRenderObject() method on a Widget. RenderObjects store basic details of widgets like child position, basic layout, paint protocols, etc.

These three trees work together seamlessly to ensure an efficient and performant rendering process. When you make changes to your UI code, Flutter only updates the necessary parts of these trees, minimizing the amount of work required to reflect the changes on the screen.

Understanding these three trees is crucial for writing efficient and performant Flutter apps. By knowing how they interact, you can make informed decisions about your UI structure and code optimization strategies.

The post How Flutter Renders Widgets appeared first on WeCanCode.

Flutter uses three types of languages

1. The framework layer is written in Dart for application layer development.
2. The engine layer is written in C/C++ and used for graphics rendering.
3. The embedder layer is written in the embedding layer languages. For example, iOS uses Objective-C/swift, while Android uses Java/Kotlin.

When it comes to the memory used by Flutter, it refers to the sum memory of the three layers and it’s a virtual memory that is assigned to app, it does not have to do anything with Physical memory in your device.

What is a Memory Leak?

In computer science, a memory leak is a type of resource leak that occurs when a computer program incorrectly manages memory allocations in a way that memory which is no longer needed is not released.

Source Wikipedia

Memory leaks happen in Dart?

As we saw previously in Dart Memory Management are done automatically using a Garbage collector but it cannot prevent all types of Memory Leak In Dart/Flutter, and developers still need to watch objects that can lead to memory leak.

How do memory leaks occur?

Memory Leak In Dart/Flutter can happen when an object is still being referenced in (heap) memory but is no longer being used. Some common cause is the presence of unused objects that remain in memory due to caching, improper use on BuildContext or failure to remove listeners when they are no longer needed.

Why can’t the garbage collector prevent all leaks?

While the garbage collector takes care of all unreachable objects, it’s the responsibility of the application to ensure that unneeded objects are no longer reachable (referenced from the root object).

So, if non needed objects are left referenced (in a global or static variable, or as a field of a long-living object), the garbage collector can’t recognize them, the memory allocation grows progressively, and the app eventually crashes with an out-of-memory error.

here is an example

class Leak {
  Leak();
  Timer? timer;

  void leakTest() {
    // Time callback can lead to memory leak
    // Leak class can be destroyed but the timer can continue to run 
    timer = Timer.periodic(const Duration(seconds: 1), (timer) { 
      print(timer.tick);
    });    
  }
}

In the above example we have a Timer callback but we have no way to cancel the timer once the task is completed, Timer will hang around in memory unless we cancel it, which can lead to Memory Leak.

class LeakScreen extends StatefulWidget {
  final Leak leak;
  const LeakScreen({ Key? key, required this.leak }) : super(key: key);

  @override
  _LeakScreenState createState() => _LeakScreenState();
}

class _LeakScreenState extends State<LeakScreen> {
  List<int> _numbers = [1,2,3,4,5];
  
  @override
  void initState() {
    super.initState();
    // execute method
    widget.leak.leakTest();
    
  }

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar()
      ,
      body: ListView.builder(
        itemCount: _numbers.length,
        itemBuilder: (context, index) {
          return Text('Number: ${_numbers[index]}');
        },
      ),
    );
  }

}

import 'package:flutter/material.dart';
import 'package:flutter_basic/leak.dart';
import 'package:flutter_basic/screen/leak_screen.dart';
import 'package:flutter_basic/screen/test_screen.dart';

class RowWidget extends StatelessWidget {
  RowWidget({super.key});
  
  // create a n object of Leak class
  // this can lead to memory leak  as Leak object can't be GC 
  // as long as there is a reference to RowWidget
  // you need to make sure RowWidget is disposed properly once it's not needed
  final leak = Leak();

  @override
  Widget build(BuildContext context) {
    return ColoredBox(
      color: Colors.black45,
      child: Row(        
        children: [         
            OutlinedButton(
              onPressed: () {                
                Navigator.push(
                  context, 
                  MaterialPageRoute(builder: (_) => LeakScreen(leak: leak,)));
              }, 
              child: Text('Leak'),
            ),
            OutlinedButton(
              onPressed: () {
                Navigator.push(
                  context, 
                  MaterialPageRoute(builder: (_) => const TestScreen()));
              }, 
              child: Text('Leak'),
            )
        ],
      ),
    );
  }
}

In the above example we are passing leak object to LeakScreen(leak: leak) since we are constructing a Leak object in RowWidget class, as long as the root object has a reference to RowWidget Leak object can’t be GC which can lead to Memory Leak, we need to make sure that RowWidget is properly disposed once it’s not required.

How to Fix a above code?

Here is the example

class Leak {
  Leak();
  Timer? timer;

  void leakTest() {
    timer = Timer.periodic(const Duration(seconds: 1), (timer) { 
      print(timer.tick);
    });
    
  }
  // add a dispose method to clean unwanted resources
  void dispose() {
    print('dispose');
    timer?.cancel();
  }
}

In the above class we have added a dispose() to clean all the unwanted resource allocation

import 'package:flutter/material.dart';
import 'package:flutter_basic/leak.dart';


class LeakScreen extends StatefulWidget {
  const LeakScreen({ Key? key }) : super(key: key);

  @override
  _LeakScreenState createState() => _LeakScreenState();
}

class _LeakScreenState extends State<LeakScreen> {
  List<int> _numbers = [1,2,3,4,5];
  
  // create a nullable variable of leak object
  Leak? leak;
  
  @override
  void initState() {
    super.initState();
    // construct a Leak class object
    leak = Leak();
    // run the function
    leak?.leakTest();
    
  }

  @override
  void dispose() {
    // dispose the leak object
    leak?.dispose();
    // assign null to leak object - ready for GC
    leak = null;
    super.dispose();
  }

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(),
      body: ListView.builder(
        itemCount: _numbers.length,
        itemBuilder: (context, index) {
          return Text('Number: ${_numbers[index]}');
        },
      ),
    );
  }

}

In the above example we have move the Leak class from constructor to state class and initialized it in initState method and properly dispose it in dispose method, in this way Leak object is ready for GC as soon as we dispose the LeakScreen

Here is an another example

class MyWidget extends StatefulWidget {
  @override
  _MyWidgetState createState() => _MyWidgetState();
}

class _MyWidgetState extends State<MyWidget> {
  StreamSubscription _subscription;

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

  @override
  Widget build(BuildContext context) {
    return Container();
  }
}

In the example above, _MyWidgetState subscribes to someStream in its initState method. However, it does not unsubscribe from the stream when the widget is disposed. This could cause a memory leak if someStream continues to produce data even after MyWidget has been removed from the widget tree.

How to fix the above code?

class MyWidget extends StatefulWidget {
  @override
  _MyWidgetState createState() => _MyWidgetState();
}

class _MyWidgetState extends State<MyWidget> {
  StreamSubscription _subscription;

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

  // unsubscribe to stream
  @override
  void dispose() {
    _subscription.cancel(); // Unsubscribe to avoid memory leak
    super.dispose();
  }

  @override
  Widget build(BuildContext context) {
    return Container();
  }
}

In the above example we have added a dispose method in which we have cancel the Stream subscription.

How to prevent a Memory Leak in Flutter?

Here are some of the point that you can follow to prevent a Memory leak in Flutter:

• Proper Disposal of Objects: Always dispose of objects when they are no longer needed by utilizing the disposal method in the Stateful Widget. This ensures that any associated resources are released and prevents unnecessary memory consumption.
• Manage Streams Properly: When subscribing to a Stream, make sure to unsubscribe (cancel the subscription) when you’re done using it. This is particularly important in the case of StatefulWidgets, where you commonly subscribe in initState() and should unsubscribe in dispose().
• Avoid Long-Lived Global Keys: If you use a GlobalKey and it’s referenced globally, this could lead to memory leaks. Instead, consider using other types of keys like LocalKey or ValueKey, or pass the context as a parameter.
• Manage Controllers: If you’ve created any controllers (like TextEditingController, AnimationController, etc.), they should be disposed of when the widgets using them are disposed to prevent memory leaks.
• Avoid Persisting BuildContext: Don’t persist the BuildContext in a long-lifetime object or class. The context should exist during the widget’s lifecycle and should be discarded when the widget is disposed.
• Resolve Callbacks: If you’ve attached callbacks to a widget like Timer.periodic, and that widget gets disposed, the callback may still hang around in memory. If the callback references other objects, those will also be retained. Be sure to nullify your callbacks where appropriate.

Memory leak vs memory bloat

In a Memory leak, an application progressively uses memory, for example, by repeatedly creating a listener, but not disposing it.

Memory bloat uses more memory than is necessary for optimal performance, for example, by using overly large images or keeping streams open through their lifetime.

Both leaks and bloats, when large, cause an application to crash with an out-of-memory error. However, leaks are more likely to cause memory issues, because even a small leak, if repeated many times, leads to a crash.

The post Memory Leak In Dart/Flutter appeared first on WeCanCode.

As we have learned in our previous post Introduction to Garbage Collection, Dart automatically manage memory for use using Garbage Collection, unlike other programming C, C++ where the developer have to manage memory allocate or deallocate manually. Even though Dart automatically manages the Memory it is crucial to understand how it works to build a efficient and performative app failing to do so can lead to a Memory Leak in your are app which in return can will lead to slow and buggy app.

How Dart Allocates Memory

Dart objects created using a class constructor (for example, by using MyClass()) live in a portion of memory called the heap. The memory in the heap is managed by the Dart VM (virtual machine). The Dart VM allocates memory for the object at the moment of the object creation, and releases (or deallocates) the memory when the object is no longer used

Here’s a simple example:

class Person { 
  int age = 20; 
} 
void main() { 
  // Memory is allocate for object Person 
  // Memory is allocated for the age variable within the myCar object. 
  // The age variable will have an initial value of 20, 
  // as specified in the class definition. 
  final person = Person(); print(person.age) 
}

Object Types

Disposable object

A disposable object refers to an object that implements the Disposable pattern or a similar mechanism in order to release any resources it holds, such as file handles, network connections, database connections etc.

The purpose of the disposable pattern is to ensure that resources are properly released and not held indefinitely, preventing resource leaks which can cause a memory leak.

In Dart / Flutter, the disposable pattern is typically implemented by defining a dispose() method on the object. When you are done using the object and want to release its resources, you explicitly call the dispose() method.

Here’s an example of a disposable object in Dart:

abstract class Disposable { 
  void dispose(); 
} 
class MyDisposableObject implements Disposable { 
  // ... implementation of the object 
  @override void dispose() { 
    // Release any resources held by the object // ... 
  } 
} 
// Usage: 
void main() {
  MyDisposableObject myObject = MyDisposableObject(); 
  // Use the object... 
  // Dispose of the object when it is no longer needed 
  myObject.dispose(); 
}

Here is also a dart package that we can use to implement Disposable.
w_common | Dart Package

Memory-risky object

A memory-risky object refers to an object that can potentially consume a significant amount of memory or cause memory-related issues in a program if not managed properly.

Root Object

Every Dart application creates a root object that references, directly or indirectly, all other objects the application allocates.

These are special objects that are always accessible and could never get deleted by GC. Examples include global variables and static fields. By being an anchor point in memory, they serve as the starting point for GC to track other objects. The GC starts from the root object and track every object that’s reachable from it.

Retaining Path

The retaining path is the path from the root object that leads to a certain object. It’s a chain of pointers which starts at a root object and ends at the desired object. Any object that has a retaining path from root is considered as ‘reachable’ and won’t be cleaned up by GC.

Reachability Path

An object is said to be ‘reachable’ if there’s a way to reach it starting from a root object, or in other words, if it has a retaining path. If an object is unreachable (has no retaining paths), it implies that the program can no longer access it. Hence, GC can safely deallocate memory occupied by it.

Here’s a simple example:

class Child{}

class Parent {
  Child? child;
}

Parent parent1 = Parent();

void myFunction() {
  
  // child - 1st path
  Child? child = Child();

  // The `child` object was allocated in memory.
  // It's now retained from garbage collection
  // by one retaining path (root -> myFunction -> child).
  
  // child - 2nd path
  Parent? parent2 = Parent()..child = child;
  
  // child - 3rd path
  parent1.child = child;

  // At this point the `child` object has three retaining paths:
  // root -> myFunction -> child
  // root -> myFunction -> parent2 -> child
  // root -> parent1 -> child

  child = null;
  parent1.child = null;
  parent2 = null;

  // At this point, the `child` instance is unreachable
  // and will eventually be garbage collected.

}

Shallow size

Shallow size refers to the memory consumed by an object itself, without taking into account any objects it references. It represents the direct memory usage of the object, including its own fields or properties. Shallow size provides an estimate of the memory required to store the object without considering any additional memory usage caused by referenced objects.

Retained size

Retained size, on the other hand, refers to the memory consumed by an object and all the objects that are still reachable from it, directly or indirectly. It takes into account not only the shallow size of the object but also the memory usage of all the objects it references. Retained size provides a more comprehensive measure of memory usage, accounting for all objects that are retained and cannot be garbage-collected.

Here’s a simple example:

class Child {
  String name;
  Child(this.name);
}

class Person {
  String name;
  List<Child> children;
  
  Person(this.name, this.children);
}

void main() {
  var child1 = Child('John');
  // This will create a shallow memory allocation for child1
  
  var child2 = Child('Amy');
  // Another shallow memory allocation for child2
}

In this example, child1 and child2 are both shallow memory allocations, each contains an object of Child holding only their own property (name).

void main() {
  var child1 = Child('John');
  var child2 = Child('Amy');
  
  var parent = Person('Mike', [child1, child2]);
  // This will create a retained memory allocation for parent
}

In this case, parent is a retained memory allocation. It contains the Person object, which includes its own properties (name and children) and the objects it references (child1 and child2).

FAQ

1. Is the instance variable memory allocated in Stack or Heap?

class Car {
  // instance variable
  String name = "Audi"
}

In Dart language, instance variables are stored in the heap.

Each object, including all of its instance variables, occupies a memory area on the heap. When you create an instance of a class, memory is allocated on the heap for a new object, and a reference to that object is returned.

Values in the heap can be accessed by any part of your application and live beyond the scope of the function they were created in, persisting for as long as there’s some part of your application holding a reference to them.

In contrast, the stack is used for static memory allocation and stores temporary information such as function call information, local primitive types and reference variables. However, the actual objects these reference variable point to would be stored in the heap.

Therefore, if you create an instance of an object – the reference to this object is stored in the stack, while the actual object and its instance variables are stored in the heap.

2. Is the static variable memory allocated in Stack or Heap?

class Car {  
  // static field
  static int year = 2020;
  
}

In Dart, static variables are stored in the heap, not the stack.

A static variable is essentially bound to a class, rather than an instance of the class. It exists from the time the class is loaded until the application is terminated. Therefore, the memory allocated for static variables is available for the entire duration of the application, which is consistent with the behavior of heap-allocated memory.

The post Introduction To Dart Memory Management appeared first on WeCanCode.

In the previous post we learned about Dart VM, Garbage collection is one of the feature provided by Dart VM. Understanding garbage collector is crucial when you want to build a efficient applications. It allows you to manage memory resources effectively, preventing memory leaks and improving the overall performance and stability of your programs.

What Is Garbage Collection?

The Dart VM uses a form of automatic memory management where the garbage collector attempts to reclaim memory occupied by objects that are no longer in use by the program. Garbage collection primarily focuses is to managing dynamically allocated memory on the heap.

How is the memory allocated to heap?

In Dart, memory allocation on the heap typically occurs when you create objects using the new keyword or object constructors.

class PersonClass {
  int age;
}

void main() {
  PersonClass myObject = PersonClass(); // Object created on the heap
}

What are the steps taken by Dart Garbage Collector to free up memory?

1. Marking:
   1. The garbage collector thoroughly scans the heap, which is the memory region where objects reside.
   2. It identifies which objects are still actively referenced by your program and marks them as “in use.”
2. Sweeping:
   1. Once objects are marked, the garbage collector pinpoints the objects that are no longer referenced and therefore eligible for removal.
   2. These unreferenced objects are swept away, freeing up valuable memory space.
3. Generational Approach:
   1. The Dart VM employs a generational garbage collection strategy:
      1. New objects are allocated in the new generation, which is frequently garbage collected to keep it clean and efficient.
      2. Objects that survive multiple garbage collections are promoted to the old generation, which is collected less often, reducing the overall overhead of garbage collection.
4. Optional Compaction:
   1. Although not always performed, the garbage collector can optionally perform a compaction step.
   2. This involves rearranging the remaining objects in memory to create larger, contiguous blocks of free space.
   3. Compaction can help mitigate memory fragmentation, which can negatively impact performance over time.
5. Continuous Process:
   1. Garbage collection is not a one-time event. It’s a continuous process that runs throughout your program’s execution to ensure efficient memory usage and optimal performance.

What is a generational approach used by Dart VM garbage collector?

The generational approach is a key strategy employed by the Dart VM’s garbage collector to optimize memory usage and improve performance. It works by dividing the heap (the memory area where objects reside) into two generations:

1. New Generation: This generation holds recently allocated objects. It’s frequently scanned for garbage collection (typically mark-and-sweep), removing unreferenced objects swiftly. This helps prevent memory fragmentation and keeps the new generation small and efficient.
2. Old Generation: Objects that survive multiple garbage collections in the new generation are promoted to the old generation. This generation is scanned less frequently than the new one, reducing overall garbage collection overhead. However, objects in the old generation can persist longer, potentially leading to fragmentation if they die at uneven intervals.

Memory fragmentation is when the sum of the available space in a memory heap is large enough to satisfy a memory allocation request but the size of any individual fragment (or contiguous fragments) is too small to satisfy that memory allocation request.

What are the benefits of using generational approach in Dart VM?

• Reduced Memory Fragmentation: Frequent collection in the new generation minimizes fragmentation, meaning smaller wasted space between active objects. This allows smoother allocation of new objects without needing to search for fragmented pockets.
• Improved Performance: Less frequent collection in the old generation reduces the overall overhead of garbage collection, boosting the program’s performance.
• Balance Between Efficiency and Overhead: The approach balances efficient memory usage in the new generation with lower overhead in the old generation, aiming for an optimal overall performance.

However, it’s important to note that:

• Full GC pauses can still occur: While less frequent, garbage collection in the old generation can still cause brief pauses in program execution, especially for long-lived applications with large object populations.
• Generational approach does not eliminate fragmentation entirely: While significantly reduced, fragmentation can still occur in the old generation if object lifetimes vary greatly.

The post Introduction To Garbage Collection in Dart appeared first on WeCanCode.

Kernel service, which handles compilation of Dart source into Kernel binary. VM then will run resulting Kernel binary.

The Dart Virtual Machine is a critical component of the Dart platform, providing a high-performance runtime environment for Dart programs. It offers a range of features, including garbage collection, concurrency support, native extensions, and profiling tools, enabling developers to build powerful and efficient applications. With its cross-platform support and seamless integration with popular IDEs, the Dart VM empowers developers to create performant Dart applications for a wide range of platforms and use cases.

The Dart VM is designed to be fast, efficient, and portable. It provides a just-in-time (JIT) compiler and an ahead-of-time (AOT) compiler for optimizing and executing Dart code. The JIT compiler allows for rapid development cycles by quickly compiling and executing code during the development process. On the other hand, the AOT compiler generates highly optimized machine code in advance, resulting in faster startup times and better performance for standalone Dart applications.

Does Flutter use Dart Virtual Machine (VM)?

Flutter uses Dart as its primary language and takes full advantage of Dart’s features, including running the Dart code in the Dart Virtual Machine (VM).

Flutter completely separates compilation to Kernel and execution from Kernel by putting them onto different devices: compilation happens on the developer machine (host) and execution is handled on the target mobile device, which receives Kernel binaries send to it by flutter tool.

Dart provides a flexible runtime through its VM that makes it possible to run both JIT (Just-In-Time) compiled code and AOT (Ahead-Of-Time) compiled code, which Flutter uses during different app life-cycle stages.

During the development phase, Dart VM runs with JIT compilation. This enables developers to make changes in the code and see them reflected in the app in real-time — a feature known as hot-reloading. The Dart VM keeps the compiled code in memory and updates it as the developer modifies the source code.

When you’re ready to release your Flutter app , the Dart VM compiles the Dart code using AOT compilation. AOT compilation converts the Dart code into machine code in advance, which results in faster app startup times and smoother execution. It’s important to note that in this phase, there’s no actual Dart VM included in the final app – the Dart code is compiled directly into native machine code for the respective platform (like ARM or x86 for mobile devices).

It’s also worth mentioning that the Dart VM provides other features to Flutter, such as garbage collection for memory management, and a rich set of core libraries for functionalities like collections, async programming, string manipulation, and more.

In summary, Flutter uses Dart VM for running Dart code efficiently with flexibility during the development and debugging stages, and it uses AOT compilation for creating a highly optimised final app binary for distribution.

When is the Dart VM Created?

The Dart Virtual Machine (Dart VM) is created when a Dart program starts running. Essentially, the Dart VM is an engine that executes Dart code in a managed runtime environment, bridging the gap between high-level Dart code and lower-level machine code.

However, in the case of Flutter, the Dart VM works bit differently. When a Flutter application is executed in development mode, the Dart VM is created and is used for JIT (Just-In-Time) compilation, enabling features like hot reload. The Dart VM is active throughout your session as you test and develop your Flutter application.

For building and releasing Flutter apps, Dart uses AOT (Ahead-Of-Time) compilation, which compiles Dart code directly into native machine code for each platform (Android, iOS, etc). So when a Flutter app is running on a device, it’s not actually using the Dart VM. Instead, it’s executing the compiled machine code directly.

The post Introduction To Dart VM appeared first on WeCanCode.

Understanding Flutter’s InteractiveViewer Widget

InteractiveViewer is a versatile widget in Flutter that enables users to pan, zoom, and interact with its child widget(s) in a fluid and intuitive way. It provides a flexible and customizable approach to implement interactive elements such as maps, images, or any other visual content that requires user interaction.

Creating a Pinch-to-Zoom Image Experience

Let’s now delve into creating a pinch-to-zoom image feature using Flutter’s InteractiveViewer widget. Follow the steps below to implement this functionality:

Step 1: Import the Required Libraries

In your Dart file, import the necessary libraries:

import 'package:flutter/material.dart';

Step 2: Build the User Interface

In the build method of your widget, construct the user interface that includes an InteractiveViewer widget as its child. For this example, we will use an Image widget as the child:

@override
Widget build(BuildContext context) {
  return Scaffold(
    appBar: AppBar(
      title: Text('Pinch-to-Zoom Image'),
    ),
    body: Center(
      child: InteractiveViewer(
        clipBehavior: Clip.none,
        minScale: 1,
        maxScale: 4,
        child: Image.asset('assets/images/my_image.jpg'),
      ),
    ),
  );
}

Make sure to replace 'assets/images/my_image.jpg' with the actual path to your image file.

Step 3: Configuring InteractiveViewer

To enable pinch-to-zoom functionality, InteractiveViewer provides various properties that can be adjusted according to your needs. Let’s take a look at some of the commonly used properties:

• minScale: Defines the minimum scale factor for zooming.
• maxScale: Specifies the maximum scale factor allowed. Setting it to a value 4.0 limits the zooming capability to image size x 4.

Step 4: Customize and Enhance

Feel free to explore other properties and methods provided by InteractiveViewer to customize the pinch-to-zoom image experience further. You can experiment with features like double-tap zooming, constraints, alignment, and more to match your specific requirements.

Conclusion

In this blog post, we learned about Flutter’s InteractiveViewer widget and how to create a pinch-to-zoom image functionality using it. By harnessing the power of InteractiveViewer

The post Exploring Flutter’s InteractiveViewer: Creating a Pinch-to-Zoom Image Experience appeared first on WeCanCode.

Are you interested in becoming a Flutter developer? With its growing popularity and demand in the job market, Flutter offers an exciting career opportunity. Whether you’re a beginner or an experienced developer looking to transition into Flutter, having a structured learning path is essential. In this article, we’ll explore a comprehensive Flutter learning path for beginners, covering the essential topics and resources to help you embark on your journey towards becoming a proficient Flutter developer. Let’s get started!

Conclusion

Embarking on a Flutter learning path as a beginner can be an exciting and rewarding experience. By following this comprehensive guide, you’ll have a structured roadmap to become a proficient Flutter developer. Remember to practice consistently, build projects, and seek hands-on experience to reinforce your knowledge. With dedication and perseverance, you’ll be well-equipped to kickstart your career in Flutter development and seize the abundant opportunities it offers.

The post Flutter Learning Path for Beginners: A Comprehensive Guide to Kickstart Your Career in Flutter Development appeared first on WeCanCode.

I. Understanding Firebase: Firebase is a comprehensive backend-as-a-service (BaaS) platform offered by Google. It provides a suite of tools and services that assist in building and scaling applications quickly. Firebase encompasses features such as real-time database, authentication, cloud functions, hosting, and more. Its standout feature is the real-time database, which allows seamless data synchronization across clients.

II. Unpacking REST API: REST (Representational State Transfer) is an architectural style for designing networked applications. A REST API acts as an interface that enables communication between clients and servers using standard HTTP methods like GET, POST, PUT, and DELETE. REST APIs typically interact with databases or other data sources to perform CRUD (Create, Read, Update, Delete) operations.

III. Firebase Use Cases:

1. Real-time Applications: Firebase excels in scenarios where real-time data updates are crucial, such as chat applications, collaborative tools, or live dashboards. Its real-time database uses WebSockets to deliver instantaneous updates to connected clients.
2. Rapid Prototyping: If you need to develop a minimum viable product (MVP) or quickly validate an idea, Firebase’s prebuilt features and simplified setup can significantly speed up development time. It offers easy integration with popular frontend frameworks like Angular, React, or Flutter.
3. Authentication and User Management: Firebase provides robust user authentication services out of the box, including email/password authentication, social login, and more. It handles the complexities of user management, allowing developers to focus on other aspects of their application.

IV. REST API Use Cases:

1. Custom Backend Logic: REST APIs are a suitable choice when you require fine-grained control over your backend logic. If you need to integrate with existing databases or implement complex business rules, building a custom REST API allows for more flexibility and customization.
2. Integration with Third-Party Services: When your application needs to interact with various external services, such as payment gateways, SMS providers, or email services, a REST API acts as a bridge, enabling seamless communication between your application and these services.
3. Large-scale Applications: REST APIs offer scalability advantages for applications that anticipate high volumes of traffic and require advanced caching mechanisms, load balancing, or horizontal scaling. They allow for fine-tuning performance optimizations specific to your application’s requirements.

V. Choosing the Right Approach:

1. Firebase Advantages: Consider using Firebase if you prioritize real-time updates, need a quick development turnaround, or require built-in authentication and user management. Firebase shines in scenarios where speed and simplicity are essential, and real-time data synchronization is critical.
2. REST API Advantages: Opt for a custom REST API when you have specific business logic requirements, need integration with multiple external services, or anticipate large-scale application growth. REST APIs provide greater control, flexibility, and scalability options tailored to your application’s needs.

Conclusion: Choosing between Firebase and REST API depends on the nature of your application, its requirements, and the level of control and customization you seek. Firebase is an excellent choice for real-time applications, rapid prototyping, and simplified user management. REST APIs, on the other hand, offer flexibility, customization, and scalability options for applications requiring custom backend logic and seamless integration with external services. Carefully evaluate your project’s needs and weigh

The post Firebase vs REST API: Choosing the Right Approach for Your Application appeared first on WeCanCode.

• REST API: Representational State Transfer (REST) APIs are widely used in web and mobile development. RESTful APIs are commonly used to create client-server communication in various industries, making it a sought-after skill.
• WebSockets: WebSockets provide real-time, bidirectional communication between clients and servers. They are often used in applications that require instant data updates, such as chat applications, collaborative tools, or real-time analytics dashboards. Knowledge of WebSockets is beneficial if you’re interested in real-time applications or working on projects that involve live data streaming.
• GraphQL: GraphQL is a query language for APIs and a runtime for executing those queries. It offers efficient and flexible data retrieval, allowing clients to request specific data structures and reducing over-fetching or under-fetching of data. GraphQL has gained popularity due to its ability to simplify data fetching for frontend developers. Learning GraphQL can be advantageous if you’re interested in mobile development or working with modern API architectures.
• Firebase: Firebase is a backend-as-a-service (BaaS) platform that provides a wide range of tools and services for building web and mobile applications. It includes features such as real-time database, authentication, cloud functions, and hosting. Firebase is known for its ease of use and rapid development capabilities. If you’re interested in developing applications quickly, particularly for mobile platforms, learning Firebase can be beneficial.

Considering the job market, it’s advisable to have a solid understanding of REST API principles, as it is a fundamental technology widely used in the industry. Additionally, having knowledge of WebSockets or GraphQL can be advantageous, especially if you’re interested in real-time applications or modern API architectures.

Firebase, while popular and useful for specific use cases, may be more niche compared to the broader demand for REST API skills. However, if you’re interested in mobile app development or rapid prototyping, learning Firebase can open up opportunities in those areas.

Ultimately, it’s beneficial to have a diverse skill set and stay adaptable to emerging technologies. Assess the specific job market you’re targeting, consider the industry trends, and align your learning path with the technologies in demand to enhance your job prospects.

The post REST API, WebSocket, GraphQL or Firebase For Job Prospective appeared first on WeCanCode.