Case Study Archives

MoodSpace Mobile App Use Case

by Alyssa | Jan 20, 2020 | Android, Case Study, Insights, ObjectBox

Ian Alexander

Co-founder, MoodSpace

We speak with Ian Alexander, founder and lead developer at MoodSpace, a beautiful app making mental health exercises accessible to everyone. MoodSpace was released in 2019, and has over 150k+ downloads. The COVID-crises highlights the importance of digital support for wellbeing and saw MoodSpace surge. After trying several databases, Ian settled on ObjectBox because of its high performance and ease of use.

Alyssa: Hi Ian, thank you so much for joining me and for using ObjectBox. Let’s start with the basics about MoodSpace and your role there.

Ian: Hi, Alyssa, thanks for having me. I’m the software developer, founder, and runner of the company – a jack of all trades. MoodSpace is an app that teaches concepts from mental health. There is a massive problem with accessibility to mental health. In the UK, for example, you have something like 1 in 4 people that have some sort of mental health problem, but only 1 in 113 go through therapy and complete it. So our essential goal is to take concepts from therapy and bring them closer to people, teaching them techniques that they can do on an ongoing basis. There’s no end date like in therapy, no waiting list, and it’s a lot easier to use it in places where you wouldn’t necessarily have access to a therapist. In the western world it is much easier to access therapy, still difficult in some ways, but much of the world doesn’t have that benefit. So that’s the goal we’re trying to reach. We started last year, we released the MoodSpace MVP in September, and now we’re going through the next stage of trying to raise our next round of funding – it’s quite exciting.

A: That’s great, congratulations! Can you tell me a bit more about your team?

I: We’re based in the UK, and in terms of the technical side, it’s just me. We also have various other roles: designer, copywriter, and another co-founder who handles much of the business side. But in terms of technical, it is just me for now. Hopefully after we get funding, we’ll be able to expand the technical team..

A: What’s your background, what did you do before MoodSpace?

I: Actually, I was originally a chemical engineer – I worked in oil & gas for a couple of years, but then I taught myself to develop and for the last 5-6 years, I’ve worked across a lot of startups, for example the dating app Once, when they were just starting up, also ITV, and then started on MoodSpace last year. Moodspace has actually existed for quite some time, it started as a hobby project of mine about 5 years ago.

A: There are other mental health apps out there, what makes MoodSpace special?

I: If you look at apps in the space, they’re generally fairly small and limited – they’ll have maybe 4 or 5 exercises. Versus the realm of therapy, which has literally thousands of exercises. Any app that exists at the moment takes just a fraction of a percent of therapy and tries to teach it. Our USP is that we are a very technically minded team, and with new technologies which have come out along with our internal processes, we can make a much bigger app, building something far bigger than what currently exists, much cheaper and far faster. Our USP is strangely, less about the app, and more about our process and the technology that we use to make the app. The tech we will be using is Kotlin Multiplatform, which is a cross platform framework which lets us maintain a single codebase which enables us to build fully native apps with full access to native APIs.

A: It sounds like the app is quite comprehensive – who is your target audience?

I: At the moment, we haven’t hit the product-market-fit stage. We’re still figuring out who the typical user is. We find that the unique art style of our app has helped our growth so far, we often find a lot of people sharing screenshots of the app on social media. So we seem to have hit a niche, but we’re still figuring out what that niche is!

A: Do you have any direct interaction with your users?

I: Mid-last year, I put a survey in the app, so after using it for a certain time users get the survey. There are some questions like who you are, why you are using it, and they gave us way more knowledge about who is using it and what they use it for, which was very helpful. Apart from that though, it is very difficult to know.

A: Yes, it can be very challenging, we’re familiar with that struggle at ObjectBox as well. Switching gears a bit – I’d love to hear a bit more about how and why you ObjectBox.

I: As I mentioned, MoodSpace is about 5 years old, so it’s gone through several databases. One of them was really time consuming to make – it wasn’t ORM based, so you had to write a lot of stuff yourself. Then the next was an ORM called Sugar, but it stopped being developed – it was a side project by someone, so maybe I shouldn’t have used it in the first place (laughs).

I: So then we switched to ObjectBox, and actually the reason we switched was essentially to skip asynchronous code – I’ve always been a frontend developer and what I’ve come across is that asynchronous code makes things very complex, and it means app development takes much longer. Because we had a lot of time constraints and we wanted to develop as much as quickly as possible, I actually wanted to completely skip asynchronous code – which I wouldn’t recommend – but essentially ObjectBox let us do that because it’s very fast. You’d have to have a ton of data in the app, before it would visibly slow it down – and I did a lot of testing around that and it would have needed several years of data before noticeably slowing down the app. So, that was our original reason, perhaps a bit of a strange reason. And we’ve since changed the app so it’s asynchronous, so it won’t slow down any longer, no matter how much data you add in the app. Overall, I like ObjectBox a lot – it’s just simple, very easy to use.

A: What features in your app use the database?

I: Actually everything is in the app, as we don’t have a backend. So we need it to store all the data in the app.

A: Okay, sure. Keeping everything in the app is also practical from a data privacy standpoint. How did you actually find ObjectBox?

I: It was someone I used to work with at Once – they used greenDAO and mentioned that ObjectBox (by the same people) was coming out. I looked into it a little bit and wanted to use it for a while, but it wasn’t I started developing MoodSpace again that I had a chance to.

ObjectBox is very fast, it would have needed several years of data before noticeably slowing down the app. Overall, I like ObjectBox a lot – it’s just simple, very easy to use.

A: Are there any other developer tools that you’re excited about and would want to share with the community?

I: Yes, Kotlin Multiplatform. Having been an Android developer, having used Kotlin for quite some time and having tried cross-platform tools before, I think Kotlin Multiplatform will change the way you make cross platform apps, because it lets you share so much of the code base without sacrificing the native experience. It has the potential of leading to massive cost savings in app development. Maybe in the next year or two I can see it having a huge impact on frontend development across mobile, web, and desktop.

A: What are your big picture goals for MoodSpace? Upcoming milestones? Does ObjectBox help with those at all?

I: Actually, it potentially will, with regards to ObjectBox Sync, which is part of my plan for that app. The app right now is only available on Android, and providing we get our next round of funding, we are going to be adding iOS – where we’ll need some sort of backend. We want to avoid, again, spending much money, and one of ObjectBox Sync, Realm Cloud or Firestore can help us do that – obviously as ObjectBox Sync is nearly ready, we’d want to use that. The main point around that is cost saving because it solves a lot of problems that otherwise we would have to solve ourselves – things like offline access and syncing with an API, that would otherwise be very time intensive.

A: Ian, thank you for your time and sharing more about MoodSpace and working with ObjectBox. We wish you the best of luck with your fundraising round!

Start Building with ObjectBox

Edge Computing Case Study: Compatibility across Android, iOS, Raspbian & Linux

by Alyssa | Jul 1, 2019 | Case Study, Insights, IoT, Mobile Database

Christian Bongardt

CTO, easyGOband

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.

Start Developing Today!

Industrial IoT Case Study: An edge solution for railway operators

by Alyssa | Jun 18, 2019 | Case Study, Insights, IoT

GoalExecutive Summary of IIoT Edge Case Study

The biggest challenge railway providers face today is digitization to increase operational efficiency. Issues like unscheduled downtimes or track repairs are very costly and have a strong impact on customer satisfaction. On top, railway providers constantly need to work on ensuring and improving passenger security. The problem behind these issues is that railway operators are often still lacking data when it comes to knowing what is happening on the tracks, in the tunnels and trains.

This case study looks at how Kapsch and ObjectBox collaborated on an Industrial Internet of Things (IIoT) edge solution for the railway industry. The project enables railway operators to optimize their operational efficiency and asset management via rapid processing of real time mission critical data, ensuring extremely reliable asset operations and timely decision-making. In the following we are sharing the project details and accomonying benchmarks.

A solution for the railway industry

Kapsch is a longtime partner of railway operators helping the industry with digitization. By integrating ObjectBox’ database and synchronization solution into the Kapsch railway offering, Kapsch can provide superior speed and data continuity to their railway customers. This means critical data is available when needed and can be interacted with in real-time. This heightens operational efficiency and passenger security, because speed matters in that environment. It also decreases networking costs significantly. Last not least, keeping data locally as much as possible increases data security.

The challenge: Having data up to date – fast, reliably, across devices

As a long-term partner of railway providers across the world, Kapsch addresses their major pain points with its new IIoT solution. Central to optimizing railway providers’ operational efficiency and security is having real-time information about tracks and trains available when needed where needed.

Project requirements at a glance:

Performance and operation on all kinds of platforms from sensor to IoT gateway to server to iOS and Android devices
Reliable data synchronization between devices
Fast (near real-time) and network-connection-independent operation on all devices, meaning on the edge. Therefore, a superfast database across entities is required.
Possibility of opening the APIs for external developer projects in the future.

What we developed in the course of our digitalization initiative, was an end to end solution for IIoT, and with this we have an edge computing solution. We were looking for possible partners and one of them was ObjectBox. When we saw their synchronization methodology, we understood it was a perfect fit.

Jochen Nowotny

Vice President of Product Management, R&D, Delivery & Support, Kapsch

The project environment

Developed in a co-creation process with several railway operators, the Kapsch IIoT-solution is uniquely tailored to the main needs and challenges of the railway industry: Passenger experience, operational efficiency and safety / security.

The Kapsch railway cross-platform solution applies mission-critical data to avoid costly downtimes and repairs, reducing maintenance times and delays. Thus, timetables can be kept more accurately up-to-date, making travelling a better experience for end users.

At the core of the solution lies the mission-critical network. Another essential part of this solution is the storage, processing and delivery of data, so data is accessible where it is needed, when it is needed. Doing this efficiently provides a competitive edge to railway operators. Having the data needed to make decisions in real time – across any part of the railway network – improves operational management and the experience for both employees and customers. ObjectBox offers a fast data storage and synchronization solution that works seamlessly across devices, from sensors to mobile (iOS and Android) to server to cloud. Because of its out-of-the-box synchronization solution, it also saves time to market and costs. On top, ObjectBox’ easy APIs could easily be extended to external developers. Therefore, Kapsch decided to implement and benchmark the startup’s solution.

How did Kapsch find ObjectBox’ solution?

Sourcing new innovative approaches is like finding a needle in the haystack. That is why Kapsch runs the later stage accelerator program Factory1. Factory1 focuses on piloting startup solutions at Kapsch. In a rigorous process, Kapsch’ top management and experts from around the world assess startups and define pilot projects together with them. In the final evaluation step, the startups pitch these pilots to the Kapsch board. After going through this thorough process, ObjectBox convinced the board of their solution’s great potential and usefulness for Kapsch.

The solution: A unique hardware/software stack with out-of-the-box synchronization

While the rigorous sourcing process already ensured a good paper and personal fit, in software projects it always comes down to the nitty-gritty details of the technology stack.

Working together – from technology fit to project-setup

The Kapsch project was developed mainly in Java for the operating systems centOS, Android and iOS. ObjectBox supports all platforms and languages used.

So the first step was to integrate the ObjectBox database for storing data, which meant replacing the persistence layer with ObjectBox. When exchanging a database (the data persistence layer) in an existing project, four cases can be distinguished:

SQL database with abstraction layer	NoSQL database with abstraction layer
SQL database without abstraction layer	NoSQL database without abstraction layer

In this project, a NoSQL database with an abstraction layer needed to be exchanged.

The second step was to synchronize data between IoT edge gateways and central servers.

Each IoT edge gateway (located along the tracks and in the trains) collects local sensor data and makes it accessible to local devices like smartphones, as well as centralized locations (e.g. on the headquarter’s servers). This setup allows high speed operations independent of the availability and quality of network connections.

This is not a simple case of “sending data one way” or “full replication”, rather a more sophisticated technology referred to as “data synchronization”. It is transactionally safe (aka ACID compliant), meaning no data is lost in transit. The network and gateway can go down any time – once everything is up again, data is safely transmitted. This data synchronization is a built-in feature of ObjectBox and therefore does not require any additional, costly software development efforts from Kapsch.

The third step was to compare ObjectBox to alternatives. Therefore, KPIs were defined and a benchmarking application was set up. The KPIs used in this evaluation were: internal project goals, ease of use, the performance of the database, the speed and efficiency of synchronization, and data consistency across devices.

Pilot project results

Together, ObjectBox and Kapsch achieved their goals and created a solution that adds a competitive edge.

“ObjectBox integration in our IIoT solution has enabled significant performances improvement … far beyond other databases. More, we’ve learn a lot on how to operate efficiently a database from the collaboration with ObjectBox team.”

Farid Bazizi

Head of R&D Development - Mission Critical Communication & Industrial IoT Technologies, Kapsch

Overall goals

More specifically, the following goals were met in the 3 month project:

There was a successful integration of the ObjectBox database, demonstrating how fast and easy it can be implemented. Because ObjectBox is flexible and easy to use, it can help ensure that will be usable and maintainable for 10+ years.
The performance benchmarks done in the project clearly showed that ObjectBox outperformed the alternative solution, which was based on Couchbase, with regards to speed (CRUD operations), as well as CPU and memory (RAM) usage.
Last but not least, ObjectBox Synchronization proved to be easy to implement, transferring data seamlessly and reliably between devices. Benchmarked against the existing solution, measurements showed that ObjectBox synchronized the data 61 to 94 times faster.

Benchmarks

Please note, the benchmarks done here are project-specific. The benchmarks simply compare the internal existing Kapsch implementation, which is based on Couchbase, to the ObjectBox implementation. Thus, they should be read as project-specific results only.

Database Performance (CRUD), higher is better

ObjectBox is faster on all basic database operations within this project. This means you can process more data faster, and run more complex applications, like artificial intelligence or machine learning applications on the device – and respond to incidents faster, before it gets costly or dangerous.

CPU & Memory Usage, lower is better

All hardware comes with limited CPU and memory resources. These resources are shared between all the apps running on the device. The less CPU and memory that the data storage solution and sync uses, the more is left for other uses.

This means it is possible to:

install smaller (and often cheaper) hardware
run more applications and do more complex computing (e.g. edge AI) on the existing hardware, allowing you to capitalize on existing infrastructure.

Both are huge cost factors in the project settings.

Synchronization speed

ObjectBox’ synchronization implementation was much faster than the alternative, processing 37,629 objects in one second, as compared to the 400 synchronized by the alternative. In practice this means that in the given setup, ObjectBox supports 10 times more clients (nodes) for every server. This translates to huge cost savings on hardware as servers are expensive and only one server is now required where before 10 were needed.

Startup-Corporate Collaboration: A win-win situation

As this case study shows, it pays off for projects to evaluate solutions independent from their provider’s company maturity level.

On the journey, both companies learned and benefited from each other’s expertise. Apart from solving the concrete technological challenges, the project yielded further positive side effects. Sebastian Opitz, Head of Controlling and ObjectBox’ project mentor, gives an example: “ObjectBox helped to quickly identify a faster way forward with a new technical solution. It would have taken us much longer doing it on our own and probably only would have been discovered much later.”

From the startup perspective, the collaboration gave ObjectBox access to new departments and new markets. “Kapsch has a deep market knowledge and a lot of experience with digitization projects. This experience helped ObjectBox to reach the next level”, concludes Vivien Dollinger, ObjectBox CEO.

Kapsch

Founded in 1892, today this family-owned company headquartered in Vienna is a globally-operating technology group with offices and subsidiaries on all continents. The Kapsch Group focuses on peoples’ requirements in the fields of communication and mobility. With innovative products and solutions, Kapsch BusinessCom and Kapsch TrafficCom make a significant contribution to the digital transformation and a sustainable future in public and private transportation.

ObjectBox

ObjectBox makes real time data consistently accessible from sensor to server – including sensors (client), Android and iOS devices, IoT gateways, on-premise and cloud servers. ObjectBox is 10 times faster than any alternative, smaller than 1 MB and uniquely designed for IoT and Mobile settings.

Discover more IoT Use Cases