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.
Related
I'm working on a webapp at the moment that will display a list of items. The list is dynamic and can change between users. A great analogy is to think of the objects as books, with the db backing it as the library.
My database for Book will contain a list of all books in the library.
-A user can add a book to their collection.
-If a user wants to add a new book to their collection they will also add it to the library.
-If a user wants to add a new book to their collection and it exists in the library, nothing will be added to the Book database.
Currently my table is incredibly simple: Book(id, name). I am able to access a plethora of information about these books via an API call, such as a front cover, number of pages etc etc. I would like to store a subset of this information, especially the image url.
I think a sensible approach would be to alter my Book table so that it looks like: Book(id, name, imageUrl, otherValue, idOfThisBookInApiCallTable) the idOfThisBookInApiCallTable value will allow me to get other attributes as I need them, however I've two issues with this that I'm not sure on how to proceed.
Firstly is that this Table can easily get out of date with the APITable. I don't expect there to be much change, if any, but the risk is there.
Secondly, the image being stored is my main concern, on a page where there might be 50 books, I'll making a call to the url of the image each time. I think a sensible solution would be download the image locally and then serve it from then on repeated visits but I'm not sure if this is the correct approach.
Might I ask if anyone can see any issues with this approach and/or suggest a better one please? I have limited experience with db/web/app design so a little out of my depth here.
If saving the image locally is the correct approach, is there a 'best' way of doing this?
Thanks in advance for any help/suggestions/advice.
I can share my 2 cents of a plausible design but I think the question is too broad and is mostly opinion-based. Let's address it by taking one thing at a time.
First regarding your Book table. Why not a Library table where you maintain the current state of your library with all the books that the library has at the moment.
Each user can hold a collection (a table etc with a one to many relation like user_id to list of book_ids or whatever) and then each user sort of owns a subset of bookIDs.
When adding a new book via user or via library (library can also add more books even if no particular user brought it in) then always add it to the library and if the user_id is known for the 'owner' of this book, add a relation for this user as well in the collection table
More details of a book can be stored separately in a BookDetails table.
Storage of images on your side is always a nice option and you don't want to get blocked by the API for over-usage when requesting over and over again. You can use some cloud storage like s3 where you can keep the images and then not bother the external api. S3 supports compression and caching so you can save lots of time and not have speed problems.
All the above points are just my opinion based on the information you gave on the question. The situation can of course be different for your use-case.
I am just starting off with app development and am currently writing an Android application which has registered users and a list of 'challenges' which they are able to select and later mark as completed/failed.
The plan is to eventually store all users/challenge/etc data on a database though I haven't implemented this yet.
The issue I have run in to is this - in my current design each User has list variables containing their current challenges and completed challenges eg. two ArrayList fields.
Users currently select challenges from a listview of different Challenge objects, which are then added to the user's CurrentChallenges list.
What I had not accounted for is how to structure this so that when a user takes on a challenge, they have their own unique copy of that challenge that can be independently marked as completed etc, whereas at the minute every user that selects say, Challenge 1, is simply adding the same challenge with the same ID etc. as each other user that selects Challenge 1.
I supposed I could have each different challenge be its own sub-class of Challenge and assign every user which selects that challenge type a different instance of that class, however this seems like it would be a very messy/inefficient method as all the different classes would be largely the same.
Does anyone have any good ideas or design patterns for this case? Preferably a solution that will be compatible with later storing these challenges in a database and presumably using ORM.
Thanks a lot for any suggestions,
E
I'd move every aspect of a challenge that is different for each user into a new Attempt class. So Challenge might have variables for name, description etc. and Attempt would have inProgress, completed etc. Obviously these are just examples, replace them with whatever data you're actually storing.
Now in your User class, you can record challenges using a Map. Make it a Map<Challenge, Attempt> and each User will be able to store an Attempt for each Challenge to record their progress. The Challenge instances are shared between users but there is an Attempt instance for each combination of User and Challenge.
When you implement the database later, Challenge, User and Attempt would each translate to a table. Attempt would have foreign keys for both of the other tables. Unfortunately I haven't used ORMs much so I'm not sure whether they'd work with a Map correctly.
I am building a product in which customers can create dynamic form depending upon their requirements. For example one customer can create a form having fields like first name, last name, others can have one extra field like middle name.
I want to store each and every customers settings and finally i want to merge these two settings into one form at the time of display to our end users. I am finding right way to implement it.
Finding a way to store individual customers settings either in Database or XML or anything.
Finding a way to merge customers settings into one form, once our end user select both customers to apply (i want to give only one form which contains both customer form fields).
Please remember that i am providing a tool where customer can create new label like Gender, which is not defined in the system. We are giving generin data type to create such fields using text box, text-area, table, check-box, radio and many more.
Please assist me to design the architecture of above problem set.
You can do this by modelling your database as Entity–attribute–value model. See this :
Using Database Metadata and its Semantics to Generate Automatic and Dynamic Web Entry Forms
Planning and Implementing a Metadata-Driven Digital Repository
You can also find useful threads here in SO in the tag: eav
I'm working on a web app for a class. It's basically a project management system, similar to a watered down version of Bugzilla, but specifically tailored for an academic environment. One of the requirements is that for a number of settings (such as project type which could be master's project, PhD thesis, etc.) the lists of possible values be configurable. So there would be a configuration or settings page where you could change the values in each list, but then in the rest of the app (like when creating a project or task) the values in the list will be the only options to choose from. Also if you change one of the values (say from master's paper to master's thesis) all the records which use that value should have it changed, too. So all projects marked as master's paper would now be marked as master's thesis.
I'm using an HSQLDB to store data and the app is written all in Java (JDBC, JavaServlets, JSP).
I'm having a hard time figuring out how to deal with this requirement from a design perspective. First, how do I store these lists in the database? Would each list be its own table? Having each list be a column in one table seems wrong (wouldn't that violate normalization rules?). I'm not super familiar with database design, but googling hasn't revealed a good solution to this.
Second, how do I treat these lists in my code? I've been thinking of using static variables (Collections of some sort) in the associated classes, because these settings are meant to be global, not specific to one user or project. That's generally not considered good design though.
Any recommendations would be greatly appreciated. I want to get the design correct not only because this is a software engineering class so design is important, but also because I may end up expanding this project into a master's project.
this is standard normalization.
create a list table
mylist
---------
option_id
option_name
then associate it to the other table as appropriate
my_other_table
--------------
attributes...
option_id
the UI for setting values for my_other_table queries to mylist for the values that should go into the combo box or whatever UI component you choose.
Each "enum" should be stored in its own table, so that you can have foreign keys to this table.
You could store all the possible values of each "enum" in a cache, to avoid going to the database each time you need the list of options, but be careful not to propose stale data. Since the number of entries should be very small, I wouldn't care much about performance until you have a real problem.
In my company we have table Dictionary(class, field, value, description) - and for each class and field we have as many rows, as there are allowed values, and it works quite well.
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.