Today’s 0.9 release is not just a step closer to 1.0, but also an important milestone for us: for the first time, all Swift binding source code is available on GitHub. We’ve also improved performance (again) and added useful features like type converters.
ObjectBox’ lightning-fast database offers a cross-platform C API for language-specific bindings. These bindings provide a thin and nimble wrapper around the C calls and expose ObjectBox functionality in the way that feels most natural to the host language (i.e. Swift).
An open-source binding allows you to make changes to ObjectBox and build it on your own, backport it to older OS or Swift versions, and contribute your changes back to us if you feel so inclined.
Is this the binding I’ve been using all this time?
Although it’s one of our newer language bindings, our Swift binding already has a storied and colorful history. The first Swift binding actually predates our C library and was built directly against the core C++ codebase. As such, it used Objective-C to bridge Swift and C++.
Once we had the C library, we set about eliminating the intermediary and started rewriting the central Objective-C portions as pure Swift on top of the C API. The immediate result when we released ObjectBox for Swift 0.8, was a significant speed-up in write operations due to Swift’s new native UTF-8 strings, and struct support.
But for the open source release, we completed this rewrite, and ObjectBox Swift got even faster:
Not having to bridge to Objective-C meant we could take advantage of Swift’s associated types to resolve class/entity associations instead of a runtime look-up, and eliminate a few duplicated classes necessitated by adding Swift features to Objective-C classes. This in turn allowed removing some unnecessary data copying, which translated directly to increased speed.
While we enjoy a good performance increase as much as the next database developer, we also added new features and fixes, like more query comparison operators for scalar types, and improved behavior when adding properties to an entity.
Property Converters
One major new feature of this release is support for converting simple user-defined types into types the database understands. For example, you can mark any RawRepresentable enum with an annotation to tell ObjectBox how to serialize it. Let’s say we have an enum like
1
2
3
4
5
6
enumOlympicRanking:Int{
caseunset=0
casefirst=100
casesecond=200
casethird=300
}
In your class, you simply add the following annotation:
But of course we also let you work with your own types, or system types. Let’s say you wanted to save a window’s dimensions into your database. You do this using a converter class that implements convert() methods that convert your custom type into one of ObjectBox’s built-in types, and back:
1
2
3
4
5
6
7
8
9
classRectConverter{
staticfunc convert(_box:CGRect)-＞String{
returnNSCoder.string(for:box)
}
staticfunc convert(_boxString:String?)-＞CGRect{
guard let boxString=boxStringelse{return.zero}
returnNSCoder.cgRect(for:boxString)
}
}
And then you tell ObjectBox to use that converter using an annotation:
And that’s just a selection of the changes you’ll find in the new open-source release. It contains the entire binding, but also the fork of Sourcery that does its duties as our code generator, and a performance test app. It is faster, more feature-full, and we’ve also squashed some bugs in the binding.
To take a look and get started, simply go to our ObjectBox Swift Git repository, where, in addition to our example application, you can now also find the binding’s source code. Or pull version 0.9 via CocoaPods.
We can’t wait for you to try it out and let us know what you think. Don’t forget to star us if you like it!
Sideloading can cause crashes when used with Android App Bundle. Google is pushing Android developers to publish their apps to Google Play using the new Android App Bundle format. While it comes with benefits, it can also cause your app to crash, if users sideload your app. We’ll explore why this happens and how to fix it.
Android App Bundle (AAB) enables smaller app downloads and updates, increasing the chances that more people will install your app. Developers benefit as well by only having to build a single artifact instead of multiple APKs tailored to various types of devices.
App Bundle and Sideloading
The Play Store will take care of installing the right set of split APKs from the App Bundle for each user’s device configuration. But what happens, if users bypass Google Play and sideload the app? Sideloading has been popular (APKMirror anyone?) to get early access to new versions of an app or to not waste expensive data volume on app downloads (relevant e.g. in various parts of Africa and India).
To explain how sideloading can break your app, let’s first have a look at what Google Play would actually install onto a device when you publish an App Bundle. For this we use bundletool, which Android Studio and Google Play also use, to convert an App Bundle to a set of APKs for a specific device. We’ll build an App Bundle for our ObjectBox Kotlin example app and start an emulator running Android Pie (you can connect a real device as well). Then we can run the command:
If we extract the created connected.apks file (e.g. using unzip or 7-Zip) we find three split APKs. A master APK containing the app’s manifest and all of its code. An x86 APK containing the ObjectBox native library. And a xxhdpi APK with some resources specific for the screen density of the emulator device. Depending on your app (if it uses dynamic feature modules or includes translations) and connected device there might be more or less split APKs. But let’s stick with these three.
Out of the three only the master APK can be installed on its own. The others will fail to install. You can try this yourself by dropping the APKs onto an emulator.
Crashing with LinkageError
Now how does this affect sideloading? You can probably already see the issue: due to lack of awareness that you are using the cool new App Bundle format, users only share the master APK. And as mentioned it installs just fine. However, at runtime your app might access a native library like ObjectBox or some density-specific resources. As these are not part of the master APK your app will crash. Bummer.
If you do not have an Application class or are using content providers check the full documentation. To see this as part of a working app look at the ObjectBox Kotlin example.
Et voilà, instead of your app crashing users will see a dialog asking them to reinstall the app from the Google Play Store (or “an official store” if the library can’t detect it).
How it works
So how does Play Core know if parts of your app are missing? The library is obfuscated – as most Play libraries are. However, decompiling (just open the class files in Android Studio) allows some basic analysis.
At first, it verifies that the device is API level 21 or higher. Older versions of Android do not support split APKs, so no need to check on these devices.
Then it makes sure that the currently installed version of your app actually requires APK splits. After all, you might still distribute your app as a full blown APK to some devices. This check just looks for a special meta-data manifest tag. This tag is added by bundletool (read Play Store) when converting an App Bundle to a set of split APKs (drop the master APK onto Android Studio and check AndroidManifest.xml).
Now that it is certain your app requires multiple APKs for installation it asks PackageManager for the PackageInfo of your app. Starting with API level 21 this has a splitNames property which has the names of any installed split APKs for your app package. If it is empty one or more APKs were not installed and the user is warned to reinstall the app. Straightforward.
Curiously it also warns you, if there is only one entry with an empty name. Please let us know in the comments why you think that is.
And that is it. Make sure to add the Play Core detection if your app is using ObjectBox and App Bundle to avoid sideloading crashes and keep your users happy.
In this case study, we talked with easyGOband CTO Christian Bongart about their implementation of ObjectBox in a cashless payment and access control solution, which spans across devices from Android to Raspberry Pi.
Alyssa – Hi Christian, thanks for joining me. Can you quickly introduce yourself and easyGOband?
Christian – Hi Alyssa, thanks. I am the co-founder of easyGOband and the CTO. We founded easyGOband back in 2017 as a product for music festivals. We introduced RFID wristbands as an access control system and as a payment solution for music festivals, since they have issues with connectivity.
Normally festivals only accept cash or they have a plastic token system. easyGOband, is a cashless system where you link your entry ticket over web application with your barcode. You can prepay your Near-Field Communication (NFC) wristband with lets say €20, for example. We activate and validate your ticket through the access control, and we hand you over the activated NFC wristband which would then contain the €20. Each seller then has an android device, which is like a small POS device, where you can enter the products you want to charge and the balance gets removed from the wrist band.
A – So, tell me a bit more about where the data sits.
C – The actual data is all stored in the wrist band and on the POS device. So it works in low connectivity environment because music festivals the massification of all the people together adds connectivity issues. Antennas can’t make it. Wifi is also a problem because of interference with audio devices, microphone and stuff like this – it is very hard to have a good connectivity. Other music festivals have invested online solutions with WiFi and they always have big problems with it because music festivals have 60,000 – 70,000 attendants and then the whole payment system goes down – it’s a catastrophe. That many people – no beer, that’s not good at a music event. And that’s how our company was initially born. We have been working in music festivals all over the world, in small music festivals, in bigger music festivals, in Argentina and Mexico, in Ecuador, and in Spain mostly.
A – Are music festivals still your primary target group?
C – Well, we noticed that this music festival business is not the best business we could pick up because it is very hard. Every year, you have to rearrange the agreement with the music festivals. It is quite hard for them to pay and then we noticed that our product could be well suited as well for hotels and resorts. And then we started to work with some large hotel customers, for example, in Spain we worked with Globalia which is the owner of Air Europa. Or Grupo Piñero, and in Cancun working with hotel chain called Oasis and now we are quite far into the hotel business and it’s working quite well.
A – Okay, that makes sense, hotels are a big market. So, tell me a bit about how you use ObjectBox, what does our solution solve for easyGOband?
C – The thing is, the low connectivity environment for us plays a pretty important role in our product. And that means we have to store a lot of data locally on the devices. For example, when the device makes a transaction, it tries to make the notification through the application server but if it can’t notify it then it just stores the data locally and tries again afterwards. For example, all transactions that are made during the event or hotel will store it locally on every single device so that device – as long as it has any connectivity during the operation even if the connectivity breaks at a single moment – can still see all the data: which transaction has been made, what’s the balance, what room is this wristband related to, what access group has it. We combine the data that we synchronize with the application server with ObjectBox, and the data that we can get real time with the NFC wristbands, we can operate 100% even if we are out of connectivity.
We first started with just SQLite. The thing is, we have to work on different devices. We have to work on Android devices, on Linux devices, we have to work on Windows PC and other devices. Something happened in the Android versions I think with the JDBC driver for SQLite and then we needed two different implementations. One with the native SQLite driver from Android and one with just the JDBC driver. That wasn’t ideal for us, more maintenance. After that we tried H2 but there were some issues with corrupting the DBs and stuff like this. And then I found ObjectBox and we give it a try and it worked quite well. And we are now using ObjectBox on all our devices – Windows PC, Linux PC, we are even using Raspberry Pi.
We have to work on different devices. We have to work on Android devices, on Linux devices, we have to work on Windows PC and other devices.
A – Very cool. What’s the use case for the Raspberry Pi?
C – We have a system where we integrate with gatekeeper devices, like automatic doors, and we have one single Raspberry Pi for each gatekeeper. You scan the wrist band, the Raspberry Pi makes the connection with the gatekeeper and opens the door, for example. Or in general we use it for access control system for example, camping or resorts where you have access to the gym, it’s an electro magnetic door and we connect the Raspberry Pi to it and with a relay to open the door for it. And the Raspberry Pi is perfect for this. The newer Raspberry Pis run java based applications very well. Even with a user interface, we found it works well. ObjectBox is just perfect for us, since we can use it on all the different devices, one single implementation for all the repositories. For us, it’s perfect.
A – I believe it. So, in terms of implementation, was it fairly easy to do so across the different devices, were there any challenges?
C – It was quite easy. There was some smaller workarounds. For example we had to stick to number IDs, but the IDs on our system are UIDs. Because data is generated on the devices, we have to use UIDs, we cannot just use a non-sequential ID for this. Just some smaller workarounds – I think you are already working on different solutions that would fix our minor issues. Performance is very good. Implementation was done by one week or so, so yeah, it was quite good.
A – What are some big picture goals for your company, in terms of your road map, product road map?
C – Our next goal is a whole new product for hotels. Because, when we started doing business with hotels and we began seeing what our customers need. Now we have learned enough so we can do a single product for our hotel customers. We are going to do a web page and connect to peripherals over websockets. This means, for example, you as an operator in a hotel, as a receptionist, you login to your web panel, and there’s a button that says, let’s say – “Activate RFID Wristband” and we can connect to the device and execute the order that was initiated by the receptionist. The peripherals in Android devices, and in general would all be using ObjectBox to sync and store on the later.
ObjectBox is just perfect for us, since we can use it on all the different devices, one single implementation for all the repositories.
A – Great that you are able to solve a specific customer pain point. What are you using as a synchronization solution, is that built in house?
C – Yes, yes. On the app server, we use MySQL, I think Aurora Serverless from Amazon and we use JOOQ, a query builder on top of it to build our queries and stuff like this, and then we have an SDK on the client size which uses ObjectBox to store the data on the device.
A – Okay, that’s interesting. Maybe, if you’re familiar or not, we have a synchronization solution for ObjectBox as well.
C – Yes, I’ve been looking into it. Looks good, we will definitely try it out when it’s released. We generate data on different devices and all devices need to sync data that is generated by all the other different devices.
A – So, did you look at ObjectBox because of performance at all?
C – Not really, we were mostly having issues in terms of compatibility. That was the main reason we switched from SQLite or H2 to ObjectBox. It wasn’t only performance related. For example, with SQLite, the performance we were getting was okay. Because the data was stored on every single device, it’s not that much data volume that you have. For example, even at the largest music festival, maybe the biggest we make 1000 or 2000 transactions in minutes or at most. We don’t generate that much data. It was much more relevant with the different compatibility, on the different devices, and that code-base was usable on the most devices possible. That was very important for us. Obviously performance is also important – but it’s not the most important thing for us.
A – Sure, so performance wasn’t necessarily a driver there. Anything else you would like to share about using ObjectBox?
C – You solved a lot of issues that we were facing. And the thing is, we are very happy that every time we have an issue, for example, we found an issue that we couldn’t use it on 32-bit windows devices, that was also almost a year ago, it was fixed within just a few weeks and that is very nice. We have never found such a good and quick response from 3rd party and free solution. Later on we had the issue with the Raspberry Pi where we couldn’t use it because of some issue with your continuous integration – also it was solved by you. That was amazing, I don’t know how to thank you.
A – That’s great to hear. Our community is extremely important to us, it’s a large part of why we’re building ObjectBox. Thank you for sharing your case study, it will be nice to be able to give other users an idea of how ObjectBox can be implememented in so many different applications.
Today, over 90 percent of enterprise data is sent to the cloud. In the next years, this number will drop to just 25 percent according to Gartner. Where is the rest of the data going? It’s not going anywhere. It is being stored and used locally, on the device it was created on. This is Edge Computing.
Mist, fog, edge, cloud – the terms
To bring some light into the terminology mess: The terms “mist” and “cloud” constitute the ends of a continuum.
Mist covers the computing area that takes place on really tiny, distributed, and outspread devices, e.g. humidity or temperature sensors. To make it a bit more tangible: These devices generally are too small to run an operating system locally. They just generate data and send it to the network.
As opposed to this, the cloud refers to huge centralized data centers.
The terms “fog” and “edge” fall within this continuum and – depending on whose definition you follow – can be used interchangeably.
The underlying megatrend enabling this shift is cheaper and more efficient hardware, as well as the emergence of edge databases. Edge databases are specifically designed to run on the edge and therefore lean and efficient. Both the number of mobile and IoT devices, and alongside data volumes are exploding at exponential rates. At the same time computing capabilities on the edge level are advancing faster than those on the cloud level. So, the edge has increasingly more power – power that is currently often underused.
New applications and requirements drive the shift to the edge:
Offline Capability is necessary in some applications, but many offer it for a more seamless user experience (think about it: When you are mobile, at some point you will be offline)
Advantages of setting your project up in the cloud
So, what about the cloud; do we still need it in this era of Edge Computing? Setting up your project in the cloud has some advantages: First of all, the setup itself is comparably easy, as the cloud servers are managed by another organization. This also means that you do not need to worry about scalability of your servers or data loss, i.e. the need for redundancy, reducing overall downtimes. Additionally, cloud systems also are well tested, automatically updated and often encryption mechanisms are provided natively. This eases up on administration. Generally, you can use the cloud rather quickly without worrying about lengthy and error-prone setup tasks. Using servers also centralizes the logic: clients will just call a unified interface (e.g. Web/REST).
A typical IoT-setup would often be centralized and look like this today:
Advantages of running your application on the edge
Running an application on the edge, e.g. your Android phone, a Smart Home Server, or in the car, has a couple of advantages:
The application works everywhere, all of the time (offline / online)
Great supersmooth User Experience (UX) as the app can respond in (near) realtime
Data stays where it was produced and belongs, the user maintains data ownership
Cloud / Connectivity costs go way down
Some tangible use cases for edge computing:
Many Mobile Games run on the edge. As a game developer you really want your users to be able to engage with the game whenever they feel like it and have the time. And as a gamer, you may well want to play when offline, for example when commuting on the underground. Also, gamers really care about the user experience with very smooth animations and high-fidelity visuals.
Autonomous driving as well as any human safety application needs to work independent from an Internet connection and in realtime. Imagine crashing because the car was trying to connect to the cloud or still waiting for the database to respond.
Smart home or smart health applications should work even when there is no connection, but moreover: Why should you personal health data leave your private space? You probably would want to own that data and keep it safe in the local environment. That way it is much less likely that s.o. will try to hack your individual data versus millions of centrally stored data.
Predictive maintenance apps usually need to process tons of data or high-fidelity data like video streams. Transferring all this data to the cloud usually means such high cloud costs that the project becomes unprofitable. Therefore, they usually are run on the edge and only aggregated data transferred to a central server.
Unlikely. Often you want some data accessible from anywhere. Synchronizing parts of the data to the cloud (or an on-premise central server) allows you to combine many of the advantages from edge and cloud computing. Thus, the edge is a natural extension of the cloud that makes applications all the more powerful. We believe that future scenarios will often look like this:
This line of reasoning is supported by the fact that all major cloud companies, e.g. Amazon, Google, Microsoft, are pursuing an edge strategy.
Why should Android developers care about Edge Computing?
Here is why designing your app to run on the edge will help you be successful on the Play Store: There are roughly 2.1 mill. Android Apps to choose from today in the Play Store. To stand a chance in that market you need to delight your users and get good app store ratings. Edge Computing delivers on the app traits users care about most: performance, security, and availability.
Users care about performance – a lot
Whenever an app responds to a query directly instead of taking a round-trip to the cloud and back, it should be faster. More importantly, you can measure and optimize more reliably, as the latency is independent from the network connection. This enables the fast high-quality digital experience consumers want.
Reliable performance was found to be the second most important trait for app users in a study by PacketZoom.
A study by appdynamics found that more than eight out of ten respondents had deleted or uninstalled at least one mobile app because of performance issues.
The same study found that 44% of respondents closed the app when experiencing poor network performance, but even worse: 32% even uninstall the app altogether. They also found, the reverse is true for fast performing and reliable apps with usage increasing.
As an Android developer you also know that many consumers cannot or do not care, why an app is not working. If the application is not working or just responding very slowly, users are dissatisified and annoyed. Therefore, as the developer you need to make sure your app always performs well.
“When your app depends on a network, latency is out of your control.”
Now, you might need to query data from the network. That’s fine; if most of your app is running independent from a connection, there are tons of ways to optimize user experience for connectivity loss and network latency.
Security is a hot topic and can be a USP
Users care about security, and this is a trend that will – in the face of the loss of huge amounts of personal data by tech giants – only continue to grow. When you leave data at the edge, on the device of the user, data security is much easier to provide. On top, data ownership is clear, easing up on data privacy.
Data is much more secure stored in one place than when transferred over the network – possibly again and again and again. Android provides a good basis for keeping internally stored data safe. If data security and privacy are important for you, your app, or your users, think about keeping data locally and then only synchronizing data you really need accessible from anywhere. Last not least, while an individual phone may be hacked, it is less likely to occur and only an individual dataset is compromised (as opposed to millions of datasets).
Offline first – deliver an always-on-feeling
Users do not care about connectivity, they simply want to use the application when they want to – at home, in a department store, in a train, on a flight, on vacation. And when they can’t access an app, their user experience is bad. Even today in a highly connected world, there are lots of times where people have no connectivity or need to switch data off to save battery. The app that supports them in these times ;), is the one they will love and use
The most important advantage of doing an offline-first app is the availability of the app. Google translate is a great example of an app that you want to be offline-capable. Chances are that when you need it most you are in a place where you do not have a (affordable) connection. But you might also appreciate being able to read and search through your mails when you are on a plane too. Or type WhatsApp messages that go out when connected again, or just enjoy a round of Subway Surfers.
Offline-first apps make it possible to move content off the server and onto the phone. If an app only has to go to the server when it needs to, rather than all the time, it will be faster and more reliable. This is particularly significant where content doesn’t change often, but users require fast access.
First of all the 5G rollouts and uptake still will take some time, but if you are reading this you are building a business now. Secondly, while it will bring a faster network connection to many areas, there are caveats to a central cloud-based application that won’t change:
When you are mobile, at some point you will be offline or your connection flaky.
Storing and transferring data to the cloud is costly.
Storing and transferring data unnecessarily to the cloud is wasteful.
Storing data centrally yields higher security risks for your user’s data; transferring data is an additional security risk. Any data you can just keep locally is safest.
If you leave the data with the user, data ownership is clear and you do not need to worry about privacy.
How do I bring my Android app to the edge?
As an Android developer, chances are, you are already doing Edge Computing in many of the apps you are developing.
First of all, offline-first does not work with typical web pages. Usually, you would go for a native app, or alternatively, a progressive web app (PWA) or similar technology. Apart from multiple UX benefits and speed, most users prefer native apps and users still spend 80% of their mobile usage time in apps.
Secondly, for an offline-first architecture you need a local storage as a primary source of data, e.g. a database. Changes to data are made in this layer. Application also can and usually do have networking components to synchronize data to a server. However, this connection to the backend is mainly used in the background to synchronize the local database.
So, why does not everybody do it all the time? Well, there are use cases where it does not make sense to go the extra mile for the limited functionality that edge computing would bring, e.g. in a parking app. Obviously, most relevant data points like your car and the availability of parking spots are changing all the time. So, you really are dependent upon a constant connection, or rather several constant connections: From the spots to the cloud and from the cloud to the app. However, there is another reason: Offline-capable apps are hard. That is why we developed ObjectBox Sync.
Does any app need to run at the edge? ⚖️
As always, there are some cases where the cloud makes perfect sense, indeed is the only option – and the same is true for the edge. You need to assess what you want to achieve and where the value lies for your application and users.
If you do not need to push all the data to the cloud, where large chunks of it might not even be used, you might want to take a step back and consider the broader picture: What do all these billions of mobile and IoT devices (that are quite capable) do while they wait for the cloud to respond? Nothing.
Sending data to the cloud unnecessarily is wasteful in two respects: Use of bandwidth and server capacity (which comes down to infrastructure, electricity and physical space) and the big waste of underused resources.
ObjectBox is a fast object-oriented database for IoT and Mobile edge computing. With its Go support, ObjectBox is a perfect match for Raspberry Pi and will add instant speed to your next Raspberry project.
To get started right away, jump straight to the Installation section.
Local data persistence
In general, databases are great to add data persistence to your project. If you need to turn off the device or if there is a power outage, your sensor statistics or other interesting information are safe. The next time you boot up the application it’s there again as if nothing happened. Another rather obvious advantage is speed and independence from an Internet connection. Storing data on a local drive is just faster than sending it to the cloud and back. And when you store your data locally, your application works with or without an Internet connection. This also means, you have full control over all your data, especially regarding who shall be able to access it… Finally, this reduces cloud costs.
For many databases (e.g. SQLite, PostgreSQL or MySQL), you need to know SQL. And for managing complex datasets, you need to be really good at it. Some like it, but for many developers this is annoying. Also, you might worry about SQL injection attacks.
Advantages of ObjectBox
ObjectBox is a database uniquely designed to sit on IoT and Mobile devices and fix these issues.
Firstly, you do not formulate your queries in SQL. ObjectBox comes with easy APIs allowing you to use the constructs and syntax native to the language you are using anyway. In this way ObjectBox is a NoSQL database. Secondly, benchmarks show that ObjectBox is faster than alternatives. So, even if you’d like to insert the data of a lot of sensors simultaneously, you don’t need to worry about speed anymore. This has the nice side effect that more speed means less CPU and thus is resourceful in every respect. Last not least, because ObjectBox is designed for small devices, it just needs about 1 MB of disk space. If you need something smaller, you can check out the ObjectBox client for Azure Sphere.
If you want to use ObjectBox in your next Raspberry Pi project, here is how you get started:
Installation
We’ll talk about the Go version of ObjectBox here. There are bindings for C, Java and Swift as well – and we will publish articles in the future about them too.
First, you need to have access to the shell (i.e. command line) of your Raspberry Pi. It does not matter if you’re connected via SSH or directly, just make sure that your Raspberry Pi has a working internet connection. Then, just execute the following command to get started right away:
This creates a folder named go in your home directory with the following subdirectories:
go with Go 1.12.7 installation, unless you already had Go 1.12+ installed
objectbox with the shell script update-objectbox.sh you can execute to easily update ObjectBox upon a new release
projects/objectbox-go-test mainly with the file main.go which contains a demo application, with an entity model in its own directory.
Note: The script will install libobjectbox.so globally (confirm by typing “y”), so it might prompt you to enter your root password.
1
2
3
cd~/projects/objectbox-go-test
go build
./objectbox-go-test
Working with ObjectBox Go
The first tool you will come across is objectbox-gogen. It generates the correct Go files out of a Go structure to make it usable with ObjectBox. Assuming your main.go looks something like this:
As long as you only change the program’s logic, you don’t need to do anything. If you change the model, simply execute go genereate ./... to update the auto-generated files for the ObjectBox model interface. Afterwards, you can run your program using go run . .
As a result, you’ll get a directory called objectbox with the files data.mdb and lock.mdb; these are the underlying database files and they will be reused when you execute the program again.
Summary
So, that’s basically it! Setting up ObjectBox and using ObjectBox is easy. Check it out yourself and please share your thoughts with us; we appreciate any feedback. 🙂
Until we release the next part of this tutorial discussing the features of ObjectBox in Go more thoroughly, feel free to check out the fully-fledged demo application in its official repository. Also, if you’d like to learn more about all other features of ObjectBox Go, have a look at the official documentation!
If you encounter any problems during this process, please reach out to us. The best way is to ask a question and tag it “ObjectBox” on Stack Overflow. Finally, we would love hearing your thoughts on ObjectBox via Twitter, Facebook, or Mail (contact [at] objectbox . io).
We’ve been optimizing ObjectBox for speed right from the beginning, making it the fastest database for edge computing around. However, the fastest library in the world is useless if its interface to your language isn’t optimized for that language’s strengths and weaknesses. The 0.8.0 release of ObjectBox for Swift gives you a nearly 70% performance boost out of the box by improving the way we integrate with Swift:
How did we Achieve this Speed-Up?
When we created ObjectBox’s Swift binding, we did not have our C API yet. So, to bridge between the C++ database core and Swift, we implemented a number of classes using Objective-C++. Objective-C++ is neat: it looks to Swift like Objective-C (so like a Swift class), but will happily call into C++ code.
Objective-C is also a very different language from Swift, and particularly generics and structs don’t have a direct equivalent in Objective-C. So when we realized that many reactive frameworks in Swift were built around structs, we decided to change gears. We rewrote a number of core Objective-C classes in the Swift binding as Swift classes on top of the C API that we now use in all our newer language bindings, eliminating a lot of Objective-C’s dynamic dispatch, and generally improving upon algorithms here and there.
The main goal was to give our users struct support and lay the groundwork for taking advantage of Swift 5.1’s upcoming UTF8 strings by eliminating use of the UTF16-based NSString. We also wanted to bring ObjectBox’s Objective-C-beholden error handling in line with Swift conventions. So we expected modest speed-ups here and there, but a speed increase this noticeable even before Swift 5.1 was a pleasant surprise, and we wanted to get these improvements into our users’ hands as quickly as possible.
Using structs with ObjectBox
One rather unique aspect of Swift compared to other languages is how Swift defines the term struct as value type and class as reference type. That makes structs incredibly handy for cases where you want to guarantee an object can never change.
Thread-safety, for instance: if you know an object is unchangeable, there is no chance of race conditions while editing. You need no locks, no copies; your threads can all safely operate on the same memory.
However, when you put an object into your ObjectBox database, put(_:)updates the object’s id property to establish the association between the database entry and your object in memory. ObjectBox can’t do that with unchangeable structs, so we needed to make a slight adjustment to ObjectBox’s usual simple put(_:) flow:
1
2
3
4
5
6
7
8
structUser{
let id:Id<user>
let name:String
let admin:Bool
}
let myUser=User(id:0,name:"Kathryn Drennan",admin:true)
let savedUser=box.put(struct:myUser)</user>
Missed the difference? It’s tiny: You use put(struct:) instead of the regular put(_:). put(struct:) will create a copy of the struct you gave it with the ID changed to whatever ID the object was assigned in the database (the copy is what we store in savedUser in the above example).
So, what if you want to make changes? The way you change immutable structs is to make a copy with the one thing you wanted to change set to a different value. So while you could save it to the database using put(struct:), you already made a copy of the object, and it will not change after being saved, because it already has an ID. Won’t that second copy be wasteful?
That’s why Box now also offers putImmutable(_:). If you know that your object has already been saved, and you don’t need a copy. Just call putImmutable(_:). instead of put(struct:).
1
2
3
let myUser=users.first
let savedUserID=box.putImmutable(myUser)
// assert(myUser.id == savedUserID)
This will return the ID for your convenience, but you can always ignore it, if you do not need it.
What else has changed?
While we’re always improving things under the hood, not much should change for your existing ObjectBox code. Apart from the new ObjectBoxError enum replacing the janky old Objective-C-style OBXError... classes, your existing code should just compile. All the changes are in the generated code.
We use cookies to ensure that we give you the best experience on our website. If you continue to use this site we will assume that you are happy with it.Ok
