DEV Community: 7oby

Flutter Offline Data Storage: Exploring Differents Solutions

7oby — Mon, 10 Mar 2025 09:59:44 +0000

Flutter’s out here flexing as one of the top, if not THE top, frameworks for building cross-platform mobile apps. It makes it easy to create apps that perform at their best and keep your users happy with smooth experiences.

Now, when we talk about user experience, there’s one thing that really matters — making sure your app works even when users are offline. Yeah, you need to make sure they can still access the important stuff in your app even when the Wi-Fi’s acting up or they’re somewhere with bad signal.

If you didn’t know, adding offline features to your app is gonna:

Boost the User Experience: Users can still get into your app and use its features without needing a strong internet connection. It makes your app more reliable.
Make Your App Faster: Storing data locally means your app loads up quicker and runs smoother.
Help Users in Low Connectivity Areas: People with bad or no internet still get to use your app, which makes it super useful in a bunch of places.
Cut Data Costs: Users save on data by using stored info instead of constantly re-downloading stuff.
Keep Things Running Smooth: Apps like note-taking or e-commerce can still run without any interruptions — users can add, edit, and save stuff while offline.
Get People Coming Back: If your app works well offline, users are more likely to stick around and use it more.
Make It Reliable: Offline mode means less chance of interruptions, so users can count on your app when they need it most.
Give Users More Freedom: They can use the app whenever, whether they’re traveling, in a meeting, or in a spot with bad connection.

There’re many ways to handle offline storage in Flutter. From simple stuff like key-value pairs with Shared Preferences to full-on databases like SQLite, or lightweight NoSQL ones like Hive and ObjectBox.

In this article, we’re gonna give you a quick rundown on each. But trust, we’ll dive deeper into them in upcoming posts — explaining what makes each of them tick and when to use ‘em.

So, let’s jump right in…

Shared Preferences Package

Shared Preferences is like a simple locker where you can store small data, like settings or app states. It’s perfect for lightweight storage, like saving the user’s theme, language settings, or login tokens. It’s easy to set up and doesn’t require you to deal with complicated databases.

Here’s how you use it:

import 'package:shared_preferences/shared_preferences.dart';

// Save a value
Future<void> savePreference(String key, String value) async {
 final prefs = await SharedPreferences.getInstance();
 await prefs.setString(key, value);
}

// Get a value
Future<String?> getPreference(String key) async {
 final prefs = await SharedPreferences.getInstance();
 return prefs.getString(key);
}

Pros:

Easy to set up for storing simple stuff.
Lightweight and fast.
Works cross-platform with a consistent API.

Cons:

Not built for complex data or big datasets.
Only stores basic types like strings, ints, and booleans.
No fancy query options for more advanced needs.

SQLite

SQLite is like a mini database you can embed directly into your app. It’s great for handling large, structured data with relationships. It’s good when you need to manage a lot of data and want to run SQL queries to fetch and manipulate it.

Check this out for basic SQLite operations:

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

// Setup the DB
Future<Database> initializeDB() async {
 String path = join(await getDatabasesPath(), 'example.db');
 return openDatabase(
   path,
   onCreate: (database, version) async {
     await database.execute(
       "CREATE TABLE items(id INTEGER PRIMARY KEY AUTOINCREMENT, name TEXT)",
     );
   },
   version: 1,
 );
}

// Insert a new item
Future<void> insertItem(String name) async {
 final Database db = await initializeDB();
 await db.insert('items', {'name': name});
}

// Get all items
Future<List<Map<String, dynamic>>> retrieveItems() async {
 final Database db = await initializeDB();
 return await db.query('items');
}

Pros:

Good for complex queries and handling relationships between data.
Handles big data sets well.
Transactions keep your data safe and secure.

Cons:

A little more setup than simple storage options.
Not needed if you only need to store small amounts of data.
You gotta know SQL, which might be a challenge for beginners.

Hive

Hive is a fast and simple NoSQL database made for Flutter. It’s light, quick, and great for storing data without the need for SQL. You can store basic data types, lists, and maps, and it handles read/write operations like a champ.

Here’s how you can get started with Hive:

import 'package:hive/hive.dart';
import 'package:hive_flutter/hive_flutter.dart';

void main() async {
 await Hive.initFlutter();
 var box = await Hive.openBox('myBox');
// Save data
 await box.put('name', 'Flutter Developer');
// Retrieve data
 String name = box.get('name') ?? 'No Name';
 print(name); // Output: Flutter Developer
}

Pros:

Super fast, making it great for performance-sensitive apps.
Simple and easy to use.
Supports lists and maps, making it more flexible.

Cons:

No relational features like SQLite.
Changing your data structure can be tricky.
Limited querying options.

Drift (Moor)

Drift (previously Moor) is like a turbocharged SQLite. It lets you work with SQL while adding cool features like real-time updates and automatic code generation. It’s great for apps with structured data and when you need your app to react to data changes in real-time.

Here’s how you set it up:

import 'package:drift/drift.dart';
import 'package:drift/native.dart';

// Define the structure
@DataClassName('Item')
class Items extends Table {
 IntColumn get id => integer().autoIncrement()();
 TextColumn get name => text()();
}

// Create the database
@DriftDatabase(tables: [Items])
class AppDatabase extends _$AppDatabase {
 AppDatabase() : super(NativeDatabase.memory());
 Future<List<Item>> getAllItems() => select(items).get();
 Future insertItem(Insertable<Item> item) => into(items).insert(item);
}

Pros:

Type-safe, so it avoids bugs when working with data.
Real-time updates, so the app UI stays fresh.
Built-in migrations to help with schema changes.

Cons:

Takes some time to get used to if you’re new to reactive programming.
Setup can be more complex than simpler storage methods.
Code generation and extra dependencies add a bit of overhead.

ObjectBox

ObjectBox is a high-performance NoSQL database built for mobile and IoT apps. It’s fast as hell, and you work directly with Dart objects, so there’s no need to convert stuff into JSON. It’s ideal for real-time apps or anything needing quick access to a lot of data.

Here’s how you set it up:

import 'package:objectbox/objectbox.dart';
import 'package:objectbox_flutter_libs/objectbox_flutter_libs.dart';

// Define the data model
@Entity()
class Item {
 int id;
 String name;
 Item({this.id = 0, required this.name});
}

// Create the ObjectBox store
void main() async {
 final store = await openStore();
// Save an object
 final item = Item(name: 'Flutter Developer');
 store.box<Item>().put(item);
// Get all items
 final items = store.box<Item>().getAll();
 items.forEach((item) {
   print('Item: ${item.name}');
 });
}

Pros:

Super fast for large datasets.
Directly works with Dart objects — no conversion needed.
Built-in reactive programming support.

Cons:

NoSQL, so not ideal for complex queries.
Limited docs and community support.
Might take time to get used to if you’re not familiar with object-oriented databases.

Final Thoughts

When it comes to choosing offline storage in Flutter, here’s what I recommend:

For simple preferences and settings: Go with Shared Preferences.
For fast data storage: Try Hive.
For structured data with relationships: Go for Drift (Moor).
For high-performance apps: ObjectBox is the move.
For complex data and queries: SQLite is the best.

At the end of the day, it all comes down to what kind of app you’re building. Choose wisely based on your needs, and you’ll be good to go.

Follow me! And stay tuned for future posts where we’ll break each of these options down in detail and show you exactly how to integrate them into your apps.

CPUs, GPUs, TPUs, DPUs, why?

7oby — Mon, 02 Dec 2024 15:15:21 +0000

For me (I mean at that time), things were as simple as this: There would be only two types of Processing Units: GPU and CPU. CPUs are the standard and GPUs are exclusively used for everything graphics related (like video games).

But then I slid into the Machine learning field and started hearing my pairs talking about TPU and sometimes about a mysterious DPU. Sometimes they are even struggling deciding which one to use to train their Machine learning models.

Which ones are those two again? And how are they different from the other ones.
I had to find answers to those questions. So I did some googling on the matter and found out MY WHOLE LIFE WAS A LIE.

CPUs, GPUs, TPUs, DPUs, none of those is technically better than the other. But simply each of them is built or optimized for a particular purpose which it excels at, compared to the rest.

So what is the purpose of having a CPU?

First you have to understand that Processing Units have what we call cores and each of those cores can perform only one task at the same time. So the more a PU has cores, the more tasks it is able to perform in parallel (i.e at the same time).

From far, CPUs have always been the best suited for the most logic heavy computer operations you can think of. That's because the high performance cores of a CPU are optimized for sequential (step by step) processing and low-latency branching.
So CPUs are the best option when it comes to complex operations like Database Query Execution, Operating System Management, Compiling Code, Encryption and Decryption, Data Serialization/Deserialization, File System Operations, Real-Time System Operations, Error Detection and Correction, Simulation of Rule-Based Systems, etc., or any task requiring extensive if-else or switch-case branching logic, which must be executed step-by-step.

The annoying thing about sequential processing though is that it can take time, so much time… especially for massive tasks like graphics rendering.
Imagine having to rely on a few CPU’s cores for a high graphics video game like Cyberpunk 2077. It would lag so much that you’d never want to play a video game in your life, lol.
Around millions of CPUs cores would be needed to render the graphics of such a game in real time avoiding any lagging and achieving an ideal User Experience.

“Why don't we add more cores to the CPU then?” You may ask.
Well, like we (implicitly) stated earlier, the cores of a CPU are very large and resource-intensive having quite a complex architecture and making the amount that can fit on a chip very limited (typically 4–32). Scaling such cores would increase power consumption and heat generation, leading to diminishing returns.

But there is good news! Many computer operations like graphics rendering involve tasks that are highly repetitive and can be broken down into many smaller, independent operations that do not require a lot of branching or conditional logic.

If we cannot scale the number of the large cores, How about building tinier cores of simpler architecture so that we could gather thousands of them to complete repetitive tasks in parallel? That would solve many problems like the graphics rendering one. Yes, and we would call that the Graphic Processing Unit.

The need of a Graphic Processing Unit

Enter the Graphics Processing Unit (GPU), a chip built for parallel computing. While CPUs may have up to 24 cores, modern GPUs like NVIDIA's RTX 4080 boast nearly 10,000 cores. Each core can perform a computation simultaneously.
And while they were originally built to solve the graphics rendering problem (calculating lights, shadows, and textures in real-time), the massive amounts of cores of GPUs and their parallelism make them an option for other tasks like
AI and deep learning (performing massive matrix multiplications for training models)

Then Why the TPU?

The Tensor Processing Unit (TPU) is a specialized chip designed for deep learning. Created by Google in 2016, TPUs focus on tensor operations (like matrix multiplication) required for training AI models. Unlike GPUs, TPUs eliminate the need to access shared memory or registers, making them far more efficient for neural network training.

If you’re working with massive datasets or training large models, TPUs can save you significant time and resources.

DPUs: The Data Center Workhorse

The Data Processing Unit (DPU) is the newest member of the computing family, optimized for data-intensive tasks in cloud environments. These chips handle:

Networking: Packet processing, routing, and security.
Data storage: Compression and encryption.

DPUs offload these tasks from CPUs, allowing the CPU to focus on general-purpose computing. While you won’t find a DPU in your laptop, they are essential for modern data centers where efficiency is paramount.

That's it!

If you didn't, now you know the difference between those proccessing units.CPUs remain the backbone of general-purpose computing, excelling in logic-heavy, sequential tasks. GPUs, with their massively parallel architecture, dominate in rendering, machine learning, and any workload requiring high-throughput computations. TPUs are purpose-built for deep learning, offering unmatched efficiency in training and inference for neural networks. DPUs, on the other hand, cater to data-centric operations, offloading tasks like networking and storage from CPUs to boost efficiency in large-scale data centers.

Next article,

on this subject will be for machine learning engineers, where we will discuss how to choose the right processing unit for your AI workload. We'll explore the roles of GPUs, TPUs, and CPUs in training and inference, compare their performance, cost, and scalability, and dive into practical tips for optimizing your machine learning pipelines for maximum efficiency.
Keep in touch!