Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
What are the differences between a local database and a server database?
I think you know the basic answer:
-Local Database: the database is located on the User's Android Device.
-Server Database: the User's Android Device must connect to an external server to access the database.
Here is my real world example of my usages of both:
I was tasked to develop an app for "Secret Shoppers" employed by Sam's Club. Basically they had to go to different grocery stores, and report prices using the app, and that data must be saved in Sam's Clubs Databases (On THEIR Servers). Here was 'the catch', not every Secret Shopper had a tablet with a 4g network, thus could only transfer the data while they were on WiFi.
So what I did was create an exact clone of their databases using SQLite, every time they 'submitted' a report of products and prices:
First I checked that the User's Android Device had internet access.
If they DID HAVE internet at the time of submitting, the report would be sent to Sam's Club servers as normal.
If they DID NOT HAVE internet at the time of submitting, the report would ONLY save on the LOCAL Database on the Android Device with a FLAG indicating it has not been sent to Sam's Club Servers.
When the app is run with internet, it will then send the those flagged reports to Sam's Club Servers.
So basically, I used a LOCAL Database that SYNCS with a SERVER Database each time the app is run. Hope this helps with the 'picture' you are looking for in terms of Local vs Server in Android Development specifically.
Local database would be SQLite in android. It can be accessed locally only.
A server database is hosted in a remote server. Basically It can be accessed by any client in the web.
An example of local use would be for example storing credentials or information that you don't want/need to share with another user.
You can use local database to create a backup of the server database in order to access your information even if you don't have a reliable internet connection o make your app faster by not downloading data every single time you need it and using the one store locally.
For example Facebook is saving everything in a server database so you and millions people around the world can accesses to that information.
The local database is Local (offline) & the server database is online
This is the biggest difference, It all depends on your app style
If you want a dynamic application you should use online database
else
you can use both of them for static data
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 1 year ago.
Improve this question
i am developing an android application which needs to connect with an online MySQL database. I have created an amazon aws account and set up an RDS MySQL database but i don't know how to send http requests from android app to database.
I think i need to create some web services in order to send http requests but is that possible when using amazon's rds service?
Thank you all for your answers.
From a security perspective, it is not advisable to connect mobile apps directly to a database.
Mobile apps should connect to your application back-end that would perform authentication and determine what data the mobile user is entitled to access. The back-end can then retrieve the appropriate information from the database and return appropriate data to the app.
This also separates your application logic from the storage layer, allowing you to change information that is sent to/from the mobile apps without having to modify the code in every copy of the mobile app. You could also swap-out the database without having to change the mobile app.
it's probably not the best design to have clients connecting to your database remotely. The best thing to do would be to put a REST API on AWS that interacts with your database.
So, the scenario is i have a MYSQL database stored on local system on SQL server 2008 which is turned ON 24/7 and is connected to internet. there is no API, no web services.
Now, i want to develop a android application which can fetch data from that server. and that app should be able to get the data no matter from where the app is getting accessed.
i somewhere read that it is possible by connecting via IP address but could't find proper reference for it and i never done it before.
i can connect android app if the database is stored on cloud but this one is on local system.
so tell me the possible ways to connect android app with local database. i've already spent plenty of time in searching the solution but nothing is helpful.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
I'd like to use just a single method of persistence in my app, and am using Cloud Firestore for my premium/paying users.
Is it possible to also use Firestore in offline only mode for free users so that I don't incur costs?
Cloud Firestore is an online database that continues to work when you're offline for short or longer periods of time. But it's still primarily an online database, and should not be used as a fully offline database.
One reason for this is that Firestore keeps the local mutations in a separate queue until they've been committed to the server. When a query/read hits the local data, the Firestore client combines the cached reads that it got from the server, with the local mutations. As the queue of local mutations grows, this operation gets slower. As long as the client occasionally synchronizes the data to the server, this slow down won't be significant. But if you use Firestore as a fully offline database, it will become prohibitive over time.
For a good explanation of how the Firestore client works under the hood, have a look at these (long) code comments in the Firestore JavaScript SDK:
the persistence class, which is responsible for storing the data on the local disk
the local store class, which handles (a.o.) the reading from both the local cache and the local mutations.
If you need offline database, do not use Firebase. Firebase will cost you huge money in the future. Read this full article from an unhappy Firebase customer with 3+ years Firebase usage experience.
Sadly, We've been using Firebase for our Goal Meter app (Android and iOS), Weight Meter app (Android). Our users have grown over years and now we have about 100,000 active users for our Goal Meter app. About %95 of them are free users. The cost of Firebase database is growing rapidly and we cannot prevent free user data from syncing into Firebase online database. We've decided to change to another company for our future project.
Don't make the same mistake that we did. If your app needs offline database (I guess most apps do need it), then by any means avoid using Firebase. Move to other solutions such as AWS.
I've already contacted the Google Firebase team regarding this ridiculous issue. I can only imagine one scenario why Google Firebase team is preventing the full offline capabilities. The reason is because Firebase team is greedy. After all, if the database is offline, how can they make you pay? We've been in love with every single product from Google. We even produce Android version before iOS one, in order to support Android and Google. Firebase product is amazing, but this "purposefully" disabling offline capabilities is a shame. A shame for Firebase team and Google in general.
An alternative approach is allow users to create accounts and offer a trial period. If they decide to sign up for premium access, all the data is already synced to Firestore. This doesn't solve your want to have local only access, but could be a different option you could take.
For my best knowledge so far, the biggest difference between SQLite and MySQL is that it does not require a server to run, as SQLite stores data in a database file in each device.
The question rising from this part is..
Let's say I created an Android app which simply contains login and signup features. By installing this app in one device I create an ID with a password (let's say the ID is ricoangeloni and the password is 1234).
If I install the app in another device, is it still possible to log in with the pre-made ID? This is still very confusing, as I am probably not sure if the clients are sharing the centre database.
The answer to this question depends on where the database is located (regardless of whether you're using SQLite or MySQL to access the database). If you're storing the database on the Android device, then that database is specific to that device.
If the database however is stored on some internet-facing computer (doesn't have to be a "server" per say) and your app interacts with that hosted database, then an account created in that database is accessible from anywhere, not just your app. A website for example could also use the accounts in that database for login purposes.
The approach of housing the database on the device does have its advantages, namely you don't need to have a dedicated machine to host the database. But, if you wanted to have one database with all of the accounts and use that for authentication purposes, you're going to need to put that database on the internet.
This question already has an answer here:
Proper architecture for iOS connecting to database?
(1 answer)
Closed 9 years ago.
I want to develop a native App for Android and iOS. The App communicates with a MySQL DB on an online server.
What's the best way to do this? Store the DB in the App or communicate with a live DB on a server right within the App? Is it secure to connect right from the App to the DB?
When I need an app to communicate with a database, I use a server-side script (written in PHP).
Sample flow:
App performs an HTTP POST and includes all required variables in the
header.
The script on the server queries the database.
The script returns the data as a JSON/XML array.
This sort of a configuration has several benefits, the most important one being that you do not have to distribute your database passwords - even if you encrypt them, it is a risk. You can also monitor/record/refuse connections with ease.
Finally, this implementation is platform-independent and will work on both Android and iOS.
This technique has worked successfully for me however, YMMV.
The only way you would be able to store the database within the app was if it was a flatfile database.
You should not have any problems connecting to a MySql database on a server and if you want extra security encrypt your password and unencrypt it when you need to use it.