I have an app holding an array of instances of a class called SwimmingPool.
At present my application persistence is dealt with by encoding everything into NSData and saving that to the iPhone. This is then reloaded everytime the app starts.
I have a few friends populating their individual applications with instances of SwimmingPool. I want them to send me their application information. I will then import it all into my 'master' app, pooling everyones SwimmingPool instances and finally I will submit the app to the appStore.
My question is, What is the best way for me to receive their data? Is it possible for my app to encode to an instance of NSData and then export that to mail on the iphone/ipod touch? (they can email it to me)
I will then create an import method to parse the individual swimming pools into my main NSData.
Is this possible?/the best solution?
Thanks alot everyone who has answered my previous questions. I hope to contribute to this community as much as I can. (not just with questions!)
Dan
I would have the app post the data to a server via HTTP.
Is it an app for Skateboarders to locate empty swimming pools? Great app idea!
You should take a look at the NSURLConnection class, which allows you to post data to a HTTP server, or retrieve data from it.
If you don't need the fancy asynchronous download of the HTTP request results, you can also look at [NSData +dataWithContentsOfURL:] to fetch the results synchronously.
Related
Can i send location updates to my server in background from iOS4?. I want to get users location changes and post it to a server using a web-service call. Main question here is, is it possible to call a web-service or http-post while app is in background?
Absolutely, and you may want to review this earlier thread when I asked the same question - credit due to #RedBlueThing for providing the key information.
I've written this up as an example on our blog as well. The key to this working is beginBackgroundTaskWithExpirationHandler: without that you won't get reliable results as it will perhaps work some of the time, but not others.
Yes. You can basically do anything you want in the background callbacks.
I'd like to add that you should make sure you are aware of the possible impact on battery life, as the antennas may have to be turned on to perform your requests. Perhaps you could store the locations in core data, and post it to the server when the app resumes.
But there's no technical reasons to not do it, and afaik it will pass review too.
I am currently developing an application which makes HTTP request (via AsiHTTPRequest) then parse a JSON stream. Basically there is a tableView/NSFetchedResultsController, which print objects fetched from coreData, and the refresh is hand-done via a UIButton. I want my page to see the changes (so I implemented the NSFetchedResultsController).
But if the user refresh in the underground for instance, then the parsing will be differed, waiting for the answer of the request. Meanwhile the user can navigate and click on a Core Data object, which ca be deleted while he's reading it.
What would happen ?
Also, what is the best moment to save the context ?
Or is it better to use 2 context and then synchronise them ?
Thanks in advance for your opinions.
Niels
With a good use of the NSFetchedResultsControllerDelegate, only one NSFetchedResultsControllerDelegate is sufficient.
Hope it helps,
Niels
I have an iPad app that works both on and offline but when I am offline there are web service calls that will need to be made once online availability is an option again.
Example:
A new client is added to the app, this needs to be sent to the web service but since we are offline we dont want to slow the user down so we let them add locally and keep going but we need to remember that that call needs to be made to the web service when we can. Same thing for placing orders and such.
Is there some sort of queue that can be setup that will fire once we have connectivity?
I don't think the overhead of a heavyweight tool like MSMQ is needed for a simple action. You can use Core Data, persist managed objects with the data needed to call the web service, and only delete each managed object after a successful post. There might or might not be a way to capture an event when connectivity starts, but you can certainly create a repeating NSTimer when the first message is queued and stop it when there are no messages in the queue.
This library handles offline persistent message queueing for situations like you describe. It says alpha from a year ago, but I have confirmed it is used in production apps:
https://github.com/gcamp/IPOfflineQueue
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 am just testing an app to get data off our web server, previously I had been using:
NSURL, NSURLRequest, NSURLConnection etc. to get the data that I wanted.
But I have just noticed that if I swap to using XML I can simply do the following and pass the results to NSXMLParser:
NSURL *url = [NSURL URLWithString:#"https://www.fuzzygoat.com/turbine?nbytes=1&fmt=xml"];
Am I right in thinking that if your just after XML this is an acceptable method? It just seems strongly short compared to what I was doing before?
gary
That code only creates a URL object that represents a URL. It doesn't make any request or download any data. You still need to use NSURLRequest and NSURLConnection in order to actually download any data from the server.
Also, stay away from methods like 'initWithContentsOfURL:` and friends, unless you understand that they will block the thread that they are called on until complete. For network services, this method shouldn't be used because it'll block your UI for an indeterminate time, because you can't predict how fast the internet connection will be wherever the app is used.
NSURLConnection's asynchronous request system is exactly what you need. It won't block the UI, and provides a nice encapsulated interface to downloading data from a remote location.
This is definitely the right way to go. There do exist many different connection methods (including my favorite, ASIHTTPRequest) and many, many different xml parsers (including my favorite, KissXML) that are faster or more memory efficient than the Apple built in methods.
But to answer your question, yes, your logic and design pattern is correct.
UPDATE: Because Jasarien seems to think the question talks about asynchronous actions, I will discuss that here. ASIHTTPRequest handles async very very easily. Just check out the quick samples.
Depending on how much XML you get back from the web service, NSXMLParser may not be ideal because the entire XML document has to be read into memory.
Memory is pretty scarce on an iPhone, so using a SAX parser like that in libxml2 is probably better for larger XML files. Instead of reading the entire document into memory, the XML is streamed through and parsed for specific nodes of interest. The memory overhead is lower because less data is stored at once.
Once a node of interest is parsed, an event handler is called to do something useful, like store the node data somewhere.
In this case, take a look at Apple's XMLPerformance sample project for example code.