Hi
i have plan to develop app similar to
http://itunes.apple.com/app/download-meter-for-wi-fi-3g/id327227530?mt=8
Please suggest me, which api's i have to look into?
Any tutorials avilable?
Thanks in advace.
You want to be looking into the UIProgressBar object, and the related delegate methods. When you open a NSURLConnection, you can retrieve the expected size of the thing you are downloading (this method will vary depending on where your data is coming from).
The NSURLConnection will download the object in chunks, calling the didReciveData method every time it receives a packet of bytes. Here you can calculate the percentage of the file downloaded (it will be decimal format, ie. 0.74/1.0) as you append the data and update the progress bar accordingly.
Check out the tutorial HERE
Related
I need to improve my coding.so i am finding something better.
My problem is i need to fetch the data from server from 10 different url.that url have images 100.
for example i need to hit
http://192.168.11.222/images/a
http://192.168.11.222/images/b
http://192.168.11.222/images/c
http://192.168.11.222/images/d
http://192.168.11.222/images/e
http://192.168.11.222/images/f
http://192.168.11.222/images/g
http://192.168.11.222/images/h
http://192.168.11.222/images/i
so a b c d e are folder on server that contain images.
Currently i am doing this through NSURLConnectionWithTag and then parse the response.and get saved.is there any another better way to handle this? i also need to show progress bar which is also difficult in this case.
I would setup an NSOperationQueue ,with a single operation per URL and set it to, say, three concurrent operations. Then use NSURLConnection's non-asynchronous API to do the download.
For your progress bar, it's probably good enough to update the progress after each individual file is finished, and do two of them at a time (or something). Chances are latency will be more than half the "progress" anyway, so unless you start trying to predict your ping times, a progress bar based on the actual bytes transferred will not be accurate enough to bother (unless these are very big images).
You will need to learn how operation queues and GCD work, but once you've got that sorted it really won't be much code at all, and it will be rock solid.
Basically you want to add a "block" of code to the operation queue for each URL to download, and the queue will figure out how to download each one, and then when each individual block of code is finished it executes another block on the main thread (dispatch_sync(dispatch_get_main_queue(), ^{ ... })) to update the progress bar.
If you are going to write network related code in your app, I recommend take a look at AFNetworking, it's a wrap of network API iOS already provided with much less hassle.
In my iphone application i have to recieve 1000 images from webmethod . It will take too long time.
Instead of waiting that muc time is there any process to get data from service by part by part.
Is there any possiblity let help me.
Thanks in advance.
Yes. You can do It. I've already implemented that using AsyncImageView which is inherited from UIImageView. What it does is it stores images in Cache memory fetched from a url and whenever you need to load image from the same URL again it will simply load it from the cache memory saving a lots of time.
Just follow the link for implementing that:
https://github.com/nicklockwood/AsyncImageView#readme
http://www.markj.net/iphone-asynchronous-table-image/
Update 1:
Please have a look at the image showing the technique I've implemented it lets you do other activity while images are loading.:
I can able to download a file when an URL is given using the delegate methods of NSURLConnection. When a download is active, its download progress like percentage downloaded, transfer rate, bytes received are shown in the UITableView. So, when I initiate a download, the first cell of the table is active till the download completes. Everything is perfect for a single download.
My problem is, I have no idea how to handle multiple asynchronous downloads. If the URL is given when a download is active, the second cell of the table should be activated and the progress should be shown. I surfed many blogs and forums regarding this. Many suggested to use ASIHTTPRequest. But I am trying to handle the NSURLConnections in an array and hit the requests. When I tried, the first active download is overridden by the second request.
Please help me with some ideas to deal this problem using array, without ASIHTTPRequest. Thank you in advance.
Assuming that you're making multiple NSURLConnection objects, one per request just store the connection that each table view cell is referring to in an array.
Then, when the delegate methods are called, they should all pass back the connection object that they are referring to i.e. connection:didReceiveData:'s connection parameter.
You can use this parameter to work out which table cell this delegate call is referring to.
I've not found a answer to this question anywhere, but this seems like a typical problem:
I would like to send some POST-Requests (with ASIHTTPRequest, what I already do), but if something goes wrong, ther user can decide to "Try Later", that means, the task should be put on a queue and this queue should be read next time the application starts. So, that's my question: how to "save" the queue, so that the app can read it next time it starts? Is it possible to "read" the queue and try sending this POST-Request again, let's say, 10 min later, even if the application is not running?
What kind of documentation should I read in order to be able to do this?
I would be very glad to hear any answers. Thanks in advance.
P.S.: Another Idea I have: as I just have to Upload Photos, I could have a folder with all the Photos that still need to be uploaded, and when the App starts, the app looks at this folder and try to send all the photos in this folder. Does it make sense?
My approach for this issue would be like this:
Whenever you fail to send details - write content of the array to a file using '[NSArray writeToFile:]' you can use serialization if array contain any data which is custom defined (if your array contain standard cocoa objects(NSString,NSData etc) they already implemented with serialization )
When app launches; load the content from file directly to an array object ('[NSArray arrayWithContentsOfFile:]')
then construct http request and try sending. In application the data(in your case array) is stored/serialized not the request, you need to reconstruct the http request when you want to try one more time.(don't try serializing ASIHTTPRequest, you have reconstruct it)
I'm going to assume you've already looked at NSOperationQueue and NSOperation. AFAIK there is no built-in support for serializing NSOperation, but you could very easily write your own serialization mechanism for an NSOperation subclass that you use for posting data and write the an NSOperationQueue's operations to disk if something goes wrong.
Without knowing too many details it's hard to give a precise answer. There are many ways to write data to disk and load it again later, the direction you take will be largely dependent on your situation.
I have a question and I am very open to suggestions (even very odd ones!)
I am writing an iPhone app, which does a request (URL with parameters) to a server. As a response, the iPhone receives XML. All is well.
Right now, I am looking to improve my application's speed by measuring the time it takes to perform certain tasks. I've found that, of all the tasks performed (downloading, XML Parsing, sending the request, handeling the request, parsing objects from XML), downloading the actual XML takes the longest.
Now, my XML files are very, very, very easy and very, very, very small. I use them primarily to read RSS-like data and show them in a UITableView.
My app works very well, and there is nothing that feels really slow, but there is one application in the App Store right now which does something very similar to my application, but is way faster and feels more 'snappy', if you know what I mean. It also has the great feature to load the headlines one by one from the RSS-feed.
Currently I'm experimenting with gzip compression of my data, but the compression only makes my data half the size and it doesn't seem to do any real good for performance. The main thing is, that the data has to be downloaded, before it gets parsed. It would be very cool to have a 'stream' of data, which is parsed as it comes in. That way, I can do two jobs almost simultaneous and load headlines one by one (making user interactivity more attractive).
Anyone has an idea of how to improve my performance? Either by great compression tips or entirely different ways to communicate with the server.. All is welcome!
UPDATE: putting the latency and responsiveness of the server aside; how could I get a source of XML to be 'streamed' to my iPhone (downloaded byte for byte) and at the same time get parsed? Right now it is a linear process of downloading -> parsing -> showing, but it could become semi-parallel by downloading & parsing at the same time (and show each item when it is done downloading, instead of loading it all at the same time in a UITableView)
Assuming you're using NSXMLParser's initWithContentsOfURL:, that's probably part of the problem. It seems like that downloads the entire contents of the URL, then hands it off to the parser to parse all at once.
Despite the fact that the NSXMLParser is an event-driven parser, it doesn't seem to support streaming data to the parser in an incremental manner. You could, of course, replace NSXMLParser with some other parsing library that handles incremental data in a more sensible way.
An alternative would be to use NSURLConnection, and create a new NSXMLParser and re-parse the data each time some data comes in, in the connection:didReceiveData: method of your NSURLConnection's delegate. You''d have to write some extra code to ignore the extra events from re-parsing the beginning of the file more than once.
This seems like it'd be more work than just grabbing some other library and adapting it, but maybe not, depending on how you're handling the downstream creation of your table data.
If NSMutableArray is the underlying data structure of your UITableView you should try
using initWithContentsOfURL. The format on the server needs to be in apples "plist" xml which is easy to generate. I'm guessing that if cocoa already has resources acquired for
processing xml it would be quicker to use them instead of creating your own xml parser instance.
How are you parsing the XML data. The need to parse XML as you receive it is the whole reason pull parsing was invented, and they have the NSXMLParser event driven parser that operates on a stream of data...
That also means compression of the data is counterproductive.
For very small amounts of XML, the issue of speed is probably about latency of connection.
Thus, other big factor could be the DNS lookup. You could do that yourself once beforehand and cache the IP, perhaps rechecking only on failure to connect to your server...
Since your xml files are very small, (just 8k or so, I imagine?) I don't think you'd see a big performance boost trying to parse them as they come in. You can use an asynchronous NSURLConnection to do that, but I can't see it helping with a small file very much. Have you considered the time it takes to generate the XML file on the server? Are you using PHP to create the XML, or accessing a static file? For testing purposes, it might be interesting to access static files and see how that compares.
I ran into a problem like this a while ago, and it turned out the mySQL database on my server was being slow, and it really had nothing to do with my app.
Also, use Instruments to look at the amount of memory that is allocated while you're downloading and parsing an XML document. Some XML parsers load the entire XML document into memory and then allow you to index randomly into the document's elements, while others provide step by step parsing only. The step-by-step method is much better for limited devices like the iPhone and it's probably what you're using, but a quick look at memory consumption should tell you.