Android: using Firebase to store static data - android

I'm developing an android application that will allow users to find informations about the streets in my city. They will be able to register and save some streets as "favourites".
My question is, how can I use Firebase to store the streets data considering that they won't change overtime?

The Firebase data model is not well suited to storing arrays (or Java List objects). See this blog post explaining the behavior you get. Instead of storing a List, follow the Firebase documentation's approach for storing collections. This will indeed store it as a map, which is the correct approach precisely .

That depends mostly on how you want to read the data.
If you always load all of the street data, then you might as well store it as a file on Firebase Hosting. That'll be a lot cheaper, and perform better (since the data is cached on a CDN).
If the app loads parts of the data, but it's not very dynamic, you could split the data into multiple files and still store those on Firebase Hosting.
If users sometimes update the data, but it's still hardly queries by the apps, consider storing it in Cloud Storage through the Firebase SDK. The files are available to all of your users that way.
If you want advanced querying of the data, consider storing it in the Firebase Realtime Database or in Cloud Firestore.

Related

How to keep firebase realtime database in sync with firebase storage, the standard approch to this problem of two nested queries?

How to keep firebase realtime database in sync with firebase storage? I am trying to store images in firebase storage.
The current scenario
a POJO (which contain 3 images placeholder link) is saved in the realtime database.
Then the 3 images are uploaded in firebase storage and on successful upload the respected placeholder links in the realtime database are updated.
Now the problem is that sometimes when the user deletes the project in between the POJO is deleted from firebase but the links are still updated.
Is there a better way of doing this ? or is there any standard approch? Thankyou for your time.
There is not a standard approach to this, and it can't be solved by simple configuration. You will have to get creative and implement something that meets your specific needs.
One thing you can do is use Cloud Functions triggers to mirror and delete data between the two products, so that one data in one is added, modified, or deleted, that change is reflected in the other product. It would take at least two triggers, one database trigger, and one storage trigger, to make sure changes in either product are mirrored to the other product. You might also need some additional process to remove or correct invalid data periodically, if that is a concern.

What is the best way to store app data and load it in app?

This is just a information question. I'm new to Android app development and currently I'm working on my first app and and it is ready for the release. Now I'm concerned about how to handle heap of users and where to save all their details my app is a service booking app so it needs to save all the order details products details and lots other stuff.
Currently I'm using cloud firestore to load and save all the data of app. But I'm having some issues like without authentication it won't allow users to access some of my data and other. I wonder how large apps save their data and load them perfectly.
I wish someone will help me how can I save all my app data and load them perfectly in app. And suggest me for a best way to manage large user base. And other stuff.
First of all, firestore is good option if you don't have complex backend logic on the database. For simple CRUD operations on data firestore is a good choice but as you said you have a bulk of data then you must go for the Backend database and then connect your database with Rest API. So that all your complex queries will be done on the backend and you can simply consume your API in the app.
If you have lots of data from different users, maybe you should use a central server(DB), something like Postgres or MySQL should work fine.
At the same time, you can also do some sort of caching to accelerate the fetching process, like create a small database locally(you can use Room) to store some user specific data.

Firebase Real-Time database vs Storage

Im using Real-Time database to storage my users Profiles.
Each of the profiles can contain multiple rooms, where each of them contain their own picture creating a quite complex structure.
Here an example:
To make it easier to store the pictures to the corresponding profile, and room I am changing my pictures Bitmap in android to a String before I parse the object into the Database, and then when I get the object back I transform the String back to the Bitmap.
I was just wondering if this comes with any down cost in the future. Or if this implementation is safe where we put more data in the databases.
With your current database structure as-is, you will run into problems.
With the Realtime Database and this structure, everytime you request "user/SOME_ID", you will download all of the data below it - including your serialized images. Consult the database structure guide for information on how to flatten your data out so this doesn't occur.
Furthermore, I would recommend making use of Cloud Storage for Firebase to store your images in their native binary format rather than serializing to Base64 taking up ~30% more space. Like the RTDB, storage can be secured with rules if you store the files in structured locations like "user/SOME_ID/roomImages/ROOM_ID/..." or "roomImages/ROOM_ID/..."
I think that's not safe and bad implementation because u save users data in a third party service even without any encryption rather than storing it in your back-end which you have full control on it.
if I was A user for your app I didn't like that but if this app just for testing something there is no problem.

What is the best way to store data for an information app in Firebase?

I need to do a application that incorporates a database and I'm thinking about using the Firebase Realtime database.
Basically the application is an information app. It has different categories, Shops, Restaurants, Attractions, ect. I've almost completed the Udacity course on firebase and It can do what I need, I'm just not sure it's the most efficient.
They way they explain the database is structured is having a key so my key would either be Shop, Restaurant or Attraction. Below the Shop key there would be "Shop1","Shop2","Shop3", ect. Now this is where my problem comes in, inside shop1 I'm planning to have the shop name, longitude, latitude, description, and other details about the shop. Each time I want to add a new shop I'm going to have to add a child of the shop then under the new child I'm going to have to manually type the key and value.
This will get very time consuming and I was wondering if this is the correct way of adding data to the database ?
Thanks
Is Firebase the best way to store data for an information app?
This question is primarily opinion based, but since Firebase gives you so many choices under the hood, it is becoming a pretty decent service. Being scalable and the quick response of the database is a great option.
Read more about a good Database Schema here and about populating the database, you can write cloud functions and that would be a pretty advanced level of implementation.
May be your question is "What is the best way to store data for an information app in Firebase?"
In your case, it will be difficult to save sequential key without keeping track the number of shop.
I would rather suggest using push(shopModel). If you're using push, the key will be automatically generated and it's guaranteed to be unique and order by time inserted.

Java POJO classes and No sql Datastores

Sorry if this question is very basic but I started seeing no sql storages for an android app and I found App engine endpoints and servlets that as far as i understood, expose an api to do CRUD operations.
The thing that it is difficult to grasp for me is the format of the objects stored and it's efficiency. I read that by using libraries like objectify/gson the objects are stored in json.
Now, suppose I have a class Person that has an attribute Friends that is a list of Person. If two different persons share the same friend it will be stored in two different json objects, duplicating the information. Should I make a different class for the storage that keeps the id of the friends and then when loading a person find his/her friends from a hash map of Person? But that would imply requesting all the Persons to the Web service to construct that map even though I only want to find a Person without friends.
Another way would be to make the 'query' in the server side, return the friends objects of the person that is requested and put them in a hash map for future 'queries' of other Persons. In this way I would transfer less data each time but i would consume more times the webservice which can lead to exhaust the daily request limit quota.
Again sorry for the beginner question. I would appreciate any directions, patterns to solve this problem, in a nutshell how to efficiently -in the sense of space- store objects and efficiently retrieve them -in the sense of the amount of queries and data transfer from the web service- in a nosql database.
Indeed Google Cloud Endpoints will allow you to do CRUD operations through one or more API(s). But, as detailed in the documentation (https://cloud.google.com/appengine/docs/java/endpoints/) it allows you to do much more than that, e.g. "all of the services and features available in App Engine, such as Google Cloud Storage, Mail, Task Queues" etc.
You can use Objectify when the back end of your endpoints is Datastore. Objectify is the open-source API for Java which is recommended by Google. However, note that the data is not store as json but as Data objects that are called "Entities" which can have properties of different data types. See https://cloud.google.com/appengine/docs/java/datastore/entities for more info.
The approach to NoSQL database is very different from relational database when it comes to data modelling. You should not care about normalizing your data and storing the same data multiple times is quite a common approach.
In your case, if two persons share the same friend, you would save the friend information two times, in each person entity. In such a way, when you will query the list of friends for one person you just have to get the person entity through Objectify in your endpoint: it will include the list of friends and it will automatically be transformed to JSON when sent to the front-end.
I would suggest you try the Google examples (https://cloud.google.com/appengine/docs/java/endpoints/helloworld-java-maven) or even better follow the Udacity MOOC which will help you understanding the entire stack https://www.udacity.com/course/developing-scalable-apps-in-java--ud859
The tutorials from Romin Irani are also an excellent entry point to this technology https://rominirani.com/google-cloud-endpoints-tutorial-part-1-b571ad6c7cd2#.p4h8rmkt3 There are tutorials for Eclipse as well as Android Studio (I recommend using the second one).

Categories

Resources