Is conversion of image to byte array in android heavy task? - android

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?

Related

How to insert your own image into a SQLite table?

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.

Android: uploading user images to server (Volley/Blob)

I want to perform a simple action, to upload user images from the app to online server to store them and to have them available for future uses.
For that purpose, I will use Volley library.
Basically I would convert the image into Base64 format, send it to server, and store it.
My question, however, is that I have read answers to other questions here at stackoverflow about BLOB for storing data into database. Could anyone explain if BLOB is needed in this case or if am I mixing concepts here?.
INFO: My initial idea is to store the images in another folder in the server, and maybe the name and the path to the images in the database...but not the image in the database.
Making your own external Folder for saving images would be better than saving the Images in the database , because when you save the images as BLOB in the database some of the problems you face in database transfer is that, the database becomes to huge to transfer , but when you create a folder aside and you just call the names of the images in the Database , that is much more better. and Volley is also good in this.
If you need like a code sample i can post it
Thanks .

How to store large Data in application?

I want to make image backup through my Application what is the best way for storing large amount of data . I tried to save image in sqlite database it worked fine for small amount of data in case of large amount it shows MemoryOutOfBoundExceptions after increasing the Heep size(android:largeHeap="true").
please help me guys .
If you want to save only image or any file try to save only path of that file in database.After that you can get file path by normal SQL query and access file from file path.
Instead of Storing Large data in Application you have to store it DataBase so it will speed up your Application and you have no Exception produce like OutOfMemoryException in your Application.
You don't store images in databases, that makes the database huge and slows it down. Store the images to disk and store the path to the file in the database. This will make the database a lot lighter and faster.
If you're developing for Android, i'd also recommend using something like Picasso, Fresco or Glide to display your images too. They cache the image and use memory efficiently when doing operations like scaling images.

SQLite and storing images

I wonder which way is better to store images in memory:
Storing images as BLOB in DB
or
Saving images to file and store only path to it in database
What way is more efficient? I suppose that storing files' paths requires more operations because we need to refer to DB and then to file, but I'm not sure if this is less efficent than keeping whole images in DB.
In a nutshell:
If size of your images are fairly small and number of images are also less, go for storing directly in database, as it is simpler to manage.
However, if size of your images in large and also number of images is high, go for saving in file system. Typically, database don't show any performance issues until 10MB for an average mobile.
Let me know if you find any other criteria of judgement.

Android: Saving images into Sqlite database

im wondering if storing images as BLOB in the sqlite database would be a good idea?
Does anybody has performance - experience with storing images (blob).
My android app would be a small one, which will need to handle 20 to 100 images (100 kb up to 1MB per image). Worst case: I would say, that my database could reach a size of 100 MB. Does this has significant impact on the database performance?
Average case: I guess the average user of my app has 40 images with 200 kb per image, so the size of database would be around 8 MB.
Btw. of course the database stores also other "normal" data, so its not a image database only :)
Is storing the path to the image which is stored on the storage(internal or sd card) a better approach? I guess that retrieving the image file path from the database and open and load the image from file would be a little bit slower (but not really significant, since I need to load only two images at once).
A second question:
If I would use the second approach (store the path to image file in the database and load the image file):
Does a disk cache (DiskLruCache) is something useful in this scenario? Would it bring a significant performance boost? My understanding is that a Disk cache would store bitmaps (instead of encoded jpg or png) and therefore a disc cache would load a bitmap directly from storeage and my app would save the time to decode the image(jpg or png). Is that correct?
Btw. In the "database approach" i would store the image already decoded as bitmap. So it seems to me to be something similar as the disc cache, isnt it?
Edit:
I forgot to tell you, that i need to store the images persistent on the device. Im not talking about caching images that for example I have retrieved from a web service ...
My guess will be that the database will get significantly slower if you store that much of information in it, especially when you retrieve the images themselves.
On the other hand, as I get it, every user has the images associated with him downloaded after the application is installed. This is perfect place for using a library another SO user recommended to me in a question of mine I asked couple of days ago: Universal Image Downloader. Here is a link to the thread I speak about.
This library uses on disk caching, but abstracts away all the complexities for you (hopefully, I have not yet tried it, but it seems promising).

Categories

Resources