Develop Reference

Android: store data locally or not?

My Android app is fetching data from the web (node.js server).
The user create a list of items (usually 20-30 but it can be up to 60+). For each item I query the server to get information for this item. Once this info is fetched (per item), it won't change anymore but new records will be added as time go by (another server call not related to the previous one).
My question is about either storing this info locally (sqlite?) or fetching this info from the server every time the user asks for it (I remind you the amount of calls).
What should be my guidelines whether to store it locally or not other than "speed"?

You should read about the "offline first" principles.
To summarize, mobile users won't always have a stable internet connection (even no connection at all) and the use of your application should not be dependant on a fulltime internet access.
You should decide which data is elligible for offline storage.
It will mainly depend on what the user is supposed to access most often.

If your Items don't vary, you should persist them locally to act as a cache. Despite the fact that the data mayn't be really big, users will welcome it, as your app will need less Internet usage, which may lead to long waits, timeouts, etc.
You could make use of Retrofit to make the calls to the web service.
When it comes to persisting data locally within an Android application, you can store it in several ways.
First one, the easiest, is to use Shared Preferences. I wouldn't suggest you this time, as you're using some objects.
The second one is to use a raw SQLite database.
However, I'd avoid making SQL queries and give a try to ORM frameworks. In Android, you can find several, such as GreenDAO, ORMLite, and so on. This is the choice you should take. And believe me, initially you might find ORMs quite difficult to understand but, when you learn how do they work and the benefits they provide us, you'll love them.

What is the best way to store MySQL database for Android apps

I know this is not a type of question that should be asked on this platform, but I really need an good insight from the people who have worked in this field. I want to set up a database for my Android app. My app has no Image or Media data, it's all text for now, like user posts, likes and dislikes. I am thinking of storing all this in SQL tables. I want to perform tasks like auto deletion of entries after a certain time they have been entered. Store likes and dislikes, deletion of posts based on their dislikes, (if dislikes cross certain threshold, I want the post to be deleted.) I was thinking of using PHP and use hosting from a basic hosting provider like, hostgator or something like that. Though I am worried about the performance. For now I don't expect large no of users, only few hundred a day. But they will be interacting with the database all the time for eg, liking a post, disliking a post etc. It would be really nice if someone could guide me into right path. Thanks!!

You need to develop web services for doing that.According to me rest api is best for the task you wanna do.
check the link for demo.
http://www.androidhive.info/2014/01/how-to-create-rest-api-for-android-app-using-php-slim-and-mysql-day-12-2/

You could use the inbuilt SQLite database which is standard in android development or you store them in a backend on your server on a MySQL instance and the app can access your data over a restful webservice.

Copying a local Database and mailing it.

I have made an application which is about pets, at first I had kept the database local to the phone, however as new features arrive I want to make it a network based application with remote database. However I have around 500 downloads on the play store and I dont want my previous users to lose data. I came up with an idea of rolling out an update in which I copy all the databases to the SD card and then mail them back to me and update them in the remote database. I wonder if there is a better way to go around this. Help will be highly appreciated.

A better way would be to write a webservice to which you can send the database row by row. The webservice will then update your Server database(s).
This not only prevents duplication of your database between internal and external memory, but it also allows automation and more flexibility in the update process. You can also pause the transfer, and pick up from whichever row was last sent easily.

What would I need to do in order to connect to a central database with Android?

I'm about to build a GPS Spot Finder application with Android and I am trying to decide what requirements are feasible and what aren't. The app would enable users to essentially add different spots on a Google Map. One of the problems would be fetching the data, adding new spots, etc, etc. This, of course would mean the database would have to be online and it would have to be central. My question is, what kind technologies would I need to make this happen? I am mostly familiar with XAMPP, PHPMyAdmin and the like. Can I just use that and connect Android to the database? I assume I would not need to create a website...just the database?
What different approaches can I take with this? Be great if people can point me in the right direction.
Sorry if I don't make any sense and if this type of question is inappropriate for Stackoverflow :S

Create a website to access the database locally, and have Android send requests to the website.

If users are adding spots to a map that only they see, then it makes sense to keep the data local to Android using a built-in database (SQLite). That looks like
ANDROID -> DATABASE
You can read up about SQLite options here.
If users need to see all the spots added by all other users, or even a subset of spots added by users, then you need a web service to handle queries to the database: Connect to a remote database...online database
ANDROID -> HTTP -> APPLICATION SERVER -> DATABASE
Not only is trying to interface directly to a database less stable, but it may pose risks in terms of security and accessibility.
Never never use a database driver across an Internet connection, for any database, for any platform, for any client, anywhere. That goes double for mobile. Database drivers are designed for LAN operations and are not designed for flaky/intermittent connections or high latency.
Additionally, Android does not come with built in clients to access databases such as MySQL. So while it may seem like more work to run a web service somewhere, you will actually be way better off than trying to do things directly with a database. Here is a tutorial showing how to interface these two.
There is a hidden benefit to using html routes. You will need a programming mindset to think through what type of data is being sent in the POST and what is being retrieved in the GET. This alone will improve your application architecture and results.

Why not try using something that is already built into android like SQLite? Save the coordinates of these "spots" into a database through there. This way, everything is local, and should be speedy. Unless, one of your features is to share spots with other users? You can still send these "spots" through different methods other than having a central database.
And yes, you just need an open database, not a website, exactly. You could technically host a database from your home computer, but I do not suggest it.

If you are looking at storing the data in your users mobile nothing better than built in SQLLite.
If you are looking at centralized database to store information, Parse.com is a easy and better way to store your user application data in centralized repository.
Parse.com is not exactly a SQL based database, However you can create table , insert / update and retrieve rows from android.
Best part is it is free upto 1GB. They claim 400,000 apps are built on Parse.com. I have used few of my application typically for user management worked great for me.

Storing Tables of Information on the Android Platform

I have about twenty pages of information that is stored in tables that needs to be stored in my Android application. Each column is a designated stop on a bus route and the column is filled with times that the bus will be at the stop. There is also certain information that needs to be associated with some times, such as if the bus is handicap accessible at a certain time.
Here is an example of one of the tables: Bus Times
I have thought about using a SQL lite as that seems as though it would be able to store these tables quite easily; but when I think of using SQL I think of dynamic data storage and this shouldn't be changing more than once a year.
Is SQL appropriate for this application? Is there a better way to do this?
Thanks,
Rob

I think a database is really the appropriate form for doing this. Data in a database don't have to chance regularly or very often, almost more important is the fact that you can relatively easy extract very specific information from a large data set. So if you need to store the data lcoally I would use a database.
Just a hint for another approach. Did you think about reading this data directly from the website? Judging from the style of this page I don't think they offer a webservice, but maybe you could parse it using HTTP Get? Don't know if the structure changes over time, but this solution would have the advantage that you don't need locale storage and if the data is update you don't have to manually update your database.
Hope could help you