I have made a table with user info already stored in it. When the user registers with the id, all the details like username, course are retrieved from the table if the id matches. Now I want to add profile pictures in my user info table. Almost all tutorials on the internet are about saving a photo from your phone into that database and retrieving it. But i don't want that. I would like to add different image into the table for each user, i.e. it should be specific to the user. Now I know a BLOB datatype is used and the images should be converted to bytes. But I don't know where I should store the images, whether in my phone or in my res folder. Or maybe store it on the internet. I am confused.
I should mention that this isn't an ideal application, its just a model.
One of the most important factors to consider is the size of the images. If the size is likely to be in excess of say 200k then there is an increasing risk of there being issues not with storing the image in the database but retrieving the image.
Without writing your own alternative of CursorWindow then a CursorWindow (a buffer to hold a sub-group of the rows in a Cursor) is limited to 2M in size (in later versions at some it I believe it was 1M). If a picture is approaching 2MB there is no way that the picture can be retrieved (even without considering space for other columns).
As such, the generally recommended approach is to not store images but store a means of retrieving the image from a file store elsewhere (you've mentioned the res folder, which could be fine but you may need to consider the size of the APK), you could then store the file path in the database.
There's a more comprehensive answer that covers the above including storing small images in the DB and larger images elsewhere (assets folder) here
For anyone who has the same question like me, I found this tutorial to be the most easiest way to store images and retrieve it. It uses an external sqlite database to store images and info, and access it in the java page to display which i found quite easy.
Related
We're building an app (ios and Android) that lists ~1000 records. This list is displayed in a tableview/listview with an image related to each record displayed in the view. When a record is selected, a detail view opens up and displays multiple images related to that record.
What are some of the best (and simplest) ways to organise these image assets in both platforms and access them?
More info:
There is also a few lines of text related to each detailed screen. This also needs to be handled.
The images should be packaged with the app as the app will be used offline a lot.
For iOS ::
Collection view for display once selecting would probably be the most simple.
1000+ images? That is pretty big and will bloat your ipa for the store, also it locks you into having to add all images. You should really have those on a server and download them when needed, or download all on first load or something.
I'd have thumbnails or something for the tableview then when selected download the related images into a directory on the app bundle. That temp directory can act as your source. Just create a wrapper that reads the directory and creates and ImageObject for each image found (image and text description if available) and compile into a Dictionary with the key being whatever identifies each record.
The wrapper is an important layer when compiling all the images associated with the records because you can swap the implementation if needed as long as you maintain the interface contract of using a Dictionary to organize your data.
The tableview displays all the records and downloads the thumbnails when needed (this is pretty standard). Selecting the record then goes to a collection view that asks the wrapper for the records images/descriptions. The wrapper grabs the either from the system or the server and returns the dictionary. Then the collection view uses the dictionary as the data source displays all the images with the image descriptions
That's how I'd do it based off your vague specs anyhow.
First of all, it is definitely not recommended to store them in Core Data. Core Data has low performance and can't be cross-platform. I don't see any benefit in storing images into Core Data, and you need to serialize it when displaying.
I recommend that you store your records in a SQLite database. SQLite is a high-performance, cross-platform embedded database that is fully supported by both platforms.
Create a SQLite 3 database and store all the records, but there are two cases for the image:
The image is very small, such as the icon of the button, the number of images is less, then you can store them directly in the database.
The image is large, the number is large, then it should be stored in the system, only store the name or path of the image into database.
I recommend storing the image in the system, because blob data can't be queried and indexed. It's more troublesome when you need to do something with the image. Reading from the system will be more faster than reading from the database.
Images should be compressed before packaging. If the image is large, creating a corresponding thumbnail will improve UI fluency.
Then you just need to copy the database and images (if not stored in the database) to your apps. When the data changes in the future, you only need to replace the database for your apps.
dear programmers!
My question is about inserting data in SQLite, in such a way that there are four five items of spinner(dropdown list)
for any item of spinner there is a table in database, the tables are:
1- lcd
2- crt
3- dish => short form of dish antenna
4- antenna
5- cd_dvd_player
I have determined the algorithm in such a way when i choose any item of spinner, the data of the item should be inserted in its related table
like; above five tables, but toast message shows wrong data inserted while in fact is not inserted. The codes are as following:
if you answer my question, you would have helped a lot thanks a lotenter image description here
In short you are likely going to encounter numerous issues if you try to store large images in the Database.
The recommended way is to store the images as files and store the paths or part of the paths in the Database, using the stored path to access the images when required.
It very much appears that the screen shot is related to exceeding memory limitations.
I am converting image as a byte array to store in the database in android. For this, I have to convert image both at the time of storing and reading. I can definitely store all image in variables during runtime at once but it might take a lot of space if there are a lot of images in the database. Does conversion actually take a lot of resources ? in that case I will use other methods to store like in file (I haven't used file before so will have to learn it first, trying to save effort :) ).
I think it depends on how many images are you planning to save in the database. For instance: if it is the user profile image, which is gonna be one image per user, I think it is okay. But, if it is something like images that the user can upload as many images as he likes, I don't really think it is a good idea. There are advantages and disadvantages on both.
There are plenty discussions about those two approaches:
Storing images in a database versus a filesystem
Why is it considered bad to store images in a database?
Storing Images in DB - Yea or Nay?
What is the best place for storing uploaded images, SQL database or disk file system?
I have some entities which I hold in SQLite DB.
Some of these entities will have image as well, as I read, SQLite DB can return up to 2MB per cursor, so storing the images in the DB isn't an option.
So I guess we are left with internal storage and self managing.
Are there any support libraries for managing these images ?
Is there a recommended design for this ?
I though about saving the images with a filename scheme of entityType_id.png where the id is the entity id in the SQLite DB, but I'm afraid it may change over time (backup / restore and such) so maybe another scheme might be a better solution ?
I used the solution that you mentioned here:
I though about saving the images with a filename scheme of entityType_id.png where the id is the entity id in the SQLite DB, but I'm afraid it may change over time (backup / restore and such) so maybe another scheme might be a better solution ?
I created a folder in my Android project and used ids that will never change. Knowing the folder and the id, which I retrieve from the DB, I am able to get the image. I used the android SQLite asset helper library for the solution.
I used such an approach for this little app: MTBcat. You can find an example here: http://www.6020peaks.com/2015/03/how-to-ship-an-android-app-with-preloaded-data/
You should store all of images on the internal storage. There is a post about that with piece of code, which could be helpful for you:
Capturing and Saving an image in Android with different names and then retrieving it by any of those names?
EDIT:
I mean external storange not internal
Have some sequence to generate unique ids (maybe just store current value as property), and store the id only in the database. Name the image file by id and store the file somewhere in the file system. If you delete the record, remove the file and do not reuse the id.
Generate own ids, independent from what the database is doing. Then they will not be affected by backup/restore or things the like.
I think storing an image which size is more than 2M in sqlite is not good for reading or whiting,maybe you can compress your image before you store it.
Is it a good idea to store images retrieved from the web server via a web service in SQLITE DB. I am working on this android app that retrieves a lot of images from a web server and places them in a listview. And I would like to store the first 100 images in some storage area within an android device(That is after compressing them.) when a user first opens the app so that the app doesn't reload a fresh the next time the user opens the app . So, I am looking at SQLITE as one of my top storage options and I am not sure whether there could be a better way to doing this for the sake of improving the app performance. I have seen the question asked at Should i store images in SQLite database? and its answer, which a little fuzzy to me. Your opinion is highly appreciated. Thanks in advance.
Depends on the size of images - If the returned result of your query is going to be more than 1 MB (the binder limit) then you would have to store them as files and only store the URIs in the dbs.
For example you can look at the Contacts Provider - the thumbnails are stored in the db but the full images are not - only URI of the full image is part of the contacts database.
The question you linked too explains the best practise.
Generally, you should store the actual image files in the filesystem or memory card of the device.
Then your app can find references to them in your database
e.g.
SELECT avatar_image FROM profile WHERE user_id = 1; would return the local device file path of your stored image that can then be loaded into your ImageView.