The scenario is, I have a Web Dashboard (Developed using PHP + MySQL) and have Android and iOS Apps synchronizing data from the Web Dashboard (only one way i.e. Dashboard to Mobile Apps)
Now the problem is that, on few screens in App I need to show images which will be captured in Web Dashboard via file upload.
Firstly, I designed the tables such that to store the image paths. But in that way both the App’s needs to run a background service of something to fetch the images from those URL’s once they get the Table data in JSON Format.
Later, I changed the DB Design to store Image BLOB, which made this job simpler, but while synchronizing, if I have around 100 Rows with Image BLOB’s, it’s taking a lot of time to Sync. The number of rows is going to increase further.
And for the first time, when the App’s are installed I’m supposed to Sync all the data at once then on interval only incremented transactional data.
So the main problem is with First time data.
Any suggestions on how can I provide a better solution?
3
On file size
You need to deal with the vast array of issues that come from the sheer size of images – whether compressed or not, images range from hundreds of KBs and up – which is tens to hundreds times larger than the typical amount of data your frontend/backend handles per operation.
Therefore, the first strategy is to focus on reducing the image size. Don’t bother with techniques that only improve a few percents – to make things improve, you need an order of magnitude better compression.
The best file-size-reduction approach is to scale down the image – as much as you can without making your users angry.
If you use JPEG or WebP (or some other lossy formats) you can try use different quality level. Sometimes the best trade-off is obtained from a combination of scaling down and adjusting quality level. Don’t limit your scale-down factors to powers-of-two.
The second best image compression approach depends on the type of image content. You will need to learn about the basics of compressed image formats, and be creative applying those basics.
In one very simple approach, large areas of uniform color is simply cropped away from the image, and replaced with a background color – to be painted by the app – using the same RGB hex.
On versioning
The backend database needs to be able to serve a checksum, timestamp (last modified time) or file version number that serves to inform the app whether they have the most up-to-date file.
On keeping the user from boredom
You might need to show small, fast-to-download thumbnails (which are scaled down versions of the image) just in case your app users are quick-tempered. Make sure these thumbnails are properly cached by the backend – loading the thumbnails from disk adds to the latency, which defeats the purpose.
On backend image processing
It looks like the prevailing advice on Programmers.StackExchange is to keep a queue of image processing operations to be performed; the queue to be executed by an out-of-process ImageMagick worker process; results are added back to another “finished queue” to be handled by the backend.
0
I would only sync the URLs to the images stored on the server, not the complete image as BLOB. So the sync is fast and the images must be loaded ‘on time’ when they are used/displayed.
Edit: I saw, that your first solution was something like that. So sorry, no news for you, but I still think lazy image loading should solve the problem…