This is the sixth post in a multi-part series on the Realm Database; it shows how the features in the previous parts come together to make a database for modern mobile apps.
If you missed the first post on our custom engine, the second post on the benefits of some of the Realm API types, the third post on sharing code across platforms, the fourth post on good architecture, or the fifth part on notifications we recommend taking few minutes to read through.
Throughout this series, we’ve covered many interesting and useful aspects of the Realm Database and its SDKs. We highlighted a number of the core ideas behind Realm’s engine and the main concepts in the implementation of the language-dependent SDKs, which define the recurring patterns in creating mobile apps with Realm.
In this final piece we’re going to have a look at how everything we spoke about so far comes together to enable developers create faster, more robust mobile apps.
Realm Database highlights
If we look back at the first five articles in this series, this is what we covered so far:
- Realm doesn’t iterate over existing tech - it has its own storage engine built for performance and robustness.
- You get to work with native, live objects. You don’t have to do type conversion between “storage-only” or “programming-only” formats.
- Realm provides lazy, pull-driven collections in alignment with its zero-copy policy: “No data is being copied into memory and you can therefore never work with old, outdated data”.
- Realm provides data-change notifications and live collections to enable rapid reactive app development.
Get more development news like this
Even looking only at the short list above, it feels like a lot of special features are coming into play in the same product. Let’s consider some of the ways Realm changes how developers create apps.
Avoiding the humdrum of managing data changes
When using static data storage, a large part of the code that brings the app to life (e.g., networking, the data layer, view controlling, view bindings) has to do with pushing data to storage and figuring out when to pull changes from that storage.
Realm removes the need to come up with clever mechanisms to allow the different parts of your app to talk to each other. Realm manages your data AND notifies all interested parties about changes. You don’t need to use a data cache — or worse, an ORM.
The SDK lets your classes focus on their single responsibility and leave data synchronization and notifications to Realm. Without the need for different classes to communicate with each other, fetching and storing objects and driving the app UI is as simple as:
Reusing your data layer across platforms
Have you used a “perfect ORM” framework in your iOS app, and then expanded to the Android market only to find out that there is no alternative, so you have to go back to the drawing board?
Realm is multi-platform by design: It’s designed to be used across platforms, and you can re-use your code across some platforms and use the same Realm objects and structure across all platforms.
For example, a C# application can export files that can be shared with a tvOS app written in Objective-C — all thanks to the universal C++ core of Realm:
Designing your data layer to serve your business logic
When using a generic multi-purpose database, your app forces its way through the lowest common denominator of features the database offers to everyone. Realm has been specifically designed to be used in the constrained environments of mobile apps — the sooner you learn how to make the best out of Realm’s features, the better. There are plenty of ways you can improve the performance of your app by using Realm-specific data model patterns.
Lists, for example, are pre-sorted, instant collections. Instead of repeatedly filtering and sorting a collection of tens of thousands of objects (like you would usually do with an SQL database), you should use a list, so you can get instant access to your data and power up a table view or a map view right away. Lists are very cheap to create and maintain; they can really be the workhorse behind a blazing fast and robust app:
If you’re really pushing the boundaries of your system, you can even move select objects into another Realm file, which you open as read-only. That way, Realm can save additional resources because it will not monitor that file for changes.
Rapidly developing reactive applications
Many of Realm’s features empower quickly developing reactive applications. If we look at some of the characteristics that define reactive systems, we’ll see that the Realm Database adds those features to apps out of the box.
The apps are elastic because it doesn’t matter whether you’re showing 20 or 1000 items in a table, a list class instantly gives you the first few objects that you need to display on screen.
Apps are responsive thanks to Realm’s notifications that instantly notify all interested parties about changes. It also helps that developers don’t ever have to worry about using their database from different threads, and error-prone things like merging background contexts simply don’t exist.
Realm-powered apps are also resilient, since Realm runs trouble-free, except in exceedingly rare situations like disk corruption or running out of space.
Empowering offline-first apps
Realm has been designed from the beginning with an eye on building connected applications, specifically offline-first applications.
This has driven many of the design decisions of the Realm SDK. For example, staying away from auto-incrementing indexes (even though this feature has been requested numerous times!) is a cornerstone in enabling offline-first apps. As soon as your model includes auto-incrementing indexes, that binds you to a single source of truth, like a server, which you need to connect to before a user can use the app. Furthermore, you always need to wait on a response from the server to know the ID of newly created objects. (That said, we’re working on ways to make this work in offline-first apps.)
Another example is the
update parameter of the
Realm.add(_:update:) API. The SDK allows you to clearly specify whether your intent is to simply create new objects in the Realm Database, or to add and possibly refresh some existing objects (e.g., when fetching changed objects from a JSON API and updating your local Realm copy).
We Hope You Like What You’re Seeing!
We hope you liked everything you got to learn about Realm in this series. We haven’t covered everything about using Realm by a long shot, but hopefully we leave you inspired and curious to learn more about developing applications with Realm and discovering the new patterns in app creation made possible by the Realm Database.
All good things come to an end, so must this series. If you’d like to dig into some more code samples and maybe even give the Realm Database or Realm Platform a try, visit the learning section of our website:
- Read the docs or download the database (it’s free!)
Thanks for reading! 🙌 If you’re curious about other aspects of the Realm Database, the Realm Platform, or anything else we’re doing, let us know on Twitter, and maybe we’ll write an article!
About the content
This content has been published here with the express permission of the author.