Hi I am fairly new to Android development and am hoping someone can help me out with this.
Basically, the app I am designing needs to contain a large list of makes, models, and years for various cars. The user can then select the make/model/year they want and add this car to their personal list of favorites. What I have tried so far is to make a database with two tables: one listing every car, and one listing the cars the user has chosen as favorites. When a user selects a car from the table listing every car, ideally that data would just be copied to the second table.
This has been fairly difficult for me at my novice level and I am having some problems getting it to work at all. So i guess my question is: is there a simpler way I should do this (with multiple arrays or something)? Or should I man up and just keep going at it until it works?
I would stick with the database - it will serve you well for more advanced android development, and many other applications. Sounds like you need to get a book on SQL or fundamental database concepts - if the database is as you've described it you can just use one table and update the "Favourite" flag whenever that changes.
Using alternative structures can have it's own learning curve and be at the cost of performance, particularly if you've got a large number of records. Is there anything specifically you're stuck on?
You have to make two tables CarlistTable & favouriteTable . Add a Column favorite to carlist & make each entry 0 to this column & while mark it as favourite do two things 1.Update the perticular entry as 1 & save that entry to Favourite Table. Thats all.
I would suggest you to stick with the database because having arrays and hardcoding it will make your program bigger and needs more memory (even in RAM) which is limited in cell phones.
To get you thing done, I would suggest you to use flags as the folks have said
plus,
to ease your programming, use a dbHelper and make a function for copying data from one table to another, I think that is fairly simple.
Related
I am doing application for learning words in foreign language, so I have this words stored in my database. These words are separated for example into 3 levels of difficulty. Every level is made of some groups of words, these groups introduces TABLES of SQLite db. I am using SQLiteOpenHelper as communication between application and databases.
Now my question. What is better?
Make 3 smaller databases, each for every level and use own
SQLiteOpenHelper, so together 3 dbs with 3 open helpers.
Make 1 large database, where will be that 3 levels, which means
many TABLES, but just only 1 SQLiteOpenHelper.
Thanks for any advice or opininon.
I suggest 1 large database (DB).
You should not be worried about making large DBs, DBs are invented to store a large amount of data (and even many-many tables). It is much easier to create and maintain one DB than multiple ones and your code will be much clearer using one DB.
And I don't know your program, but I would go even further: I would rather store all words in the same table if you store the same information of them, and add a column to show the level and another one to show the group which they belong to.
The main idea of SQL is that you don't really care how much space your DB will require and how much time it gonna take to find the result of a query because DataBase Managent Systems (in your case the SQLiteOpenHelper and SQLite) are insanely efficient considering space and time. Instead you should rather concentrate on designing a system that can be expanded easily (for example if you want to add another column to tables containing words (e.g. you want to store a new information about words) or want to add new levels or groups in a later stage of development) and has clear structure. You might lose a few milliseconds separating groups and levels via the SELECT command of SQL, but your DB will be much more flexible - you can add levels and groups and add more information about words with ease. The key of desinging a good DB: You should store different kind of data in different tables and same kind of data in same table...
The error that you mention in your comment is almost certainly a bug in your application code. There is no reason that an application with multiple databases should encounter that sort of error.
That said, my answer to your original question is that it is objectively "better" to use a single database.
It is better because you will have less code to maintain, no possibility of attempting to access the wrong database in a given situation, and the code will be more idiomatic - i.e. there's no benefit to using multiple databases, so if you were to use multiple databases, anyone reading your code would spend a lot of time trying to figure out why you did it.
I have a SQLite database which has a table (of course) named Object. In my application, I need to access that table and all of its fields. I am able to query the database and get all of the information I want from a cursor with no issues. The problem comes with deciding what to do with the cursor next. Right now I am thinking of creating a class called Object and it will have fields for every column in the table which will be set by the query. This just seems so... inefficient. I'm not sure how to do this without needing to write out every column that is in the table for the object to use, which seems to violate DRY. Are there any better ways to do this?
My end goal is to be able to access every row in the table and get whatever information I want for that row. For example I will be using this to populate a ListView. If this is too ambiguous let me know and I'll try to clarify.
Thanks!
Edit: I've found the library db40 and it seems to do what I want. The library seems to be kind of big though (40 mb) for a mobile application. Does anybody have experience with this? Everything I've read seems to indicate it is good. I'll post more if I find information.
Are there any better ways to do this?
This is very "wide" question and depends on personal requirements and what is for developer more comfortable. I'm using your idea that is for me the best one you can use.
Generally we can say you want to create ORM (object-relation mapping). It's very clean and efficient approach (my opinion). Of course sometimes is not the best solution to use ORM ( i never met with this case but heard about it). I almost always use my own defined ORM for sure it takes some time but results are significant against done frameworks.
Both have advantages and disadvantages. Own ORM has much more higher performance because it's designated and optimized for concrete solution (mainly queries etc.).
I suggest you to do what you mentioned -> create object that will represent table in database with properties equal to columns. I'm using this in work and we never had problems with performance or too much battery consumption with our applications.
It's also much more safe if you'll show user some data not directly from database but "copies" in objects. Users can do whatever want with dislayed results (they can add some dangerous symbols and hacks) but now you can easily check this before you'll want to update database(s) with changes.
Your source-code looks good, another developer won't be lost in your code, everything will be clear and easy to do updates for future.
I provided you "my opinion" on this thing so hope it'll help you with make a decision.
Short version at the bottom
I'm working on an android app for a computer game, Heroes Of Newerth. A part of the apps functionality is to list all the heroes in the game. Each hero has:
a short description
a few stats(faction and primary attribute)
an icon
4 spells, which also has:
a short description
a few stats (mana cost, difference in ranks, etc.)
an icon.
There are approximately 110 heroes, which means I have about 500 sets of descriptions and stats.
I made a working version of the app. I downloaded all the images and put them in the drawable folder (note, this was 500 images), and created a Hero Enum which stored name, faction and primary attribute. Obviously, this was a bad idea, as it was horrible looking, and hard to extend to storing the rest of the data.
I have though about using a database, but as I don't have any experience with databases, I'm not really sure as how to do this, especially in Android. I looked it up, and it seems I need to initialize the database on the phone, which means I have to get that data from somewhere - which, again, means I'm back to square one.
I have never worked with this much data in a programming project, and have no idea for how to save it all. As if this is not enough, the game developer, S2 Games, releases new heroes with only weeks in between. As I wouldn't want to update one of my apps every other week, I want the app to be able to update itself with the new data. The best way I see this in my head is you download the app, either with a database of the current heroes, or without any, and the app checks each friday(patches are released on fridays) if the app is up to date. If not, update the database(with text and icons).
Short version
I want to save a few thousand strings, some formated in a special way(unless I can to this afterwards), and about 500 icons. How should I approach this?
Note: I know this was a really bad question, with a horrible structure, but I've been stuck here for weeks, and I couldn't get myself to ask someone, I really need help here!
well it's very recommended that you use sql and databases . you could go to w3schools for the basics .
if you don't want to use DB (or don't have time) , you can store all the data in xml files , and then parse them all . the images should never be part of the DB (or the xml files) , since they cause a bad performance while moving between items.put their names/paths instead .
if the images take a lot of space , consider using google expansion library .
I'm working on a trivia like app and wondering how is the best way to store all of the questions and answers. Right now, I just have a random number and using a whole lot of if statements. For example, if randomNum = 25, then question is THIS and choices are THIS. This seems to work fine, but my file is starting to get very large and this seems like it should cause performance issues. Space is also starting to become an issue. I have started to look into just putting all of the data into database and use a random number to just retrieve a row. Anybody have any suggestions on which would be the best practice or have any other ways of doing this?
Sounds like its a good time to start using the database. You can learn how to include a pre-populated database here.
...using a whole lot of if statements.
I have started to look into just putting all of the data into database and use a random number to just retrieve a row
I think you've kinda answered the question yourself.
What happens with your model if you have 10,000 questions? Are you going to use 10,000 'if' statements?
Even if you're never going to get to that many questions, using a SELECT on a DB where the question number equals a particular random number, is going to be far more extensible.
You should use the database.
It's not just a maintainability and (ultimately) a code simplicity option, either, but offers significant advantages.
Imagine if you want to be able to supply different packs of questions, for example. You could offer people the ability to download a trivia pack from a website, or load it from a file off their SDcard. This simply would not work for masses of if statements.
Suppose you want to let people add their own trivia questions? Upload them to the website for voting and ultimate inclusion into crowd-sourced question packs.
So yeah: you should use a database.
I'm creating an app which is going to have some data that is stored in an SQLite database. I want the user to be able to create "folders" which can be assigned to each data item.
I was going to do this using a one to many relationship e.g. one "folder" can have many data objects under it but having looked at relationships with SQLite and Android it seems that this would only work in 2.2+ so I'm just wondering what the alternative is?
Any information is much appreciated.
You can still have relationships; older versions of SQLite just won't enforce them. As a stopgap, you can build triggers to do it; in fact there's a handy generator that will generate the SQL for you to use as a starting point.