I am developing a glossary of terms in physics. In this glossary app, user can search the definition alphabetically as well as by category . Shall i store data in one table or create different table for different categories? which will be better. I want to develop something like this app https://market.android.com/details?id=com.beiks.bd_1119_NurserySongs_FULL but with images to explain it better. Shall i store the images also in database? Is there any way to use pdf files to display? Sample app with code will really be helpful. thanks in adv.
Shall i store data in one table or create different table for different categories?
I would suggest spending some time creating a normalized database structure, instead of splitting it into separate tables. For example, if you think you might assign one entry to multiple categories, that would call for a very different table schema (categories table, definitions table, and a definition_categories linking table that references the first two). If you don't need that, then having a single definitions table with a category column would be sufficient.
Shall i store the images also in database?
If you'll be shipping the application with the images included, then do not store them in the database -- the reason is because then you'll be using up twice the space for your images (once in the application resources, and once in the database).
If you'll be downloading the images from the Internet, it really comes down to personal preference.. The easy way would be to just download the images and store in your data directory, or on the SD card ("external storage").
Is there any way to use pdf files to display?
That depends on the device, and if it has a PDF reader installed. You can test for the existence of a PDF-capable application on the device using techniques described in this question.
Related
I am developing a launcher for Android and need some advice on designing my persistent storage system.
I wish for people to be able to create different categories for their apps (e.g Media, Utilities, Social). Users must be able to choose the order of their apps and apps can appear in more than one category. Users can update the order of the apps and order should persist on restart. I would also like to keep track of how often apps are launched so that I can have an automatic 'most used' category.
I have had 2 approaches but neither seem ideal:
Save the list of apps to a file (JSON or other), taking note of the package name and position in the list. When required bring this file in and sort by order
Save the list in an SQLlite database, either:
Have a table for each category. Columns would be package_name and list_position
Have a single table, with a column for each category, which stores the position of that app in that category (or null if not present). When a new category is created, a new column is added (not supported in Room).
Option 1 I feel would be tricky to keep dynamic and unsure of efficiency, so I prefer option 2 because its's simple to update and automatically Order By, however it may be overkill to use a DB for this.
Any advice or other possible solutions would be great! Thanks
I'd go for a database approach. I think storing data in a file is perhaps a good choice for small applications where the data don't grow and you flush changes max once before the application is destroyed.
If you want to avoid the boilerplate code of SQLite, then consider Room. Alternatively, you may want to have a look at Realm which is an alternative to SQLite.
If your function is limited then a file based approach works, your approach depends on basis of features you want to have like
-->add i.e (append) specific index or you resorting or shuffling of data is needed.
-->consuming the data i.e If accessing the data in ordered fashion or filtering on multiple features.
Storing data in a file is generally preferred for a small collection of key-values like android Sharedpref itself.
Depending on the functionalities your launcher has the file system gets complex and slower accessing and modification in which case it(file) won't be the best way to store the list of apps (& other info if needed) in a file.
Building a database would help overcome all the complex for future functions like different sorting and other features.
I really need to create a small DB for doing only SELECT querys in my app. Because of that I would like to know:
Does android provide something for design and fill a DB? I mean no programming. Something like phpmyadmin so I could fill it and make a relation between 2 tables before running the app in an emulator or a phone.
If I create a DB, will it be visible from some file in the user mobile phone? Because I read in android manual that it was invisible but in some places I read that it's saved in the mobile... I would prefer that this DB would be like a resource like it can be a layer or a string.
If I really need to create a DB each time the app is displayed for present the same information always, could I just "upload a sample" of that database in one line of code or so?
I need this for display a big list of items (maybe 2000 items) in different languages. I could do that just creating an array string resource but I need to order the list in a different way depending on the location of the user. At the end I need to retrieve an "ID" of the items selected but because it's impossible to do a 2D array string as a resource then I can't assign a number to the items so I can only know their positions in the list. The problem is that if I alter the items I will have a mismatch of positions numbers as ID.
This array is for an autofill text. I know I can put a comma after each item with the number and before adding this array to the autofill do a split and select the first column for the autofill and the second for compare position to real ID but I thought it would have a better performance to have all in a DB. Am I wrong?
1. Does android provide something for design and fill a DB? I mean no
programming. Something like phpmyadmin so I could fill it and make a
relation between 2 tables before running the app in an emulator or a
phone.
You can use Sqlite Browser to create a database
2. If I create a DB, will it be visible from some file in the user
mobile phone? Because I read in android manual that it was invisible
but in some places I read that it's saved in the mobile... I would
prefer that this DB would be like a resource like it can be a layer
or a string.
It depends on where you create. Usually if you open a database it will be created in /data/data/[yourpackagename]/databases . This folder is incaccessible in normal cases, but if you have a rooted phone you can access this folder. Also while creating you could change the path to sdcard which is accessible everytime
3. If I really need to create a DB each time the app is
displayed for present the same information always, could I just "upload a
sample" of that database in one line of code or so?
You could store the db in assets folder of your app and open it.
Edit:
If it is just a 2D array i think its better to save as a csv and extract. You could put it in assets or raw folder.
I wonder when to use several tables in the same database file, and when to use multiple files? For example a separate database file for each table. What are the advantages and disadvantages?
I have "places", "persons" and "bookings". A person is booked to be in one place (at a certain time). Since there are some many-to- relations between them, they need to be in separate tables. Btw, this is a common task, so I wonder if anyone has links to examples or suggestions on how to solve it in the best way.
Your data model is simple, and can be perfectly implemented using 3 tables in the same database. If you use a SQLite database, this database would be one file.
There is no benefit here in creating several files/databases. It would only bring more complexity (and even slightly impact performance/startup time because you would need to open 3 db files)
You can find a tutorial on how to use SQLite (which is the best option if you want to store the data locally on the user device) with Android here.
I apologize in advance if this question is too broad or too "it-depends."
Basically, I need to make a decision about how to store and access data in my app. The app works very much like flashcards; the "front" of the card presents the topic and the "back" presents the details/explanation. At first it seemed like a SQLite database would work best for this type of structure (and maybe it really is, I just don't know) because the data is static and this model works well with the rows and columns structure of a db. (btw, as of now, I'm using openCSV to parse the csv files containing my cards. Thought it was easier than SQLite...)
My issue (finally) is that I want to be able to display images for some of the data items. Some cards, for example, should display a corresponding image. Is this something that I can do with a SQLite db? Like, have one column store the path to an image....? Maybe what I'm asking is really basic, but I just haven't seen too many examples to really have a good sense of the design options out there.
I might also be confused about how I would dynamically change my views based on whether there is an image available. Maybe that's just an issue of dynamically creating an imageview whose source is the file that the db points to...
In summary, I'd really appreciate some guidance on how I can fetch and display text data along with images when they're available, whether it be in SQLite or some other way.
Thanks!
If all this data is being shipped with the app, I'd suggest just keeping everything stored as resources. You can have string arrays for the topics and details, and you can store images either as drawable resources or as assets. In the latter case, you could store the asset names as another string array resource. (In the former case, you'd have to build a map from each card to the resource identifier. This is, unfortunately, one area in which the Android resources architecture doesn't shine.)
If you want to use SQLite, it has BLOB fields in which you could store the images themselves, or int fields in which you could store image resource identifiers. Take a look at the searchable dictionary sample project for how to build an SQLite data base from resource data.
Sorry but this really is a 'it depends' kind of topic.
Unless you're storing a large number of rows of data (around the order of 10 000) then an XML file would be your best bet. In a Train Timetable app I recently wrote we went with a XML SAX parser loading a 14 000 record database to memory and it took no more than 2 seconds on an HTC Hero, so even for large databases its pretty fast.
The SQLite option is preferable only if you want to make use of relationships that come with a database structure. It is better at handling large numbers of rows but terrible at handling images.
Since you're flash cards are not relational I would recommend an xml file, using the xmlSax parser, and a folder of images within your assets folder. You could even run the images through pngCrunch to save some space.
XML is very flexible, below is an example of what your xml file could look like. Check out http://www.w3schools.com/schema/ for more information on writing an xml schema.
<?xml version="1.0" encoding="UTF-8"?>
<cards>
<card title="card 1" topic="atopic" image="image file name">
<front>Lots of text</front>
<back>Lots of text</back>
</card>
<card ..>
..
</card>
</cards>
I'm just looking for some insight into what would be the best way for me to store images as part of my app.
I have an activity that represents a 'Job' which has a couple of edittext's and underneath was planning on using the Gallery component to show images relevant to this job.
The job data is stored in a database (on the sdcard) so was also thinking of creating a table to store 'JobImages' and having each image stored as a byte array.
But I'm not sure if it would be better to store the images directly on sdcard under a folder structure specific to my application and the job. E.g. using the job ID number as a folder name.
Depending on which method I use will greatly determine the code that goes into an 'adapter' that allows me to bind to the gallery component so before I begin I was wondering if anyone has had the same design problem and what option they chose.
Thanks,
Dave
Regardless of what storage method you choose, don't let that stop you from writing the code that will use it. Write a class that abstracts this from your app and just gives you images, how/where it retrieves images from, doesn't matter, this will also help you in the future if you decide to change your storage method, you will only have to change this class, not the whole app.
Back to the original question, it depends how you'll be using the images, if you already have a db and need to associate the images with other records or add additional properties (i.e. a database of animals in a shelter with their pictures and other attributes), makes sense to store in a db. If all you care about are pictures that don't have any need to be organized (i.e. the built in Gallery), then store in a folder.
Here's a link on how to store in DB: http://www.helloandroid.com/tutorials/store-imagesfiles-database