In MySQL database, I have a table in which there is a field named features. I have nearly 20 features to store there. I am trying to retrieve these features from my Android mobile application. In app, it has to be shown as line by line (so 20 lines in total). Is there anyway to store the 20 features in that single field by doing something like \n? Or is there anyway to get those features in new lines by doing something in my android app?
Firstly, this is almost certainly a terrible idea...by storing the features in a single field, you make it very hard to query and manage. For instance, finding all records where feature "x" is available requires you to parse the feature field in some way, which will almost certainly not make use of any indexing on the column.
If you have no choice, you have two options: store the features as some kind of string representation (XML, JSON, CSV), or store the features as a bit flag.
I strongly recommend using a structured text format - JSON is probably the most lightweight - because it's human readable, and easily parsed.
Well assuming you have the code set up to run a query and retrieve the data, you should store the data retrieved into a collection (an array or list) and loop through each item, displaying the needed data on the screen.
Displaying the data can work anyway you want, you can add a button for each record, write a line of text to a text field (which is probably good for your case), create a cell in a table etc....
I wouldn't place all of the data into the same record, it could get messy should you decide to add a field which is tailored to an individual feature. Plus, if you combine all the features into one record and decide to add or remove a feature later on, you will have to do string manipulation.
I would go with LONGTEXT. TEXT and BLOB can hold 64K of data while LONGTEXT and LONGBLOB (used primarily for binary data) can hold up to 4GB.
http://dev.mysql.com/doc/refman/5.0/en/storage-requirements.html
And yes, /n is fine for line delimiting
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 have been looking at different ways to hold onto some predefined character data, however I am having a hard time nailing down which would be the best solution.
An example of data would be 10 strings, 5 int arrays (of size 10 each). There would be 10+ set's of this data. The application would load in the information and inflate generic "character" objects.
Possible solutions:
XML: Due to Android's structured XML requirements it can be hard to use without making a different XML file for every character, and even then it would have ID overlapping for similar named data values.
SQLite: Wouldn't be a huge database, but databases are ugly version controlled unless it is done with a create-database script which has its own downsides (such as making sure DB is up to date between builds).
Hard-coded Objects: By far my least favorite solution, using polymorphism to hardcode all of the objects. Too dirty, not nearly as dynamic as it should be.
I would like to consider things such as version controlling the files, ease of updating (due to them only being inflated, never changed by the app).
If this data is baked i would suggest to use harcoded data.
Reasons.
In those three solution you save the data in the application.
If you use XML-data, you have to consume the time while code parsing inside the code. And you have to write the code that parses your xml.
If you use SQLite, your data will be doubled because of you have to store this database in raw or assest directory, copied in the /data/data folder. Futhermore, if you use Strings and SQLite by default the data will be doubled again (due to UTF-16 encoding).
If think, if only you manage the data this is more usefull to store directly inside the code. Obviously, if you do not use tons of content:)
You might want to use the Realm framework, which is comparatively faster than SQLite and easy to implement inside in your current code.
It handles large data too and it feels like you're using only native android classes.
I am developing a glossary using the sample code Searchable Dictionary. Thanks to searching here, I have figured out how to update the database, which is a .txt file, and then get it to load by changing the version number in Dictionary.java.
My question is, how to do the following:
I would like to be able to insert illustrative images into the definitions.
I would also like to insert links to other entries in the dictionary (e.g. 'inventory' should have a link to 'product flow' and other related terms).
I would also like to know how to insert a carriage return.
My original glossary in spreadsheet format has several fields: 'term' 'definition' 'example' 'related terms'. I want to be able to put in links and images inside these fields and have a couple of carriage returns in between each field to differentiate them.
The dictionary code seems to take in everything as a string, so even if I try to put 'image.jpg', or '\n' for a new line, it simply prints that as part of the string. Is there a way around this?
Searching stackoverflow gave a few links to using SQLite. I am honestly a newbie at all this; the last time I programmed anything significant was ten years ago. Rewriting the code to directly access a SQLite database would be nontrivial for me. So I would like to know if that is really the route I should be taking. If it is, then could you point me to the most simple tutorials for constructing a dictionary that way? I downloaded SQLite data browser, but haven't figured out how to use to construct a new database. I know it should not be so hard; I just don't know what I am doing. :(
If there is an easy way to just do it inline, still using the Searchable Dictionary sample code as a base, that would really make my day. Otherwise, any specific suggestions/directions would be really appreciated.
Thank you!!
Update:
For clarification, below is an example of one entry in my glossary, as desired. There are carriage returns between sections, and links and images are inline with text:
Heijunka, or Load Leveling - An approach to smooth production flow when a mix of products is to be produced, by identifying for a selected time period, the smallest batch size at which to produce each specific product in the mix, before switching over to make another product in the mix.
Example:
Keeping a steady work flow, even if much slower than the original max, reduces waste (<-this is a link to the entry 'waste' in the glossary):
[image of line of balance graph with load leveling, and without]
Related Terms: work structure, demand leveling (<-These are links to respective entries)
Not sure if you saw this already, but Android has some developer lessons for saving Key-Value sets for simple data, and saving to SQLlite for more complex structures.
It sounds like your app needs a database called "Invetory" with the following fields: "ProductImage", "ProductTitle", "ProductLink". And you want to store the image as a BLOB. There's a good SO post on how to take an image from a URL and convert it to a byte array for storage: how to store Image as blob in Sqlite & how to retrieve it?
For the carriage return, i'm assuming you're using "\n"? If that's not working have you tried unescaping your string for TextView:
String s = unescape(stringFromDatabase)
Or for SQLlite:
DatabaseUtils.sqlEscapeString()
Key-value data: http://developer.android.com/training/basics/data-storage/shared-preferences.html
SQLlite data: http://developer.android.com/training/basics/data-storage/databases.html
Additional SQLite resources:
http://www.youtube.com/watch?v=G8ZRXdztESU
http://www.vogella.com/articles/AndroidSQLite/article.html
I wanna make an app kind of like Google keep, which has these features:
Storing the names, content, background color of every notes and photos (not including to-do lists, it's a little complicated), using TextView for notes, Custom View (TextView + ImageView) for photos;
Entries could change position with each other by drag and drop;
It could only save 10 entries at most. If there exists opening entry position, The app will fill the position with placeholder, and display all the 10 position in one screen (no scrollbar).
In my opinion, both method have some shortcomings for this situation:
Sharedpreferences: the amount of data is too much and kind of complex;
Sqlite: the data entries are limited. Besides, I think TableLayout is more suitable than GridView cus I want them display in one screen without scrollbar.
Then which data storage method should I choose, sqlite or sharedpreferences? Thanks for your help.
SharedPreferences is not suitable. As you note, it is not meant for that amount and complexity of data. As the name implies, it is meant for storing a users' preferences, not their data.
Note that SQLite support BLOB type that can be used for storing images, etc.
But you aren't limited to those two options. The third option would be to store your data in a file, in any format you choose, e.g. you could serialize your Java objects into a file. Since you will be dealing with a limited amount of data you don't necessarily need the capabilities of SQLite.
But on the whole, I think that SQLite is your best option. It is better then SharedPreferences for reasons given above, and better then the 3rd option because it is built into Android and is widely used.
I am trying to create an Android dictionary-like application and get slow performance on retrieving the data. Currently, each dictionary entry is stored in a text file (inside Android assets), each file is named as number, so that I can use index to locate, open and read the file's content (simply read out a single line of String). When using ListView to render the output data and reading the file's content inside getView() method, it takes about 3 second to retrieve 10 entries. I just wonder if there are another approaches (using SQLLite, ???) for retrieving and rendering these entries faster. Any recommendations are appreciated.
I would suggest you to use SQLite
Advantages
You can query
You can update definitions easily
Your data is more secure while using database (If you can Encrypt
using AES or similar algorithm it, then it will become more
secure!)
Fetching results is more faster
You can easily populate the results to a ListView
You can see a complete article here
SQLite will definitely make your job easier and make the app work faster. It's also a lot easier to read data; when you're writing data to the DB make sure to use transactions to speed up multiple sequential writes. I probably wouldn't even consider using a text file except for initial data. There are many resources available online such as this tutorial.