I have an app that gets data from web api.
I am returning some info and image from web api. I have 2 options for image and these are:
Return image link(web address) and download it with async task.
Return image in base64 encoded string.
I would want to know which is faster and better idea?
Thanks.
I would say this depends on the way your application is workingand what it needs,
The data itself is the same, so just think what would fit your app better,
I'll give some examples:
If the web api returns many responses with the same image and different info, you might want to use another server so you could use caching systems / cdn and than better perform your app
If it would help you that the "info" will reach to the app before the image (so you could load it first), you should also use the first option, and when the async proccess ends display the image (just an example...)
If you want to spare computing resources from the api servers every time it is used (encoding the image to base64 ect..) you should also use the first option
If lets say, you want to make sure that all the data comes at-once and non of the above is relevent to you, maybe you would prefer the second option
If you want to avoid async requests or having multiple requests every time may be the second option is better for you too
So, its just up to what your app needs :)
Hope i helped
Related
I don't know this title is clearly reflect the question content. Please help rephrase if you think it is confusing. Thanks!
This is a generic question about some common architecture. I am working on a Android app that can take and share photo just like Instagram. And I have a backend web service powered by Django.
The issue I am facing is, in the app, I will need to show different resolution of image (for example, thumbnails for profile image, mid-resolution for previews, and full resolution for expanded image views.) I want to ask a common pattern about how to make this happen.
I have two proposals on doing this task, and not sure which way I should go:
1.When user upload photos from the mobile app, I can compress it locally and send 3 different sizes (low res thumbnails, mid res, and high res). So server side can store them and return them back in different cases. The Con of this approach that I can think about is it will drain more user's data usage because now user will need to send multiple images. It may also cause uploading take more time and higher impact in user experience.
2.When user upload photos from the mobile app, they only upload the original image. The server side logic will do the compression for each income image, and store them accordingly. The Con of this approach is server may need to carry a lot more workload. In this case, if user increases a lot, it may crash the server.
I am hoping to get some pointer on this issue, or any reference about this topic will be helpful!
Upload the full size image to the server and have the server do the heavy lifting. Create three version of the image (small medium and large) and store them on the server (or content delivery network). Create a database table to keep track of the image id for each image and its various versions.
With android you wont know how powerful the phone running your app is, never assume it can handle whatever image manipulation you need, also try and keep network I/O as low as possible.
Alan - Think of smart phones as relatively dumb terminals made for purpose of consuming content. Most of the business logic and heavy processing should me implemented on server side.
In terms of architecture, you are facing scalability problem. You cannot expand cpu/memory or storage of a device to any level you want. However you can scale your servers horizontally or vertically by adding more ram/cores/disks etc. You can put cluster on server and have a farm of servers if data increases to that level.
So its always advisable to just upload the original image without locally processing. Locally processing also drains battery besides other downside you mentioned.
Again you business logic or processing technique changes, you have to redeploy all apps. Where as on server side such deployments are very well in your control.
What i would do is a first resize in the mobile, just one, because you dont one to transfer 13Mpx picture and also you dont want in your server a picture 2 screens wide (this is the first thing instagram does). After that, upload the file, and have the server doing the rest of the stuff.
this avoid a lot of that usage
ensures that will work fine in any device (every one has different capabilities, so you cant trust them for heavy work)
You can change some decisions about settings or configurations, and all this is centralized, if you change any common behavior, you don't need all the devices to get the last version of the app.
About crashing the server, there is one first measure i would take:
Don't do any operation, like re-sizing or making copies of the image in the moment of the upload, you can choose one of this approaches:
Do it when there is a request for the file. this is, dont do it when the user sends it, but when somebody needs it.
Do it in a continuos backgorund process, like a cronjob running every minute, for instance.
or a combination of the two, there is a process in the background doing the stuff for all the pending images, but if somebody enters in the website and they need an image that is not yet generated, it is generate in that moment.
I'm developing an Image Manager in Android. It will always check images in servers to draw...
I use a Disk-cache to cache images in SDCARD, and i must refresh them by cycles for some minutes..
But, Performance is not good if always update non-changed files.
How to check a changed status of an image? I want only get changed-files...
Can get a hash-code of image? or check-sum code?
I thinked a soluton: create a XML file on server, that stores all hash-sum list...
But, it not possible... so, Images are stored in many many sites...
thanks!!!
A simple solution:
Attach a time stamp to each image every time it is updated/modified.
On each refresh cycle, get only the time stamps of images and compare with timestamps of images on device.
Only download images which have timestamps greater than that of the corresponding cached images.
This way, you'll only be downloading text data (very small in size) in each cycle and image downloading will only be done when it is necessary.
You can also wire up your backend server to respond to a REST API and return only the updated images. The decision on whether to handle the calculations and logic on client side or server side will need considerations of the tradeoffs involved and will depend a lot on your apps specific requirements.
I have an android application, that will call a SOAP web service for some data.
For the purpose of this question, we'll assume its data about cars.
I've got as far as returning text data about the car (make, model etc), that is the easy part. I'd also like to return an image of the car some how.
So far, I see two viable options :
Retrieve the image in the SOAP response (don't even know if this is
possible)
Retrieve a URL in the SOAP response that points to the image,
perhaps a URL to a web image
Could anyone please give advice as to what is a robust solution for achieving this?
Thanks
Option 2, definitely. If you do option 1, you're limited to displaying only after you've completely downloaded the entire message, including the encoded images. That can take a while. On the other hand, if you just include URLs, you can download the message, render your UI, then download the images and update those image views dynamically as the images finish fetching from the web. This results in a much more responsive UI, especially in a mobile environment where your data connection may not be as fast or reliable.
Here's what I'm trying to accomplish:
After user takes a picture with the android camera, I want to save the image onto my Ruby on Rails web application (like PicPlz or Instagram)
Approach 1: After user takes the picture, convert the byte array and save as .jpeg on the phone. Then upload the image file onto the server through a post request (Link here)
Approach 2: After user takes the picture, post the byte array data directly to my web application's web service, and then have the web application convert the byte array into an image file and save it onto the server
Question: Which approach is faster and more efficient?
I'm also open to suggestions for other approaches.
Thanks for your time and help :)
The answer is inexplicably the server, especially if you can get Image Magick installed on the box and convert the stream from the command line. I use PhP, but to my understanding running commands from Ruby is very similar and easy.
The phone... nine times out of ten is going to be running a whole lot of background apps and you will never be able to rely on it to do anything quickly. People install garbage on their phones and never clean it up just like they do there PC's and Laptops.
Approach 2 is better.
There is another approach that u can take.
- store the byte array into a temp file before u start sending it to the server.
- This makes sure that u don't lose the data even if there's a problem with the connection.
- Once the upload is complete, ur application can erase the temp file.
- One more advantage of this approach is that u can make sure that the user can make use of ur application, even when they are not connected to the internet.
- Once the user is connected u could ask them, n then start uploading to the server.
I need to load several thumbnails (the images on the server are full sized images, so I need to resize them in the app), and display them in a way that allows for the user to click on one (or more) and have some associated id be given back to the app for use in a larger context.
so, in pseudo code...
ImageObjArray ioa = loadImagesFromServer("http://server/listOfImages.php");// this returns
for(ImageObj io : ioa){
drawThumbnail(io); //io contains both a jpg and a reference id
}
//later when a user clicks on a thumbnail
clickHandler(){
passIdToBundle(this.refId);
}
So, I've never played with a webview before but I suspect it might be the best approach here, though I don't know how easy it is to send info back out of a webview to the larger app when the user clicks on a thumbnail. Or is there a more elegant approach?
All advice welcome.
Using a WebView would be the quickest way to implement this. Otherwise, you have to fetch each image and write them to the device in order to display them in a native Android widget. There are several ways to approach this, like: http://www.dreamincode.net/code/snippet4724.htm
You can use WebView.addJavascriptInterface to communicate with native code. A good example can be found in the WebViewDemo from the apps-for-android project on Google Code.
You might want to consider a framework like PhoneGap to help with the Java to JavaScript interface.