A while ago I wrote an article on offline first apps. This is a follow up which offers more details on how to use SQLite in Flutter apps. Hopefully I can get time to write one on React Native in the future.

SQLite is a lightweight database that is perfect for mobile apps, allowing you to store and query data locally. SQFLite is a Flutter plugin that provides an interface for using SQLite databases in Flutter applications. This guide includes experience and knowledge I have learn’t while working at Heylixir and building our mobile app which is designed to be offline-first.

Setting Up

Step 1: Create a New Flutter Project

First, create a new Flutter project:

flutter create my_app
cd my_app

Step 2: Add Dependencies

Open pubspec.yaml and add the sqflite and path dependencies:

dependencies:
  flutter:
    sdk: flutter
  sqflite: ^2.0.0+4
  path: ^1.8.0

Run flutter pub get to install the dependencies.

Database Setup

Step 3: Create a Database Helper Class

In your lib/services folder, create a new file called database_helper.dart. This file will handle all database operations.

import 'dart:async';
import 'package:path/path.dart';
import 'package:sqflite/sqflite.dart';

class DatabaseHelper {
  static final DatabaseHelper _instance = DatabaseHelper._internal();
  factory DatabaseHelper() => _instance;

  DatabaseHelper._internal();

  static Database? _database;

  Future<Database?> get database async {
    if (_database != null) return _database;

    _database = await _initDatabase();
    return _database;
  }

  Future<Database> _initDatabase() async {
    String path = join(await getDatabasesPath(), 'todo.db');
    return await openDatabase(
      path,
      version: 1,
      onCreate: _onCreate,
    );
  }


  Future _onCreate(Database db, int version) async {
    await db.execute(
      '''
      CREATE TABLE todos (
        id INTEGER PRIMARY KEY AUTOINCREMENT,
        title TEXT,
        deadline TEXT
      )
      ''',
    );
  }

}

4. CRUD Operations

Now that we have our database set up, let’s add the methods to perform CRUD (Create, Read, Update, Delete) operations.

Step 4: Insert Data

To add items to the database, we utilize the insert method. This method accepts the table name and a Map with the data we intent to add to the table as the parameters.

Future<int> insertItem(Map<String, dynamic> item) async {
  final db = await DatabaseHelper.database;
  return await db!.insert('todos', item);
}

Step 5: Retrieve Data

To retrieve all items from the database, we use the update method of SQL Database class. This method accepts a few parameters to allow us to specify which data we are interested in. where parameter allows us to define the fields we are querying by and then whereArgs is a list of the parameters matching the where fields.

Future<List<Map<String, dynamic>>> getItems() async {
  final db = await DatabaseHelper.database;
  return await db!.query('todos');
}

Step 6: Update Data

To update an item, we use the update method of SQL Database class. This method accepts a few parameters to allow us to specify the update criterion:

Future<int> updateItem(int id, Map<String, dynamic> item) async {
  final db = await DatabaseHelper.database;
  return await db!.update(
    'todos',
    item,
    where: 'id = ?',
    whereArgs: [id],
  );
}

Step 7: Delete Data

To delete an item from the database, we use the delete method. It takes paramters similar to get function. where parameter allows us to specify the deletion criterion and whereArgs is a list of the parameters matching the where fields.

Future<int> deleteItem(int id) async {
  final db = await DatabaseHelper.database;
  return await db!.delete(
    'todos',
    where: 'id = ?',
    whereArgs: [id],
  );
}

Step 8: Create a Service

In todos/repo.dart, we create a simple service to interact with the database. This service can be imported into your UI or state management class (Provider or Bloc) and used to add data into the database.

class TodosRepoService {
  static String tableName = "todos";

  static Future<int> insertItem(Map<String, dynamic> item) async {
    final db = await DatabaseHelper.database;
    return await db!.insert(TodosRepoService.tableName, item);
  }
  
  static Future<List<Map<String, dynamic>>> getItems() async {
    final db = await DatabaseHelper.database;
    return await db!.query(TodosRepoService.tableName);
  }

  static Future<int> updateItem(int id, Map<String, dynamic> item) async {
    final db = await DatabaseHelper.database;

    return await db!.update(
      TodosRepoService.tableName,
      item,
      where: 'id = ?',
      whereArgs: [id],
    );
  }

  static Future<int> deleteItem(int id) async {
    final db = await DatabaseHelper.database;
    
    return await db!.delete(
      TodosRepoService.tableName,
      where: 'id = ?',
      whereArgs: [id],
    );
  }

}

5. Run the App

To run the app, use the following command:

flutter run

This simple guide allows you to insert, update, and delete items in the local SQLite database. You can expand this to include more complex operations, multiple tables, and more advanced features as you grow more comfortable with SQFLite. In the future, I will write another guide on how to update the tables themselves in production. This, while seemingly daunting, is not as complex as one might think and it’s a fairly expected activity for apps that are in production.

Conclusion

This tutorial provides a basic introduction to using SQFLite in a Flutter application.

Happy coding! 🎉 and as always Long Live The Code 🚀.

Productivity has been one of the most popularly used words in 2023 and 2024. Behind every layoff or AI buzzword usage has been productivity. In Flutter, as engineers start building large apps with tens of thousands of lines of code, animations and other performance intensive features, there are common pitfalls they get to.

In this article, I want to discuss some of these common issues in a more granular fashion. This article will be the first of many that cover things that engineers ought to know to stay ahead of common traps. Let’s go 🚀.

When using Provider, prefer context.watch and context.read

When using provider, you have a couple of options that allow you to access you store data.

Consumer

Example

return Consumer<MyActivitiesProvider>(
      builder: (context, MyActivitiesProvider activitiesProvider, child) {
        List<Activity> activities = activitiesProvider.activities;
        bool isLoading= activitiesProvider.isLoading;
        String? error = activitiesProvider.error;
        
        if( isLoading ) {

          return LoaderWidget();
        }
        if( error != null ) {

          return ErrorWidget();
        }
        if( activities.isEmpty ) {

          return NoDataWidget();
        }
        return ListView.builder(
          itemCount: activities.length,
          itemBuilder: (context, index) {
            
            return ActivityCard(activity: activities[index]);
          },
        );
      },
    );

This is all good but the code is more verbose and it definitely reminds most people of Java. Is there a way out? Yes. you could access the data using context. Here’s how:

MyActivitiesProvider myActivitiesProvider = context.watch<MyActivitiesProvider>();
List<Activity> activities =  myActivitiesProvider.activities;
bool isLoading =  myActivitiesProvider.isLoading;
String? error =  myActivitiesProvider.error;
    
if( isLoading ) {

   return LoaderWidget();
}
if( error != null ) {

   return ErrorWidget();
}
if( activities.isEmpty ) {

   return NoDataWidget();
}
return ListView.builder(
  itemCount: activities.length,
  itemBuilder: (context, index) {
        
     return ActivityCard(activity: activities[index]);
   },
);

The clarity here is undeniable. In this case, i used context.watch because I need to be notified of any changes to the state in realtime but if that’s not a requirement, context.read would suffice.

Use Builder widgets when creating lists

Flutter builder widgets offer a performance boost and efficiently than plain ListViews and GridViews. ListView and GridViews create all items at once, the but their builder counterparts create items as they're scrolled onto the screen, definitely using less resources and offering better UX for users.

return ListView(
  children: activities.map((e) {

        return ActivityCard(activity: activities[index]);
      }).toList(),
);

// PREFER builder alternative 
return ListView.builder(
  itemCount: activities.length,
  itemBuilder: (context, index) {
        
    return ActivityCard(activity: activities[index]);
  },
);

Fixing ListTile animation bug when it has tileColor

When you have a ListTile with background color then add animations to it, the background color either disappears or it’s shown outside the widget. This issue has definitely hit many Flutter engineers. The first time I encountered this, I had to recreate flutter ListTile with Card to fix the bug.

The fix is very simple and involves little to no code. Wrap the ListTile with a Card then set the Card’s color to Colors.transparent and elevation to 0 if you don’t require the elevation.

Card(
  color: Colors.transparent,
  elevation: 0,
  child: Listtile(
    ....
  ),
);

Ensuring Text Inputs are Shown Above Keyboard Always

It’s really annoying when users are trying to enter data but the keyboard springs up and obstructs hiding the text input below the keyboard. The user in this case has to scroll the text input into view to see what they are entering. This is a common issue engineers face and a common question in git and stackoverflow.

The fix? If you are using Scaffold, set resizeToAvoidBottomInset to true. Even if you have the text input in a modal bottom sheet without a Scaffold, add it and set the property. I’ve tested the other suggested approaches to fix the issue but this has been the most consistent approach that works in all situations I tested.

return Scaffold(
  resizeToAvoidBottomInset: true,
  ...
);

Additionally, android has another option that can be set in AndroidManifest.xml to fix the issue:

<activity
  android:name=".MainActivity"
  android:launchMode="singleTop"
  android:theme="@style/LaunchTheme"
  android:configChanges="orientation|keyboardHidden|keyboard|screenSize|smallestScreenSize|locale|layoutDirection|fontScale|screenLayout|density|uiMode"
  android:hardwareAccelerated="true"
  android:windowSoftInputMode="adjustResize">
  <!-- ...rest of configuration here -->
</activity>

While also this works but I don’t prefer it because it’s a platform config that still leaves iOS with the same challenge. In some scenarios, even with the setting, Android still misbehaves and the keyboard hides the currently focused text input which leaves resizeToAvoidBottomInset: true, as the more consistent fix.

Replace empty container with SizedBox.shrink

It’s common to have situations where based on a condition you show a widget with content or an empty container. In this case you could use Container by instinct but, SizedBox.shrink() should be the Flutter widget of choice.

return isPremium ? AnalyticsList() : const SizedBox.shrink();

Avoid calling function multiple times when in loading and user clicks it multiple time

In situations where the user clicks a button and loading begins, there is still a chance that they click the button again especially for long running tasks even when you show them a loader.

In this case, you could have a state variable isLoading that you set to true when loading begins. While loading, you could set onPressed or onTap to null.

class LoginScreen extends StatefulWidget {
  const LoginScreen({super.key});

  @override
  State<LoginScreen> createState() => _LoginScreenState();
}

class _LoginScreenState extends State<LoginScreen> {
  bool isLoading = false;

  @override
  Widget build(BuildContext context) {
    return ElevatedButton.icon(
      onPressed: isLoading ? null : _login,
      icon: isLoading ? const CircularProgressIndicator() : const Icon(Icons.join_inner_sharp),
      label: const Text("Login"),
    );
  }

  _login() async {
    setState(()=> isLoading = true);

    try {
      
    } catch (e) {
      
    }
    setState(()=> isLoading = true);
  }
  
}

Module was compiled with an incompatible version of Kotlin. The binary version of its metadata is x.x.x, expected version is x.x.x.

This is a common gotcha sometimes when using packages from pub.dev. Recently I had to fix this and while there are alot of questions about this, the fixes are somewhat unreliable.

A common theme that even the flutter cli will recommend is updating ext.kotlin_version. This however does not work on its own. even flutter clean and clearing pub_cache may not work.

The fix lies in android/settings.gradle. here is what its plugins section may look like:

plugins {
    id "dev.flutter.flutter-plugin-loader" version "1.0.0"
    id "com.android.application" version "7.3.0" apply false
    id "org.jetbrains.kotlin.android" version "1.7.1" apply false
}

Assuming your error looks like:

Module was compiled with an incompatible version of Kotlin. The binary version of its metadata is 1.9.0, expected version is 1.7.1.

The fix is to set the version here “id “org.jetbrains.kotlin.android” version “1.7.1” apply false” to 1.9.0. so the plugins section looks like:

plugins {
    id "dev.flutter.flutter-plugin-loader" version "1.0.0"
    id "com.android.application" version "7.3.0" apply false
    id "org.jetbrains.kotlin.android" version "1.9.0" apply false
}

Next, in android/buid.gradle in buildscript or allprojects section, add this line:

ext.kotlin_version = '1.9.0'

In my case, I was able to fix it by updating android/settings.gradle alone.

That’s all for now. Hope this article offers some tips and fixes for common issues you may face in your Flutter engineering career. Remember, this will be an ever evolving article so when you visit the next time there may be more tips and fixes here.

Happy Building and as always Long Live The Code 🚀.

Next.js, a powerful React framework, excels in creating fast and SEO-friendly web applications. Performance and UX of these applications can however differ depending on the components used as well as an applications logic.

Recently while building Heylixir’s website, we used 3D components and our website bundle turned out to be huge, the site loading took a long time and the user experience took a hit as a result. This is where I realized that we had to maximize user experience by doing some performance optimization to reduce the website’s loading time as well as the build bundle. This article explores various strategies to streamline your Next.js app and ensure its lightning-quick delivery.

Leveraging Next.js Built-in Optimizations:

next/image: This versatile component streamlines image handling, offering:

1. Lazy Loading: Images are loaded only when they enter the viewport, minimizing initial page load time.
2. Automatic Resizing: Images are resized to fit the device’s screen dimensions, reducing data usage and optimizing display.
3. Responsive Images: Images are served in appropriate formats (WebP for modern browsers, JPEG for older ones) based on user device, enhancing compatibility.

import Image from 'next/image';

function MyImage() {
  return (
    <Image
      src="/path/to/image.jpg"
      alt="My Image"
      width={640}
      height={480}
    />
  );
}

next/link: This component prefetches linked pages in the background, resulting in smoother page transitions when users navigate between them.

import Link from 'next/link';

function MyLink() {
  return (
    <Link href="/about">
      <a>About Us</a>
    </Link>
  );
}

next/script: Manage third-party scripts efficiently with next/script. Control loading behavior (defer, beforeInteractive, etc.) and execution order for optimal performance.

import Script from 'next/script';

function MyScript() {
  return (
    <Script
      src="https://www.site.com/pytorchjs.js"
      strategy="afterInteractive"
    />
  );
}

next/dynamic: enables loading components only when required, further optimizing your application’s initial bundle size. This is particularly beneficial for components that are used conditionally or on specific routes. This is probably one of my favourite methods especially when I’m building websites with 3D components. It helps reduce the bundle size as well as improve overall UX for users for example with heylixir.

import dynamic from 'next/dynamic';

const Site3DExperienceComponent = dynamic(
  () => import('./components/experience'),
  { ssr: false } // Disable server-side rendering if not needed
);

function MyPage() {
  const showConditionalComponent = true; // Or based on a prop or state

  return (
    <div>
      {/* Other content */}
      {showConditionalComponent && <Site3DExperienceComponent />}
    </div>
  );
}

Advanced

1. Code Splitting and Tree Shaking: Code splitting partitions your application’s JavaScript code into smaller bundles, ensuring only essential code loads on initial page render. This reduces initial load time. Tree shaking, a webpack optimization, eliminates unused code within your bundles, further minimizing bundle size.
2. Font Optimization: Utilize tools like font-optimization or fontmin to compress font files.
3. Third-Party Library Evaluation: Scrutinize third-party libraries for performance impact. Consider alternatives or only import necessary components.
4. Code Analysis: Tools like webpack-bundle-analyzer help identify unused code within your bundles for targeted removal.
5. Content Delivery Networks (CDNs): Utilize CDNs to serve static assets from geographically distributed servers, significantly reducing latency for users worldwide.
6. Caching: Implement caching mechanisms for static assets and API responses to minimize server requests.

Remember, Balance is Key, optimize without sacrificing functionality. Measure and Iterate; regularly evaluate performance and refine your approach based on data.

By following these techniques and continuously monitoring your Next.js application’s performance, you can create a noticeably faster and more responsive user experience.

Hope this helps. Happy Building 🚀 and as always Long Live The Code.

The Soft Skills Every Senior Engineer Needs in the Age of AI

The rise of AI has been a cause of concern for many and yes, that has been for a good reason. We are at the time of AI and investor satisfaction now which means that the workforce interests have taken a back seat.

While AI can automate certain tasks, the irreplaceable value of senior engineers lies not just in their technical expertise, but in their mastery of the often-overlooked soft skills. Here’s why communication, collaboration, and problem-solving are the secret weapons that will keep senior engineers at the forefront of the tech revolution.

Communication: From Binary to Boardrooms

Senior engineers are no longer isolated code wizards. We’re expected to translate complex technical concepts into clear, concise language for stakeholders, clients, and even junior team mates. This requires exceptional written and verbal communication skills.

Imagine explaining a new AI-powered recommendation system to a room full of business executives — being able to break it down into layman’s terms without sacrificing accuracy is a superpower.

Collaboration

Software development is rarely a one-man show. Senior engineers lead and mentor junior developers, creating a collaborative environment where products and services can be delivered as envisioned.

This requires active listening, the ability to delegate effectively, and a healthy dose of empathy. A senior engineer who can build strong relationships within the team gets the best out of everyone, leading to more innovative and efficient solutions.

Problem-Solving

AI might be impressive at pattern recognition, but it can’t replicate the human ability to think outside the box. Senior engineers are the ultimate problem-solvers, the ones who delve into intricate technical issues and emerge with better solutions. This requires critical thinking, the ability to analyze complex situations from multiple angles, and a relentless curiosity. A senior engineer who approaches every challenge with a fresh mindset is an invaluable asset more than a pre-trained model.

Sharpening Your Soft Skills

So how do you, the seasoned or new engineer, further grow these crucial soft skills? Here are a few tips:

• Seek opportunities to present technical concepts to non-technical audiences. Volunteer for training sessions or write blog posts (like this one) explaining complex topics in a clear and engaging way.
• Become an active listener. Pay attention to what your teammates are saying, both verbally and non-verbally. Ask clarifying questions and be open to different opinions.
• Embrace mentorship. Share your knowledge and experience with junior developers. Use LinkedIn to share your knowledge and the interesting things you are working on. Additionally, help other engineers who have bugs while building.
• Never stop learning. Take courses, attend workshops, or join online communities focused on soft skills development.

The future of engineering belongs to those who can wield both the power of code and the power of human connection. By strengthening your soft skills, you, the senior engineer, will not only ensure your own relevance but also become the architect of a more collaborative and innovative tech landscape.

Remember, your soft skills will be the reason more opportunities find you even after ChatGPT and Google drop their next best models.

Happy Building and as always Long Live The Code.

So, you’ve decided to dive into the world of app development with SwiftUI? Welcome to the party 🎉. This framework from Apple makes building user interfaces for iPhones, iPads, Macs, and more, an easy process. Whether you’re a coding novice or an experienced developer, SwiftUI offers a powerful and intuitive approach to bring your app ideas to life.

This guide will equip you with the essential concepts to kickstart your SwiftUI journey.

Swift

Before you get anything done with SwiftUI, it’s important to learn Swift itself. This language is at the core of SwiftUI, it’s what you will be working with everyday. Great thing is if you know Java, TypeScript, Kotlin, Rust, Scala or even C++, you will get up and running pretty fast. Some concepts between these languages are shared so knowledge in any of them will give you an upper hand.

Declarative Power

Unlike traditional coding that dictates every step (imperative style), SwiftUI uses a declarative approach. You simply describe what your UI should look like, and SwiftUI handles the rest behind the scenes. This makes your code cleaner, easier to understand, and lets you focus on the desired outcome.

Views & Modifiers: The Building Blocks

Imagine a world where everything you see on a screen was a lego block. In SwiftUI, that’s exactly the case. Buttons, text, images, and even layouts — all these are views. You can combine these views using stacks (think vertical stacks with VStack and horizontal ones with HStack) to create complex interfaces. To further customize these views, you have modifiers at your disposal. These let you change the look and feel with properties like color, font size, overlays, and even add animations.

State Management

Imagine an app that doesn’t update when you change something. It would not be ideal. To ensure your UI stays fresh with dynamic data, SwiftUI offers state management tools. For simple data within a single view, you can use the @State property wrapper. If you need to share data across multiple views, the @ObservedObject protocol comes into play. It helps keep data syncronized in multiple pages.

Navigation and Routing

SwiftUI provides built-in navigation features like NavigationLink. This lets you effortlessly guide users through your app's various screens, creating a smooth and intuitive user experience.

A Wealth of Learning Resources

Apple itself offers fantastic SwiftUI tutorials to get you started. Check the docs here. The developer community is incredibly supportive as well, with tons of online resources, courses, and tutorials available to guide you further.

Embrace the Learning Curve

SwiftUI is a powerful tool, but like any skill, it takes practice. Start small, experiment frequently, and don’t hesitate to use the available resources. With dedication and these beginner-friendly tips, you’ll be well on your way to crafting beautiful and functional SwiftUI apps.

If you are curious about iOS development or want to get started, I hope this guide however short offered all the information you need to know to get going.

Happy Building 🚀 and as always, Long Live The Code.

How to get ahead of AI and thrive for engineers

The rise of AI has understandably caused concerns for many who wonder what the future holds for them and their livelihoods. For software engineers, things are not any different.

Visions of robots writing code with frightening efficiency paint a dystopian picture. Is AI here to steal your job? or is it more of a teammate?

By understanding its capabilities and limitations, and by strategically building your skillset, you can not only survive but thrive in the age of AI-powered engineering. Let’s see how this can be possible.

A Double-Edged Sword

AI brings a bunch of benefits to the table for engineers:

• Efficiency on Autopilot: Imagine a tireless assistant handling repetitive tasks like unit testing and code generation. AI can automate these with superhuman speed, freeing you for the strategic aspects of engineering — system architecture, user experience design, and tackling complex problems. For most repetitive tasks, you can let AI do the hard work and then you can do the rest 🚀.
• Bug Fixer: AI can analyze vast amounts of code, pin-pointing bugs and security vulnerabilities that might escape even the best of engineers. This not only improves software quality but also saves you debugging headaches. Sometimes bugs show up and you have no idea how to fix them, asking AI could be the beginning of solving them ✅.
• Innovation Engine: AI can analyze user data and identify emerging trends, helping you design software that anticipates user needs and stays ahead of the curve.

Now that we identified some benefits, lets see some limitations:

• The Black Box Problem: AI’s decision-making processes can be opaque, making it difficult to understand how it arrives at solutions. Some LLMs have introduced the ability to show sources and the thinking process but for most, there is no transparency in the process. This lack of transparency can be a challenge for debugging and maintaining AI-powered systems without having to improve an existing LLM.
• Creativity Gap: While AI excels at automation and analysis, it currently lacks the human touch for genuine creative problem-solving. Your ability to craft great solutions and design user-friendly interfaces will remain invaluable.
• Edge Cases: AI is very fluent at many things. For example, I decided to build a game with Godot the last Christmas. Thing is, Godot Engine was updated last year to version 4 which meant a great amount of the API changed. Things like Kinematic Body are now Character Body, Particles is now GPUParticles3D etc. Asking AI to give me a new Godot guide yielded junk results so I ended up building my own LLM with the new docs to get things up and running. I imagine for engineers working with new technologies, AI may be less than useful.

Thriving in the Age of AI

So how do we leverage AI as software engineers and not get left behind? Here are some key strategies:

• Become an AI Engineer: Don’t shy away from AI. Take online courses, attend workshops, and actively engage with the world of AI. Understanding how AI works and its limitations will make you a better at you job; trust me, it’s a powerful tools.
• The Full Stack Specialist: While AI might handle specific tasks, a well-rounded software engineer with expertise across the development lifecycle, from design to deployment, will always be in demand. Remember, if you are looking to learn something new, AI can help bridge that gap fast.
• Soft Skills: Develop your soft skills like communication, collaboration, and critical thinking. The ability to communicate complex technical concepts to non-technical stakeholders and collaborate effectively within teams will be increasingly valuable.
• AI Architect: Instead of fearing AI, view it as an opportunity to become an “AI architect.” LEarn to integrate AI tools into existing workflows and design human-AI collaboration frameworks.

The future of software development is not about humans being replaced by machines, at least not in my opinion. It’s about collaboration, a synergy between humans and AI.

It’s true that AI will take jobs including from engineers but that doesn’t mean that jobs will not exist. While companies cut jobs because of AI, they can also keep you because of it. For those who also love side projects like building SaSS services, AI can give you an edge.

Happy Building and as always Long Live The Code 🚀.

Surviving beyond 50k line of code

Ever look at a beautiful and intricate building and wonder how the architect planned it all out? Well, software design follows a similar principle. Just like blueprints guide construction, design patterns provide a tried-and-tested approach to structuring your code. At least, that is the simplest way I got to understand design patterns.

In this article, we’ll explore some of the most common design patterns that software engineers use to build robust, maintainable, and flexible software.

What are Design Patterns?

Imagine you’re building a house. You wouldn’t start from scratch every time, right? You’d likely use a pre-defined floor plan or adapt an existing one to fit your current needs. Design patterns work the same way for code. They are reusable solutions to common software development problems. This way engineers can be more productive and software can be more reliable and efficient.

There are three main categories of design patterns:

• Creational Patterns: These patterns focus on how objects are created. A common example is the Singleton Pattern, which ensures only one instance of a class exists, useful for things like loggers or database connections.
• Structural Patterns: These patterns deal with the composition of classes and objects. The Adapter Pattern allows incompatible interfaces to work together, like using a round peg in a square hole with an adapter!
• Behavioral Patterns: These patterns define how objects communicate and interact with each other. The Observer Pattern is a great example, where one object (the subject) keeps track of others (observers) and notifies them of any changes it experiences.

Benefits of Using Design Patterns

• Improved Code Readability: By using established patterns, your code becomes easier for others (and future-you) to understand.
• Increased Maintainability: Well-designed patterns make modifications and bug fixes simpler. In the long term, most of the second guessing on what to do is reduced and thus, improving maintainability.
• Promotes Reusability: Patterns provide pre-built solutions that can be adapted and used in different parts of your code or even across projects. Think of the next time you are adding a feature, using design patterns, you would almost always already know what to do.

Popular Design Patterns for Beginners

1. Singleton Pattern

Imagine a light switch that controls all the lamps in your house. Flipping the switch from anywhere turns them all on or off. The Singleton Pattern ensures only one instance of a class ever exists, and provides a central access point to that object. This is useful for things like loggers that track application activity, websocket connections or database connections that need to be shared across your program. There’s only ever one logger or one connection needed, so the Singleton Pattern enforces this rule and simplifies access.

2. Factory Pattern

Think of a car factory that can produce different car models based on your needs. You wouldn’t have to know the exact steps to build a sedan versus a truck. With the Factory Pattern, you create objects without specifying the exact type upfront. Instead, you tell the factory what kind of object you need (sedan, truck, etc.), and it takes care of the behind-the-scenes logic of creating the right object. This approach offers flexibility in your code, especially when you might need to create different types of objects based on certain conditions.

3. Facade Pattern

Have you ever interacted with a vending machine? The buttons and display provide a simple interface to a complex system that dispenses drinks and snacks.

The Facade Pattern hides the inner workings of a subsystem, making it easier to use. Imagine a complex library for image editing. The Facade Pattern would provide a simplified interface with common operations like resize or crop, hiding the underlying code that performs those actions. This makes your code cleaner and easier to understand for anyone using the library.

4. Strategy Pattern

Imagine different payment methods at an online store, like credit card or cash. The Strategy Pattern lets you choose an algorithm at runtime. The core concept is separating the logic (how to pay) from the object that uses it (the shopping cart). This allows for flexible behavior. You can easily switch between payment methods without modifying the core shopping cart functionality.

5. Observer Pattern

Ever receive notifications on your phone about news updates or social media activity? The Observer Pattern lets one object (like a news service) notify many others (subscribers) about any changes it experiences. Imagine a weather monitoring app. The weather data (subject) can notify various observers (widgets, news feeds) whenever there’s an update, ensuring everyone has the latest information.

This pattern promotes loose coupling between objects, making your code more modular and easier to maintain.

Conclusion

Design patterns are a deep topic that devolves in to dozens of other topic that have to do with engineering. The goal of this guide was to offer a starting point for engineers on what I have come to believe are the most common design pattersns. For senior engineers, use this as a refresher on the your design patterns knowledge.

Happy Building 🚀 and as always, Long Live The Code.

AWS Cloud is an engineers playground, offering tons of services for product and platform development. The AWS CLI (Command Line Interface) is the most common tool for interacting with these services directly from your terminal for most engineers.

Sure, some of us will have scripts or Terraform to automate the process but for a good number of times, the CLI is the common tool. It also empowers automation, scripting, and an overall smoother workflow.

This guide dives into some essential AWS CLI commands that every engineer should have in their toolbox.

aws help

No one will remember everything at every moment so considet this to be the only command you should not forget. This will allow you to get more information on commands that you want to use and get you up and running without a google search.

Use this command to explore all available services (S3, EC2, etc.) and their corresponding commands.

aws help

aws configure

This command sets your default AWS region and preferred output format (often JSON) and profile. This will generally be the first or second command you run when setting up AWS.

aws configure

IAM Management

Identity and Access Management (IAM) is the cornerstone of AWS security. This command provides a quick overview of all IAM users within your account. Run:

aws iam list-users

S3 Bucket Management

Simple Storage Service (S3) is a popular storage solution. To get buckets use:

aws s3 ls

To list lists the contents of a specific S3 bucket. For instance, to see what's inside profile-avatars, run:

aws s3 ls profile-avatars

Working with Profiles

Ever been in a situation where you have multiple aws accounts and still need to use them on the same device? Well, profiles sort that out for you. To add a new profile for example “qa-dev”, run:

aws configure --profile qa-dev

After that, use the --profile option with other commands to specify which profile you want to use when running CLI commands.

Service-Specific Help: aws <service> help

Need a deeper dive into a specific service’s commands? Use aws <service> help. For example, to explore all the options for S3:

aws s3 help

I could list the hundreds of commands that AWS CLI provides but more than 90% would not apply to you. The most common commands are the ones listed above. Depending on whether you are working with AWS Beanstalk, Bedrock, Cognito, Lambda or RDS the commands will differ.

To learn more about the commands, visit the AWS CLI documentation here.

Happy Building 🚀 and as always Long Live The Code.

Level Up Your Engineering Skills.

Flutter, with its hot reload and tons of widgets, is a dream for crafting beautiful and engaging UIs. But as our apps grows, so does the complexity of managing data flow and keeping your code organized.

Remember, it’s always advisable to avoid technical debt which for most of the part, happens when your app codebase starts getting to the thousands of lines. This is where design patterns come in — they’re battle-tested solutions to common software development challenges that engineers have faced since system engineering and design began.

Think of design patterns as architectural blueprints for your code. They provide a structured approach to object creation, communication, and relationships, leading to more:

• Reusability: Don’t reinvent the wheel! Design patterns offer pre-defined solutions that can be adapted across different parts of your app. Easy huh 😊.
• Maintainability: Clean and well-structured code is easier to understand, modify, and debug, saving you time and frustration in the long run 🚀.
• Testability: Design patterns often promote separation of concerns, making it easier to isolate and test individual components of your app ✅.

Let’s check out some of the most common design patterns for Flutter engineers, along with practical examples to illustrate their power:

The patterns and principles I share here are helping teams at Heylixir build a scalable product with great user experience for both our customers and developers alike.

Singleton Pattern

Ever needed a central place to store app-wide data like user preferences or a theme manager? The Singleton pattern ensures only one instance of a class exists throughout the application. Imagine a single “SettingsManager” class that controls the app’s theme. Any part of your UI can access this manager to retrieve the current theme settings and style its widgets accordingly. For apps using GraphQL, imagine a single GraphQL client that you can use to execute queries and mutations. An even more common example is a websocket connection, your app will almost always need only one.

This is where this pattern can be utilized.

class SettingsManager {
  static final SettingsManager _instance = SettingsManager._internal();

  factory SettingsManager() => _instance;

  SettingsManager._internal();

  ThemeData _themeData = ThemeData.light();

  void switchTheme() {
    _themeData = _themeData.brightness == Brightness.light ? ThemeData.dark() : ThemeData.light();
    // Notify listeners of theme change (implementation omitted for brevity)
  }

  ThemeData getTheme() => _themeData;
}

Factory Method Pattern

When you need to dynamically generate UI elements based on data, The Factory Method pattern provides an interface for creating objects without specifying the exact class upfront. This allows for greater flexibility — for instance, a factory class could create different types of buttons (primary, secondary) based on the data it receives.

For sports lovers think of a dashboard showing the bets a user has placed but depending on the game result, the user can see a won or lost widget.

abstract class ButtonFactory {
  Widget createButton(String text);
}

class PrimaryButtonFactory implements ButtonFactory {
  @override
  Widget createButton(String text) => ElevatedButton(onPressed: null, child: Text(text));
}

class SecondaryButtonFactory implements ButtonFactory {
  @override
  Widget createButton(String text) => TextButton(onPressed: null, child: Text(text));
}

// Usage
ButtonFactory buttonFactory = (isPrimary) => isPrimary ? PrimaryButtonFactory() : SecondaryButtonFactory();
Widget myButton = buttonFactory(true).createButton("Click Me"); // Creates a primary button

Provider Pattern

The provider pattern is a lightweight state management solution ideal for efficient data management. It leverages InheritedWidget to propagate data changes down the widget tree.

Think os a global list of user expenses for an expense app. The Provider pattern allows you to create a single ExpenseProvider that holds the counter state and “listens” for changes. Any widget down the tree that needs to display the expenses can access it through the Provider.

class MyExpensesProvider with ChangeNotifier {
  DateTime startDate = DateTime.now().subtract(const Duration(days: 30));
  DateTime endDate = DateTime.now();

  bool isLoading = false;
  String? error;

  List<Expense> expsenses = [];


  MyExpensesProvider() {

    getExpenses();
  }

  getExpenses() async {
    
  }

}

Composition Pattern

Flutter’s main strength lies in its composable widget system. This aligns perfectly with the Composition Pattern, which promotes building complex UIs by assembling smaller, reusable widgets.

This pattern promotes reusability, flexibility and testability.

class RoundedButton extends StatelessWidget {
  final String text;
  final VoidCallback onPressed;

  const RoundedButton({required this.text, required this.onPressed});

  @override
  Widget build(BuildContext context) {
    return TextButton(
      onPressed: onPressed,
      child: Container(
        padding: EdgeInsets.all(16.0),
        decoration: BoxDecoration(
          color: Colors.blue,
          borderRadius: BorderRadius.circular(10.0),
        ),
        child: Text(text, style: TextStyle(color: Colors.white)),
      ),
    );
  }
}

// Usage
Widget myScreen = Scaffold(
  body: Center(
    child: RoundedButton(text: 'Click Me', onPressed: () => print('Button Pressed')),
  ),
);

Bloc Pattern

The Bloc pattern offers a structured approach for state management, separating the UI (presentation layer) from the business logic (data fetching, calculations, etc.). This leads to cleaner, more maintainable, and highly testable code.

It includes Blocks that handle events, update and emit state, Events that represent app actions, State which is data contained in an app and the BlocProvider to manage Block lifecycle and provide it to child widgets. For those who are familiar with TypeScript and React, this is very similar to React Redux in a number of ways.

@immutable
abstract class CounterEvent {}

// Events
class IncrementEvent extends CounterEvent {}

class DecrementEvent extends CounterEvent {}

// State
class CounterState {
  final int counter;

  CounterState(this.counter);
}

// Bloc
class CounterBloc extends Bloc<CounterEvent, CounterState> {
  CounterBloc() : super(CounterState(0));

  @override
  Stream<CounterState> mapEventToState(CounterEvent event) async* {
    if (event is IncrementEvent) {
      yield CounterState(state.counter + 1);
    } else if (event is DecrementEvent) {
      yield CounterState(state.counter - 1);
    }
  }
}

// Usage (in UI)
Widget build(BuildContext context) {
  return BlocProvider(
    create: (context) => CounterBloc(),
    child: Scaffold(
      appBar: AppBar(title: Text('Counter')),
      body: Column(
        mainAxisAlignment: MainCenter,
        children: [
          BlocBuilder<CounterBloc, CounterState>(
            builder: (context, state) => Text('Count: ${state.counter}'),
          ),
          Row(
            mainAxisAlignment: MainSpaceEvenly,
            children: [
              ElevatedButton(
                onPressed: () => BlocProvider.of<CounterBloc>(context).add(IncrementEvent()),
                child: Icon(Icons.add),
              ),
              ElevatedButton(
                onPressed: () => BlocProvider.of<CounterBloc>(context).add(DecrementEvent()),
                child: Icon(Icons.remove),
              ),
            ],
          ),
        ],
      ),
    ),
  );
}

Conclusion

Most mobile engineers who work on mobile apps are not as familiar with design patterns and the goal of this guide was to offer a starting point for them as well as to give senior engineers a refresher on the most common patterns.

I created it for Flutter because the flutter docs don’t exactly offer these patterns in an explicit manner like Swift does for example. Additionally, these are patterns that I currently use at Heylixir.

Happy Building 🚀 and as always, Long Live The Code.

If you have been an engineer who uses JavaScript for at least the last 6 or so years then you are familiar with tons of JavaScript runtimes like Bun, Deno, Napa.JS, WasmEdge, NodeJS and probably a few others. Each of these were developed with a promise to make JavaScript a better language in a way; whether by making it lightweight, adding type checking, reducing memory consumption or making the runtime multi-threaded.

Now we have a new entrant in to this field and the developers are from AWS. This should not be a suprise because AWS engineers have built tons of tools that other engineers can use over time. Their experience working with the cloud and cloud infra has informed the new still experimental runtime called LLR (Low Latency Runtime).

As they put it:

LLRT (Low Latency Runtime) is an experimental, lightweight JavaScript runtime designed to address the growing demand for fast and efficient Serverless applications.

Yes, this is a rather nifty addition to the list especially with the rise of serverless platforms. Since 2020, almost all APIs I have build have been deployed to a serverless environment whether it’s a micro-service or a monolith.

As these kinds of APIs have increased, AWS saw the need to build their own runtime to try make serverless APIs run faster and effectively. One key issue that has been in everyones mind is, everytime your cloud function is executed for example, their is a cold starts happen.

A cold start occurs when AWS Lambda needs to boot up a new instance of a function’s container before it can execute the function’s code.

Given cold starts could take a few seconds, it can be alarming depending on the nature of platform using the API.

A way out?

Is there a way out of cold starts, yes. I have attached an article by Sean here. There are other ways like not using serverless functions but as we all know, that’s an awfully expensive ordeal that’s rarely justifiable. The most common advice for most people is to always keep serverless functions as nimble as possible, this allows cold starts to take less time.

And now we have LLRT, at least that’s the hope. The AWS team made a note that their runtime is not the silver bullet. LLRT is meant to be more efficient and faster for smaller serverless functions that don’t particularly run intensive tasks.

What this means for us is that we will still have to wait a while longer before we can get a runtime that works for all use cases.

Here are some screenshots from the AWS team showing LLRT vs NodeJS runtimes:

LLRT

NodeJS

Benefits

• Low latency: LLRT’s design prioritizes fast startup times and execution, resulting in lower response times for your serverless functions. This is important for real-time applications and microservices.
• Small footprint: LLRT uses minimal resources, leading to better resource utilization and potentially lower costs on serverless platforms.
• Simplicity: Its focus on a specific subset of JavaScript features makes it easier to understand and develop for.

Pros

• Ideal for specific use cases: LLRT shines in smaller serverless functions like data transformation, real-time processing, authorization, and validation.
• Complementary: It’s designed to supplement existing components rather than replace everything, offering options for targeted performance gains.

Cons

• Limited scope: LLRT isn’t meant for complex applications or computationally intensive tasks, as its stripped-down nature might impact performance.
• Experimental stage: It’s still under development, so you might encounter bugs or changes in future versions.
• Limited API support: It adheres to a subset of Node.js APIs, potentially requiring adjustments in existing code.

Conclusion

Cost, performance and speed have always been on top of my mind when I deploy any API so much so that I have used Go in the past to replace some functions whose performance was lack-luster.

I was excited to see the new runtime especially because it comes from AWS and it promises to make serverless APIs faster and more efficient. Yes this also means reduced bills from AWS but with the caveat that your functions are also efficient.

LLRT is still in development so if you want to try it in production, ensure you test it on your QA environment to validate your expectations when you go live.

When I get some time to do my own benchmark on the runtime, I will be sure to update this article or write a new one with more details on my observations.

For the curious, the github code for the runtime can be found here.

Happy Building and as always, Long Live The Code.

#aws #cloud #engineering #API #serverless