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
Related
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.
I am currently developing an application that provides some temporary static, but often changing data.
You can think of it like a telephone book. Most of the entries might never change, but there might be cases where people change their telephone number or move in/out. The dataset isnt large but has to be available at any time.
My first thought was to implement a clientside-SQLDatabase which queries a backend in certain intervals asking for updates (stored in another database on the backend server). If there was an update since the last query, the updated data will be send over and stored in the local sqldatabase.
Now I stumbled over this interesting looking database model Couchbase. Altough I dont see through it completly by now, if I got it, I can use it to keep the client-side database in sync with the servers database. Is this a usecase for couchbase or should I go with another strategy?
Thanks in advance!
That's a perfect use case for Couchbase. You'll want to check out Couchbase Lite (https://github.com/couchbase/couchbase-lite-android) and the Sync Gateway (http://docs.couchbase.com/sync-gateway/).
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.
We've got an android app and an iPhone app (same functionality) that use sqlite for local data storage. The apps initially come with no data, then on the first run they receive data from a remote server and store it in a sqlite database. The sqlite database is created by the server and the apps download it as one file, which is then used buy the apps. The database file is not very large by today's standards, but not a tiny one either - about 5-6 MB.
Now, once in a while, the apps need to refresh the data from the server. There a few approaches I can think of:
Download a new full database from the server and replace the existing one. This one sounds like the simplest way to deal with the problem were it not for a repeated 5-6 MB downloads. The apps do prompt the user whether they want to download the updates, so this may not be too much of a problem.
Download a delta database from the server, containing only the new/modified records and in some form information about what records to delete. This would lead to a much smaller download size, but the work on the client side is more complicated. I would need to read one database and, based on what is read, update another one. To the best of my knowledge, there's not way with sqlite to do something like insert into db1.table1 (select * from db2.table1) where db1 and db2 are two sqlite databases containing table1 of the same structure. (The full sqlite database contains about 10 tables with the largest one probably containing about 500 records or so.)
Download delta of the data in some other format (json, xml, etc.) and use this info to update the database in the app. Same as before: not to much problem on the server side, smaller download size than the full database, but quite a painful process to do the updates.
Which of the three approaches you recommend? Or maybe there's yet another way that I missed?
Many thanks in advance.
After much considerations and tries-and-errors, I went for a combination of options (2) and (3).
If no data is present at all, then the app downloads a full database file from the server.
If data is present and an update is required, the app downloads some database from the server. And checks the content of a particular value in a particular table. That value will state whether the new database is to replace the original or whether it contains deletions/updates/inserts
This turns out to be the fastest way (performance-wise) and leaves all the heavy lifting (determining whether to put everything into one database or just an update) to the server. Further, with this approach, if I need to modify the algorithm to, say, always download the full database, it would only be a change on the server without the need to re-compile and re-distribute the app.
Is there a way you can have a JSON field for each of the tables? For instance, if you got a table named users, have a column named "json" that stores the JSON for each of the users. In essence, it would contain the information the rest of the fields have.
So when you download the delta in JSON, all you got to do is insert the JSON's into the tables.
Of course with this method, you will need to do additional work in parsing the JSON and creating the model/object from it, but it's just an extra 3-4 small steps.
I will recommend approach 3, because app will download the json file more fast and local db will be updated more easily avoid overhead of more internet usages.
Just create a empty db initially according to server db and then regularly updated the same by fetching json
I have created a database for my application. I will use the data in this database, again and again. I just want to know the preferred way to do this.
One way is to query the database again and again, and the other way in my mind is to have multiple ArrayList for different fields, or something like that, to store data in the start of application in these Lists and then access these Lists whenever I need data(sort of a disconnected mode e.g. DataSets that we have in .Net).
So, which is the efficient way or is there any 3rd better way?
Is your database local, local and external (shipped to your apk) or remote? If it is local then you can query the database everytime you need. Because you rather have operation with your CPU than keep memory occupied. When it comes to remote database than you can implement various ideas about keeping the last query in case of disconnection, then on the next query release the last query results (not good to me, because you might have milion of results, which will occupy so much memory [scenario]), or save the query results (get result - translate into query for your own database = long process). Or you can query again the database again and again, with least effort so many results. I hope you get my idea and will serve you.