Share your experience using ObjectStore

We use SQLite to store data locally within our mobile applications.

We use it for storing data within the local storage of the mobile application. That's its primary purpose.

A potential drawback is that the database file stored within the application's local storage could be accessible to users. 

When you build a mobile application with SQLite, the database file is often included in the assets folder. When the app is installed, a folder is created in the device's local storage. 

In older Android versions, it was possible to access that database file directly from the local storage. I'm not sure if this is still a concern with the latest Android versions like 10, 11, or 12.

I have been using it for three years. 

I haven't encountered any problems in my use cases. So, it has been a stable product for me. 

Usage depends on project requirements. Some applications need local storage, so developers might use SQLite; others might use something like Entity Framework. It varies, and sometimes, client preferences also play a role.

There might be over a hundred end users. 

SQLite was a standard approach for storing data locally in mobile applications. That's the main reason for its adoption.

The initial setup quite simple. You download the setup files from the official source, install them on your Windows system, create a database, and then copy that database file into your mobile application. The process is clear and easy to follow.

SQLite is primarily used for embedded storage in mobile applications.

It is not expensive.

There are both pros and cons to SQLite. 

• On the positive side, it's easy to use. 
• However, a potential drawback is that the database file stored within the application's local storage could be accessible to users. 

You need to consider both the advantages and the potential security concerns.

Overall, I would rate the solution an eight out of ten. I would recommend using it. 

In this organization, we use SQLite as a local database stored within the mobile applications themselves.

SQLite's small footprint has positively contributed to our project's performance overall. SQLite has helped us achieve exactly what we need in terms of our requirements and goals.

In my experience, SQLite is good for scenarios where you need offline capabilities within your mobile applications. Sometimes, you want data to persist within the app even when there's no internet connectivity. To avoid showing blank screens, we can use SQLite to store data locally and then sync it with the cloud database when connectivity is restored.

There are some difficulties on the server side. When syncing data with databases like SQL Server or Oracle, SQLite requires a kind of double effort. 

We need to implement business logic either on the API side or within the mobile application for proper data syncing – both when pushing data from the server and when syncing incoming data. It would be an improvement if SQLite could connect more automatically. Right now, there's no automatic syncing approach built into SQLite, so we have to write code to fulfill that requirement.

There should be an automated thinking approach in SQLite. 

I currently work with an organization that uses SQLite. 

In my experience working with SQLite for the last six years – across three or four applications – I haven't found any major issues that would cause problems for clients or developers. 

It's a very useful plugin. We don't see other replacements for it right now. There are file-based solutions, but for local storage as opposed to cloud-based, I find this to be a stable product.

It is a scalable product. We don't always know who else might be using SQLite, as it's often adopted based on specific project requirements. If a project needs local data storage on mobile devices, then SQLite is the go-to choice. There's good adoption of SQLite in my company. 

So, we might have more than five end users using this solution. 

When I first started working with SQLite, I had concerns about how to sync data – specifically, how to sync when an application goes from offline to online. I had some questions initially, but later I found the solution.

Neutral

I'd consider myself more of a full-stack developer.

I have over ten years of experience in the IT industry, working with technologies like ASP.NET, .NET Core, and, more recently, mobile application development – specifically Android and iOS using Xamarin and MAUI.

In the last six years, I've worked extensively with technologies like CRM, Jamf, Jamf Native, MAUI, SQL Server, SQLite, .NET Core, and others. I'm also familiar with various project management methodologies.

Anything seems difficult when we start. However, it's not overly difficult once you start working and thinking about the particular model or requirements. So, initially, it might seem a bit challenging, but overall, it's easy.

It's a good value, especially considering [SQLite's open-source nature].

I'd recommend using SQLite, especially since I already know this particular plugin. If you're familiar with SQL Server concepts – tables, queries, and so on – then I definitely recommend SQLite.

It is easy for a beginner to learn to use SQLite. If you have knowledge of SQL Server, understand how to write queries, and have a basic grasp of database structures, then it's very easy to pick up and use in your project. It's straightforward.

Overall, I would rate the solution a six out of ten. I've not encountered major limitations. While we've had some questions, we've always found solutions.