# Realm .NET for Xamarin (Best Practices and Roadmap) Meetup

Didn't get a chance to attend the Realm .NET for Xamarin (best practices and roadmap) Meetup? Don't worry, we recorded the session and you can now watch it at your leisure to get you caught up.

>Realm .NET for Xamarin (best practices and roadmap)

>:youtube]{vid=llW7MWlrZUA}

In this meet-up, Nikola Irinchev, the engineering lead for Realm's .NET team, and Ferdinando Papale, .NET engineer on the Realm team, will walk us through the .NET ecosystem as it relates to mobile with the Xamarin framework. We will discuss things to consider when using Xamarin, best practices to implement and gotcha's to avoid, and what's next for the .NET team at Realm.

In this meetup, Nikola & Ferdinando spend about 45 minutes on  
-   Xamarin Overview & Benefits
-   Xamarin Key Concepts and Architecture
-   Realm Integration with Xamarin
-   Realm Best Practices / Tips&Tricks with Xamarin

And then we have about 20 minutes of live Q&A with our Community. For those of you who prefer to read, below we have a full transcript of the meetup too. As this is verbatim, please excuse any typos or punctuation errors!

Throughout 2021, our Realm Global User Group will be planning many more online events to help developers experience how Realm makes data stunningly easy to work with. So you don't miss out in the future, join our [Realm Global Community and you can keep updated with everything we have going on with events, hackathons, office hours, and (virtual) meetups. Stay tuned to find out more in the coming weeks and months.

To learn more, ask questions, leave feedback, or simply connect with other Realm developers, visit our community forums. Come to learn. Stay to connect.

## Transcript

**Shane McAllister**: Welcome. It's good to have you all here. Sorry for the couple of minutes wait, we could see people entering. We just wanted to make sure everybody had enough time to get on board. So very welcome to what is our meetup today. We are looking forward to a great session and we're really delighted that you could join us. This is a new initiative that we have in MongoDB and Realm, and so far is we're trying to cater for all of the interested people who want to learn more about what we're building and how we're going about this.

**Shane McAllister**: Essentially, I think this is our third this year and we have another three scheduled as well too, you'll see those at the end of the presentation. And really it's all about bringing together Realm developers and builders and trying to have an avenue whereby you're going to get an opportunity, as you'll see in a moment when I do the introductions, to talk to the people who built the SDKs that you're using. So we very much look forward to that.

**Shane McAllister**: A couple of housekeeping things before I do the introductions. It is being recorded, we hope everybody here is happy with that. It's being recorded for those that can't attend, timezone might be work for them. And we will be putting it up. You will get a link to the recording probably within a day or two of the meetup finishing. It will go up on YouTube and we'll also share it in our developer hub.

**Shane McAllister**: We will have an opportunity for Q&A at the end of the presentation as well too. But for those of you not familiar with this platform that we're on at the moment, it's very straightforward like any other video platform you might be on. We have the ability to chat up there. Everybody's been put in there, where they're from, and it's great to see so many people from around the world. I myself am in Limerick, in the west coast of Ireland. And Ferdinando and Nikola, who are presenting shortly, are in Copenhagen. So we'll go through that as well too.

**Shane McAllister**: But as I said, we'll be doing Q&A, but if you want to, during the presentation, to put any questions into the chat, by all means, feel free to do so. I'll be manning that chat, I'll be looking through that. If I can answer you there and then I will. But what we've done in other meetups is we've opened out the mic and the cameras to all of our attendees at the end, for those that have asked questions in the chat. So we give you an opportunity to ask your own questions. There is no problem whatsoever if you're too shy to come on with an open mic and an open camera, I'll quite happily ask the question for you to both Ferdinando and Nikola.

**Shane McAllister**: This is a meetup. Albeit that we're all stuck on the screen, we want to try and recreate a meetup. So I'm quite happy to open out your cameras and microphones for the questions at the end. The house rules are, would be, just be respectful of other people's time, and if you can get your question asked, then you can either turn off your camera or turn off your mic and you'll leave the platform, again, but still be part of the chat.

**Shane McAllister**: So it's a kind of an interactive session towards the end. The presentation will be, hopefully, Nikola and Ferdinando, fingers crossed, 40 to 45 minutes or so, and then some Q&A. And what I'll be doing in the chat as well too, is I'll put a link during the presentation to a Google form for some Swag. We really do appreciate you attending and listening and we want you to share your thoughts with us on Realm and what you think, and in appreciation of your time we have some Swag goodies to share with you. The only thing that I would say with regard to that is that given COVID and postal and all of that, it's not going to be there very quick, you need to be a bit patient. A couple of weeks, maybe more, depending on where in the world that you are.

**Shane McAllister**: So look, really delighted with what we have scheduled here for you shortly here now. So joining me today, I'm only the host, but the guys with the real brains behind this are Nikola and Ferdinando from the .NET team in Realm. And I really hope that you enjoy what we're going through today. I'll let both of you do your own introductions. Where you are, your background, how long you've been with Realm, et cetera. So Nikola, why don't we start with yourself?

**Nikola Irinchev**: Sure. I'm Nikola. I'm hailing from sunny Denmark today, and usually for this time of the year. I've been with Realm for almost five years now, ever since before the MongoDB acquisition. Start a bit the dominant theme move to various different projects and I'm back to my favorite thing, which is the .NET one. I'm super excited to have all of you here today, and now I'm looking forward to the questions you ask us.

**Ferdinando Papale**: Hello. Do you hear me?

**Shane McAllister**: Yes.

**Ferdinando Papale**: Okay. And I'm Ferdinando. And I've joined Realm only in October so I'm pretty new. I'm in the same team as Nikola. And before working at Realm I was a Xamarin developer. Yes. Shane, you're muted.

**Shane McAllister**: Apologies. I'm talking head. Anyway, I'm very much looking forward to this. My background is iOS and Swift, so this is all relatively new as well to me. And I forgot to introduce myself properly at the beginning. I look after developer advocacy for Realm. So we have a team of developer advocates who in normal circumstances would be speaking at events and conferences. Today we're doing that but online and meetups such as this, but we also create a ton of content that we upload to our dev hub on developer.mongodb.com.

**Shane McAllister**: We're also active on our forums there. And anywhere else, social in particular, I look after the @Realm Twitter a lot of the time as well too. So please if you're enjoying this meetup please do shout outs on @Realm at Twitter, we want to gather some more followers, et cetera, as well too. But without further ado, I will turn it over to Nikola and Ferdinando, and you can share screen and take it away.

**Ferdinando Papale**: Yes. I will be the one starting the presentation. We already said who we were and now first let's take a look at the agenda. So this presentation will be made up of two parts. In the first part we'll talk about Xamarin. First some overview and benefits, and then some key concepts in architecture. And then in the second part, we're going to be more talk about Realm. How it integrates with Xamarin and then some tips, and then some final thoughts.

**Ferdinando Papale**: Then let's go straight to the Xamarin part. That will be the first part of our presentation. First of all, if. Xamarin is an open source tool to build cross platform applications using C-sharp and .NET, and at the moment is developed by Microsoft. You can develop application with Xamarin for a lot of different platforms, but the main platforms are probably iOS and Android.

**Ferdinando Papale**: You can actually also develop for MacOS, for Tizen, UWP, but probably iOS, Android are still the main targets of Xamarin. Why should you choose to develop your application using Xamarin? If we go to the next slide. Okay, yes. Probably the most important point of this is the code reuse. According to Microsoft, you can have up to 90% of the code shared between the platforms. This value actually really depends on the way that you structure of your application, how you decide to structure it, and if you decide, for example, to use Xamarin.Forms or not, but we'll discuss about it later.

**Ferdinando Papale**: Another important point is that you are going to use C-sharp and .NET. So there is one language and one ecosystem. This means that you don't need to learn how to use Swift on iOS, you don't need to learn how to use Kotlin on Android, so it's a little bit more convenient, let's say.

**Ferdinando Papale**: And then the final thing that needs to be known is the fact that in the end, the application that you develop with Xamarin feels native. I mean, a final user will not see any difference with a native app. Because whatever you can obtain natively you can also obtain with Xamarin from the UI point of view.

**Ferdinando Papale**: Now, to talk a little bit more about the architecture of Xamarin. If you go to the next slide. Yes. In general, Xamarin works differently depending on the platform that we are targeting. But for both Android and iOS, the main targets, they both work with Mono. Mono is another implementation of them that is cross platform.

**Ferdinando Papale**: And it's a little bit different the way that it works on Android and iOS. So on Android, the C-sharp code gets compiled to an intermediate language. And then when the application runs, this gets compiled with the just-in-time compiler. So this means that if you try to open the package developed with Xamarin, you will see that it's not the same as a completely native application.

**Ferdinando Papale**: Instead, with iOS, it's not possible to have just-in-time compilation, and we have ahead-of-time compilation. This means that the C-sharp code gets directly compiled to assembly. And this was just to give a very brief introduction to the architecture.

**Ferdinando Papale**: Now, if we want to talk more specifically about how to structure Xamarin application, there are essentially two ways to use Xamarin. On the left we have the, let's say, traditional way, also let's say Xamarin Native. In this case we have one project that contains the shared app logic, and this one will be common to all the platforms. And then on top of that, we have one project for each platform that we are targeting, in this case, Android and iOS. And this project contain the platform specific code, but from the practical point of view, this is mostly UI code.

**Ferdinando Papale**: Then we have Xamarin.Forms. Xamarin.Forms is essentially a UI framework. If you have Xamarin.Forms, we still have these project with the shared app logic, but we also have another project with the shared UI. We still have the platform-specific projects but this contains almost nothing, and they are the entry point of the application.

**Ferdinando Papale**: What happens in this case is that Xamarin.Forms has it's own UI paradigm that is different from Android and iOS. And then these gets... The controls that you use with Xamarin.Forms are the one that transform to native controls on all the platforms that are supported. Obviously, because this needs to support multiple platforms, you don't have a one to one correspondence between UI controls.

**Ferdinando Papale**: Because with Xamarin.Forms, practically, you have these additional shared layer. Using Xamarin.Forms is the way that allows to have the most shared code between the two possibilities. And now we can talk a little bit more about some key concepts in forms. First of all, data binding and XAML.

**Ferdinando Papale**: In Xamarin.Forms there are essentially two ways that you can define your UI. First, programmatically. So you define your UI in a C-sharp file. Or you can define your application in a XAML file. And XAML is just a language that is defined on top of XML. And the important thing is that it's human readable. On the left here you have an example of such a XAML file. And on the bottom you can see how it looks on an iOS and Android device.

**Ferdinando Papale**: This application practically just contains a almost empty screen with the clock in the middle. If you look at the XAML file you will see it has a content page that is just Xamarin.Forms named for a screen. And then inside of that it contains a label that is centered horizontally and vertically. But that's not very important. Yes.

**Ferdinando Papale**: And then the important thing here to notice is the fact that this label has a text that is not static, but is actually defined with bindings. You can see the binding time written in the XAML file. What this means here is the fact that if the bindings are done properly, whenever the time variable is changing our code, then it will also be updating the UI. This simple application it means that we have a functioning clock.

**Ferdinando Papale**: The way that this is implemented, actually, you can see it on the right, we have an example of a ViewModel. In order for the ViewModel to notify the UI of these changes, it needs to implement I notify property changed, that is an interface that contains just one event, that is the property change event that you see almost at the top.

**Ferdinando Papale**: Practically, the way that it works is that you can see how it works with the property time that is on the bottom. Every time we set the property time, we need to call property changed. And we need to pass also the name of the property that we're changing. Practically, let's say behind the curtains, what happens is that the view subscribes to this property change event and then gets notified when certain properties change, and so the UI gets updated accordingly.

**Ferdinando Papale**: As you can see, it's not exactly straightforward to choose data binding, because you will need to do this for every property that needs to be bound in the UI. And the other thing to know is that this is just one simple way to use, data binding can be very complicated. It can be two way, one way in one direction, and so on.

**Ferdinando Papale**: But data binding actually is extremely important, especially in the context of MVVM. MVVM is essentially the architectural pattern that Xamarin suggests for the Xamarin.Forms application. This is actually the interpretation that Microsoft has, obviously, of MVVM, because this really depends who you ask, everybody has his own views on this.

**Ferdinando Papale**: In MVVM, essentially, the application is divided into three main blocks, the model, the view, and the ViewModel. The model contains the app data and the business logic, the view represents what is shown on the screen, so the UI of the application, and preferably should be in XAML, because it simplifies the things quite a lot. And then finally we have the ViewModel, that essentially is the glue between both the view and the model.

**Ferdinando Papale**: The important thing to know here is that as you see on the graph, on the left, is that the view communicates with ViewModel through the data binding and commands, so the view knows about the ViewModel. Instead, the ViewModel actually doesn't know about the view. And the communication happens indirectly through notifications. Practically, the views subscribes to the property change event on the ViewModel, and then gets notified when something is changed, and so the UI needs to be updated eventually.

**Ferdinando Papale**: This is really important. Because the ViewModel is independent from the view, this means that we can just swap the view for another one, we can change it without having to modify the ViewModel at all. And also these independents allows to have the code much more testable if this wasn't there, that's why the data binding is so important.

**Ferdinando Papale**: Then there is another thing that is really important in Xamarin.Forms, and those are custom renders. As I said before, because Xamarin.Forms essentially needs to target multiple applications, sometimes the translation within the forms' UI and the native UI, is not what you expect or maybe what you want. And in this case, the way that you can go around it is use custom renders. Really with custom renders, you have the same control that you will have natively.

**Ferdinando Papale**: What is on the screen is an example of how to create a custom render practically. So on the left, we can see that first of all we need to create a custom class, in this case my entry. And they need to derive from one of the forms' class, in this case an entry is just a text view on the screen where the user can write some stuff.

**Ferdinando Papale**: Obviously you need also to add this custom view to your XAML page. And then you need to go into the platform-specific projects, so iOS and Android, and define the render. The render needs to obviously derive from a certain class in forms. And you need also to define the attribute expert render. This attribute practically say, this render, to which class it should be linked to.

**Ferdinando Papale**: Once you use the render, obviously, you have full control over how the UI should look like. One thing to know is that what you have on this screen is actually a little bit of a simplified example, because actually it's a little bit more complicated than this. And also, one needs to understand that it's true that it's possible to define as many custom renders as needed, but the more custom renders are created, probably the less code reuse you have, because you need to create these custom renders in each of the platform-specific projects. So it starts to become... You have less and less shared codes, so you should start asking yourself if Xamarin.Forms is exactly what you want. And also, they are not exactly the easiest thing to use, in my opinion.

**Ferdinando Papale**: Finally, why should you decide to use Xamarin.Forms or Xamarin Native. Essentially, there are a couple of things to consider. If the development time and the budgets are limited, Xamarin.Forms is a better option, because in this case you will need to create the UI just once and then it will run on both platforms, you don't need to do this development twice.

**Ferdinando Papale**: Still, unfortunately, if your UI or UX needs to be polished, needs to be pixel perfect, you want to have exactly the specific UI, then probably you will need to use Xamarin Native. And this is because, as I've said before, if you want to have something that looks exactly as you want, you will need to probably use a lot of custom renders. And more custom renders means that Xamarin.Forms starts to be less and less important, or less advantageous, let's say.

**Ferdinando Papale**: Another thing to consider is what kind of people you have in your team. If you have people in your team that only have C-sharp and .NET experience, then Xamarin.Forms can be important as an advantage because you don't need to learn... Even if you use Xamarin Native you will still use C-sharp and .NET, but you will also need to understand how you will need to have some native experience, you will need to know what is the lifecycle of an iOS application, of an Android application, how the UI is built in both cases and so on. So in this case, probably Xamarin.Forms will be a better option.

**Ferdinando Papale**: And the final thing to consider is that generally Xamarin.Forms application are bigger than Xamarin Native applications. So if this is a problem, then probably native is the way to go. And I think that this is the end of my half of the presentation and now probably Nikola should continue with the rest.

**Nikola Irinchev**: Sure. That's great. That hopefully gives people some idea for which route to take for the next project, the route they should take regards whether they use Xamarin Native or Forms they use to use Realm. Let's talk about how it fits into all that.

**Nikola Irinchev**: The first thing to understand about Realm is that it's an open source, standalone object database. It's not an ORM or an interface for accessing MongoDB. All the data leaves locally on the device and is available regardless of whether the user has internet connectivity or not. Realm has also been meticulously optimized to work on devices with heavily constraint resources.

**Nikola Irinchev**: Historically, these have been mobile devices, but recently we're seeing more and more IoT use cases. To achieve an extremely low memory footprint, Realm adopts a technique that is known as zero copy. When you fetch an object from Realm, you don't need the entire thing in memory, instead, you get some cleverly-organized metadata that tells us which memory offsets the various properties are located.

**Nikola Irinchev**: Only when you ask us the property to which the database and read the information stored there. This means that you won't need to do any select X, Y, Z's, and it also allows you to use the exact same object in your master view, where you only need one or two properties as in the detail view where you need to display the information about the entire entity.

**Nikola Irinchev**: Similarly, collections are lazily loaded and data is never copied into memory. A collection of a million items is, again, a super lightweight wrapper around some metadata. And accessing an element, just calculates the exact memory offset where the element is located, returns the data there. This, again, means you can get a collection of millions of items in fractions of a second, then drop it in the ListView with data binding, and as the user scrolls on the screen, new elements will be loaded on demand and don't want to be garbage collected. Meaning you never have to do pagination limits or add load more buttons.

**Nikola Irinchev**: To contribute to that seamless experience, the way you define models in Realm is nearly identical to the way you define your in-memory of the process. You give it a name, you add some properties, and that's it. The only thing that you need to do to make sure, it's compatible with Realm, is to inherit from RealmObject.

**Nikola Irinchev**: When you compile your project, Realm will use this code leaving. It will replace the appropriate getters and setters with custom code that will read and write to the database directly. And we do support most built in primitive types. You can use strings, various sizes of integers, floats, doubles, and so on.

**Nikola Irinchev**: You can of course define links to other objects, as well as collection of items. For example, if you have a tweet model, you might want to have a list of strings that contain all the tags for the tweets, or you have a person model, you might want to have a list of dogs that are owned by that person.

**Nikola Irinchev**: The final piece of core Realm functionality that I want to touch on is one that is directly related to what Ferdinando was talking about with Xamarin.Forms and data binding. That thing that I mentioned about properties that hook up directly to the database, apart from being super efficient in performance, it has the nice side effect that we're always working with up to date data.

**Nikola Irinchev**: So if you have a background thread then you update a person's age, the next time you access the person's age property on the main thread, you're going to get the new value. That in and of itself is cool, but will be kind of useless if we didn't have a way to be notified when such a change has occurred. Luckily, we do. As all Realm objects implement I notify property changed, and all Realms collections implement I notify collection changed.

**Nikola Irinchev**: These are the interfaces that are the foundation of any data binding engine, and are of course supported and respected by Xamarin.Forms, WTF, and so on. This means that you can data bind to your database models directly, and then we'll learn the UI whenever a property changes regardless of where the change originated from. And for people who want to have an extra level of control or those working with our native, we do have a callback that you can subscribe to, which gives you more detailed information than what the system interfaces expose.

**Nikola Irinchev**: To see all these concepts in action, I've prepared a super simple app that lists some people and their dogs. Let me show that to you. All right. Let's start with the model definition. I have my person class. It has name, birthday and favorite dog. And it looks like your poco out there. The only difference again being that it inherits from Realm object, which is a hint for the code leaver that we use to replace the getter and setter with some clever code that hooks into the native Realm API.

**Nikola Irinchev**: All right. Then let's take a look at lazy loading. I cheated a little bit, and I already populate my grammar, I inserted a million people with their dogs and their names and so on. And I added button in my view, which is called load, and it invokes the load medium items command. What it does is it starts a stopwatch, gets all items from Realm, and alerts how many they are and how much time it took.

**Nikola Irinchev**: If I go back to my simulator, if I click load, we can see that we loaded a million elements in zero milliseconds. Again, this is cheating, we're not really loading them all, we are creating a collection that has the necessary metadata to know where the items are. But for all intents and purposes, for you as a developer, they are there. If I set a breakpoint here, both the items again, I can just drop the evaluator and I can pick any element of the collection, of any unit, and it's there. The property channel that their dog is all that... You can access any element as if you were accessing any memory structure.

**Nikola Irinchev**: All right. That's cool. Let's display these million people. In my main page, I would have a ListView. Let's use a UITableViewController or just a collection of cells. And in my cell I have a text field which binds to the person's dog name, and I have a detail field which binds to favorite dog.name. And the entire ListView is bound to the people collection.

**Nikola Irinchev**: In my main view model, people collection is just empty, but we can populate it with the data from Realm. I'm just passing all people there, which, as we saw, are on \[inaudible 00:29:55\]. And I'm going mute. What's going to happen now is Realm will feed this collection, and the data binding engine will start reading data from the collection to populate its UI. I can go back to my simulator. We can see that all the people are loaded in the ListView. And as I scroll the ListView, we can see that new people are being displayed.

**Nikola Irinchev**: Judging by the fact that my scroller doesn't move far, we can guess that there are indeed a million people in there. And again, of course, we don't have a million items in memory, that would be ridiculous. The way Xamarin.Forms works is, it's only going to draw what's on screen, it's only going to ask around for the data that is being currently displayed. And as the user scrolls, all data is being garbage collected, new data is being picked up. So this allows you to have a very smooth user experience and a very small developer experience, because you no longer have to think about pagination and figuring out what's the minimum set of properties that you need to load to drive that UI.

**Nikola Irinchev**: Finally, to build on top of example, I added a simple timer. I have a model called statistics which has a single property, which is an integer counting the total seconds users pass in the app. What I'm going to do is, in my app, when it starts, I'm going to run in the background my app data code. And what that does is, it waits one second, very imprecise, we don't care about precision here, and opens around and increments the number of total of seconds.

**Nikola Irinchev**: In my main page, I will data bind my title property to statistics.total of seconds, also to the total of seconds property. I have a nice string format there to write a lapse time there. And in my view, I'll just populate my statistics instance with the first element from the statistics collection.

**Nikola Irinchev**: I know that there's one. Okay. So when I run the top, what is going to happen is, every second, my app will increment this value on a background thread. In my main view model, the statistics systems, which points to the same object in the database, is going to be notified that there's a change to total of seconds property, is going to proxy that to the UI. And if we go to the UI, we can see that every second, the title is getting updated. And that require absolutely synchronization or UI code on my end, apart from the data binding logic.

**Nikola Irinchev**: Clearly, that is a super silly example, I don't suppose any of you to ship that into production, but it's the exact same principle you can apply when fetching updates from your server or when doing some background processing in your offline, converting images or generating documents. What you need to do is just store the results in Realm, and as long as you set up your data bindings property, the UI will update itself regardless of where in the app the user is. All right. That was my little demo, and we can go back to more boring part of the presentation and talk about some tips when starting out with Realm and Xamarin.

**Nikola Irinchev**: The main thing that trips people up when they start using Realm, is the threading model. Now that definitely deserves a talk of its own. And I'm not going to go into too much detail here, but I'll give you the TLDR of it, and you should just trust me on that. We can probably have some different talk about threading.

**Nikola Irinchev**: First of, on the main thread, it's perfectly fine and probably good idea to keep a reference to the Realm in your ViewModel. You can either get a new instance, with the Realm getinstance close, or you can just use some singleton. As long as it's only accessible on the my thread, that is perfectly fine. And regardless of which approach you choose, the performance will be very similar. We do have native caching of main thread instances, so you won't be generating a lot of garbage if you did the getinstance approach.

**Nikola Irinchev**: And on the my thread, you don't have to worry about disposing the managing instances, it's perfectly fine to let them be garbage collected when your ViewModel gets garbage collected. That's just fine. On the background thread though, it's quite the opposite. There you always want to wrap your getinstances into using statements.

**Nikola Irinchev**: The reason for that is, background threads will cause the file size to increase when data gets updated, even if we don't insert new objects. This base is eventually reclaimed when you dispose the instance or when the app restarts. But it's nevertheless problematic for devices with constrained resources.

**Nikola Irinchev**: Similarly, it is strongly encouraged to keep background instances short-lived. If you need to do some slow data pre-processing, think before you open the Realm file and just write the results when you open it. Or if you need to read some data from Realm, do the processing and private results, open the Realm plus. First, open it with the data, extract putting it in memory, then pause Realm, start the slow job, then open the Realm again, bind results. As a rule of thumb, always run background threads on using statements, and never have any advice in using block.

**Nikola Irinchev**: All right. Let's move to a topic that will inevitably be controversial. And that is avoid repository pattern. And only going to be a bit of a shock especially for people coming from Java or back end backgrounds. But the benefit to complexity ratio of abstracting Realm usage is pretty low.

**Nikola Irinchev**: The first argument is universal, doesn't apply just to Realm but with mobile apps. You should really design your app for the database that you're going to use. Each database has strengths and weaknesses. And some things are easy with \[sycilite 00:36:54\], others are easy with Realm. By abstracting away the database in a way that you can just swap it out with a different implementation, it means you're not taking advantage of any of the strong sides of the current database that you're using.

**Nikola Irinchev**: And when an average active development time for a mobile app are between six and eight months, you'll likely spend more time preparing for database which then you save in case you actually have to go through with it.

**Nikola Irinchev**: Speaking of strong sides, as much as one of Realm's strong sides is, the data is live. Collections are lazily loaded. And abstracting data in a generic repository pattern is going to be confusing for your consumers. You have two options. Return data is easy. Return live collections, live objects. But in a general purpose repository, there'll be no way to communicate with the consumer that this data is live, so they might think that they will need to fetch it or be confused as to why there are no pagination API. And if you do decide to materialize the FTC into memory, you're foregoing one of the main benefits of using Realm and taking a massive performance hit.

**Nikola Irinchev**: Finally, having Realm refine the repository will inevitably complicate threading. As we've seen earlier, the recommendation is to use thread from instances or background threads. And if you want to have to go get repository, dispose repository all the time, you might as well use Realm directly.

**Nikola Irinchev**: None of that is to say that abstractions are bad and you should avoid using them at all costs. We've seen plenty of good obstructions built on top of Realm, that work very well in the context of the apps that they're waiting for. But if you already have a secure-line-based app that uses circles and pattern and you think you can just swap out secure life with Realm, you're probably going to have a bad time and not take full advantage of what Realm has to offer.

**Nikola Irinchev**: Finally, something that many people miss about Realm, is that you totally can't have more than one database at play in the same app. This can unlock many interesting use cases, and we've seen people get very creative with it. One benefit of using multiple Realms is that you have a clear separation of information in your app.

**Nikola Irinchev**: For example, in a news app, you might have Realm that holds the app settings, a different one that holds the lyrics metadata, and a third one that holds the user playlist. We've seen similar setups in modular apps, where different themes work on different components of the app, and want to avoid having to always synchronize and align changes and migrations.

**Nikola Irinchev**: Speaking of migrations, keeping data in different Realms can eliminate the need to do some migrations altogether. For example, if you have a Realm instance, this whole, mostly-cached data, and your server side models change significantly, it's probably cheaper to just use the new model and not deal with the cost of migration. If that instance was also holding important user data, you wouldn't be able to do that, making it much more complicated to shift the new version.

**Nikola Irinchev**: And finally, it can allow you to offer improved security without data duplication. In a multicolored application, like our earlier music app, you may wish to have the lyrics' metadata Realm be unencrypted and shared between all users, while their personal playlist or user information, it can be encrypted with their user-specific key and accessible only for them.

**Nikola Irinchev**: Obviously, you don't have to use multiple Realms. Most of the apps we've seen only use one. But it's something many folks just don't realize is an option, so I wanted to put it out there. And with that, I'm out of tips. I'm going to pass the virtual mic back to Ferdinando to give us a glimpse into the future of Xamarin.

**Ferdinando Papale**: Yes. I'm going to talk just a little bit about what is the future of Xamarin.Forms, and the future of Xamarin.Forms is called MAUI. That stands for Multi-platform App UI, that is essentially the newest evolution of Xamarin.Forms that will be included in .NET 6. .NET 6 is coming out at the end of the year, I think in November, if everything goes well.

**Ferdinando Papale**: Apart from containing all the new and shiny features, the interesting thing that they did with .NET 6 is that they are trying to unify a little bit the ecosystem, because .NET has always been a little bit all over the place with .NET Standard, .NET Core, .NET Framework, .NET this, .NET that. And now they're trying to put everything under the same name. So Xamarin, they will not be Xamarin iOS and Xamarin Android anymore, but just .NET iOS and .NET Android. Also Mono will be part of .NET and so on.

**Ferdinando Papale**: Another important thing to know is that MAUI applications will still be possible to develop application for iOS and Android, but there is also a bigger focus also on MacOS and Windows application. So it would be much more complete.

**Ferdinando Papale**: Then they're going also to work a lot on the design, so to improve the customization that can be done so that one needs to use much less custom renders. But also there is the possibility of creating UI controls that instead of feeling native on each platform, they look almost the same on each platform, for a bigger UI consistency, let's say.

**Ferdinando Papale**: And the final things is the single project experience, let's say, that they are going to push. At the moment with Xamarin.Forms, if you want to have an application target five platforms, you need to have at least five projects plus the common one. What they want to do is that they want to eliminate these platform-specific projects and they have only the shared ones. This means that in this case, you will have all the, let's say, all the platform-specific icons, and so on, in these single projects. And this is something that they are really pushing on. And this is just the... It was just a brief look into the future of Xamarin.Forms.

**Nikola Irinchev**: All right. Yeah, that's awesome. I for one I'm really looking forward to some healthy electronic competition which doesn't need to buy Realm for breakfasts. So hopefully it's our dog that seats in MAUI, we'll deliver that. I guess the future of Realm is Realm. We don't have Polynesian delegates in the pipeline, but we do have some pretty exciting plans for the rest.

**Nikola Irinchev**: Soon in the spring, we'll be shipping some new datatypes we've been actively working on our past couple of months. These are iDictionary, Sets and Guids. We're also adding a thought that can hold any \[inaudible 00:44:37\].

**Nikola Irinchev**: At Realm we do like schema so definitely don't expect Realm to become MongoDB anytime soon. But there are legitimate use cases for apps that need to have heterogeneous data sometimes. For example, a person class may hold the reference to a cat or a dog or a fish in their pet property, or an address in just a string for an address structure. So we kind of want to give developers the flexibility to let them be in control of their own destiny.

**Nikola Irinchev**: Moving forward, in the summer, we're turning our attention to mobile gaming and Unity. This has been the most highly qualification on GitHub, so hope to see what the gaming community will do with Realm. And as Ferdinando mentioned, we are expecting a brand new .NET releasing in the fall. We fully intend to offer first-class MAUI support as soon as it lands.

**Nikola Irinchev**: And I didn't have any plans for the winter, but we're probably going to be opening Christmas presents making cocoa. With the current situation, it's very hard to make long term plans, so we'll take these goals. But we are pretty excited with what we have in the pipeline so far. And with that, I will pass the virtual mic back to Shane and see if we have any questions.

**Shane McAllister**: Excellent. That was brilliant. Thank you very much, Nikola and Ferdinando. I learned a lot, and lots to look forward to with MAUI and Unity as well too. And there has been some questions in the chat. And we thought Sergio was going to win it by asking all the questions. And we did get some other brave volunteers. So we're going to do our best to try and get through these.

**Shane McAllister**: Sergio, I know you said you wanted me to ask on your behalf, that's no problem, I'll go through some of those. And James and Parth and Nick, if you're happy to ask your own questions, just let me know, and I can your mic and your video to do that. But we'll jump back to Sergio's, and I hope \[inaudible 00:46:44\] for you now. I might not get to all of them, we might get to all of them, so we try and fly through them. I'm conscious of everybody's time. But we have 10, 15 minutes here for the questions.

**Shane McAllister**: So Nikola, Ferdinando, Sergio starts off with, I can generate Realm-encrypt DB at the server and send this file to different platforms, Windows, iOS, Android, MacOS. The use case; I have a large database and not like to use sync at app deploy, only using sync to update the database. Can he do that?

**Nikola Irinchev**: That is actually something that I'm just writing the specification for. It's not available right now but it's a very valid use case, we definitely want to support it. But it's a few months in the future outside, but definitely something that we have in the works. One caveat there, the way encryption in Realm works, is that it depends on the page file size of the platform is running on.

**Nikola Irinchev**: So it's possible that... For my question iOS is the same, but I believe that there are differences between Windows and Android. So if you encrypt your database, it's not guaranteed that it's going to be opened on all platforms. What you want to do is you shift the database unencrypted, in your app, encrypted with the page file of the specific platform that their app is running on.

**Shane McAllister**: Okay, that makes sense. It means Sergio's explained his use case was that they didn't want some user data to be stored at the server, but the user wanted to sync it between their devices, I suppose. And that was the reason that he was looking for this. And we'll move on.

**Shane McAllister**: Another follow up from Sergio there is, does the central database have to be hosted in the public cloud or can he choose another public cloud or on premise as well too?

**Nikola Irinchev**: Currently we don't have a platform on premise for sync. That is definitely something we're looking into but we don't have any timeline for when that might be available. In terms of where the central database is hosted, it's hosted in Atlas. That means that, because it's on Azure, AWS and Google Cloud, it's conforming to all the rules that Atlas has for where the database is stored.

**Nikola Irinchev**: I believe that Atlas has support for golf cloud, so the government version of AWS. But it's really something that we can definitely follow up on that if he gives us more specific place where he wants to foster. But on premise definitely not an option at the moment.

**Shane McAllister**: And indeed, Sergio, if you want more in-depth feedback, our forum is the place to go. Post the questions. I know our engineering team and our developer advocates are active on the forums there too. And you touched on this slightly by way of showing that if you have a Realm that you don't necessarily care about and you go and update the schema, you can dump that. Sergio asked if the database schema changes, how does the update process work in that regard?

**Nikola Irinchev**: That depends on whether the database... If a lot of the questions Sergio has are sync related, we didn't touch too much on sync because I didn't want to blow the presentation up. There's a slight difference to how the local database and how sync handle schema updates. The local database, when you do schema update, you write the migration like you would do with any other database. In the migration you have access to the old data, the new data, and you can, for example, populate new properties from all properties, split them or manipulate.

**Nikola Irinchev**: For example if you're changing a string column to an integer, parse the string values from right to zeros there. With sync, there are more restrictions about what schema changes are allowed. You can only make additive schema changes, which means that you can only add properties after losses, you cannot change the type of a property.

**Nikola Irinchev**: This is precisely to preserve backwards compatibility and allow apps that are already out in the wild in the hands of users not to break in case the schema changes, because so you cannot ship back your code and handle the different schema there.

**Shane McAllister**: Super. Great. And I'll jump to Sergio's last question because I kind of know the answer to this, about full text search. Where are you with that?

**Nikola Irinchev**: Again, we are in the specification part. One thing to notice, that the Realm database is fully open source. Like the core database, RTS is open source. And if he goes to the Realm core repository, which is the core database, he can definitely see the pull request that has full text search. That's a very much in a POC phase. We're nowhere near ready to shift that to the production quality, but it's definitely something we're actively working on and I do hope to have interesting updates in the coming months.

**Shane McAllister**: Super. Thank you, Nikola. And James, you have three questions there. Would you want to ask them yourself or let me ask on your behalf? If you want to just type into the chat there, James, because with three you can follow up on them. I'll happily open the video and the mic. So he's happy to try. Fair play, brave individual. Let me just find you here now, James. You will come in as a host, so you will now have mic and video controls down the bottom of your screen. Please turn them on. We will see you hopefully, we'll hear you, and then you can ask your own questions.

**James**: I don't have a camera so you won't see me, you'll only hear me.

**Shane McAllister**: It's always dangerous doing this stuff live.

**James**: Can you hear me?

**Shane McAllister**: Is that working for you? Yeah, he's getting there.

**James**: Can you hear me?

**Shane McAllister**: We'll see.

**James**: No?

**Shane McAllister**: James, I see your mic is on, James. No. Hold on one second. We'll just set you again. Apologies everyone else for the... Turn that back on and turn this on. Should be okay. Look, James, we'll give you a moment to see if you appear on screen. And in the meantime, Parth had a couple of questions. How does Realm play with backward compatibility?

**Nikola Irinchev**: That's a difficult question. There are many facets of backwards compatibility and \[inaudible 00:54:22\]. Let's see if the other questions give any hints.

**Shane McAllister**: A follow up from Parth, and I hope I've got the name correct, is there any use case where I should not use Realm and use the native ones? In every use case you should always use Realm, that's the answer to that.

**Nikola Irinchev**: Now I know that there are cases where sycilite performs better than Realm. The main difference is sycilite gives you static data. You get something from a database and it never changes. That may be desirable in certain cases. That is certainly desirable if you want to pass that data to a lot of threads. Because data is static, you don't have to worry about, let's say, updating values, environment, suddenly, things change under your feet.

**Nikola Irinchev**: That being said, we believe that Realm should fit all use cases. And we are working hard to make it fit all use cases, but there's certainly going to be cases where, for example, we've got that you can use the iOS synchronization with the Apple ID. That is absolutely valid case. That has its own synchronization but it works differently from what Apple offers. It's not as automatic.

**Shane McAllister**: Sure. No, that makes sense. And you answered his third question during the presentation, which was about having multiple Realms in a single app. I think that was definitely covered. Nick has told me to go and ask his questions too to save time. I presume the minute or two we tried to get James on board it wasn't the best use of our time.

**Shane McAllister**: Nick, you've requested number two here but I can't see question number one, so go ahead and... I have to read this myself. Is RealmObject still the direction? A few years ago there was talk of using generators with an interface which would make inheritance easier, particularly for NSObject requirements for iOS.

**Nikola Irinchev**: Yes. Generators are definitely something that we are very interested in. This is very much up in the air, I'm not giving any promises. But generators shipped with .NET 5 in November, at least, the stable version of generators. We haven't gotten the time to really play with them properly, but are definitely interested. And especially for Unity, that is an option that we want to offer, because certain things there also have special inheritance requirements. So yeah, generators are in the hazy part of the roadmap, but definitely an area of interest. We would want to offer both options in the future.

**Shane McAllister**: That makes sense. And Nick had a follow up question then was, performance recommendations for partial string search of a property, is it indexing the property?

**Nikola Irinchev**: Yeah. Right now, indexing the property it will not make up performance differences searching for partial matches. Once the full text search effort is closer to completion, that will yield performance benefits for partial searches even for non-full text search properties. Right now indexing won't make a difference, in the future it will.

**Shane McAllister**: Okay, perfect. So we have two from James here. Will Realm be getting cascading deletes?

**Nikola Irinchev**: Another thing that we didn't touch on in this talk is the concept of embedded objects. If you're familiar with MongoDB and their embedded objects there, it's a very similar concept. You have a top-level object like a person, and they may have objects that are embedded in that object, say, a list of addresses associated with that person.

**Nikola Irinchev**: Embedded objects implement cascading deletes in the sense that if you delete the person, then all their objects are going to be deleted. That is not supported currently for top-level objects. It is something that we are continuously evaluating how to support in the best possible way. The main challenge there, of course, in a distributed system where sync is involved, cascading deletes are very dangerous. You never know who might be linking to a particular object that has been offline, for example, and you haven't seen their changes. So we are evaluating cascading deletes for standalone objects, but embedded objects will fit like 90% of the use cases people could have for cascading deletes.

**Shane McAllister**: Super. Perfect. Thank you, Nikola. And I think there's only one more. Again, from James. Will Realm be providing a database viewer without having to remove it from the device, was the question.

**Nikola Irinchev**: That is an interesting question. Yeah, that's an interesting question and I don't know the answer to that, unfortunately.

**Shane McAllister**: That's all right. We don't need to know all the answers, that's what the meetups are for, right? You get to go back to the engineering team now and say, "Hey, I got asked a really interesting question in a meetup, what are we going to do with this?"

**Shane McAllister**: James had another one there that he just snuck in. He's quick at typing. Will Realm objects work in unit tests or do they only work when the Realm is running, for example, integration test.

**Nikola Irinchev**: Realm objects, they behave exactly like in-memory objects when they're not associated with Realm. So you can create a standalone person, don't turn it to Realm, it will behave exactly like the person model that you find with the in-memory properties. So that's probably not going to be enough for a unit test, especially if you rely on the property change notification mechanism. Because an object that is not associated with Realm, it's not going to get notified if another instance of the same object changes, because they're not linked in any way whatsoever.

**Nikola Irinchev**: But Realm does have the option to run in in-memory mode. So you don't have to create a file on disk, you can run it in memory. And that is what we've seen people typically use for unit tests. It's a stretch call unit test, it's an integration test, but it fits 90% of the expectations from a unit test. So that's something that James could try, give it a go.

**Nikola Irinchev**: But we're definitely interested in seeing what obstacles people are saying when writing unit tests, so we'll be very happy to see if we fit the bill currently, or if there's a way to fit the bill by changing some of the API.

**Shane McAllister**: Super. And another final one there from \[Nishit 01:02:26\]. UI designed by schema XML or something else?

**Nikola Irinchev**: I'm not sure. It can mean two things the way I understand it. One is, if he's asking about the design of the schema of Realm, then it's all done by XML or anything, it's designed by just defining your models.

**Shane McAllister**: I think it's more to do with the UI design in XML, in your app development. That's the way I \[crosstalk 01:03:02\] question.

**Nikola Irinchev**: I don't know. For Xamarin.Forms, and we like to XAML, then yeah. XAML is a great way to design your UI, and it's XML based. But yeah. And Nishi, if you want to drop your question in the forum, I'd be happy to follow up on that.

**Shane McAllister**: Yeah.

**Nikola Irinchev**: Just a little bit more context there.

**Shane McAllister**: Well, look, we're going over the hour there. I think this has been superb, I've certainly learned a lot. And thanks, everybody, for attending. Everybody seems to have filled out the Swag form, so that seems to have gone down well. As I said at the beginning, the shipping takes a little while so please be patient with us, it's certainly going to take maybe two, three weeks to hit some of you, depending on where you are in the world.

**Shane McAllister**: We do really appreciate this. And so the couple of things that I would ask you to do for those that attended today, is to follow @Realm on Twitter. As Nikola and Ferdinando have said, we're active on our forums, please join our forums. So if you go to developer.mongodb.com you'll see our forums, but you'll also see our developer hub, and links to our meetup platform, live.mongodb.com.

**Shane McAllister**: Perfect timing, thank you. There are the URLs. So please do that. But the other thing too, is that this, as I said, is the third this year, and we've got three more coming up. Now look, that they're all in different fields, but the dates are here. So up next, on the 18th of March, we have Jason and Realm SwiftUI, Property wrappers, and MVI architecture.

**Shane McAllister**: And then we're back on the 24th of March with Realm Kotlin multi platform for modern mobile apps. And then into April, but we probably might slot another one in before then. We have Krane with Realm JS for React Native applications as well too. So if you join the global Realm user group on live.mongodb.com, any future events that we create, you will automatically get emailed about those and you simply RSVP, and you end up exactly how you did today. So we do appreciate it.

**Shane McAllister**: For me, I appreciate Ferdinando and Nikola, all the work. I was just here as a talking head at the beginning, at the end, those two did all the heavy lifting. So I do appreciate that, thank you very much. We did record this, so if there's anything you want to go back over, there was a lot of information to take in, it will be available. You will get via the platform, the YouTube link for where it lives, and we'll also be probably posting that out on Twitter as well too. So that's all from me, unless Nikola, Ferdinando you've anything else further to add. We're good?

**Nikola Irinchev**: Yeah.

**Shane McAllister**: Thank you very much, everyone, for attending. Thank you for your time and have a good rest of your week. Take care.

**Ferdinando Papale**: See you.