I'm in the process of rethinking my approach to the request architecture of a large app I'm developing. I'm currently using ASIHTTPRequest to actually make requests, but since I need many different types of requests as a result of many different actions taken in different view controllers, I'm trying to work out the best system of organizing these requests.

I'm currently building singleton "requesters" that are retained by the app delegate and sit around listening for NSNotifications that signal a request needs to be made; they make the request, listen for the response, and send out a new NSNotification with the response data. This solves most of my problems, but doesn't elegantly handle failed requests or simultaneous requests to the same singleton requester.

Anyone have any success devising a clear, OO architecture for making many different types of requests in an iOS app?

After having tried several approaches, this is one architecture that is giving me excellent results, is easy to document, understand, maintain and extend:

• I have a single object taking care of network connectivity, let's call it a "network manager". Typically this object is a singleton (created using Matt Gallagher's Cocoa singleton macro).
• Since you use ASIHTTPRequest (which I always do, wonderful API) I add an ASINetworkQueue ivar inside my network manager. I make the network manager the delegate of that queue.
• I create subclasses of ASIHTTPRequest for each kind of network request that my app requires (typically, for each backend REST interaction or SOAP endpoint). This has another benefit (see below for details :)
• Every time one of my controllers requires some data (refresh, viewDidAppear, etc), the network manager creates an instance of the required ASIHTTPRequest subclass, and then adds it to the queue.
• The ASINetworkQueue takes care of bandwidth issues (depending on whether you are on 3G, EDGE or GPRS or Wifi, you have more bandwidth, and you can process more requests, etc). This is done by the queue, which is cool (at least, that's one of the things I understand this queue does, I hope I'm not mistaken :).
• Whenever a request finishes or fails, the network manager is called (remember, the network manager is the queue's delegate).
• The network manager doesn't know squat about what to do with the result of each request; hence, it just calls a method on the request! Remember, requests are subclasses of ASIHTTPRequest, so you can just put the code that manages the result of the request (typically, deserialization of JSON or XML into real objects, triggering other network connections, updating Core Data stores, etc). Putting the code into each separate request subclass, using a polymorphic method with a common name accross request classes, makes it very easy to debug and manage IMHO.
• Finally, I notify the controllers above about interesting events using notifications; using a delegate protocol is not a good idea, because in your app you typically have many controllers talking to your network manager, and then notifications are more flexible (you can have several controllers responding to the same notification, etc).

Anyway, this is how I've been doing it for a while, and frankly it works pretty well. I can extend the system horizontally, adding more ASIHTTPRequest subclasses as I need them, and the core of the network manager stays intact.

Hope it helps!

Hi all,

I've recently been developing an app that processes a large amount of data very frequently (~15 times a minute). To do so, I allocated a large chunk of memory, then freed it for each batch of data.

Here's a screen of my Memory Allocations from Instruments:

The Memory usage oscillates from about 3MB to about 30MB pretty quickly. I was just wondering, is this "healthy," per se for the iPhone.

Is it risky to allocate and free so much memory so quickly? Is it unsustainable, or just bad practice?

Thanks!

It is neither risky nor necessarily bad practice. Allocating and freeing memory takes time, so doing it very frequently vs. doing it once and re-using the allocated memory is a trade-off between memory usage effiency (using the lowest amount of memory at every single moment) and performance.

If the performance of your app doesn't suffer at the moment, you have probably made the correct choice regarding this tradeoff for your app.

Generally speaking, using 30 MB of memory is quite a large amount for older devices (iPhone 3G and older). You cannot be sure that your app has that much memory available so be prepared to received memory warnings. If your app cannot reduce its memory usage when it receives a memory warning, the OS might kill it.

I'm trying to make a bunch of buttons behave somewhat like float:left in CSS. So whenever the view changes size, on orientation change for example, the buttons should adjust so they fit within their container view.

In landscape mode, this UIScrollView should scroll horizontally, in portrait mode, it should scroll vertically.

I'm trying to make an ScrollView similar to the "Featured" tab in the iPad YouTube app. Landscape has 4 columns, portrait: 3 columns, "Subscriptions" tab, portrait, the same view has 2 columns.

I have implemented a layout system to do things like this. There is a demo project on how to use it checked into that repository. I'd be happy to answer any questions about it. This is much more lightweight than AQGridView, so if you don't need the extra functionality he is providing, I would recommend an approach similar to mine.

This question (or variations of this question) has been asked before, but as Apple's export compliance rules change relatively frequently, and no one seems to ever get a straight answer, I thought I would ask.

I write an iPhone application that uses version 0.2 of the Dropbox API.

I have emailed Apple concerning use of this specific API, and I will be sure to update this question as I learn more and hear back from Apple. In the meantime, if any developer is using the Dropbox API in their iPhone application, did you mark your application as using encryption?

Edit: Upon closer inspection, it looks like the file data is also transferred using SSL. Since their API is using the NSMutableURLRequest class over HTTPS though, I still can't determine whether or not this API "uses encryption." If in the App Store submission page I mark that it does include encryption, Apple then asks if I'm using greater than a 64-bit symmetric encryption key.

If your app uses SSL (HTTPS), then yes it does include encryption. The export compliance rules changed last year though, so you will need an Encryption Registration Number instead of a CCATS number. See this blog post for details.