Dart Flutter Database ObjectBox 1.0 Release

Dart Flutter Database ObjectBox 1.0 Release

In 2019 we first introduced the ObjectBox database v0.1 for Flutter/Dart. Our team has loved the engagement and feedback we’ve received from the developer community since, and we’re thrilled to announce the first stable version 1.0 for ObjectBox Dart/Flutter today.

With this release we bring you the fast and easy to use ObjectBox database for Dart objects: optimized for high performance on mobile and desktop devices. ObjectBox persists your Dart objects (null safe, of course) and comes with relations, queries, transactions, and Data Sync. For a feature list and more, please also check the pub.dev page.

ObjectBox by Example

For those of you new to ObjectBox, here is how you can use it (or check the docs if you want to dive deep right away). By annotating a class with @Entity you tell ObjectBox that you want to persist its objects, which is done putting the object in a Box:

What’s new with the 1.0?

Version 1.0 delivers a stabilized API and adds new essential features like async writes and query streams. We’ve also extended support for Flutter desktop. Let’s look at queries and how they can be used depending on the use case:

There are two new approaches to do async puts for asynchronous database writes: putAsync() returns a Future to check if the call was successful.

Or you can use a background queue if you don’t need individual Futures, the following code inserts 100 objects and only waits once:

If you are interested in further improvements we made to 1.0, please check out the full changelog.

Dart Flutter Database Benchmarks

ObjectBox Dart v1.0 also comes with considerable optimizations bringing a new level of database performance to Flutter apps. ObjectBox enables data-heavy apps that were not possible on Flutter before. Consider this a first sneak-peek; stay tuned for detailed performance benchmarks to be released including queries (hint: they are really fast) along with updated benchmarking code.

What we tested

We looked at some two popular approaches: sqflite, a SQLite wrapper for Flutter (no Dart Native support), and Hive, a key-value store with Class-adapters which seems still popular although its creator abandoned it for architectural shortcomings (it has memory problems and does not support queries). In the previous benchmark we’ve also had a look at Firestore, but being an online-only database it was thousands of times slower than the rest so we’ve left it to rest this time around. Check our previous benchmark if you’re interested.

To get an overview of the databases, we tested CRUD operations (create, read, update, delete). Each test was run multiple times and executed manually outside of the measured time. Data preparation and evaluation were also done outside of the measured time.

ObjectBox, sqflite, Hive performance comparison across CRUD

Looking at the results, we can see ObjectBox performing significantly faster than sqflite across the board, with up to 100 time speed-up in case of create & update operations. Compared to Hive, the results are a little closer in some cases (read) though ObjectBox still comes out on top in all the metrics. Considering that Hive keeps all Dart objects in memory (!) while ObjectBox does not, should give you a good impression of how fast object persistence with ObjectBox is.

ObjectBox Database for Flutter/Dart Highlights

For those of you new to ObjectBox, here’s a quick summary of what our super-fast embedded database offers, out of the box:

  • automatic schema migration: adding new classes or fields just works
  • type-safe APIs, e.g. no interface{} arguments
  • embedded edge database – no server needed, store all data directly on the device
  • no ORM, no SQL
  • relations: to-one, to-many (eager and lazy fetching)
  • robust query support, including indexes for scalable lookups
  • Support for implicit (automatic) and explicit (user defined)
  • transactions: ACID compliant with superfast bulk/batch operations
  • low memory usage
  • runs across operating systems: 64-bit Linux, macOS, Windows, small 32-bit ARM-based Linux devices (e.g. Raspberry Pi)
  • Data Sync: an efficient and easy way to synchronize data between your app and the cloud

Getting Started with ObjectBox for Flutter/Dart Today

ObjectBox is free to use and you can get started right now with the Flutter database on GitHub, via the docs, pub.dev, or this getting-started video tutorial, or getting-started article.

We ❤️ your Feedback

Now it’s your turn: let us know what you love, what you don’t, what do you want to see next? Share your feedback with us, or check out GitHub and up-vote the features you’d like to see next in ObjectBox.

ObjectBox Dart/Flutter v0.11 Database: Performance & Relations

ObjectBox Dart/Flutter v0.11 Database: Performance & Relations

Flutter Databases are few. Therefore, we’re happy to take a big step towards 1.0 with this ObjectBox Dart v0.11 release, improving performance and bringing the much-desired relations support known from other ObjectBox DB language bindings to Dart/Flutter.

For those of you new to ObjectBox: ObjectBox is a superfast NoSQL object database for Flutter / Dart and here is how you can save data in your Dart / Flutter apps:

To learn about more ObjectBox features, like relations, queries and data sync, check our ObjectBox pub.dev page.

How fast is ObjectBox Dart? Performance Benchmarks

Speed is important for data persistence solutions. Accordingly, we wanted to test how ObjectBox compares performance-wise to other Flutter Dart database options. Therefore, we looked for libraries with comparable levels of storage abstraction and feature set –  so not just plain SQL/Key-value storage but also ORM-like features. There doesn’t seem to be that much choice… 

We looked at some two popular approaches: sqflite a SQLite wrapper for Flutter (no Dart Native support), and Hive, a key-value store with Class-adapters which seems still popular although its technology is phased out (see below). As a third alternative we pulled in Firestore, which does not really fit as it is no local database, but would be fun to compare anyway.

What we tested

To get an overview of the databases, we tested CRUD operations (create, read, update, delete). Each test was run multiple times and executed manually outside of the measured time. Data preparation and evaluation was also done outside of the measured time.

We tried to keep the test implementations as close as possible to each other while picking the approaches recommended by the docs for each database. We open sourced the test code at https://github.com/objectbox/objectbox-dart-performance if you want to have a closer look.

Performance Benchmark Results

Looking at the results, we can see ObjectBox performing significantly faster than sqflite across the board, with up to 70 times speedup in case of create & update operations. Compared to Hive, the results are a little more varied, with Hive being faster at reading objects than ObjectBox (we come to that later in our outlook), and ObjectBox being faster at creating objects, about four times faster at updates and three times for deletes. As a mostly-online database, it becomes clear that Firestore’s performance is not really comparable.

Implementation notes

ObjectBox: This release largely boosted the performance. The remaining bottlenecks are due to Dart itself and how it allows to modify byte buffers. There’s potential to double the speed if we look at other languages supported by ObjectBox. And if that’s not happening soon, we’d still have the option to do some low-level hacks…

Sqflite: a wrapper around SQLite, which is a relational database without direct support for Dart objects. Each dart object field is mapped to a column in the database, as per sqflite docs, i.e. converting between the Dart class and a Map.

Hive: We’ve tested with the latest Hive release, which is technically discontinued. The author hit two architectural roadblocks (RAM usage and queries) and is currently in the process to do a rewrite from scratch.
Update: strictly speaking it’s not straightforward to directly compare e.g. ObjectBox vs. Hive. In Hive, the high read numbers result from Dart objects already cached in memory. If the objects are fetched using the async API from disk, the numbers drop by factor 1000.

Firestore: This is totally apples and oranges, but we still decided to include Firebase/Firestore as it seems at least somewhat popular to “persist data”. It’s quite Cloud centric and thus offers limited offline features. For example, in order to use batches (“transactions”), an internet connection is required to “commit”. Also, due to its low performance, the test configuration was different: batches of 500 objects and only 10 runs.

Test setup

We ran the benchmarks as a Flutter app on a Android 10 device with a Kirin 980 CPU. The app executed all operations in batches of 10.000 objects, with each batch forming a single transaction. Each test was run 50 times, averaging the results over all the runs. This ensured the VM warmup (optimization) during the first run and garbage collections don’t affect the overall result significantly. (We care about accurate benchmarks; read more about our benchmarking best practices here.)

Outlook

With this latest release, we’re not far away from a stable API for a 1.0 release (🎉), so please share your thoughts and feedback. For the next release, we’ll add features like async operations, more relation types and some smaller improvements. We are also working on an ObjectBox variant for the Web platform that is planned close to the 1.0 release. And of course there is ObjectBox Data Sync for Flutter/Dart. If you want to be first in line to try, drop us a line, we can put you on the shortlist.

MoodSpace Mobile App Use Case

MoodSpace Mobile App Use Case

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.

Moodspace Mobile App Use Case

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.

Moodspace Mobile App Use Case
Moodspace Mobile App Use Case
Moodspace Mobile App Use Case

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.

Moodspace Mobile App Use Case

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!

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

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

Christian Bongardt

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.

ObjectBox Edge Computing Case Study

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 mobile app case study

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?

CYou 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.

A Successful Open Source Story Uwe Trottmann – SeriesGuide

A Successful Open Source Story Uwe Trottmann – SeriesGuide

We had the opportunity to interview Uwe Trottmann, creator and principal contributor of the app SeriesGuide with over 1 Million downloads on Google Play. 

Uwe Trottmann

Uwe Trottmann

Small Business Owner at SeriesGuide

He received his M.Sc. Computer Science at TU Munich in 2013 and is interested in making software usable for everyone. If at all, he is only looking for part time work next to his other endeavors.

Download SeriesGuide!

Dorian: For how long have you been coding?

Uwe: That’s a very good question. I started in school in 2004 because a friend of mine coded a basic vocabulary training program in Visual Basic. I started to improve that program and later enrolled in a programming class in school, which was very new at the time. Right now it’s common to have computer science classes in school, but back then it was not the standard. I started doing other side projects for fun, but only got serious about coding when I started studying computer science at University in 2008.

Dorian: Do you think going to University helped your projects?

Uwe: Yes, absolutely. There’s a lot of technical and theoretical background that you are not exposed to, if you just program. At University, the coding exercises were very easy for me, because I had a lot of practice beforehand. However, I learned so much about other things like designing systems, Software Engineering, how to manage projects. Also the theoretical background, like data structures, how to do things efficiently. Also things I never would have looked at, like computer architecture, how stuff works on the lower levels, etc. Which is interesting to know, but it doesn’t really help with the stuff I am currently working on. 

Dorian: But that knowledge of the lower levels has maybe helped you solve some bugs?

Uwe: It has a little bit. I think the only relevant thing that I still come across now is bit operations. But things like registers, or programming in assembler, no. This is probably more helpful for the C guys, which program at a lower level. I like working at a higher level. So I program in Java, Kotlin, for Android, and Windows back in the day. These all abstract the lower level away and I didn’t have to worry about memory management, which I didn’t really like doing back then. It’s complicated and very easy to get wrong. I don’t know if you have heard about pointers, but they are one of the biggest problems with programming in C. If you get a pointer wrong everything breaks, you have security issues, and so on. If you talk to C developers about pointers, they could go on forever.

Google play store java embedded database java object database livedata android Mobile Database open source database software qsl alternative SeriesGuide sqlite alternative

Uwe Trottmann at Droidcon Berlin 2018.

Dorian:  How did you start up with Open Source? Did you start right away out of University or did you do work for other companies and do Open Source on the side?

Uwe: In the beginning I had my own projects and didn’t know about Open Source. The first thing that I open sourced was SeriesGuide. My work on SeriesGuide started as a hobby because I had recently switched to Android and was missing the series management app I previously used on another platform. I first posted SeriesGuide to Google Code and then the Google Play Store in 2010. I later moved it to GitHub 2011. My work got more serious during my computer science studies at University. Once I started using GitHub, I added more libraries that SeriesGuide uses and I contributed to other projects on there as well. GitHub really accelerated the SeriesGuide development.

Google play store java embedded database java object database livedata android Mobile Database open source database software qsl alternative SeriesGuide sqlite alternative

SeriesGuide Statistics Screen

Dorian: Did having access to other Open Source projects help you develop SeriesGuide?

Uwe: Of course, it tremendously helped. I guess SeriesGuide is probably 80% other libraries, it’s Open Source so you can go check. Some of the API integration with the TV show database I used back in the day was an Open Source library, so I built on top of that. I then replaced it with my own later. Also if you know Jake Wharton, the Keynote speaker for Droidcon Berlin this year, he was one of the early contributors to SeriesGuide and I used some of his libraries in the beginning like ActionBarSherlock. Then later the networking and logging libraries he was working on. Obviously I used the Android Open Source libraries once they came along. SeriesGuide would not exist without Open Source software.

Dorian: Why did you choose Open Source as the foundation for your paid app?

Uwe: It started as free and Open Source at the beginning on the Google Play Store, because I was just a computer science student and didn’t have the need to make money. It was also rather complicated to charge money, because you have to set up your own company. Around three years after I posted it to the Play Store, due to people suggesting that I charge money, I started developing extra paid features, such as notifications, theming, and then later the syncing component.

Google play store java embedded database java object database livedata android Mobile Database open source database software qsl alternative SeriesGuide sqlite alternative

Shows on SeriesGuide

Dorian: Is the core of your project still Open Source and will it stay like this forever?

Uwe: The whole app besides the small server component is public domain. And the spec for the server component is open, so you could build your own if you wanted to.

Dorian: What is the best thing about SeriesGuide?

Uwe: Honestly, I’d have to say the community. Back in the day I had a few people who really pushed me to improve the app, like Jake Wharton, Craig, Chris, and other friends. They really helped me get SeriesGuide off the ground. Without them I would have fixed a bug or two, and then would have moved on. Because of the continuous requests and a growing community, I had to keep going and make it better. And without the community paying for the app, I wouldn’t have the means necessary to continue working on it.

Dorian: What do you dislike about Open Source?

Uwe: Honestly, in the beginning I thought open sourcing would be risky because someone could copy my app, slightly modify it and then publish it, taking credit for my hard work. Because of that I have a separate private repository with new features that I hold off publishing for a few days. But if I remember correctly, this only happened once and was not an issue because the developer didn’t continue development. I am not 100% certain it was a copy, but the code looked very similar to mine. Right now, I don’t think this is an issue anymore. If people use my app they expect my updates because I maintain the app. If somebody copies it, they don’t have my work power and knowledge.

Google play store java embedded database java object database livedata android Mobile Database open source database software qsl alternative SeriesGuide sqlite alternative

Uwe’s contribution to SeriesGuide on GitHub as of July 6th, 2018.

Dorian: How do you manage your time between developing Open Source projects and your work?

Uwe: I work Mondays and Tuesdays on my main job, kind of as a backup. The rest of the week whenever I have time, I work on SeriesGuide and related Open Source projects. Of course it never ends up being three days. If somebody wants to contribute, I welcome pull requests. I also allow people to translate the app into their language. If somebody has a bug to report, the easiest way to do that is on the website. If people want to contribute code, they can go to the GitHub contribute file which lists everything you need to know.

Dorian: Do you have more features in mind right now?

Uwe: There’s a feedback site where people can request changes, and there’s no shortage of suggestions! I also have ideas in mind, but some things are bigger and I don’t want to do them right away. It’s a constant struggle to get things done. I am not out of ideas; it’s more of a time problem right now.

Dorian: You have a very good time structure, which is encouraging. How hard is it to turn an Open Source project into a profitable business? How did the community react that you have built a business with paid features on top of an Open Source project?

Uwe: The overall reaction was positive. Obviously there are some people that aren’t happy with the presence of paid features. I always tell them that the app has no ads in the free version and you can do pretty much everything except for some convenience features. I would say that for most people this is not an issue because the basic functionality of the app is still freely available. One of the early complaints was that I charge too much money. So in the beginning I was charging 1€ as a one time payment for all access, then increased prices to 3€ per year or a 7€ one time payment. I explained this was to support myself and future updates, basically development time, and most people understood that. I clearly mention that inside the app, paying is not only to get some features but also to support me and future updates. So far most people like the idea and buy into it. Obviously, if you look at the share of paid vs free users it’s nowhere near something like 50/50, it’s way less. But I have a core set of users who believe in the app and support it financially. So far this method has gone well. I am also pushing people towards subscriptions now to secure future development.

Google play store java embedded database java object database livedata android Mobile Database open source database software qsl alternative SeriesGuide sqlite alternative

SeriesGuide X Pass

Dorian: Do you think the complaints came mostly during the shift from free to some paid features?

Uwe: Yes. In the beginning some people were upset, but as I only made convenience features paid, it wasn’t a huge issue. That is also a takeaway for me: don’t have a free app and then suddenly make half of the features paid, because then users will get upset. I was very careful to only make new or some convenience features paid. Or when I made the previously free theming features paid, I made an effort to spruce them up before. But features like notifications and server syncing were new and weren’t available for free before I implemented them.

Dorian: Do you have any tips for developers that are starting with their Open Source projects or are thinking about open sourcing their code?

Uwe: The best thing you can do for your project is to Open Source it, or in short: put it on GitHub. If you don’t put it online, people won’t find it. Another good way to get traction is to contribute to other projects so people know you exist. And then if you ask for help or feedback about their library you are using in your project, people will get to know your project and maybe look at it. Contributing is a good way to get into the community and be noticed. Give and be given, right?

Dorian: Now we have some fun fact questions. First, what do you think about Microsoft’s acquisition of GitHub?

Uwe: I don’t really care, because Microsoft has done some great things for the Open Source community. Azure runs Linux now and they have their own Linux operating system. It’s still good to know that there is the Open Source alternative GitLab that people can switch to if needed. However, it’s sad that things get monopolized into those big companies. In the end, we are maybe going to end up with only Microsoft, Google and Amazon. GitHub sold out, but we’ll have to see what happens.

Dorian: Do you have a favorite book, film, or game?

Uwe: I’m currently reading the Expanse series, which is also on TV. But my favorite series is the Culture series from Iain M. Banks. That blew my mind. For TV, there’s so many options. I generally like science fiction. I recently watched Killjoys and Altered Carbon which were both really interesting. Star Wars Rogue One is my favorite recent movie. If you want to know what I’m watching, follow me on Trakt.tv, a tracking service similar to SeriesGuide, but web-based, that SeriesGuide also integrates with.

Thank you Uwe Trottmann for the interview, and thank you for reading! 

If you enjoyed this open source interview, sign up for our newsletter! We are going to be conducting more interviews like this with Open Source Developers.

We would like to point out that SeriesGuide is not affiliated with ObjectBox

Read more articles

Google play store java embedded database java object database livedata android Mobile Database open source database software qsl alternative SeriesGuide sqlite alternative