I am developing an Android application. Actually my app is for Societies/Apartments use. And I am using Firebase to store all the data of the app. I have a Firebase database and I want to assign one instance of Database to one society. Like Society A will have one instance of database. Society B will have another instance of same Database. And so on. And master database will have the link of all its instances of database.
How can I achieve it?
I also wanted to know How many instances of a database can we create in Firebase for one project?
firebaser here
The ability to have multiple instances of the Realtime Database is to allow it to scale beyond the capabilities of a single database. This is known as sharding, as key to this approach is dividing your entire user-base into separate shards, where the shards have minimal interaction with each other.
You should consider however if you really need a separate shard for each society/apartment. I recommend studying When to shard your data carefully and see if your usage is really going to go beyond the scalability abilities of a realtime database instance. While technically sharding sounds very possible with your scenario, using shards complicates matters significantly, so you should only use this when it is actually needed.
E.g. you could easily start of by segmenting the data for the societies/apartments into separate branches in a single database instance:
/apt1
users
groups
places
/apt2
users
groups
places
/apt3
users
groups
places
Then if you ever reach the need to shard, you can move some of these apartments into another database instance, and use a master database (or an implicit key mapping, which typically scales better) to tie users/apartments to a database instance.
There is no documented limit on the number of shards. Each database instance is quite literally that: a separate database with its own URL, (possibly) on different infrastructure, etc. There probably is a physical limit to how many instances can be created, but I would again refer back to the previous paragraph: if you find yourself creating hundreds of shards, you're probably using them for more than is needed.
Related
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.
I'm starting to learn Android development, and also have been trying to follow the DDD design patterns. One thing that has me confused is where application logic goes with respect to ContentProviders.
ContentProviders look a lot like repositories to me, but a lot of times I don't want to expose my repositories directly. There may be some additional application logic inside a Service which the repositories/database.
Most of the examples of ContentProviders I find show them accessing the database directly. Is it wrong to have a Service or Application object in between the ContentProviders and database?
For example I'm trying to create a personal finance/budget app (e.g Mint/Quicken etc..). I'm going to have a database of transactions and a corresponding TransactionProvider. In most cases transactions are independent from one another. Yet if two transactions are marked as part of the same "Transfer" there there will be some fields that I will want to keep in sync between the two transactions. If someone changes the category or amount of one transaction, I want to make sure the same values are updated for the transaction for the other account of the transfer.
A ContentProvider can execute arbitrary code on its insert(), update(), delete() and query() methods. They are not necessarily mapped one-to-one with the corresponding database operations, and neither do the structure definitions (i.e. fields) themselves. You could, for example:
Update more than one table when you insert, update or delete.
Keep normalized tables in SQLite, but present a non-normalized interface for querying.
Not store data in a database at all (for example to expose/manipulate the files available in your application's private storage).
&c.
So you can, indeed, include whatever business logic you want in the "backend" of the ContentProvider. In your case that would mean updating associated records to keep them in sync.
Just to clarify, since you're starting Android development, it's not necessary to build a ContentProvider if you just want to store data in SQLite -- you can use SQLiteDatabase directly for that. A ContentProvider is generally to expose your own data to other applications, or for specialized cases such as search suggestions.
From Creating a Content Provider:
Decide if you need a content provider. You need to build a content
provider if you want to provide one or more of the following features:
You want to offer complex data or files to other applications.
You want to allow users to copy complex data from your app into other apps.
You want to provide custom search suggestions using the search framework.
You don't need a provider to use an SQLite database if the use is
entirely within your own application.
If you're building a financial data app, you probably don't need one. Do you want other applications to be able to access that data?
I'm working on an Android app for homework management. I'm a senior in college, so my experience on larger projects is very limited, but I'd like to design all parts of this app well instead of just throwing something together. This includes the way data is stored.
We have two main objects/entities: Task and Subject. Even if someone uses the app for the whole time they're in college and never deletes anything, I'm guessing there would be a maximum of a few thousand tasks and a couple hundred subjects (not all subjects would be shown at once). The initial version of the app won't sync data with a server, but this is a definite possibility in the future, so I'd like to design with that in mind. We might also have an option for users to send tasks to each other.
Here are my questions:
Would a SQLite database be the best option for storing the amount of data we're likely to have, or would something like serializing it to XML or JSON then loading it into memory when the app starts work?
I'm used to thinking in terms of objects. This means that if I use a database and it has a Task table and a Subject table, my first instinct is to convert each database table row into a corresponding object for viewing/editing. (The objects' setters would contain validation logic.) Is this a good/helpful/necessary way to think? If not, what is the alternative?
Thanks for your help!
This question is broad so may comments below may not be 100% correct as I don't have all the information about your system.
SQLite is better suited for storing thousands of records than files (be it JSON or XML). This is especially true if your data is not static, i.e. will be changed during the usage of your app (which is the case for you, I believe). You can take advantage of existing functionality for records inserts, updates, deletions, using indexes, etc.
Yes, you generally create objects similar to your database. But you don't usually need to convert each and every record from the database into your objects. You usually query the database for a limited number of objects, depending on what you want to show in the UI. Of course, if you need to show all, let's say, tasks, you need to get them all.
1. Would a SQLite database be the best option for storing the amount of data we're likely to have, or would something like serializing it to XML or JSON then loading it into memory when the app starts work?
Yes SQlite will be the option for you.It will give you a structured format and in future if you want to access data from remote end the same structure of tables can be used without much change in the code.
2. I'm used to thinking in terms of objects. This means that if I use a database and it has a Task table and a Subject table, my first instinct is to convert each database table row into a corresponding object for viewing/editing. (The objects' setters would contain validation logic.) Is this a good/helpful/necessary way to think? If not, what is the alternative?
you can simply execute queries to manipulate data.
But dont forget to encryt your database if you storing it in mobile itself.
I have an Android application which stores user's data in a SQLite database (containing 4 tables). Each table has an Integer Primary Key (Auto-incremented).
To get an idea of the scale:
3 of those tables have less than 7 fields and aren't expected to have more than 10 entries.
1 table having 8 fields, gets roughly 5 entries per day on an average.
What I want is the database to be synced to cloud - for many reasons, including
The data to be in sync across all of user's devices
To collect anonymous data, for research purposes, if the user has opted in.
I realize I would require a multi-tenant database. I want to know an efficient way to do this.
If I use a MySQL database on a web server, would this be efficient? How do I approach multi-tenancy in this case?
Or, do I need to use a cloud service like Google App Engine? (Which is completely new to me)
Yes, you should consider using GAE and its datastore. It also supports SQL, but I think your application is well suited to the datastore.
Your datastore would have 5 'kinds' (these are like tables) - the four you listed above and a User kind. Your four kinds would have a key path that would group them beneath their respective user. This would take care of the multi-tenancy and it would be very efficient: retrieving and writing these groups (defined by the key path hierarchy) is efficient and cheap.
For a quick intro to these concepts of the datastore I recommend this page of the objectify docs.
GAE supports Java, so not only can you use the same language on client and server, but you can also share code. It requires a bit of care when organizing your code (and watch out for logging) but this has considerable benefits particularly if Android is your only client.
i have done SQLite database programming for Android, but i dont know anything about
Content-Provider except this: "As i have referred Android Developer page , Android SDK explained about "Content-provider" as it is used to store and retrieve data."
But then,
What is the exact difference between "Content-Provider" and "SQLite Database"?
Which is best to store data, when ?
Any example or helps !!
I found one major difference, as follows:
Storing your data in a database is one good way to persist your data, but there's a caveat in Android-databases created in Android are visible only to the application that created them. That is to say, a SQLite database created on Android by one application is usable only by that application, not by other applications.
So, if you need to share data between applications, you need to use the content provider model as recommended in Android. This article presents the basics of content providers and how you can implement one.
I found this article at this link
Really nice information provided.
What is the exact difference between
"Content-Provider" and "SQLite
Database"?
ContentProvider is a facade -- an API you can implement that exposes databases to other processes. It can be implemented in a way where the data is stored in a SQLite database, but it does not have to be.
Which is best to store data, when ?
That is impossible to answer in the abstract. Generally speaking, unless something is requiring you to use a ContentProvider, just use a database.
I have made many good apps with thousands of users using them which simply used SQLite methods. But that was a while ago and I had to manually write lots of code which now can easily be taken care of by ContentProvider. Back then I was not in favour of using Content Providers because it seemed to only add complexity in the code.
However for last couple of years, as Android has evolved, I have moved to ContentProvider as it saves time and allows you do to more. I now use it extensively. Once you have a Content Provider class written, your life becomes much easier. With ContentProvider I can much easily deal with Cursor Loaders, Loader Callbacks and Bulk Inserts for which I had to write everything manually in the past and still it didn't work as efficiently. Especially when updating the list view, which is now automatically updated thanks to just one notifychange() method. This means now I don't have to type my own listeners and manually updating the content in list views and adapters. Plus, I don't need to worry about opening and closing of databases or worry about memory leaks. That's all handled by the Content Provider. The only problem which once in a while I face is that that you cannot do some complex queries in ContentProviders. In this case you can still use raw queries and use the old fashioned manual interaction with sqlite.
If you have previously written your own DbAdapter, Helper and Observer, you can safely carry them on to your new apps without spending time to convert everything to ContentProvider. But based on my experience, I would highly recommend to move to ContentProvider. It'll take some time to get used to it, but once you have got experience with it, you'll stay with it.
UPDATE 2017
I have now switched to Realm, a much better way to use databases on any platform. Spend a few hours learning it, and save countless hours in your app development career.
1. Content Providers are not Thread Safe
By default content providers are not thread safe. If you have multiple threads using a content provider you can see many different exceptions being thrown and other data inconsistencies. The easiest way to fix this is to use the synchronized keyword on each of the public methods exposed by the content provider.
In this way only one thread at a time can access these methods.
2. Play nice when doing lots of writes
I have the need in the new Serval Maps application to import data from binary files into the database used internally by the application. In order to do this and play nice with the rest of the application it is best to:
Spawn a new thread to undertake the import so other threads are not adversely impacted, in particularly the thread in charge of updating the UI; and
Pause briefly at the end of the each import to give other threads which need to use the synchronized methods more of a chance.
3. Content providers force you to think laterally sometimes
The way that content providers in Android work is to provide a layer of abstraction between the rest of your code and the underlying database. This is mainly due to the fact, as far as I can tell, that content providers can access data from places other than databases.
This means that you can’t execute raw SQL queries on the underlying database and you need to specify the various components of a SQL query using variables passed to the various methods such as the query method. If you have a task that doesn’t fit into the way that SQL is handled by a content provider you have two options:
Think laterally about the query, maybe you can get the data that you need by alternative queries and accessing the results from the cursor; and
Use a URI for accessing the data normally and a special URI that is matched to a specific query for those tasks that don’t have alternatives.
Content Providers are used when you want to share your data across applications.
If you have a database attached with an application and you want another application to use some data, you can implement a content provider that exposes the data
The main difference is: when your app needs to share information to another apps, use Content-Provider. SQLite only storage data for the app who creates it
I read this answer while looking for same doubt, so thought of sharing it.
it states -
It's good practice to provide the extra level of abstraction over your data to make it easier to change internally. What if you decide to change the underlying database structure at a later time? If you use a ContentProvider you can contain all the structural changes within it, where as if you don't use one, you are forced to change all areas of the code that are affected by the structural changes. Besides, it's nice to be able to re-use the same standard API for accessing data rather than littering your code with low-level access to the database.
So, using a content provider would be a good idea.
Think of advanced Content Management Systems. Each object (page, image, news article, event item, etc.) has a content, an address, user permissions, and ways to interact with it from different parts of the system. Content Providers do that for Android. You can now share files or images you may have stored in your application. You can also create custom sharable objects, like bussiness contacts, editable notes, etc. And specify security and the default application to deal with such object when you open them from any other application.
One difference is that Content Providers have platform support for Content Observers. Your going to need to implement your own Observable pattern for a SQLite database.
How to automatically re-query with LoaderManager
ContentObserver for SQLite?