I'm currently making an app for myself to collect battery temperature data, and storing it in a Firebase database. However, if I want to run the app on a different device, they'd be writing to the same area at the same time, and hence it'd be hard to distinguish which device is which in the database. Is it possible to add some sort of unique device ID so that I can distinguish data collected from multiple devices at the same time, being stored onto the same Firebase database?
You can generate a random UUID which is essentially guaranteed to be unique, then remember/persist that in your app on that device. You're not saying what platform you're coding for, so it will be up to you to find a library to generate one. This should be pretty easy. With Java, there's a UUID class that can do this for you.
Related
The problem is as follows. We have 2 native apps (ios and android) connected to a Firestore backend. Our current data model stores the information about the users spread across 5 different collections (profile data, user answers, user legal documents, etc). This means, often times, when we need to query data about the user we need to make several queries and manually join them together to get what we need. It’d be much simpler for us to have all the information stored in a single collection. This is a problem we have now, and as our business will continue to evolve, we will have more situations where we need to change the structure of the data model.
Currently, we use the Firestore API to query the user’s data in the frontend to have real-time updates. ATM we don’t use custom endpoints and therefore we don’t have any kind of versioning in place.
Are there any best practices or strategies to perform such a data model migration without forcing the user to upgrade to the latest version of the app?
We can think of some solutions:
Use versioned-endpoints and forget about real-time updates (decouple the FE from the BE)
Migrate the current data to the new data model while keeping the old collections still actives to serve old versions of the app. Additionally, write some cloud function listeners to keep the 2 models in sync (whenever an old version of the app writes in any of the 5 user collections, copy that data to the new data model)
...
…
The problem of an evolving data model and having several FE’s consuming the data is extremely common. The normal best practice would be to have a versioned endpoint that the FE communicate to, to break the direct dependency on the data model. However, it doesn’t seem like Firebase have a set best practice for this. This sounds a bit strange to us, as it is such a common problem to have, and that Firebase solves so many other common challenges out of the box.
What are we missing?
Related questions:
https://www.reddit.com/r/Firebase/comments/dyhzlv/best_practices_of_versioning_with_a_firestore/
Thanks!
As part of a 'pet project' Flutter app that I am trying to build (in Android Studio) I am looking to add a database of information (possibly with Firebase) for users to use with the app.
My current understanding/capabilities
At the moment, I understand how to (and have already) build a database in Cloud Firestore, where the users can store their own data. A good example of this would be a to-do list app, where the user can create a new item, which is stored in the database with their uid. This remains there until they delete it manually. They are also able to update the entry, such as change the name of the item, themselves in the app.
The aim
I've got a set of data at the moment, which is in Excel format, that has the potential to have up to 1000s of rows. I would like to be able to incorporate this into my app, such that the user is able to query the database, either via multiple dependent drop-down menus, or a search widget.
My question
Is there an easy way to convert a reasonably large set of data, currently in Excel format, into a firebase-type database (such as cloud firestore or realtime database) without having to manually enter all of the data?
For RTDB, you can use use some Excel-to-JSON tool and import that JSON into RTDB. However, I doubt that the exported format will be efficient to use in your app, so you might have to do some transformations (in your language of choice).
If your data is very large (1000s of rows, but... how many columns?), you might have to split your import into multiple smaller imports at different paths of your database.
Doing huge RTDB imports in Firebase console has caused my projects to "misbehave" for a little while, but it goes back to normal quickly, so don't freak out if that happens to you too.
For Firestore, which has no direct JSON import AFAIK, take a look at How to import CSV or JSON to firebase cloud firestore for some ideas.
I'm reading on hash table and data structure, and one question come to mind. Where is hash table implemented? Is it on server code or database?
The resource I've read seems to implement them on the server code, but isnt storing data the job of database? PS: I've havent get to a point of knowing non-sql database yet, maybe that's where my knowledge lack.
Many applications need to store some data internally, even if they're also using or updating data in a database at times. Often they'll even retrieve related data from a remote (across the network) database and have it available in RAM on the local machine for the application to access quickly.
Other times, an application may use a data structure such as a hash table to support some application behaviours that are not part of the business data model, and therefore don't belong in the database. For example, a GUI application might keep help strings to display when the mouse hovers over a widget/button/whatever - they might be stored in a hash table keyed on some GUI object identifier, screen region or whatever the GUI library finds useful to help it display the tooltips at the right time. Another application might keep a table of usernames and activity statistics that it generated by scraping some website - it might display them to the user on demand, or aggregate them or something, without ever saving them down to a database (historic data may be of no value, and it can scrape the website again).
In summary - non-trivial programs tend to use hash tables to provide quick access to the data they consult or manipulate, whether the programs are themselves databases, applications that do also use databases, or applications that run without any database support.
I'm working on a IOT project, where we are evaluating to use firebase. We have a prototype implemented which works fine for real time data. Since the data is critical for client they want to be able to retrieve the data at later point of date. I couldn't find much about a persistent storage in the firebase website, any of you have idea on if we can use firebase alone or do we need to transfer it to you a cloud based store like google cloud store, if so what is the reliable time for which firebase will hold the data. Assuming you choose the right plan.
Thanks
Kamal
Firebase is a persistent database. While you certainly can setup a way to transfer the data to an archive, if you structure your data correctly, there shouldn't be any need to do so. You haven't really indicated what those requirements are, however, so it is difficult to thoroughly answer your question. (If you have one.)
There have been several demonstrations of using Firebase as part of an IoT infrastructure. Consider, for example this presentation by Jenny Tong (#mimming) about doing exactly this.
I have a Xamarin.Forms app that uses a local SqLite database as its source for data. The data is proprietary, so I want to protect it so that if someone gets access to the database file, they would have to decrypt it to access the data.
I also want to limit the number of queries users can make against the database so that at a certain point they have to purchase the ability to use more of the data (in-app purchase).
I want to avoid making network calls as much as possible to minimize impact to the user's data plan and allow the app to work well in conditions where there is poor or no connectivity. So, I want the data stored in a local database (perhaps in SqLite).
I'm curious how different people would approach this problem to protect the data and at the same time minimize network usage.
Here is kind of what I was thinking (if it's possible):
1) Let the user download/install the app.
2) On first load, the app will upload a key based on the device id and the user's current purchase information. Then it will download a SqLite database file that has been encrypted using the uploaded key.
3) When the user reaches their limit of queries, the database file is deleted. If they purchase more data, then a new key is uploaded and a new encrypted database is downloaded to be used.
Thoughts? Is there a better way?
I would suggest SQLCipher! It is a Component within Xamarin (http://components.xamarin.com/view/sqlcipher-for-xamarin-ios) but can also be built from source as it is Open Source (https://www.zetetic.net/sqlcipher/open-source/)
That will totally secure your database :)
UPDATE 8/2/2018 - SQL Cipher is now free and easy to implement thanks to the greatness of Frank Krueger. sqlite-net (https://github.com/praeclarum/sqlite-net) is the defacto sqlite library for Xamarin now (if you're still using the Sqlite.Net fork I recommend going back to sqlite-net as soon as possible as Sqlite.Net has been abandoned) and it now includes SQL Cipher support completely free of charge.
As clb mentioned, SQLCipher is open source. So if you don't want to pay for the component you can download and build the source yourself, then wrap it for use in Xamarin. This is, admittedly, a technically challenging task.
If that's not an option, I would recommend two other options:
Reevaluate your need to store data locally. It's extremely unlikely that you need to transfer enough data to even cause a blip on a user's data plan. And between cellular and wifi, it's not that common anymore for users to be without a connection. It certainly does happen, and there are certain apps where this is very important, but you may have to make concessions if the data is that sensitive.
If you absolutely have to store the data locally, and you can't use SQLCipher, your last real option is to use a cryptography library and encrypt the data itself, rather than the database file. This is less than ideal, typically, for a variety of reasons, but it may be your last resort. PCL Crypt is a PCL capable crypto library that you can look into.
https://github.com/aarnott/pclcrypto