Realm Blog

Realm Database 6.0: A New Architecture and Frozen Objects

by Katherine Maughan /

Realm is an easy-to-use, offline-first database that lets mobile developers build better apps, faster.

Since our acquisition by MongoDB in May, we’ve continued investing in building an updated version of our mobile database – Realm Database 6.0.

We’re thrilled to announce that it’s now in beta, meaning we’ve hit a major milestone on our MongoDB Realm Roadmap. Realm Database 6.0 is now included in the Realm Java 7.0, Cocoa 6.0, and JS/RN 4.0 SDKs and will follow later in .NET/Xamarin 5.0.

A New Architecture

This effort lays a new foundation that further increases the stability of the Realm Database and allows us to quickly release new features in the future.

We’ve also increased performance with further optimizations still to come. We’re most excited that:

  • The new architecture makes it faster to look up objects based on a primary key
  • iOS benchmarks show faster insertions, twice as fast sorting, and ten times faster deletions
  • Code simplifications yielded a ten percent reduction in total lines of code and a smaller library
  • Realm files are now much smaller when storing big blobs or large transactions.

Frozen Objects

With this release, we’re also thrilled to announce that Realm now supports Frozen Objects, making it easier to use Realm with reactive frameworks.

Since our initial release of the Realm database, our concept of live, thread-confined objects has been key to reducing the code that mobile developers need to write. Objects are the data, so when the local database is updated for a particular thread, all objects are automatically updated too. This design ensures you have a consistent view of your data and makes it extremely easy to hook the local database up to the UI. But it historically came at a cost for developers using reactive frameworks.

Now, Frozen Objects allow you to work with immutable data without needing to extract it from the database. Instead, Frozen Objects act like immutable objects, meaning they won’t change. They allow you to freeze elements of your data and hand it over to other threads and operations, without throwing an exception - so it’s simple to use Realm when working with platforms like RxJava.

Using Frozen Objects

Freeze any ‘Realm’, ‘RealmList’, or ‘RealmObject’ and it will not be possible to modify them in any way. These Frozen Objects have none of the threading restrictions that live objects have, meaning they can be read and queried across all threads.

As an example, consider what it would look like if you were listening to changes on a live Realm using Kotlin, and then wanted to freeze query results before sending them on for further processing:

val realm: Realm = Realm.getDefaultInstance();
val results: RealmResults<Person> = realm.where<Person>().beginsWith("name", "Jane").findAllAsync()
results.addChangeListener { liveResults ->
   val frozenResults: RealmResults<Person> = liveResults.freeze()
   val t  = Thread(Runnable {

       // It is now possible to read objects on another thread
       val person: Person = frozenResults.first()

Since RxJava needs immutable objects, we also updated our RxJava support so all Realm Observables and Flowables now emit frozen objects by default. This means that it should be possible to use all operators available in RxJava without either using Realm.copyFromRealm() or running into an IllegalStateException:

val realm = Realm.getDefaultInstance()
val stream: Disposable = realm.where<Person>().beginsWith("name", "Jane").findAllAsync().asFlowable()
       .flatMap { frozenPersons ->
                   .filter { person -> person.age > 18 }
                   .map { person -> PersonViewModel(, person.age) }
       .subscribe { updateUI(it) }

Frozen Objects are already available in the Realm Java SDKs, and will be available in the SDKs for other platforms soon. The APIs are still in beta, so if you have feedback please post it in Github and the Realm team will check it out!

A Strong Foundation for the Future

With the Realm Database 6.0 now in Beta and our first major feature released with Frozen Objects, we’re now focused on hitting the next milestones on our roadmap as we bring MongoDB Realm to public beta.

Want to learn more? Review the documentation.

Ready to get started? Download the database.

Safe Harbor

The development, release, and timing of any features or functionality described for our products remains at our sole discretion. This information is merely intended to outline our general product direction and it should not be relied on in making a purchasing decision nor is this a commitment, promise or legal obligation to deliver any material, code, or functionality.

Read more

Sharing the MongoDB Realm Roadmap

by Drew DiPalma /

We are pleased to announce a public roadmap for MongoDB Realm, the integrated product that combines Realm and Stitch, MongoDB’s serverless platform. The roadmap follows up on the vision that was presented at MongoDB World in June and brings you our more detailed plans.

We’re making our plans public so that you can see what’s coming, follow our progress, and give feedback as we work towards the best end-to-end platform for building modern applications.

Keep reading to learn about the investments we’re making and the key milestones on the way to building the MongoDB Realm product.

MongoDB Realm:

By mid-2020 we’ll hit a major milestone in our integration work when we release the public beta of MongoDB Realm.

We’re working to combine the best aspects of Stitch and Realm so that you can use Realm Sync alongside Stitch features like triggers and functions, authentication, Data access roles, and code deployment. We’re making sure it’s simple to sync data from the client to your Atlas database. And, we’re releasing new, merged MongoDB Realm SDK packages - along with lots of other features that will help you build better apps, faster.

An Updated Realm Database:

Over the summer, we increased Realm’s resources - including sending some MongoDB engineers to Copenhagen to help with the integration - and are working hard on future releases. Our teams have also charted the path to a fully integrated product, including new features and functionality that we’ve heard requested by this community.

By early 2020 we plan to release an updated version of the Realm Database that will allow our teams to more quickly iterate and release new functionality. As part of this work, the updated version - which we’re calling Realm Database 6.0 - will enable Thread Safe Objects and improve support for the latest iOS, Android and JavaScript versions.

We’ll continue developing the Realm Database during the first half of 2020, to allow for support for new types in the Realm schema, support for query operators on single-typed arrays, and Realm sharing between apps. All of these features give you more flexibility in how you store and interact with your data, and simplify your code.

New Features on MongoDB Stitch:

MongoDB’s serverless platform, Stitch, will also see new functionality like a GraphQL service. We’re enabling access across all of your MongoDB data sources to make it easy to start, extend, and scale your usage of GraphQL.

Coming Later:

Of course, there’s never enough time to do everything. As part of our roadmap effort we’ll be deprioritizing some Realm features, like:

  • Realm’s Query-based Sync, which needs to be re-architected to maximize scalability and performance. We expect to do this when MongoDB Realm moves to the GA phase in the second half of 2020.

  • The ability to host MongoDB Realm in your own environments. In the long-term, we plan to offer this, but it won’t be available as part of our beta release.

  • Support for Realm’s Syncs current Adaptors, or syncing to non-Atlas databases.

While these features aren’t going away forever, we’re focusing our efforts elsewhere as we start to build a strong foundation for the future of MongoDB Realm.

For full details on our plans and more specifics around features and functionality, be sure to read the full public roadmap. Have feedback? We’d love to hear it on our forums.

Safe Harbor

The development, release, and timing of any features or functionality described for our products remains at our sole discretion. This information is merely intended to outline our general product direction and it should not be relied on in making a purchasing decision nor is this a commitment, promise or legal obligation to deliver any material, code, or functionality.

Read more

MongoDB to Acquire Realm - The Future is Bright

by /

Since the early days of Realm, our goal has been to provide better solutions for building modern, mobile-first applications. From the strong community adopting our open-source database to enterprises using Realm Platform and data synchronization, we are striving to empower developers with tools across a wide range of platforms and use cases to develop better apps faster.

We’ve been extremely happy and proud of the growth to date. Realm’s database is used by over 100,000 developers, at companies ranging from small-to-medium to the Fortune 1000. Over 350 customers of varying sizes perform data synchronization between mobile devices and the Cloud via Realm Platform across all regions of the globe. We see a huge future opportunity for helping developers and enterprises with their mobile apps and digital transformation, and want to continue that growth.

To that end, we are thrilled to announce that Realm has entered into a definitive agreement to be acquired by MongoDB. MongoDB and Realm share a common goal and vision of providing the best possible solution for developers to work with data and accelerate innovation. We believe this announcement is a big step to accelerate the vision of Realm and support our community and customers at a new scale.

MongoDB is the leading modern, general purpose database platform, designed to unleash the power of software and data for developers and the applications they build. Headquartered in New York, MongoDB has more than 13,000 customers in over 100 countries. The MongoDB database has been downloaded over 60 million times and there have been more than one million MongoDB University registrations.

The combination of MongoDB and Realm will establish the modern standard for mobile application development and data synchronization for a new generation of connected applications and services. MongoDB and Realm are fully committed to investing in the Realm Database and the future of data synchronization, and taking both to the next phase of their evolution. We believe that MongoDB will help accelerate Realm’s product roadmap, go-to-market execution, and support our customers’ use cases at a whole new level of global operational scale.

While the acquisition is expected to close in MongoDB’s second quarter (May-July of 2019), we are thrilled to share this information with you now. To learn more, we encourage you to read the MongoDB press release or MongoDB’s CTO and co-founder Eliot Horowitz’s blog and you can see that MongoDB is just as excited as we are to realize this combination. More will be ready to share at MongoDB World, MongoDB’s annual global user conference on June 17-19 in New York City. We invite you to join us there – use the code WELCOMEREALM and receive 50% off tickets.

Both MongoDB and Realm are committed to supporting our customers on their current solution, and nothing will change right now. If you have any questions, please reach out to your Realm sales rep, send us an email at [email protected], or message us on Twitter at @realm.

Here’s to an amazing new future of Realm + MongoDB.

Read more

Realm and Microsoft Azure

by Ian Ward /

The Realm solution is incredibly flexible, capable of running on any device, extending any data source, with any Cloud. Here we outline the various steps and best practices to utilize Microsoft Azure as one Cloud solution; additionally, Realm is happy to host and manage your deployment for you, either in our Cloud or your Cloud, via our dedicated and managed Cloud deployment options. Please contact us if you’d like Realm to run the service for you as a dedicated or managed Cloud instance.

Getting Started with Realm Platform on Microsoft Azure

Overview The Realm Platform is a combination of a relational database server and client components connected via a fast and efficient sync protocol to enable real-time, connected apps and services that are responsive and performance irrespective of network status. The Realm Platform has two major components: the Realm Database and the Realm Object Server (ROS). These two components work in conjunction to automatically synchronize data enabling a large number of use cases ranging from offline first apps, field service and data collection apps, mobile services where data availability and user responsiveness is key. In addition through the integration capability with existing backends (SQL, Kafka, etc) Realm Platform is an excellent way to build a modern and real-time service experience while leveraging existing (and sometimes legacy) systems and data sources. To enable data synchronization, the ROS must be properly deployed and hosted. This document will show how easy it is to do this on Microsoft Azure which is already used by many of Realm’s enterprise customers.


  1. A Realm Object Server Feature Token (
  2. A Microsoft Azure Account
  3. An Azure Kubernetes Service (AKS) powered cluster (or the ability to create one)
  4. Experience developing mobile applications

Setting up the Realm Object Server in Azure In this section of the documents, we’ll show you everything needed to get a Realm Object Server running within your Microsoft Azure account. We’ll start by creating a cluster (if you do not yet have one). Then we’ll configure Helm and Tiller which are needed to easily deploy the server. Finally, you’ll deploy the server using Helm and inspect it to make sure the deployment was successful.

Create a Cluster with Azure Kubernetes Service if you do not already have one

Creating a cluster is easy with AKS. You can use Microsoft’s quickstart guide as a reference. You’ll want to take note of the project and cluster names that you use as you’ll need these later. We recommend a node size between 4-7 for a typical application deployment. For development purposes, feel free to start with a lower node count. It is also important to take note if you are using a RBAC enabled cluster (which is recommended for production applications).

After you create the cluster, we recommend ensuring that you can connect via the kubectl CLI. This is also explained in the quickstart guide. At the time of writing, you can do this from an Azure cloud shell with the following command:

##input your cluster information for connection
az aks get-credentials --resource-group myResourceGroup --name myAKSCluster
##verify connection by getting cluster information
kubectl get nodes

Prepare Helm and Tiller We use a Helm chart to distribute the recommended deployment architecture for the Realm Object Server. As a result, you’ll need to make sure it is configured properly for your environment. Luckily, using Helm and Tiller in Azure is easy, and you will find the process documented here. We recommend using the Azure Cloud Shell which comes with the Helm CLI already installed. After this, you will need to configure Helm which is detailed in the article linked above.

Note: If you are using an RBAC-enabled cluster, you will also need to create a service account to run tiller properly.

Deploy the Realm Object Server via Helm Add the chart repository Our charts are hosted on Github, and can be added to Helm with the following command:

helm repo add realm []( "Realm Helm Charts")

Prepare overrides file You should have access to a Realm Object Server Feature Token. This token must be passed to our Helm chart in order for Realm Object Server to operate. You can do so with an overrides file that preempts the Helm chart’s values file:


Deploy Realm Object Server

Once you have created an overrides file, you can use it when deploying:

helm install realm/realm-object-server -f overrides.yaml

When successful, you should see some output similar to:

NAME:   foolish-octopus
LAST DEPLOYED: Thu Jun 21 20:11:02 2018
NAMESPACE: default

==> v1/Role
NAME                          AGE
foolish-octopus-sync-default  1s

==> v1/StatefulSet
NAME                          DESIRED  CURRENT  AGE
foolish-octopus-sync-default  1        1        1s

==> v1/RoleBinding
NAME                          AGE
foolish-octopus-sync-default  1s

==> v1/Service
NAME                                 TYPE       CLUSTER-IP      EXTERNAL-IP  PORT(S)            AGE
foolish-octopus-realm-object-server  NodePort   <none>       80:30080/TCP       1s
foolish-octopus-metrics              ClusterIP   <none>       9081/TCP           1s
foolish-octopus-sync-default         ClusterIP  <none>       7800/TCP,9080/TCP  1s

==> v1/Secret
NAME             TYPE    DATA  AGE
foolish-octopus  Opaque  1     1s

==> v1/ConfigMap
NAME                                 DATA  AGE
foolish-octopus                      3     1s

==> v1/ServiceAccount
NAME                          SECRETS  AGE
foolish-octopus-sync-default  1        1s

==> v1/Deployment
NAME                                 DESIRED  CURRENT  UP-TO-DATE  AVAILABLE  AGE
foolish-octopus-realm-object-server  1        1        1           0          1s

==> v1/Endpoints
NAME                          ENDPOINTS  AGE
foolish-octopus-sync-default  <none>     1s

==> v1/Pod(related)
NAME                                                  READY  STATUS             RESTARTS  AGE
foolish-octopus-realm-object-server-547948d998-zgwbq  0/1    ContainerCreating  0         1s
foolish-octopus-sync-default-0                        0/1    ContainerCreating  0         1s

As you can see, Helm named our deployment foolish-octopus. You can set your own name for the deployment at installation by using the chart–name parameter.

Check the status of your deployment: To check the status of your deployment simple run the following command and check the individual statuses of each component

helm list

For future reference, you can uninstall Realm Object Server using the following command. If you get stuck, this might be the best course of action, after which you can start over: helm delete –purge foolish-octopus More information for troubleshooting with kubectl can be found here.

Developing a Mobile Application with Realm Sync Once you have a Realm Object Server deployed, we can start to synchronize data between mobile apps via shared Realm databases. We support the following mobile development platforms:

  • Native iOS: Swift, Objective-C
  • Native Android: Java, Kotlin
  • Cross-Platform: Xamarin, React Native

Start by Creating a Sample ToDo List Application The majority of our users start by following our basic ToDo app tutorial. Below you’ll find links for the major platforms:

Learn More of our Best Practices for Building an App with Realm Once you have some familiarity with how to develop with Realm, we strongly recommend reading over our detailed guide on how to properly build an app using Realm sync. This guide goes through important topics from architectural decisions to optimizing reads and writes. We consider this a must read for anyone who wants to build a highly scalable production application using the Realm Platform.

Read more

Realm 2018: A Year in Review, and a Look Forward to 2019

by /

Welcome to 2019! 2018 was a great year for Realm, its customers and partners, our international community of active developers, and everyone else focused on building reactive, responsive mobile and IoT applications that require data synchronization and/or offline support. I wanted to take a moment and reflect on the accomplishments in 2018 and what to look forward to in the year to come.

2018 saw the launch of Realm’s cloud, making it easy and simple for anyone to get started with Realm Platform. We went live with instances in both US and EU, and can make instances available in other geographies as needed. We published the how-to guide for building synchronized applications with Realm to ensure it is as easy and straightforward as possible. With all kinds of customers across a wide range of use cases now building and deploying their applications against our public cloud, we launched our status page so we could announce maintenance windows and inform you about downtime. We worked as well at improving our online documentation. We’d love to hear your feedback as we continue to improve both the service and the documentation.

Running and maintaining enterprise software, and keeping up with best practices, is not always easy. As such we launched in 2018 our dedicated and managed Cloud options for customers who want Realm to manage their backend. We are thrilled and encouraged that multiple customers quickly signed up for that option, with some that even migrated from a self-hosted private Cloud. If you’d like to migrate or otherwise take advantage of Realm’s capabilities in the Cloud, please let us know. We can support and maintain Realm running in multiple different Clouds, as we have certified our solution on most major Cloud environments. and have customers actively running on various different Cloud solutions today. We’ve even started looking at true hybrid Cloud solutions making use of Realm synchronization and Cloud-based serverless functions, such as one example we announced publicly with IBM in December 2018.

As we hope you know, Realm supports the ability to synchronize from a variety of backend databases or master data sources, and in 2018 we significantly improved our existing adapters as well as developing support for new ones such as a Kafka connector. If you have a specific backend you need a connector for, please let us know.

Our active community for the open-source Realm mobile database continued to grow as well. Today 65% of the Fortune 1000 companies use Realm in at least one of their mobile apps. Thanks to all of your help and efforts, our Github stars grew to over 47k. We are as well particularly excited that an independent book was published on how to build modern Swift apps with Realm. 2018 also saw dramatic improvements to the Realm Studio browser to make it as easy as possible to build applications with Realm, and we open-sourced the browser as well. Finally, we’ve broadened our cross-platform and flexibility goals with support for GraphQL among other interfaces.

So what’s in store for 2019?

We are working hard to ensure continued growth in all areas of Realm, as we look to help both developers and enterprises create modern applications that deliver improved productivity, offline-first “always on” functionality, and improved user experiences via synchronization and zero-latency data access. You can expect product enhancements in multiple areas towards that goal this coming year. We plan on expanding our Cloud offering into the Asia-Pacific region as needed by the global community. We will broaden our set of adapters with a Kafka Consumer, a Kafka Producer, and a set of other interfaces into popular backends. (And if you have a favorite request, please let us know!) We are looking at multiple mechanisms to evolve our key interfaces and functionality into “cloud functions” to make it easier to deploy and utilize the Realm Cloud. Of course, we continue to improve performance, scalability and look to offer both more advanced and simpler deployment options. And finally, for all our SDK users, we have been working on a upgrade of our core database that will unlock long requested capabilities such as Set and Map data-types, handling of unstructured data and even deliver Inheritance and polymorphism!

The world is increasingly moving toward the need for device-local data and processing, and Realm is leading the charge. Let us know how we can help you, and here’s to a great 2019!

Read more

Best Practices “How to Build An App” Realm Guide

by Ian Ward /

We recently finished a guide on how to build an app with Realm sync. We believe that this guide will serve as an invaluable resource for all of our companies and developers who are looking to release a reliable and scalable production application, whether they are running in Realm Cloud or self-hosting.

The guide can be found within our sync documentation. The document covers important topics such as

•	Important terminology
•	Factors to consider when choosing which type of synchronization model is correct for your application
•	User authentication and management
•	Client design decisions
•	Permissions
•	Considerations when hosting your own Realm Object Server
•	Details specific to adapter, event Handler, and GraphQL service

A great deal of experience has gone into the production of this document, and the guide will continue to be updated over time. We believe that this is a must-read guide for Realm developers and enterprises as it covers a great deal of best practices and design decisions. Please give the document a read through and send any feedback to us at [email protected]

Read more

Realm and IBM Cloud Functions

by Ian Ward /

Today we are pleased to announce a collaboration between Realm and IBM to bring the power of Realm to the flexibility and extensibility of IBM Cloud. This collaboration combines Realm’s capabilities for offline-first and zero-latency mobile applications with IBM’s Cloud and IBM Cloud Functions, enabling server-side triggers written in any language (including Swift!), for the real-time facilitation of arbitrary functions and application extensions. We have open-sourced a demo application and recorded a video of it, but this is just the beginning – this is purely an example demo, and the possibilities are endless.

The combined solution pairs a Realm-enabled mobile app with its native Realm sync technology to seamlessly synchronize state changes to and from a IBM Cloud deployed Realm Object Server in a bidirectional manner. The Realm Listener and Realm Event Handler, as part of the Realm Object Server solution, send updates and changed data in real time to the IBM Cloud Function, which is IBM’s implementation of serverless or Functions-as-a-Server. One aspect of this collaboration that should be particularly compelling to mobile developers is that IBM’s Cloud Functions can be completely written in Swift, enabling a mobile app developer to build a full stack application where both the frontend and backend share the same codebase.

In our demo app, we demonstrate how a Realm-enabled application fetches restaurant data from Foursquare’s API, triggered by a location object being synced from the mobile’s GPS. This is saved to Realm on the device, which then persists to Realm Object Server and notifies Realm’s server-side event handler which subsequently calls the IBM Cloud Function and then sends the result back down the mobile app. The beauty of this is that the restaurant data is saved locally in Realm on the mobile device, delivering a truly offline experience when WiFi or cellular coverage is not accessible or being agreeable.

We deployed the prepackaged Realm Object Server Helm chart to IBM Cloud’s Kubernetes as a Service offering; however, the Realm Object Server can be deployed anywhere, even locally, because the event handler and IBM Cloud Functions, built on Apache Openwhisk, can all be called remotely with built-in APIs. The Realm Event Handler is also deployed as a container on IBM’s Kubernetes Service and is configured with API tokens to talk to the IBM Cloud Functions. This serverless function is then configured with an API token from Foursquare enabling you to fetch data based on a given latitude and longitude. This JSON of restaurants is simply mapped to the Restaurant objects stored in a Realm on the Realm Object Server which automatically syncs the result down to the mobile app.

Please give the repo a spin and let us know what you think! All the instructions you need to get this up and running are in the document in the repository on GitHub, and you can watch an annotated video that describes the application here.

Do you have a mobile app that could use an integration into serverless functions to deliver more value to your users? We would love to hear about it! We are interested in cloud users that have deployed an app to production who would be intrigued in adding server-side event processing capabilities to their app similar to those described in this demo app.

We are happy to help build the code and run the handler for you on the IBM Cloud. With this opportunity comes co-blogging events and the potential for free credits for running the service as well as expert support from our developers to ensure that the written code is as performant as possible.

Contact us at [email protected]

Read more

Why Can’t It Work Like Email?

by /

I was sitting at Starbucks when I overheard someone complaining about the usability, or rather the lack thereof, of an app on their phone. Clearly they were having network connectivity problems (all too often your phone will automatically connect to a wifi network but not actually be connected to the Internet until you process the click-wrap or portal-agreement page). At a moment of frustration, the individual exclaimed “I just want to use (the app)…why can’t it work like email!”.

This is a more astute comment than it might initially seem. For decades, email has been purposely designed to give the “right” user experience and properly function independently of network connectivity, latency, and available bandwidth – I can create, delete, and read emails locally on my device, and all changes are eventually sent or replicated back to the Cloud for action. These changes could be sent immediately, or could be delivered hours or even days later when my device is finally properly connected, but the main point is that the usage model for email is independent of the connectivity (at least for most email clients).

The usage model is clearly fundamentally different for most other mobile applications. Many actually block users from using the app if they are not properly connected to the network (see the screen shot below); others simply spin waiting for network connectivity, or otherwise do not allow users to perform updates and manage the data. While some apps may require real-time network access to properly function (e.g. real-time stock market quotes), the vast majority could actually “work like email” and provide a dramatically enhanced experience.

It shouldn’t have to be like this:network access image

Solutions like Realm allow developers to build their apps so that they do work like email. Realm is a new and improved way for managing the connectivity and data flow between Cloud and device, and, like email, ensures both that users can interact with the data locally on the device and that the changes (creations, deletions, modifications) are tracked properly and replicated back to the Cloud and other devices, either in real-time or whenever connectivity is restored. This new model enables a much improved user experience, which enables dramatically happier users, reduced churn, more revenue, and overall better results. Realm can be built into your existing Cloud service or accessed as its own SaaS service via the Realm Public Cloud. Come check it out, and join the growing community that is building better mobile applications.

Read more

It’s All About the User Experience Part III: Scalability and Improved Cloud-to-Edge Communication

by /

As I mentioned in part one (It’s All About the User Experience: Offline Support), and part two (Responsiveness and Zero-Latency Data Access), the Cloud has been an amazing enabler, allowing the rapid launch of new and innovative solutions and making those solutions and services accessible and available world-wide and from multiple devices. However, while the Cloud enabled and principally solved the any device, anytime part of the equation, the anywhere part assumes good connectivity and service responsiveness to be true, which often it isn’t. The Cloud, therefore, actually and is unfortunately degrading the user experience, especially relative to today’s users’ expectations of instantaneous experiences that are always available at one’s fingertips, everywhere and anywhere.

In part three and the final part of this series on the user experience, we’ll focus on the notion of scalability and improved communication between the Cloud and the true edge – the mobile or IOT device – and talk more about the connective tissue between the two.

Many applications today function by requesting data or various data sets from the Cloud, either on boot-up or based on specific user action. The data may include application content or meta-data, images and related graphics, A/B UI testing directives, or even fundamental aspects of the UX itself. However, most companies that I talk to find that as they grow in user adoption and thus the number of devices, they encounter a fundamental scaling problem – the size and amount of data, the sheer number of devices and the fact that this data needs to be exchanged over and over again strains the system architecture. The key interfaces (the “head-end”) in the Cloud that communicate with the devices begins to fall over under the strain, and the overall system no longer delivers the experience expected by the user community without costly and expensive internal system upgrades. It’s a fundamental problem caused by success, but that doesn’t make it any more palatable, especially since the cost of scaling the internal architecture can quickly outpace the financial gain of increased users and usage. The key to avoiding this scalability problem and its ensuing impact on the user experience is improving the communication between the Cloud and the devices at the edge.

Solutions like Realm bridge the gap between the device and the Cloud and allow for unprecedented efficiencies as solutions and applications scale. Rather than send all the data to the device every time, Realm allows developers to cache data on the device — Realm will update it automatically when it changes, which fundamentally reduces the amount of data that gets sent to the device as only updates need to be sent instead of sending all the data every time. Additionally, for large data sets, delta data diffs can be delivered instead of resending the entire object. These changes can dramatically improve the efficiency and scalability of the system, reducing overall load at the head-end of the Cloud, and not just make the system less expensive to operate but fundamentally deliver an improved user experience.

In a world where most services have multiple options, delivering the best possible user experience at the right price and cost structure is critical. The current default mechanism of fetching ever-increasing data sets from the cloud every time simply doesn’t scale, isn’t efficient, and ends up negatively impacting the user experience. REST is not actually best – solutions like Realm can help. Come and check out why various companies are coming to Realm to fundamentally drive the next-generation of user experience.

Read more

It’s All About the User Experience - Part II: Responsiveness and Zero-Latency Data Access

by /

As I mentioned in part one (It’s All About the User Experience: Offline Support),the Cloud has been an amazing enabler, allowing the rapid launch of new and innovative solutions and making those solutions and services accessible and available world-wide and from multiple devices. However, while the Cloud enabled and principally solved the any device, anytime part of the equation, the anywhere part assumes good connectivity and service responsiveness to be true, which often it isn’t. The Cloud, therefore, actually and is unfortunately degrading the user experience, especially relative to today’s users’ expectations of instantaneous experiences that are always available at one’s fingertips, everywhere and anywhere.

In part two of this series on the user experience, we’ll focus on the responsiveness of the user interface and the benefits of zero-latency data access.

As an example, in my home I have television and content services provided by a company with a Cloud DVR. In general, it works well, and I love the ability to access content from any device over any connection. However, during periods of high latency or lag, the solution becomes downright horrible, when even seemingly simple tasks such as browsing the content guide or changing the channel get queued up with no feedback for the user. The entire UI grinds to a halt, making the system unusable, and then at some point in the future it unfreezes and processes every queued key press in rapid succession, resulting in unanticipated behavior and frustrating results. While the content, of course, benefits from being in the cloud, the meta-data describing that content should be available on the device and shouldn’t necessarily be dependent on instantaneous cloud access because the user experience drops to “unusable” the instant the latency exceeds a given threshold.

Most mobile applications have the same problem – they rely on fetching data from the Cloud, and are largely unusable or otherwise paused when doing so. Latency cannot always be guaranteed on most networks, especially mobile and WiFi, but is critical to providing a good experience, driving usage, and even revenue. Amazon found every 100ms of latency cost them 1% in sales; Google found an extra half-second in search page generation time dropped traffic by 20%. When consumers have choices, they will use the solution that provides the best experience, and churn off the applications that don’t. So why don’t more applications focus on providing a good experience? The key to avoiding this latency-induced lag is storing data locally on the device and enabling zero-latency access to data.

Solutions like Realm allow developers to store data locally on the mobile/IOT device, keep it updated in real-time, and track changes both on the device and the Cloud to automatically resolve conflicts caused by updates. In the above example, the meta-data around content could be stored locally on my device(s) and updated as it changes (and in reality, it changes slowly). In the second example, the important data could be stored locally on the mobile or IOT device, ensuring that the UI is highly responsive and reactive, independent of the current connectivity characteristics. In this way the system can deliver unparalleled user experiences, ensuring continued usage, customer acquisition, revenue, and reputation.

In a world where most services have multiple options, and today’s expectation of service experiences (often assuming instantaneous access to data), delivering the best possible user experience is critical, and the current default mechanism of relying on on-demand data fetching from the cloud is not adequate to satisfy this requirement. REST is not actually best – solutions like Realm can help. Come and check out why various companies are coming to Realm to fundamentally drive the next-generation of user experience.

Read more

It’s All About the User Experience - Part I: Offline Support

by /

The Cloud has been an amazing enabler to allow the rapid launch of new and innovative solutions, and make those solutions and services accessible and available world-wide and from multiple devices. The Cloud is key for mobile-first experiences that are at the forefront of the digital transformation which many companies went through or are going through to enable any device, anytime and anywhere access. While the Cloud enabled and principally solved the any device, anytime part of the equation, the anywhere part assumes good connectivity, low latency, and service responsiveness to be true. While (rightly so) a lot of attention and investment is spent on UX and UI, the assumption for most is that connectivity issues and continuity of the experience under adverse conditions is relegated to backend engineering, or worse, the mobile carrier’s problem. Given that connectivity, bandwidth, and latency fundamentally change and are often incompatible with delivering a great experience, I might argue that the Cloud can actually and unfortunately degrade the user experience, especially relative to today’s users’ expectations of instantaneous experiences, always available at one’s fingertips, everywhere and anywhere.

In this multi-part series on the user experience, we’ll focus on various aspects of the user experience and how to improve it – first, let’s look at the user experience and the notion of offline support.

I have previously written about my experiences with airline apps on the mobile phone. It is highly frustrating to watch a mobile app spin while fetching data from the Cloud because the connection at the current point in time is not strong enough, suffers from high latency, or worse cannot get a data channel because all the nearby cell-towers or Wi-Fi hotspots at the Airport are overloaded. As a user, I understand the need to wait when I am fundamentally requesting new or updated data, but for data that rarely changes and should be instantly and predictably available, it can be incredibly aggravating.

Even worse, most applications today fundamentally don’t work when connectivity drops, often stalling or popping up “you are not connected” banners in the UI. While obviously certain transactions require connectivity, such as transactional services like purchases or state changes, most applications could continue to function during temporary network changes, perhaps in some degraded state, if the data being accessed was stored locally on the device. I call this offline support. And having offline support, I would argue, is critical to providing that seamless, good experience that mobile users expect. Whether you are browsing content tiles, accessing collections of data, or reviewing previous information and messages, having the data stored locally on the device and updated in real-time when connected to the network provides the best of both worlds – an up-to-date experience when connected to the network, and a useful, seamless experience when not. This is the way email has worked for the longest time – why shouldn’t all apps function this way?

Providing offline support is one powerful use case from Realm. Realm bridges the gap between the device and the Cloud and allow applications to provide the best experience – local data for offline support, the ability to keep that data updated in real-time, and the guarantee to track changes due to data updates and resolve any and all conflicts created by simultaneous updates. Realm allows developers to deliver an unparalleled user experience, independent of connectivity, by enabling this offline support.

In a world where most services have multiple options, and given today’s expectation of service experiences by the consumer (often assuming instantaneous access to data), delivering the best possible user experience is critical to driving revenue and usage, keeping and growing the user population, and minimizing churn. The current default mechanism of relying on on-demand data fetching from the cloud is not adequate to satisfy this expectation. REST is not actually best – solutions like Realm can help. Come and check out why various companies are coming to Realm to fundamentally drive the next-generation of user experience.

Read more

Technical Guest Post: “The things I’ve learned using Realm”

by /

It’s been exactly two years since I posted the article “How to use Realm like a champ”!

In this article, I try to sum up all the things I’ve learned from using Realm, and how it all relates with the current landscape of Android local data persistence: Android Architecture Components, Android Jetpack, Room, LiveData, Paging, and so on. Stay tuned!

An overview of Realm

Realm debuted as a mobile-first database, and has since grown into its own full-scale data synchronization platform. From the get-go, Realm’s vision was to provide the illusion of working with regular local objects, while in reality enabling safe and performant concurrent sharing of data. On top of that, Realm intends to handle most complexities of concurrency, and when something changes in the database, we receive notifications so that we can update our views, to always reflect the latest state of data. With the Sync Platform, these changes could be committed across multiple devices, and get seamlessly merged, like with any local write. Personally, I’ve used the Realm Mobile Database in multiple applications, and if there’s one major thing it taught me, it is to prefer simplicity over complexity. Sometimes, we might be so used to doing something in some way, that we don’t even think of just how much easier it could be with a slightly different approach.

In case of Realm, that different approach is observable queries, but of course, being able to define classes that are automatically mapped to database without having to think about relational mapping and joins is also a plus.

Out of the box, with Realm, pagination from a local data source is also not a real problem, as data is only loaded when accessed, therefore whether it’s 200 items or 10000, we can’t run out of memory, and the query will generally be fast.

A story of faulty abstractions

It is commonly seen as a good practice to abstract away specific implementations under our own interfaces, so that if need be, they can be safely replaced with a different implementation. And if you ever truly do need to swap out one implementation for the other, it’s definitely helpful that changes are localized to a single “module”, instead of it influencing parts of the code all over the codebase.

However, sometimes we think we’d like the module to behave one way, and enforce a contract that might not necessarily be the best solution to our problem. In this case, our interface restricts us from using a different approach.

In the case of local datasources, the common “mistake” is that if we have a DAO layer, then the DAO must have methods akin to this:

public interface CatDao {
   List<Cat> getCatsWithBrownFur();

In which case we’ve hard-coded that we have no external arguments (and is intended to be a constructor argument of the dao, most likely a singleton instance), and that retrieval of data is single, synchronous fetch. Following up on that could be, for example, a Repository:

public interface CatRepository {
   void getCatsWithBrownFur(OnDataLoaded<List<Cat>> callback);

In which case we’d ensure that the getCatsWithBrownFur() is most likely executed on a background thread, and will make its callback on the UI thread. The retrieval of data would be a single, asynchronous fetch. The data is loaded in its entirety to memory on a background thread, then passed to the UI thread for it to be rendered.

But is this really the best thing we can do?

What Realm’s queries look like

Observable async queries, change listeners, and lazy loading In Realm, or at least in its Java API, you receive a so-called RealmResults, which implements List. So we might be tempted to just use it as a List and move on. But that’s actually not how it’s intended to be used: Realm updates any RealmResults after a change has been made to the database, and notifies its change listeners when that’s happened.

So in practice, setting up a Realm query on the UI thread involves both defining the query, AND adding a listener to handle any future change that happens to it.

private Realm realm;
private RealmResults<Cat> cats;
private OrderedRealmCollectionChangeListener<RealmResults<Cat>> realmChangeListener = (cats, changeSet) -> { adapter.updateData(cats, changeSet);    // initial load + future changes
protected void onCreate(Bundle savedInstanceState) {
   realm = Realm.getDefaultInstance();
     // ← open thread-local instance of Realm
   cats = realm.where(Cat.class).findAllAsync();
     // ← execute Async query
     // ← listen for initial evaluation + changes
protected void onDestroy() {
   cats.removeAllChangeListeners(); // ← remove listeners
   realm.close(); // ← close thread-local instance of Realm

For those familiar with Swift, the API is slightly different, but it does the same thing:

let realm = try! Realm()
let results = try! Realm().objects(Cat.self)
var notificationToken: NotificationToken?
override func viewDidLoad() {
   // …
   self.notificationToken = results.observe {
    (changes: RealmCollectionChange) in   // … (handle changes)
   // call `notificationToken?.invalidate()` when needed
} ```

But we’re getting lost in details. What’s different here, compared to the aforementioned common DAO approach? Well, pretty much everything.

The common DAO pattern assumes that we want to call the DAO to refresh our data, whenever we know that any other parts of the application, on any other thread could have potentially changed the data we’re showing. That’s quite the responsibility!

In case of Realm, we can observe the query results — in fact, Realm automatically updates it for us, whenever it’s been changed. In this case, our listener is called: and we even receive the positions of where items have been inserted, deleted, or modified. When we commit a transaction, Realm handles all of this for us in the background.

Another thing to note is that when using Realm’s Async queries, the evaluation of the new result set and the diff happens on Realm’s background thread, and we’ll see the new data along with the changes only when the change listeners are being called.

When we call an accessor on a RealmResults, we actually receive a proxy instance, that can read from and write to the data on the disk, essentially minimizing the amount of data read to memory. This eliminates the need for pagination, even when working with larger datasets.

RealmResults<Cat> cats = realm.where(Cat.class).findAll();
  // sync query for sake of example
Cat cat = cats.get(0);
  // actually `fully_qualified_package_CatRealmProxy`
String name = cat.getName();
  // calling accessor reads the data from Realm

The price of proxies: threading with Realm

Anyone who’s used Realm knows that there is a price to pay with proxy objects and lazy results, which also extends to Realm’s thread-local instances. Namely, that while Realm handles concurrency internally, the objects/results/instances cannot be passed between threads.

final Realm realm = Realm.getDefaultInstance();
Thread thread = new Thread(new Runnable() {
public void run() {
 RealmResults<Cat> cats = realm.where(Cat.class).findAll(); // <--
// IllegalStateException: Realm access from incorrect thread.
// Managed objects, lists, results, and Realm instances can only be
// accessed on the thread where they were created.

I’ve often heard the claim that “threading with Realm is hard”. I firmly believe this claim is false.

Even when there are multiple threads involved, using Realm is pretty easy — just get an instance of Realm for while you need it, then close it.

// on a background thread
try(Realm realm = Realm.getDefaultInstance()) {
   // open Realm for thread
   // use realm
} // realm is closed by try-with-resources

The one special case the developer has to remember is that instead of passing a managed object, you should generally pass its primary key, then re-query it on the background thread instead.

final String idToChange = myCat.getId();
// create an asynchronous transaction
// it will happen on background thread
realm.executeTransactionAsync(bgRealm -> {
// we need to find the Cat we want to modify
// from the background thread’s Realm
Cat cat = bgRealm.where(Cat.class)
         .equalTo(CatFields.ID, idToChange)
// do something with the cat

However, that’s actually as far as complexity goes, when it comes to Realm and threading, out of the box. RealmResults are already evaluated automatically by Realm on a background thread, and then the data is passed to the listener on the UI thread, so there is zero reason to ever try to pass them between threads.

Why people think threading with Realm is hard

So why is the claim so common? After spending a lot of time on the realm tag on Stack Overflow, I believe it comes down to the following primary causes:

1.) The developer has introduced RxJava into their project without understanding it, and end up introducing such level of complexity that they don’t understand what threads their code is running on.

2.) The developer doesn’t know how RealmResults works, specifically that findAllAsync() will evaluate the results on a background thread, and then the RealmChangeListener will receive it on the UI thread — and instead they attempt to handle the threading that Realm would already handle for them internally.

3.) Reluctance to pass instance of Realm as a method argument, and/or intending to use Realm’s thread-local instances as global singleton.

The first and second causes are self-explanatory. But what about the third?

When you “get an instance of Realm” with Realm.getDefaultInstance(), you actually receive a thread-local and reference counted instance, where the reference count is managed by calls to getDefaultInstance() and close(). It is not a singleton, and it cannot be accessed on different threads.

It’s a little known fact, but to avoid passing Realm and instead see it as a thread-local singleton, it’s possible to store it in a ThreadLocal. Then, once set on a given thread, Realm can be acquired from it as simply as Realm realm = threadLocal.get(). This is one way one could turn instances of Realm into globally accessible variables. In this case, what we need to manage is Realm’s reference counting.

Why do people need and want a singleton instance of Realm? To create the data layer implementation for their abstraction, of course!

public interface CatDao {
List<Cat> getCatsWithBrownFur();
 // ← initial attempt: uses List (no changes!) and has no arguments
// -------------
// alternatives?
RealmResults<Cat> getCatsWithBrownFur();
 // ← problem: Realm opened and closed could immediately
 // invalidate the results, Realm-specific

RealmResults<Cat> getCatsWithBrownFur(Realm realm);
// ← problem: We’re passing Realm as a dependency
 // as part of the contract, Realm-specific

So we’d like to create a contract that lets us hide Realm as an implementation detail, but takes it into consideration that data could be evaluated on a different thread, and is sent to us with some delay through a subscription (to a listener). And on top of that, any future writes to the database that invalidate our current dataset should trigger a retrieval of the new data, and notify us of change.

public interface CatDao {
  LiveObservableList<Cat> getCatsWithBrownFur();
  // it would be possible to write a wrapper
  // around RealmResults like this
  Observable<List<Cat>> getCatsWithBrownFur();
  // it is possible to convert listeners to Rx Observable
  // something else???

How Realm shaped the future of local data persistence on Android

The introduction of Jetpack, Room, and LiveData With time, other libraries emerged that supported the notion of “observable queries”. One of the first to follow Realm was SQLBrite, which exposed SQLite queries as Observable<List> — and used RxJava to do so.

Eventually, Google created their own approach, called the Android Architecture Components — which are now a part of Android Jetpack. The idea was to solve common problems that developers face when writing applications, and simplify them by providing a set of libraries and an opinionated guideline that helps solve these problems.

Observable queries with Room and LiveData The most notable addition to the Architecture Components is LiveData. It is a “holder” that can store a particular item, and can have multiple observers. Whenever the data stored within the LiveData is changed, then the observers are notified, and they receive the new data. When a new observer subscribes for changes of the LiveData, it receives the previously set latest data.

One of the biggest additions to the Architecture Components was Room, which is Google’s own ORM over SQLite. But what’s more interesting is that it allowed defining a DAO (for accessing the entity’s tables) like this:

public interface CatDao {
  LiveData<List<Cat>> getCatsWithBrownFur();

We can then use this in our Activity:

private LiveData<List<Cat>> cats;
private Observer<List<Cat>> observer = (cats) -> {
adapter.updateData(cats); // initial load + future changes
protected void onCreate(Bundle savedInstanceState) {
 CatDao catDao = RoomDatabase.getInstance()
                    .catDao(); // get Dao
 cats = catDao.getCatsWithBrownFur(); // ← execute query
 cats.observe(this, observer);
// ← listen for initial evaluation + changes
protected void onDestroy() {
 // no need to unsubscribe,
 // because of `observe(LifecycleOwner`

Doesn’t this look extremely familiar? Swap out Observer for RealmChangeListener, and LiveData<List> for RealmResults, and it should look almost just like the example above!

When we subscribe for changes of a LiveData (or more-so, “start observing it”), then as there is at least one active observer, Room begins to evaluate the query on a background thread, then passes the results to the UI thread. Afterwards, Room tracks the invalidation of the table(s) this query belongs to, and if that table is modified, the query is re-evaluated.

The key differences are that the diff calculation is moved to the adapter (see ListAdapter), and that LiveData’s lifecycle integration allows for automatic unsubscription of its observers, instead of having to do it explicitly.

Otherwise, the behavior is rather similar, in fact, so similar that LiveData<List> is a possible way to wrap RealmResults as merely an implementation detail — as it’s also shown in Realm’s examples.

The downside of LiveData<List>

In case of Room, there’s a downside to using LiveData<List> directly with large datasets. Each time a new version of the dataset is retrieved, the full dataset is copied to memory. So assuming we have 10000 cats, and modify a single cat, all other 9999 cats will be retrieved from database again as well in the newly evaluated list.

When relying on Realm’s lazy evaluation, this isn’t really a problem: we only ever retrieve items when we access them. We don’t load the full dataset to memory.

However, Google realized this poses a problem, and began working on a solution. The release of a new Architecture Component: Paging To eliminate the need for complete re-evaluation of a modified dataset each time a change occurs, Google invented something amazing: the LivePagedListProvider. Since then, the API has changed a bit, so it’s more appropriate to refer to it as the combination of DataSource.Factory and LivePagedListBuilder. With help of these classes, it’s possible to expose an observable query as a LiveData<PagedList>.

A PagedList is like a list, except it is backed by a DataSource, and it only loads pages of data at a time, instead of the whole dataset. If an item is accessed that’s not yet loaded, then that page is loaded from the datasource on a background thread. When the page of data is loaded, it’s passed to the UI thread, and can be “seamlessly diffed” into the currently loaded dataset. For this to work, Google also provides the PagedListAdapter.

The way Room’s Paging integration works is that we can expose a DataSource.Factory instead of a LiveData<List>.

public interface CatDao {
 DataSource.Factory<Integer, Cat> getCatsWithBrownFur();

Then we can do: private LiveData<PagedList> cats; private Observer<PagedList> observer = (cats) -> { pagedListAdapter.updateData(cats); // initial load + future changes };

protected void onCreate(Bundle savedInstanceState) {
CatDao catDao = RoomDatabase.getInstance()
                    .catDao(); // get Dao
DataSource.Factory<Integer, Cat> dataSourceFactory = catDao.getCatsWithBrownFur();
cats = new LivePagedListBuilder<Cat>(dataSourceFactory, new PagedList.Config.Builder()   .setPageSize(20)   .setPrefetchDistance(20)   .setEnablePlaceholders(20)   .build())
cats.observe(this, observer);   // ← listen for initial evaluation + changes

This allows Room to expose an observable query, where the data is fetched asynchronously, but page by page, instead of loading the full dataset. This allows Room to be much faster than using regular SQLite, while retaining the benefit of observable queries.

Making Realm work with Paging

Realm already brings lots of benefits to the table, but many people intend to use Realm as an implementation detail, not directly. As such, they might want to keep observable queries (just like Room does), but don’t want to use managed results and managed objects: they always see the latest state of the database, which also means they mutate over time. They’re still proxies, and not regular objects.

One possibility would be to read the data from Realm using realm.copyFromRealm(results). However, this method could only be called on the current thread (in this scenario, generally the UI thread), and it would read the full dataset from disk. We’d have the exact same problem as with LiveData<List>, and would be reading large datasets at once on the UI thread! This is clearly a terrible idea, so what’s a better alternative?

We could move the copying of data from Realm to a background thread, but Realm cannot observe changes on regular threads, only on threads associated with a Looper. However, it’s possible to create a HandlerThread — if we can create a Realm instance on this handler thread, execute and observe queries on this handler thread, and keep these queries (and the Realm instance) alive while we’re observing them, then it can work!

Even then, we would still have the problem of loading the full dataset on the handler thread for each change. However, not if we can make Realm’s query results be exposed through the Paging library! Monarchy: global singleton Realm with LiveData and Paging integration I’ve been working on a way to expose RealmResults in an observable manner from a handler thread, either copying the dataset, mapping the objects to a different object, or through the Paging library.

The end result is called Monarchy, a library that lets you use Realm very similarly to as if you were using LiveData for a Room DAO. To create a global instance, all it needs is a RealmConfiguration, and then we can use it as a DAO implementation like this: public interface CatDao { DataSource.Factory<Integer, Cat> getCatsWithBrownFur(); } @Singleton public class CatDaoImpl implements CatDao { private final Monarchy monarchy; @Inject CatDaoImpl(Monarchy monarchy) { this.monarchy = monarchy; } @Override public DataSource.Factory<Integer, Cat> getCatsWithBrownFur() { return monarchy.createDataSourceFactory(realm ->
realm.where(Cat.class) .equalTo(CatFields.FUR, “BROWN”) ); } }

One strange design choice of the Paging library is that the fetch executor can only be set on the LivePagedListBuilder, and not on the DataSource.Factory. This means that to provide Monarchy’s executor that executes fetches on the handler thread, Monarchy must be used to create the final LiveData<PagedList>:

LiveData<PagedList<Cat>> cats = monarchy.findAllPagedWithChanges(
   dataSourceFactory, livePagedListBuilder);

On the other hand, it is still quite convenient: we receive unmanaged objects that are loaded asynchronously, page by page, and we’ve also retained the ability to receive future updates to our data when the database is written to.

Another interesting tidbit is that Monarchy uses LiveData, therefore depending on whether there are active observers, it can automatically manage whether the underlying Realm should be open or closed: completely moving lifecycle management of Realm instances into the onActive/onInactive callbacks of LiveData.


If it weren’t for my time using Realm, it would probably be much harder for me to understand the driving forces that shaped the Android Architecture Components: especially Room, and its LiveData integration.

The ability to listen for changes and always receive the latest state of data with minimal effort just by subscribing to an observable query is something that at first might seem foreign, but simplifies the task of “fetching data from the network, storing it locally, and also querying for and displaying data” — which is what most apps need to do.

Why would we manually manage data load callbacks, if we could just run background tasks that fetch data from network and write it directly into our database, while all we need to do for the UI is observe for changes — and have any new data passed to us automatically?

What if in “Clean Architecture”, fetching data isn’t even a “use-case”, but just an Effect of finding that our data is outdated and should be refreshed?

What is the point of introducing Redux, if it restricts us from making subscriptions to our database queries, as the database would become a second store, and therefore would force us to make data loading be a single fetch inside “middlewares”? (Unless subscriptions are seen as a “state” that should be built up as a side-effect in the store’s observer, of course).

What if the abstraction we’re trying to build binds our hands and keeps us from finding simpler solutions that solve our problem in a more efficient way?

Realm’s observable queries were ahead of its time, but shaped the future of Android local data persistence. Instead of manual invalidation of data, we could just observe for changes. What else is there that we take for granted, build on top of, and keeps us from finding a better solution?

Using Realm taught me that even though there’s a common way of doing things, sometimes taking a completely different approach yields much better results. I’m glad that I had the chance to try Realm, and could learn from the opportunity.

Note from Realm:

We liked Gabor’s article, thus we want to re-post it here with Gabor’s permission. Gabor Varadi regularly writes articles on Medium which can be found here.

While Monarchy is not an official Realm library, it is an interesting complimentary library developed by Gabor. You can find it and file issues on his repo (

Read more

5G is coming: Faster – But What Else is Needed?

by /

There has been a lot of talk and perhaps hype about 5G in the wireless industry, with arguably one of the largest announcements being between T-Mobile and Nokia of a $3.5B infrastructure investment. 5G delivers higher bandwidth and is better suited for IoT and mobile by supporting the anticipated explosion of devices with smarter allocation of spectrum, lower latency, higher bandwidth and improved power handling. But I’ll argue that 5G only addresses part of the solution gap, and omits a key element that has been historically neglected. With each new generation of wireless network and the promises surrounding it, the industry underplays that by their very nature, mobile and IoT devices are fundamentally semi-connected: sometimes the connection is unavailable, sometimes it’s adequate but sub-optimal, and other times it works great. Even worse, users cannot always predict which situation they will be in, for any given location and time of day. Improved coverage through mid-band LTE (as per T-Mobile US), and augmenting coverage with WiFi and CBRS, helps of course, but we’ve all experienced applications and services that simply didn’t work properly and provided a poor experience when the mobile device was disconnected from the network, or in a semi-connected state with high-latency. This situation – the fact that coverage is not universal, and not universally consistent across geographies and even time of day – is a fact of life and fundamentally will not change.

Both proponents of 5G and IoT talk a lot about computing moving to the edge, and the advantage for applications when doing so. Exceptional consumer experiences are only obtained from immediate, i.e. zero-latency, access to relevant data; in fact, many applications fundamentally require immediate access to data or else risk loss of functionality, decreased revenue, failure of business operations, or consumer churn. For many of today’s connected applications, data must be immediately accessible at the edge – the true edge, such as one’s phone, wearable, sensor, car, etc. While mobile networks can sometimes deliver low-latency connections, and that is a key promise from 5G, the network conditions can never be guaranteed for devices that fundamentally move in time and space. The “always connected”, low-latency, mobile network does not exist; rather, the application developer and service architect must overcome this obstacle to reduce risk around loss of revenue, customers, functionality, and correct operations.

The fundamental way to ensure zero-latency access to data is to put the data on the device, prior to use, and keep it synchronized and updated behind the scenes. In this way data is guaranteed to be accessible at all times, can be processed and updated independent of the real-time connectivity dynamics, and the consumer or business application operation can complete successfully, with changes updated automatically once connectivity is restored. Especially in a competitive market where consumers have multiple options, they will inevitably flock to the solutions that provide superior mobile experiences. Similarly, business applications – mobile applications, process flows, field services, or IoT – need data at the edge to ensure business continuity, revenue, efficiency, and correct operations.

Realm solves this problem through its world-renown mobile-client database and its synchronization companion (Realm Platform) for both businesses and consumer use-cases. Starting from its roots as a developer-friendly, mobile-optimized solution, Realm allows data to be cached or synchronized at the true edge for mobile, IoT, and connected devices, ensuring that the data is kept up-to-date and that conflicts are reliably resolved. The Realm Platform can be flexibly deployed in both public and private Clouds to support various use-cases, and can integrate with any external database or data source to effectively mobilize and synchronize any set of data.

5G promises to move the connected world forward for faster and better user experiences, more connected devices (including IoT) and higher bandwidth. But it does not overcome the reality of the mobile world: being disconnected. For optimal consumer experiences and true business success, applications and services must address connectivity changes and occasional disconnectivity by putting the data at the true edge. The success of mobile, IoT, and connected applications, whether on 5G or other, requires Realm and its seamless data synchronization capabilities for a true fulfillment of the promises that 5G and the future intends to provide.

Check out Realm at or sign up for a free trial with our public Cloud at

Read more

Building Modern Swift Apps with Realm Database

by /

We love that the Realm development community at large is so, so good at taking existing code and content and iterating on it to make great things even better. That’s why we’re pleased (and humbled!) to let you know about a new book that covers Realm development in the iOS world: Read more about it here.

Why a book about Realm? Sure, the Realm API docs are quite complete, and the tutorials from the Academy do a great job at giving you hands-on experience at integrating Realm into your apps. But the nice thing about this book is that it pulls all of those concepts together in one place, and takes you all the way from foundational concepts to building out multiple apps that leverage Realm just as you would in your real-world projects.

Author Marin Todorov recognized early on that there just wasn’t a good, comprehensive resource for “all things Realm” — so he wrote his own resource. That eventually turned into the book “Realm: Building Modern Swift Apps with Realm Database”, which, as far as we know, is the only complete book about developing modern Realm apps against iOS.

“Finally, a book that doesn't feel like homework! Right off the bat, the book shows you how to add basic Realm capabilities to your app. The further down the rabbit hole you go, the more advanced Realm features you'll discover.” — Gabriel Rosinski, iOS Developer

It’s easy to throw around numbers and stats, like our installed product base, the ever-growing number of developers who have adopted Realm in their projects, or even the stars on our GitHub repo. But when someone cares enough about your platform to sit down at their desk, put the digital equivalent of pen to paper, and write an actual book about your product to share with other developers? That’s humbling, and shows us that what we’re doing here at Realm is really making a difference in your day-to-day development.

In this book, you’ll take an app-centric view of working with the various features of Realm in real-world app scenarios. You’ll cover common use cases with the platform; dig into schemas and relationships; learn about the built-in notification APIs; manage Realm configurations; handle dependency injection and testing; and implement some solid migrations strategies that all showcase the great features that Realm has to offer the modern app developer.

“Marin and the RW team wrote the ultimate Realm guide. From the basics: how it differs from Core Data, how to model the data, and have the UI reacting to changes; up to more advanced scenarios: syncing data with the Realm Cloud and multi-threading. This book covers everything an iOS developer needs in order to write simple or complex apps using Realm, and I totally recommend it!” — Natan Rolnik, Kik

And as a bonus, the final chapter in the book is a great resource for getting up and running with Realm Cloud with a minimum of fuss. It covers data access, synced Realm providers, partial sync, how to manage your sync subscriptions, and more. Although talking about Realm Platform could easily fill its own book, this bonus chapter has everything you need to get started with real-time sync.

The book is from the folks over at, who also have some great written and video resources about Realm. As part of the launch event around this book, they’re offering the book to the Realm community at a discount for a limited time. We’d suggest that you head over and grab the book while the discount is still live; it ends on Friday, April 27. You can get the book here:

Read more about it here

We’d love to know what you think of the book. If there’s something you think that could benefit from being covered in a book like this, let us know and we’ll pass it along!

Read more

Realm Announces Product Name Changes and Sunsetting of Developer Edition

by /

Today Realm announces it will be sunsetting the “Realm Platform Developer Edition” as well as merging our “Enterprise” and “Professional” Editions under a new product name “Realm Platform Standard”. For any of our existing “Professional” and “Enterprise” customers there will be no changes to your existing agreements, but for our “Professional” customers you may have the ability to make use of additional features by contacting us. While the “Developer” Edition has been a great way for developers to experience a limited set of features of the Realm Platform software, our research has shown that the vast majority of users need our Enterprise features. To this end we will now offer an extended trial period on “Realm Platform Standard” edition for early development and next month we will be releasing a 30-day free trial for Realm Cloud as well. Lastly, we have created a much more scalable pricing model for both the cloud and self-hosted versions that will allow you to get started at the right price and have Realm scale with your business.

Starting today (February 26, 2018) the Developer Edition will no longer be offered for download. Don’t be concerned…we will continue to support any existing deployments for critical defects until April 30, 2018 and will advise you on migrating to Realm Platform Standard. If you have any questions please email us at: [email protected]

Frequently Asked Questions:

• What does the Developer Edition Sunsetting (February 26, 2018) mean to me ?

Developer edition was designed for developers to get access to a minimal set of functionality in Realm Platform that they could use in development and in the early stages of the apps release. After careful consideration and a great amount of feedback from our users, we will no longer develop, maintain, or release the Realm Platform Developer Edition after April 30, 2018. We also will be combining the various software editions into one new edition called Realm Platform Standard. This version will essentially have all the functionality of our old Enterprise edition in one, more economical edition. With this new edition (offered in both the cloud and self-hosted deployment models) we will also provide a free trial version in the cloud that has all the core features and no limitations on functionality, as well as an extended trial period for developers to use and develop with the self-hosted version, again with no limits on functionality.

•How do I migrate from Realm Developer Edition to Realm Platform Standard?

Please contact us at [email protected] and we can guide to the best path forward.

•What is the detail on the new pricing models going forward so that I can get started at the right price and have Realm scale with my business?

The new pricing models will be updated on our website shortly. In the interim, if you have any pricing questions, please feel free to contact us at [email protected]

•Can I get access to the Realm Platform Standard on the Cloud now?

Yes. We have the service up and running today in beta, with an expected GA date soon. You can sign up for the beta service at

•What’s the best way for me to contribute my feedback and desires for future functionality in Realm Platform Standard?

We appreciate your feedback. Please email us at [email protected]

Read more