I am looking to add a (local, not online) high scores table to my Android app and I wanted to get some insight on the best way to approach the problem.
I have a list of users (right now being saved out to a file and read back in as an array of User objects), and the high scores need to reference this data to populate the table with the user's name and photo, etc.
For the display, I think a TableLayout would probably be my best option. I can make columns for picture, name, score, etc.
For the information itself, I'm thinking maybe a SQLite table would be the best way to organize my data? If so, then it may be worthwhile to move my user data to a SQLite table as well so I can ensure the data is cross-referenced properly.
Does anybody here have any helpful information or opinions on this? Thanks.
UPDATE: I went with the SQLite database (using two tables) and it works great! Wasn't too hard to learn and get working either. For the layout, it turns out a ListView with a custom adapter was the best way to accomplish what I wanted (more flexible than a TableLayout).
I haven't done a lot with Andriod but I believe you are on the right path. Using the SQLite for data will not only help keep your data structured and organized it will allow your data set to grow exponentially and you can use a common standard way to go from SQL database to Objects using a DAO pattern. I would recommend using SQLite with MyBatis. MyBatis is an Object Relational Mapping utility for java. It allows you to write sql and get back your results as java object. MyBatis
I personally think it would be simpler to use a SQlite table for this. From what I can tell you only really need one table, so it might be a bit of overkill but to me it seems much simpler than dealing with file I/O.
Also with database you can more readily add extra information such as date it was recorded etc.
For something as dirt simple and non-critical as a high scores list, a database feels a little like overkill to me. I'd be inclined to use a CSV file myself.
Of course, take that with a suitable grain of salt, as I don't develop on Android. If the overhead for SQLite is trivial (or if it's already on Android waiting for you to use it!), may as well use it for your data storage needs, if only to keep your code consistent.
ScoreNinja, the open-source score library for Android, might save you some time, or give you some ideas.
Related
So I have a simple android app which is like this: It has a list of Car Manufacturers such as Honda, Ford, Mazda etc.
Then when one of the manufacturer is chosen, I need to display their car models. So if user selects Honda, I would display "Civic, CRV, Odyssey" etc.
And when user selects a specific model, I would display another list with more information.
So what kinda of data structure would be simple and easy to implement in my android app. I was thinking about using nested ArrayLists.
Also, can you please provide a link to an example on how to save the data internally using android studio and get the data when I need to.
Note: The list is dynamic, meaning that the user will have the option to add or delete any item from any of lists.
Thanks :)
This is practically what databases are for (of course I'm talking about SQLite here). I'm assuming you will have loads of data that are interconnected in a way.
I do not know how well you know database design, but you should have a table called Manufacturer which will hold the data about those (think about what data you want to save and therefore create proper columns of the table) and a table called CarModel which will have a foreign key which connects it to the Manufacturer (called manufacturer_id). These two tables need to have Many-To-One relationship -> Each manufacturer can have Many models, but each model can be produced by only One manufacturer.
This is just a basic idea which you can still improve to your own liking, but this should cover everything that you asked for very easily. For example, to get a list of Manufacturers, you'd simply Select * from Manufacturer. When you click a particular manufacturer and wanna display it's models, you'd just write a quite simple query Select * from CarModel where manufacturer_id = id (id being the parameter you pass to some function, the id of the manufacturer you want the models for. The models you select can have arbitrary amount of data like additional information about that model.
If you're not that good with raw queries, there are useful query builder which can make your life a whole lot easier.
I think that the most approaches to implement data in Android is based on SQLite. If you don't have enough experience with it i strongly recommend to investigate following tutorials with content provider:
Content-provider basics
Content-provider creating
You are right that it is very time consuming (even for experienced developers) just because this approach needs to specify entire database scheme using simple strings. But there are a few ORM-solutions you can use, such as ORMLite, but it still demanding task to investigate.
In addition i would reccomend Realm, that significantly simpler to implement, but, in my opinion, has many features you should consider (such as multithreading work)
Hope, it'll help.
I have a situation here. I have a huge database with >10 columns and millions of rows. I am using a matching algorithm which matches each input records with the values in database.
The database operation is taking lot of time when there are millions of records to match. I am thinking of using a multi-hash map or any resultset alternative so that i can save the whole table in memory and prevent hitting database again....
Can anybody tell me what should i do??
I don't think this is the right way to go. You are trying to do the database's work manually in Java. I'm not saying that you are not capable of doing this, but most databases have been developed for many years and are quite good in doing exactly the thing that you want.
However, databases need to be configured correctly for a given type of query to be executed fast. So my suggestion is that you first check whether you can tweak the database configuration to improve the performance of the query. The most common thing is to add the right indexes to your table. Read How MySQL Uses Indexes or the corresponding part of the manual of your particular database for more information.
The other thing is, if you have so much data storing everything in main memory is probably not faster and might even be infeasible. Not to say that you have to transfer the whole data first.
In any case, try to use a profiler to identify the bottleneck of the program first. Maybe the problem is not even on the database side.
Extending this thread - I would just like to know why it's faster to retrieve files from a file system, rather than a MySQL database. If one were to benchmark the two to see which would retrieve the most data (multiple types of data) over 10 minutes - which one would win?
If a file system is truly faster, then why not just store everything in a file system and replace a database with csv or xml?
EDIT 1:
I found a good resource for alternate storage options for java
EDIT 2:
I'm looking for a Java API/Jar that has the functionality of a SQL Database Server Engine (or at least some of it) that uses XML for data storage (preferably). If you know of something, please leave a comment below.
At the end of the day the database does just store the data in the file system. It's all the useful stuff on top of just the raw data that makes you decide to use a database.
If you can replicate the functionality, scalability, robustness, integrity, etc, etc of a database system using CSV and still make it perform faster than a relational database then yes I'd suggest doing it your way.
It'd take you a few years to get there though.
Of course, relational systems are not the only way to store data. There are object-oriented database systems (db4o, InterSystems Cache) and document-based systems (RavenDB).
Performance is also relative to the style and volume of data you are working with and what you intend to do with it - I'm not going to even try and discuss that, it's too open ended.
I will also not start the follow on discussion: if memory is truly faster than the file system, why not just store everything in memory? :-)
This also seems similar to another question I answered a long while ago:
Is C# really slower than say C++?
Basically stuff isn't always done just for performance.
MySQL uses the file system the same as everything else on a computer. To retrieve a single piece of data, or a table of data, there is no faster way that directly from the file system. MySQL would just be a small bit of overhead added to that file system pull.
If you need to do some intelligent selecting, match some rows, or filter that data, MySQL is going to do that faster than most other options. The database server provides you calculation and data manipulation power that a filesystem can't.
When you have mixed/structured data, a DBMS is the only solution. For eg. try to get the people's name, surname and country for all your customers stored into your DB, but only those born in 1981 and living in Rome. If you have this data into files on the filesystem, how do you easily get only the required data without scanning all your files and how do you join returned data?
A DBMS give you much more than that.
Many DBMS store data into files.
This abstraction layer will make you retrieve data in a very easily, standard and structured way.
The difference is in how the desired data is located.
In a file system, locating the desired data means searching through all existing data until you find it.
Databases provide indexing which results in locating the desired data almost immediately (within ~12 comparisons) regardless of the amount of data.
What we want is an indexed file system - lucky for us, we have them. They are called databases.
I have a database with a lot of web pages stored.
I will need to process all the data I have so I have two options: recover the data to the program or process directly in database with some functions I will create.
What I want to know is:
do some processing in the database, and not in the application is a good
idea?
when this is recommended and when not?
are there pros and cons?
is possible to extend the language to new features (external APIs/libraries)?
I tried retrieving the content to application (worked), but was to slow and dirty. My
preoccupation was that can't do in the database what can I do in Java, but I don't know if this is true.
ONLY a example: I have a table called Token. At the moment, it has 180,000 rows, but this will increase to over 10 million rows. I need to do some processing to know if a word between two token classified as `Proper Name´ is part of name or not.
I will need to process all the data. In this case, doing directly on database is better than retrieving to application?
My preoccupation was that can't do in the database what can I do in
Java, but I don't know if this is true.
No, that is not a correct assumption. There are valid circumstances for using database to process data. For example, if it involves calling a lot of disparate SQLs that can be combined in a store procedure then you should do the processing the in the stored procedure and call the stored proc from your java application. This way you avoid making several network trips to get to the database server.
I do not know what are you processing though. Are you parsing XML data stored in your database? Then perhaps you should use XQuery and a lot of the modern databases support it.
ONLY an example: I have a table called Token. At the moment, it has
180,000 rows, but this will increase to over 10 million rows. I need
to do some processing to know if a word between two token classified
as `Proper Name´ is part of name or not.
Is there some indicator in the data that tells it's a proper name? Fetching 10 million rows (highly susceptible to OutOfMemoryException) and then going through them is not a good idea. If there are certain parameters about the data that can be put in a where clause in a SQL to limit the number of data being fetched is the way to go in my opinion. Surely you will need to do explains on your SQL, check the correct indices are in place, check index cluster ratio, type of index, all that will make a difference. Now if you can't fully eliminate all "improper names" then you should try to get rid of as many as you can with SQL and then process the rest in your application. I am assuming this is a batch application, right? If it is a web application then you definitely want to create a batch application to do the staging of the data for you before web applications query it.
I hope my explanation makes sense. Please let me know if you have questions.
Directly interacting with the DB for every single thing is a tedious job and affects the performance...there are several ways to get around this...you can use indexing, caching or tools such as Hibernate which keeps all the data in the memory so that you don't need to query the DB for every operation...there are tools such as luceneIndexer which are very popular and could solve your problem of hitting the DB everytime...
I need to create a Java (J2EE) application that allows people to generate "views" on large CSV/TSV tabular data. Views might include things like: pagination through the data, sorting, filtering, pivoting and perhaps charting.
My current thinking is to load the data into temporary tables in a database, use SQL to perform the view tasks and then discard the tables.
Can someone recommend a better approach for this that is also fast?
My constrains are:
This is a real-time transaction, so Hadoop/Hive is not an option
Fast response times are important
I would like to be able to do this in a stateless way where individual requests describe the view (but not at the cost of performance)
I would like to not have to hand-code view generation, hence the preference for SQL databases.
Answering my own question. I find that HSQL does exactly what I need. Looks like Text Tables in HSQL are what I would use to create views the way I need.