Working student developer relations — part-time, remote, flexible

Please note: We only consider applications that have a cover letter specific to this job offer.

The funded and growing team at ObjectBox is seeking a developer relations talent.

ObjectBox (Techstars ’17) is a company on a mission to bring joy and delight to app developers. The core of our solution is a superfast lightweight, embedded database with easy native language APIs for Java, Kotlin, Swift, Dart (Flutter), Go, and C / C++. On top of the database, we’re building a data synchronisation solution (currently in Early Access).

–> Check out GitHub or the Docs

Job role

There’s quite some flexibility in defining the role and working conditions as well as lots of room to advance within the company depending on your skillset, dreams, and needs. At this moment, we are looking for someone that has a good developer background and a strong passion for developer relations and enjoys making developer products shine. This is a remote part-time position (5-10 hours/week to start with, up to 20 depending on skill set, flexible), ideal for a Computer Science Master student or a freshly graduated Computer Science freelancer.

This is a great position for someone who is looking to gain working experience within the developer market at the intersection of development, community management, and sales.

Main responsibilities

Interact with our users and customers, helping them to use the ObjectBox database and Sync. It entails supporting new customers along the way and providing them with more information when necessary. The associated tasks include:

  • Respond to new inbound leads, helping them to set things up
  • Reply to specific dev-related questions about our products
  • Help maintain our community management channels on GitHub and Stack Overflow
  • Improve our documentation based on user experience

We are looking for someone that is driven and ready to help us take our company to the next level. All of the following tasks are optional, depending on your skill set and ambitions:

  • Developer content creation: tutorials, tech blog articles, videos, etc. – from idea to publishing
  • Developer Marketing: Social Listening Social Media postings (managing the channels), SEO measures, website maintenance (update texts, new content, design)
  • Pitch decks, (web) design, brand positioning
  • Represent ObjectBox at meetups, tech conferences etc (you are expected to submit papers yourself; though we do help of course)

Requirements

  • You are currently pursuing a Masters degree in Computer Science, Information Technology or similar; or have just recently graduated
  • You have an affinity for mobile technologies, IoT, open source, or the digital industry in general
  • You are proficient in at least one programming language (ideally C/C++, Java or Dart) with ideally some application development experience
  • You have a hands-on mentality with strong analytical and communication skills
  • You have very strong English skills
  • You pay attention to detail and enjoy working diligently
  • You are a team-player and fast learner who likes to take over responsibility and appreciates working responsibly

Nice to haves

  • Experience with working in a startup
  • Experience with speaking at tech events (meetups, conferences, etc.)
  • Experience with tech writing
  • Experience with GitHub / open source
  • Experience with Social Media

What’s in it for you

  • The chance to work in one of Europe’s hottest startups (check out our slush pitch)
  • An easy-going and super-friendly working environment in a start-up that is growing, where you will be shaping the company together with us
  • Exciting tasks with the option to learn and grow and take over much more responsibilities as fits your skill set and personal goals
  • Flexibility in every respect: No matter if you just finished your degree or already have a family. We are flexible and looking forward to design the job conditions and contract together with you to match your needs
  • A job in one of the most creative and exciting growing industries: Mobile and IoT

This position is remote, however we’re happy to meet up (occasionally or regularly) if you live in Berlin or Munich.

If this appeals to you, we are looking forward to receiving your application including a possible starting date and salary requirements.

Embedded databases – what is an embedded database? and how to choose one

Embedded databases – what is an embedded database? and how to choose one

What is an Embedded Database?

What is a database?

While – strictly speaking – “database” refers to a (systematic) collection of data, “Database Management System” (or DBMS) refers to the piece of software for storing and managing that data. However, often the term “database” is also used loosely to refer to a DBMS, and you will find most DBMS only use the term database in their name and communication.

What does embedded mean in the realm of databases?

The term “embedded” can be used with two different meanings when talking about databases:

  1. Embedded database”: this means that the database is deeply integrated in the software and does not need a server. Also referred to as an “embeddable database”,  “embedded database management system” or “embedded DBMS (Database Management System)”. 
  2. Database for embedded systems” is a database specifically designed to be used in embedded systems (sometimes also called embedded devices). These are systems consisting of a hardware / software combination that is are deeply integrated, e.g. microcontrollers or mobile devices. A database for such systems must be small and optimized to run on highly restricted hardware (small footprint, efficiency). This can be also called an “embedded system database”. For clarity, we will only use the first term in this article.

A lot of confusion arises from these terms being used interchangeably. This is mainly because not all embedded databases are suitable for embedded systems. But also the databases used in embedded systems should not necessarily be embedded in the software. What further complicates the issue, is that the phrase “embedded database” can refer to any of the two meanings. To avoid confusion, we will only use these two terms as defined above.

A practical example: SQLite is typically referred to as an embedded database in Mobile, because it is in Android and iOS (as in embedded in the OS). However, it is also an embedded database as defined here and can be embedded in the app directly (which people do, e.g. to make sure to deliver the most current version).

Embedded Database vs Embedded System

What is an embedded system / embedded device?

Embedded systems / embedded devices are everywhere nowadays. They are used in most industries, ranging from manufacturing and automotive, to healthcare and consumer electronics. Essentially, an embedded system is a small piece of hardware that has software integrated in it. These are typically highly restricted (CPU, power, memory, …) and connected (Wi-Fi, Bluetooth, ZigBee, …) devices. Embedded Systems very often form a part of a larger system. Each individual embedded system serves a small number of specific functions within the larger system. As a result, embedded systems often form a complex decentralized system. Examples of embedded systems: smartphones, controlling units, micro-controllers, cameras, smart watches, home appliances, ATMs, robots, sensors, medical devices, and many more.

Embedded Database vs Database for Embedded Systems

When and why is there a need for a database for embedded devices?

A large number of embedded systems has limited computational power, so the efficiency and footprint of the DBMS is vital. This fact gave rise to the new market of databases specifically made for embedded systems. Because of being lightweight and highly-performant, embedded databases might work well in embedded systems. However, not all embedded databases are suitable for embedded devices. Such features like local data storage and efficient synchronisation with the backend play a huge role in determining which databases work best in embedded systems. 

A database that is both embedded in the application and works well in embedded systems is called an Edge database. To clarify, Edge Database is an embedded database optimised for resource-efficiency on restricted decentralised devices (this typically means embedded devices) with limited resources. Mobile databases, for example, are a type of Edge databases that support mobile operating systems, like Android and iOS.

New Edge databases solve the challenge of an insanely growing number of embedded devices. This applies to both in the professional / industrial as well as the consumer world. Edge databases hence create value for decentralised devices and data by making the former more useful. 

    A database for embedded systems / embedded devices can be simultaneously an embedded database. However, more important is its performance with regards to on-device resource use to serve the restricted devices. A database that is embedded and optimized for restricted devices is called “Edge database”.

    Why use an embedded database in an embedded system?

    First of all, local data storage enabled by embedded databases is a big advantage for embedded systems. Due to the intermittent connection that these often experience, one cannot rely on it for retrieving data. Instead, a smart solution would be to store data locally on the device and sync it with other parts of the system only when needed.

    Aside: a word about data sync. Embedded systems often deal with large amounts of data, while also having an unreliable or non-permanent connection. This can be imposed by the limitations of the system or done deliberately to save battery life. Thus, a suitable synchronisation solution should not only sync data every time there is a connection, but also do it efficiently. For example, differential sync works well: by only sending the changes to the server, it will help to avoid unnecessary energy use and also save network costs.

    The two most important features of databases in embedded systems are performance and reliability. A database used in embedded systems should perform well on devices with limited CPU and memory. This is why embedded databases might work well in embedded systems – they are largely designed to work in exactly such environments. Some of them are truly tiny, which means they thrive in small applications. While better performance helps to eliminate some of the risks, it does not help with sudden power failures. Therefore, a good data recovery procedure is also important. This is most consisely demonstrated by ACID compliance.

    Let’s have a look at the features of embedded databases that make them a great choice for embedded systems. 

    Advantages of embedded databases

    1. High performance. Truly embedded databases benefit from simpler architecture, as they do not require a separate server module. While the client/server architecture might benefit from the ability to install the server on a more powerful computer, this also means more risk. Getting rid of the client/server communication level reduces complexity and therefore boosts performance. 
    2. Reliability. Many embedded devices use battery power, so sudden power failures might happen. Therefore, the data management solution should be built to ensure that data is fully recovered in case of a power failure. This is a popular feature of embedded databases that are built with embedded systems in mind.  
    3. Ease of use and low maintenance. Other important benefits of using an embedded database include easy implementation and low maintenance. Designing embedded devices often requires working in tight schedules, so choosing an out-of-the-box data persistence solution is the best choice for many projects. Since embedded databases are embedded directly in the application, they do not need administration and effectively manage themselves.
    4. Small footprint. Embedded databases do not always have a small footprint, but some of them are smaller than 1 MB, which makes them particularly suitable for mobile and IoT devices with limited memory.
    5. Scalability. As the number of embedded devices grows every year, so does the data volume. An efficient solution should not only perform well with large sets of data, but also adapt to new device features and easily change to fit the needs of a new device. This is where rigid database schemas come as a disadvantage.

     

    How to choose an embedded database

    When choosing an embedded database, look out for such factors as ACID (atomicity, consistency, isolation, durability) compliance, CRUD performance, footprint, and (depending on the device needs) data sync.

    SQLite and SQlite alternatives – a detailed look at the market of embedded databases

    Database solution
    Primary model Minimum footprint Sync Languages
    SQLite relational <1mb no C/C++, Tcl, Python, Java, Go, Matlab, PHP, and more
    Mongo Realm object-oriented NoSQL database 5 MB+ sync only via Mongo Cloud Swift, Objective-C, Java, Kotlin, C#, JavaScript
    Berkeley DB NoSQL database; key-value store <2mb no C++, C#, Java, Perl, PHP, Python, Ruby, Smalltalk and Tcl
    LMDB key-value store <1mb no C++, Java, Python, Lua, Go, Ruby, Objective-C, JavaScript, C#, Perl, PHP, etc
    RocksDB key-value store   no C++, C, Java, Python, NodeJS, Go, PHP, Rust, and others
    ObjectBox object-oriented NoSQL database <1mb offline, on-premise and cloud Sync, p2p Sync is planned Java, Kotlin, C, C++, Swift, Go, Flutter / Dart, Python
    Couchbase Lite NoSQL DB; document store 1-5 MB sync needs a Couchbase Server Swift, Objective-C, C#, C, Java, Kotlin, JavaScript,
    UnQLite NoSQL; document & key-value store ~1.5 MB no C, C++, Python
    extremeDB in-memory relational DB, hybrid persistence <1 MB no C, C#, C++, Java, Lua, Python, Rust

    Conclusion: When to use an Embedded Database and how to choose one

    Firstly, when choosing a database for an embedded system, one has to consider several factors. The most important ones are performance, reliability, maintenance and footprint. On highly restricted devices, even a small difference in one of those parameters might make an impact. While building your own solution with a particular device in mind would certainly work well, tight schedules and additional effort don’t always justify this decision. This is why we recommend choosing one of the ready-made solutions that were built with the specifics of embedded systems in mind. 

    Secondly, to avoid unnecessary network and battery use, you might want to choose an embedded database. On top, an efficient differential data sync solution will help reduce overhead and reduce the environmental footprint.

    Finally, there are several embedded databases that perform well on embedded devices. Each has its own benefits and drawbacks, so it’s up to you to choose the right one for your use case. That being said, we’d like to point out that ObjectBox outperforms all competitors across each CRUD operation. See it for yourself by checking out our open source performance benchmarks.

    Cross platform Data Sync: a simple example

    Cross platform Data Sync: a simple example

    Cross platform data sync can be simple: In this tutorial we will show you how you can easily sync data across devices.

    Built for fast and effortless data access on and across embedded devices from Mobile to IoT, ObjectBox keeps data in sync between devices for you. The Database and Data Snyc works across platforms (iOS, Android, Linux, Rasbian, Windows, MacOS) and supports a variety of languages with easy native APIs (Swift, Java, Kotlin, C / C++, Flutter / Dart, Golang).

    For example, you can sync between an Industrial IoT sensor app in Go and a C++ monitoring application – and a mobile Android app written in Kotlin or Java – and of course an iOS app written in Swift – and… you get the drift 😉

    ObjectBox is a high-performance embedded database for Edge Computing with integrated Data Sync. The ObjectBox database is quick to set up and free and easy to use. Our powerful and intuitive APIs are a great match for multiplatform development environments.

    Syncing data across devices – a task-list app example

    In this tutorial, we are going to sync data across three instances of an example task-list app (written in C++, Go and Java).

    With the task-list app, users can create simple text-based tasks and mark them as done. It stores tasks together with their creation dates. There is also a parameter to store the date when the task was completed. It acts as a filter for users to only see unfinished tasks. 

    This app is a standard cross platform ObjectBox example that is available for all language bindings. Here are the repositories of each example app that we will be looking at today:

    Overview of the example code 

    In this section, we’ll quickly review how the the task-list example app uses ObjectBox Sync. For a more detailed description, check out the Sync docs. If you want to see how each of these steps were incorporated into the example code, go to the next section.

    Note: The basic use of the database and its sync features is the same for all programming languages. If you haven’t used the ObjectBox DB yet, please refer to the corresponding documentation: C/C++ Docs, Java/Kotlin/Dart Docs, Go Docs, Swift Docs.

    For sync to work in any app, we generally only need four things:

    1. The sync-enabled library — this is not the same as the general ObjectBox library and has to be downloaded separately.
    2. Database objects enabled for sync — for this we need include the sync annotation in the ObjectBox schema file.
    3. ObjectBox Sync Server — please apply for a free Sync Trial here to get your own copy of the Sync Server (available for Linux and Docker). Note that this will only have to be started once and in this tutorial we’ll show you how to run the server on Linux. If you are using Docker, follow the steps outlined here.
    4. Start a Sync Client in the app — as one can see from the Sync Client docs, creating and starting a sync client is just a matter of a couple of lines of code.

    Important: When syncing between different apps, please make sure that the UIDs in the model JSON file (e.g. objectbox-default.json) are the same everywhere.

      How to run the examples

      Here you’ll find requirements and step-by-step guides for running the task-list example app in each of the three languages.

      C++ example app

      Requirements

      New to C++? Check out our beginner C++ ObjectBox installation tutorial.

      • WSL Ubuntu
      • CMake
      • Git
      • C++
      • Clang

        Step-by-step guide

        1.Start by creating a CMakelists.txt file:

        Now configure and build the project via CMake: Configure (Clang), CMake: Build.

        2. Sync-enabled objects: note the first line in tasklist.fbs.

        3. [if not running a server already] Start the ObjectBox Sync Server on Linux by running ./sync-server --model build/_deps/objectbox-src/examples/cpp-gen/objectbox-model.json --unsecured-no-authentication

        where sync-server is the path to your sync server executable. You can find more information about the server in the Sync Server docs.

        4. Sync Client: launch [objectbox-c-examples-cpp-gen-sync], and the Sync Client will start automatically. You can see how it was implemented in main.cpp.

        As this is just an example, we opted for no authentication to make things simple. This is not what you would use in production. We currently offer two authentication methods: shared secret and Google Sign-In. Here is the relevant Sync docs section on authentication options that explains how to use these.

        5. Let’s add a first task, called “task-cpp” (new task-cpp-1), to check if our C++ app syncs correctly. The output should look like this:

        Output of the C++ tasklist example app, showing a newly added task

        6. You can finally open the Admin UI to check if the task appears there. This is most easily done by opening http://127.0.0.1:9980/ in any web browser. For a more detailed description of what this can do, check out the Admin UI docs.

        Go example app

        Requirements

        • WSL Ubuntu
        • Go (see how to configure it for VS Code here)
        • Git

        Step-by-step guide

        1. First, clone the objectbox-go repository to your VS Code project. Make sure the current directory is objectbox-go.

        2. Sync-enabled objects. There are two versions of the task-list example: with and without sync. To run the one with sync, we need to enable our Task object for syncing. To do this, simply put the sync annotation on a new line in examples/tasks/internal/model/task.go:

        Then run the generator: go generate examples/tasks/internal/model/task.go to update the schema.

        3. [if not running a server already] Now start the ObjectBox Sync Server: ./sync-server --model=examples/tasks/internal/model/objectbox-model.json --unsecured-no-authentication,

        where sync-server is the path to your sync server file. You can find more information about the server in the Sync Server docs.

        4. Run go run examples/tasks/main.go. The Sync Client will start within the app; check main.go to see how this was implemented.

        As this is just an example, we opted for no authentication to make things simple. This is not what you would use in production. We currently offer two authentication methods: shared secret and Google Sign-In. Here is the relevant Sync docs section on authentication options that explains how to use these.

        5. Now we can add our first task (new task-go) – if it synced correctly, you should already see that from the output of the app. In particular, there will be a message from the change listener (“received 1 changes”):

        Output of the Go task-list example app after adding a first task

        6. Lastly, open the Admin UI to check if the task appears there. This is most easily done by opening http://127.0.0.1:9980/ in any web browser. For a more detailed description of what this can do, check out the Admin UI docs.

        Admin UI showing a task created with the Go example app

        Java (Android) example app

        Requirements

        • Java
        • Android Studio

        Step-by-step guide

          1. First of all, open Android Studio and clone the objectbox-examples repository via File → New → Project from Version Control. Use this URL: https://github.com/objectbox/objectbox-examples.git
          2. Sync-enabled objects: check out Task.java to see how this was done (note the @Sync annotation).
          3. [if not running a server already] Start the ObjectBox Sync Server

        ./sync-server --model android-app-sync/objectbox-models/default.json --unsecured-no-authentication,

        where sync-server is the path to your sync server file. You can find more information about the server in the Sync Server docs.

        1. Now you can run “android-app-sync” on a device of your choice. The Sync Client will start in the app. 

        As this is just an example, we opted for no authentication to make things simple. This is not what you would use in production. We currently offer two authentication methods: shared secret and Google Sign-In (only for Java, Kotlin, Dart, C & Go). Here is the relevant Sync docs section on authentication options that explains how to use these.

        5. Add a new task called “task-java”.

        6. Finally, open the Admin UI to check if the task appears there. This is most easily done by opening http://127.0.0.1:9980/ in any web browser. For a more detailed description of what this can do, check out the Admin UI docs.

        Next Steps

        How easy was that? cool Now that you’ve run your first ObjectBox Sync example, why not build something yourself? Use any combination of the supported languages to build your own cross platform app.

        We’re eager to see your use case examples! Don’t hesitate to share your results with us by posting on Social Media and tagging @objectbox_io, or simply sending us an email on contact[at]objectbox.io. 

         

        If you want to learn more about how ObjectBox can be used in IoT, here is an overview of different use cases

        ObjectBox Database Java 3.1 – Flex type

        ObjectBox Database Java 3.1 – Flex type

        We are happy to announce version 3.1 of ObjectBox for Java and Kotlin. The major feature of this version is the new Flex type. For a long time, ObjectBox worked on rigid data schemas, and we think that this is a good thing. Knowing what your data looks like is a feature – similar to programming languages that are statically typed. Fixed schemas make data handling more predictable and robust. Nevertheless, sometimes there are use cases which require flexible data structures. ObjectBox 3.1 allows exactly this.

        Flex properties

        Expanding on the string and flexible map support in 3.0.0, this release adds support for Flex properties where the type must not be known at compile time. To add a Flex property to an entity use Object in Java and Any? in Kotlin. Then at runtime store any of the supported types.

        For example, assume a customer entity with a tag property:

        Then set a String tag on one customer, and an Integer tag on another customer and just put them:

        When getting the customer from its box the original type is restored. For simplicity the below example just casts the tag to the expected type:

        A Flex property can be not justString or Integer. Supported types are all integers (Byte, Short, Integer, Long), floating point numbers (Float, Double), String and byte arrays.

        It can also hold a List<Object> or a Map<String, Object> of those types. Lists and maps can be nested.

        Behind the scenes Flex properties use a FlexBuffer converter to store the property value, so some limitations apply. See the FlexObjectConverter class documentation for details.

        Query for map keys and values

        If the Flex property contains integers or strings, or a list or map of those types, it’s also possible to do queries. For example, take this customer entity with a properties String to String map:

        Why is properties not of type Object? ObjectBox supports using Map<String, String> (or Map<String, Object>) directly and will still create a Flex property behind the scenes.

        Then put a customer with a premium property:

        To query for any customers that have a premium key in their properties map, use the containsElement condition:

        Or to only match customers where the map key has a specific value, here a specific premium tier, use the containsKeyValue condition:

        What’s next?

        ObjectBox database is free to use. Check out our docs and this video tutorial to get started today.

        We strive to bring joy to mobile developers and appreciate all kinds feedback, both positive and negative. You can always raise an issue on GitHub or post a question on Stackoverflow. Otherwise, star the ObjectBox Java repository and up-vote the features you’d like to see in the next release.

         

        Beginner C++ Database Tutorial: How to use ObjectBox

        Beginner C++ Database Tutorial: How to use ObjectBox

        Introduction

        As a direct follow up from the ObjectBox database installation tutorial, today we’ll code a simple C++ example app to show how the database can be used. Before starting to program, let’s briefly overview what we want to achieve with this tutorial and what is the best way to work through it.

        Overview of the app we want to build

        In short, we will make a console calculator app with an option to save results into memory. These will be stored as objects of the Number class. Every Number will also have an ID for easy reference in future calculations. Apart from the function to make calculations, we will create a function to enter memory. It will list all the database entries and have an option to clear memory. By coding all of this, we will make use of such standard ObjectBox operations as put, get, getAll and removeAll.

        Our program will consist of seven files: 

        • the FlatBuffers schema file, that defines the model of a class we want to store in the database
        • the header file, for class function definitions
        • the source file, for function implementation
        • the four files with objectbox binding code that will be created by objectbox-generator

        How to use this tutorial

        While looking at coding examples is useful in many cases, the best way to learn such a practical skill like programming is to solve problems independently. This is why we included an exercise for each step. You are encouraged to make the effort and do each of them, even if you don’t know the answer straight away. Only move to the next step after you test each part of your program and make sure that everything works as intended. Ideally, you should only use the code snippets presented here to check yourself or look for hints when you feel stuck. Bear in mind that sometimes there might be several different ways to achieve the same results. So if something that we ask you to do in this tutorial doesn’t work for you, try to come up with your own solution.

        How to create the FlatBuffers file?

        First, we’ll create the FlatBuffers schema (.fbs) for our app. This is required for the objectbox-generator to generate binding code that will allow us to use the ObjectBox library in our project. 

        The FlatBuffers schema consists of a table, which defines the object we want to store in the database, and the properties of this object. Each property consists of a name and a type. We want to keep our example very simple, so just two properties is enough.

        1. To replicate a calculator’s memory, we want ObjectBox to store some numbers. We can define the Number object by giving the table a corresponding name.
        2. Inside the table, we want to have two properties: id and contents. The contents of each Number object is the number itself (double), while id is an ulong that our program will assign to each of them for easy identification.

        Exercise: create a file called numbers.fbs and define the table in the format

        Reveal code

        Generating binding code

        Now that the FlatBuffers file is ready, we can generate the binding code. To do this, run the objectbox-generator for our FlatBuffers file:

        The following files will be generated:

        • objectbox-model.h
        • objectbox-model.json
        • numbers.obx.hpp
        • numbers.obx.cpp

        The header file

        This is where the main chunk of our code will be. It will contain the Calculator class and all the function definitions.

        1. Start by including the three ObjectBox header files: objectbox.hpp, objectbox-model.h and numbers.obx.hpp. Our whole program will be based on one class, called Calculator. It should only have two private members: Store and Box. Store is a reference to the database and will manage Boxes. Each Box stores objects of a particular class. In this example, we only need one Box. Let’s call it numberBox, as it will store Numbers that we want to save in the memory of our calculator.

        Exercise: create a file called calculator.hpp and define the Calculator class with two private members: reference to the obx library member Store and a Box of Numbers.

        Reveal code

        2. After the constructor, we define the run function. It will be responsible for the menu of our program. There should be two main options: to perform calculations and enter memory. As discussed above, we want this app to do two things: perform calculations and show memory. We’ll define these as separate functions, called Calculate and Memory. The first one is quite standard, so we won’t go into a detailed explanation here. The only thing you should keep in mind is that we need to account for the case when the user wants to  operate on a memory item. To deal with this, we’ll process input in a function called processInput.

        Exercise: define the parametrised constructor which takes a reference to Store as a parameter. Then define the run and Calculate functions.

        Reveal code

        3. The final part of this function is for saving results into memory. We start by asking the user if they want to do that. If the answer is positive, we create a new instance of Number and set the most recent result as a value of its contents. To save our object in the database, we can operate with put(object) on our Box. put is one of the standard ObjectBox operations, which is used for creating new objects and overwriting existing ones. 

        Exercise: create an option to store the result in memory, making use of the ObjectBox put operation.

        Reveal code

        4. Next, we should define processInput, which will read input as a string and check whether it has the right format. Now, to make it recognise the memory items, we have to come up with a standard format for these. Remember, we defined an ID property for our Numbers. Every number in our database has an ID, so we can refer to them as, e.g. m1, m2, m3 etc. To read the numbers from memory, we can make use of the get(obx_id) operation. It returns a unique pointer to the corresponding Number, whose contents we need to access and use as our operand.

        Exercise: define the processInput function, which detects when something like m1 was used as an operand and updates x, y, and op according to the input.

        Reveal code

        5. The last function in our header file will be Memory. It should list all the numbers contained in the database and have an option to clear data. We can read all the database entries by calling the getAll ObjectBox operator. It returns a vector of unique pointers. To clear memory, you can simply operate with removeAll on our Box.

        Exercise: define the Memory function, which lists all the memory items, and can delete all of them by request.

        Reveal code

        The source file

        To tie everything together, we create a source (.cpp) file. It should contain only the main function that initialises the objectbox model, creates an instance of the Calculator app, and runs it. To create the ObjectBox model, use

        then passing options as a parameter when you initialise the Store.

        Exercise: create the source file

        Reveal code

        Final notes

        Now you can finally compile and run your application. At this point, a good exercise would be to try and add some more functionality to this project. Check out the ObjectBox C++ documentation to learn more about the available operations.

        After you’ve mastered ObjectBox DB, why not try ObjectBox Sync? Here is another tutorial from us, showing how easily you can sync between different instances of your cross platform app.

        Other than that, if you spot any errors in this tutorial or if anything is unclear, please come back to us. We are happy to hear your thoughts.