I'm trying to build an navigation app with place location and its photos.
I have 200 spot location names (String), its location (GeoPoints), and its image (JPG).
is it possible to upload the database including the image instantly?
I only managed to upload the String and GeoPoints database using json, but still can't do it for the image file.
anyway,
clicking one by one is definitely not an option. I got 200 images and still counting. It might reach 500 or more in several weeks.
thank you in advance,
how large are the images?
if you can scale (photos) them down a little bit and if you have multiple threads on the httpclient being used with parse.com then you should be able to saturate the WIFI / ISP bandwidth available to your device.
ie if you've got 10 Mb available upstream to the ISP then you ought to be able to optimize the use of multiple , async connections up so that you are pushing close to 10Mb of photos to parse.com.
It probably wont help much ( parse - android example ) but this was precisely the target of this question.
63 photos ( each 70K in sz ) upload in 3 seconds total .
Related
I am currently developing my iOS application which includes some feature uploading images in one time along with its album name.
I came up with a solution to use encoding base64 image in order to send nested json format instead of using multipart form data method.
My question is on my localhost, it seems like my application is capable to send many pictures in one time, let say 15 pictures. However, when it comes to sending through my web server (Amazon EC2 free tier), it seems like my application is capable to send up to 4 pictures at a time, if there are more than 4 pictures, nothing would appear.
I have tried to debug on networking part, it turns out that status 200 is returned with no images sent. My question is that does the problem occur due to server stuff or something ??
Updated
I think I've found some important insight. I will classify into two scenarios. What I have found on simulator debugging is that
i) I use a simulator to connect with my server. When I send only one picture, the size of it is around 252 bytes. Sending two pictures, they are 450 bytes. The weird thing is that sending more than 3 pictures, its size is calculated to be only 208 bytes. This is very weird, it is supposed to be higher when a number of pictures increases.
However, I remember that things work perfectly fine on my localhost; thus I try to debug on a simulator that connects with localhost to figure it out more.
ii) I use a simulator to connect with localhost. When I send one picture, it has 252 bytes. Sending 2 pictures, it is around 450 bytes and sending 4 pictures, it is around 1152 bytes. We can see that data's size here is growing when the number of pictures is increasing. The scenario ii) does make sense.
Anyway, I still have no idea what causes this problem; I believe this should involve with server stuff for sure. Please help !!
The following code fragment
for($i=0;$i<60;$i++){
$u[$i]=$_REQUEST["u".$i];
$pic[$i] =imagecreatefromjpeg("http://graph.facebook.com/".$u[$i]."/picture");
}
is taking more than 90 seconds to execute on my new server. It was taking less than 15 seconds on my shared hosting server. However, on dedicated server it is taking more than 90 seconds.
The data center of my new server is Asia Pacific.
Please advice on how I can reduce this time of fetching images on the graph.
thanks and regards
Why not just request all the pictures' URLs in a single call?
https://graph.facebook.com/?fields=picture&ids=[CSV LIST OF IDS]&access_token=ACCESS_TOKEN
You'll then have a list of all the images and can fetch them all however you so wish
is taking more than 90 seconds to execute on my new server.
Well, for 60 HTTP requests that’s not too bad, I’d say.
It was taking less than 15 seconds on my shared hosting server. However, on dedicated server it is taking more than 90 seconds.
Maybe the connection of your old server was just faster …?
The data center of my new server is Asia Pacific.
Do you know by any chance, which one it was before?
Please advice on how I can reduce this time of fetching images on the graph.
Do you have to request all these images in one go?
Maybe your app’s workflow (which we don’t know anything about yet) would allow for other approaches, like getting user images at a previous time (f.e. when a user starts using your app) and cache them locally, so that you don’t have to do 60+ HTTP requests in one go.
We have an application on iPhone. This application displays 25 products per page/screen. The text items such as product name, price, discount, URL of the product image, etc of all the 25 products is downloaded from the server first.
After that we make 25 synchronous requests to download the 25 product images, one after the another. Each image is about 25KB in size and these are of size 300 by 400 pixels approximately and we only need 72 by 72 pixels size images for display on iPhone. We notice that it takes about 40 seconds to display one screen/page and this sort of performance is not good. So we are investigating how to increase the performance.
Will the performance improve if we scale down the size of the images on the server to 72 by 72 pxiels.
Also is it possible to download all 25 images from server to the iPhone? If so can you please share your approaches as to how to do that? We want to do this only if it can improve the performance.
I suggest you ask this on Stackoverflow as already mentioned.
From a programmer's perspective, if you only need 72x72 images, you should definitely bring that. You'll be saving bandwidth, battery and processing power.
Then 25 sync requests seems like a bad idea, why not bring an entire page (or two pages) at the same time?
A URL request is "slow" by nature, so the less you make, the faster it will work.
I'd modify the server to allow batch fetching as in "give me the first 25" and then you process them locally. Then you can fetch the next 25 asynchronously (and preemptively) for when the user presses next you already have it (and always have 1 or 2 in advance).
Use Cache, save them locally if you can and always check if that page is available locally, so you don't have to re-fetch the records if the user presses back and then next again. What's downloaded stays downloaded :) Product pages should't change that often.
For more specific implementations, I suggest you jump over to StackOverflow.
We have an application on iPhone. This application displays 25 products per page/screen. The text items such as product name, price, discount, URL of the product image, etc of all the 25 products is downloaded from the server first.
After that we make 25 synchronous requests to download the 25 product images, one after the another. Each image is about 25KB in size and these are of size 300 by 400 pixels approximately and we only need 72 by 72 pixels size images for display on iPhone. We notice that it takes about 40 seconds to display one screen/page and this sort of performance is not good. So we are investigating how to increase the performance.
Will the performance improve if we scale down the size of the images on the server to 72 by 72 pxiels.
Also is it possible to download all 25 images from server to the iPhone? If so can you please share your approaches as to how to do that? We want to do this only if it can improve the performance.
1.if you resize them to 72x72 then you will a have smaller size to download in total so it's faster.
2.for batching i don't have a solution but you could try to make an asynchronous request for each file. while downloading put a temporary image(a logo or something). when the image is downloaded replace the temp image with the new one.
you can put the images in a cache in order not to download them every time.
for asynchronous download you can use ASIHTTPRequest(it also has a cache class).
if you do synchronous requests then your GUI will freeze until they are finished.
First off, scaling the images on the server is a complete no-brainer - there's no need to download any more data that you absolutely have to.
Once you've done that you'll see a marked performance improvement, which you can further increase by using placeholder images and downloading the real images in the background asynchronously. (The ASIHTTPRequest library is a nice wrapper for such functionality.)
Finally, if appropriate you should use an image cache and store the images locally (perhaps with references in an SQLite database). However, you'll need to perform maintenance on this occasionally to keep it within a sensible filesize limit.
**You can use sdwebimage framework for images download from server in ios **
**You can use this link **
go to this link
download frame and get information , how to use it.
I'm having issues with audio files on the iPhone web-app. Seems as each time an audio file is played, it's loaded first then played, even if repeating the same audio on a page that hasn't refreshed (done via javascript). From what I've research manifest files would be great but they are for offline application. I'm now researching HTML5 databases.
Does anyone know if HTML5 databases can store audio files such as mp3? The end result it then to pull the mp3 from the database. It might still have to load the file each time from the database but I'm hoping it's quicker than retrieving it from a server.
Thank you.
I think what you are after is possible, however you have a significant hurdle in that the implementation of HTML5 databases on most browsers is limited to 5mb as per w3c recommendations:
A mostly arbitrary limit of five
megabytes per origin is recommended.
Having said that the way its implemented in iPhone Safari is that databases can grow until they reach 5MB in size at which point the browser will ask the user if they wish to allow for the extra size, asking again at 10, 50, 100 and 500MB (see section "Estimated Database Size" in this post by html5doctor).
There is no limit on the number of databases you can build per domain in safari, however according to this post by Cantina Consulting you can have a total of 50MB across all databases in a single domain.
Given these parameters, a possible work-around for this implementation is to split your mp3 blobs across multiple databases, creating a new database each time your reach 4.9MB, however even if you follow this design it may not be ideal as you will still experience the following:
50MB is not a lot of audio files, a typical 5/6min song is about 5MB at 128Khz, so that only gives you space for about 1CD (60 min) of mp3 songs, after this you will need user cooperation to use additional database space.
You will still have significant security issues trying to play the mp3 blobs from the javascript runtime, it may be possible to bypass these tricking flash into thinking they are mp3 stream but I'm not sure how you'd go about it.
Feel free to have a play around with this iPhone HTML5 SQL Client I put together, you may want to use something similar for experimenting with your local mp3 Database.