I have an android application that allows users to upload images to their account. Im storing the images as longblob files in a mysql db and pulling them from that but I have read on here and other places that its more efficient to store your images in a file system. I know it will work for my alpha to show but its already sucking up space in the db.
Ive seen plenty of people on here and other places mentioning file systems over using a db however....no one makes any references to specific file system software or set ups. Ideally I need a system that would allow for the fastest retrieval of images from it and it has to work with a query from php.
Any tips on the matter would be awesome :)
You could store the images on the file system, and use the database to keep a file-pointer, which is simply the path to the location of the image on your system. Then, use a query to fetch the location, and use that as you would for any image.
This thread on DaniWeb shows how uploads could be handled:
http://www.daniweb.com/web-development/php/threads/162230
Also, use relative paths in case you wish to move the location of the images in the future, as mentioned in the chosen answer here:
When storing Images in the File System, Use relative paths or absolute paths?
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.
I am developing an E-commerce application. Here I need to show lots of product images when the app is up. I have stored few product images in the drawable folder to reduce the network usage. I am planning to download delta product images when the new product is added in my back end product inventory and save it in SQLite database.
In the app I have to refer two different path ( drawable and SQLite database) to get all product images.
So how can I move the initial fish images in drawable folder to SQLite database at the time of APK generation OR after the app installation (in onCreate method of my MainActivity). And I also need to delete those initial images in the drawable folder after moving it to SQLite database.
Any suggestions are appreciated. Thank you in advance.
The bottom line is that if you deliver with content bound into your APK, it will remain there. Assuming you're planning on distributing through the Google Play store, the only way to modify this via an app update, which is obviously extremely hacky. So if your goal is to discard initial drawable resources, you cannot do this.
My advice is to compress the images as much as possible and only provide one image size which you can resize at runtime, so use the nodpi drawable resource folder (i.e. drawable-nodpi)
The alternative is to download the images via network. Though you say you don't want to do that the file sizes can be made quite small and so the download fast in most cases, so unless you're sure network connectivity will be a problem for your users it's a viable option.
Background
Currently I am working on a project that needs to deal with all images on Android phone. Android provided the MediaStore.Images.ImageColumns, together with ContentResolver I can access meta data like longtitude and latitude of all images.
Question
What if I want to mark the photos with custom tags, and query photos with these tags, like, retrieve all photos tagged with "food"? What are the possible ways to do this?
Possible solution
For jpeg files, one can use ExifInterface to add attributes(the setAttribute() and saveAttributes() method). But according to the document:
This is expensive because it involves copying all the JPG data from one file to another and deleting the old file and renaming the other.
Is it efficient enough when I have thousands of megapixel jpeg images?
I was considering building another database that syncs with the MediaStore database regularly. Better solutions?
I have an app that downloads many images that are about 50k to 100k in size. The full database can be anywhere from 50MB to 500MB.
We are currently using sqlite, but it has slow inserts. We did a test writing files and that was slow as well. It seems to be taking about 300 to 800ms per image to write - which comes out to about 250kb/sec (slower than the network speed). I did a benchmark with A1 benchmark and it says my write speed is 14MB/sec, so i'm not sure why my app is so slow?
Here are the primary requirements:
1) Fast writes
2) Fast reads/lookups via an custom integer key (this can be converted a file path for individual files)
3) Prevents user from easily accessing the images (if we save as images they can connect the external storage to their computer and browser, but we can write the files in reverse byte order)
hopefully we can still use the sqllite solution, as i like one file, but either way it seems like a storage issue?
As suggested in the comments, I think you are better off using the private memory storage for the actual images. This will have better speed then storing BLOBs in SQLite.
If you still need to keep a DB, for example for complex image searches or such, I suggest you just replace the BLOB field in your DB with a string with the actual location of the image file.
Another solution is to keep the images as app assets, but this assumes the images are always the same and can't change dynamically, and I doubt this is your use case.
I want users of my app to be able to view a gallery of profile photos on their phone but I'm not sure about the best way to store the gallery on the server? I'm using Postgres and a Java web service.
Should I store the images (or only a thumbnail) on the database or store only the paths and use a separate web server as I have read some people do? I wanted to make it as Android-based as possible so I wouldn't have to rely on having a web server to serve photos, but is there no way around it?
I have read about Postgres extensions to hold image files but I don't know if this is the most efficient way or not (I suspect it wouldn't be).
It really comes down to the size of the photos and how many of them you plan to be storing. Sometimes the database can be a viable option to store small thumbnail images, but generally this probably isn't the cheapest or most scalable solution but could avoid system complexity for a small project. For most projects I would go for file system/blob storage for images.
You should store both your full-size photos and thumbnails in the file system and store only paths in database. This would be more performance efficient.
You will probably need web server in order to protect who can see which photo.