The connection would initialize and then run without a hitch. As I was hoping to port the app over to the iPad, I decided to test it using the iPad simulator under 3.2. However, once the app hit [c start];, I immediately got a EXC_BAD_ACCESS exception and the app crashed.
On further inspection, it seems as though the app will obey the startImmediately boolean on an iPhone device, but is strangely ignored on an iPad. I gave the documentation a read-through, and I couldn’t find anything of the sort.
A somewhat simple but annoying work around involved starting the NSURLConnection request immediately and removing [c start];:
In your iPhone app, you’ll probably be spending most of the time pushing new view controllers to the stack in order to show screen flow. Sometimes, though, you just want to popup a screen for quick display or input.
Here’s a quick demo/tutorial on the different standard modal views offered by iOS, including a simple way of passing generic string data back to the parent view. I’m assuming basic knowledge of iPhone programming, so feel free to skim if you’re comfortable.
First up, create a new Xcode View-Based application. I named mine “ModalViewExample”. Open up the NIB file “ModalViewExampleViewController.xib” and drag four buttons onto the screen as shown.
Now, we’ll begin attaching the buttons created in Interface Builder to our View Controller code. Open “ModalViewExampleViewController.h” and declare your buttons as IBOutlets (Interface Builder Outlets):
Ok, so now we have some buttons declared in our class, and some buttons dropped into the interface. At this point, your app has no idea what the relationship is. We’ll set these relationships in Interface Builder.
Switch back to your NIB file, and select “File’s Owner” in the NIB Object Window. Select the Connections Inspector tab, and drag a connection from the hollow point to the Button object in your View. You can see what I mean in the screenshot below. Repeat for the other buttons on the page.
Basically, what we’ve told Xcode to do is relate the code-based objects with the interface objects we created. This allows them to pass messages back and forth.
The next step is to actually assign methods to the click events. Go back to your ModalViewExampleViewController.h file and add these methods:
You’ll also need to implement them in ModalViewExampleViewController.m:
We now have definitions for buttons, and the actions to go with them. To connect them, go to Interface Builder. Select one of your buttons and drag a relationship between the “Touch Up Inside” event in the Connections Inspector and the First Responder in the Object Window. Select the name of the method you created.
After connecting all the buttons to their relative objects and actions, you’ll actually need to make the app do something. This is where we will define a modal view to present to the user.
Add a new UIViewController subclass with XIB to your project. I named mine “SampleViewController”. Open the XIB in Interface Builder and drag a new button onto the screen.
Once you’ve done that, create an IBOutlet for the button and define an action as above.
Be sure to go to Interface Builder and assign the connections as you did above. Once that’s done, you’ll need to synthesize and release the dismissViewButton object in SampleViewController.m as you did in ModalExampleViewController.m.
Assuming all your connections are in place, it’s time to actually do something with them. Switch to your ModalViewExampleViewController class and replace your previous method definitions with the following code. Also be sure to add #import “SampleViewController.h” to the top of your definition in order to expose SampleView to your class.
Let’s take a very quick look at what we’re doing. First, we define an instance of the new SampleViewController class. We then give it a modal transition style, based on the values found in the UIViewController documentation. Sending it to the front is as easy as using presentModalViewController:animated: Take note that you should probably use the navigation controller to push modal views if you have one. (i.e. [self.navigationController presentModalViewController:animated:]).
To finish up, we’ll need to code a way to dismiss the modal view once it’s presented to the user. Jump to the SampleViewController class and add this code:
Once that’s in place, build and run the project. You should be able to click through the buttons and check out the range of different modal views iOS has to offer. Note that the page curl only works in iOS 3.2 or greater. If you’re compiling for lower versions, you’ll just get the default slide up animation.
In Part 2, we’ll add a delegate in order to pass values between the modal and non-modal views.
Download the sample project from this tutorial here.
What this snippet does is initialise two related caches – a core cache, and a page cache. The core cache (in this instance) is attached to our database table abstract class, which allows results to be stored as serialized strings. The page cache is invoked whenever template output is due to occur, and saves pre-rendered HTML for immediate output.
I had a Zend project in which we had to use the Apache module mod_rewrite to “toggle” our secure connection depending on what pages the user landed on. The requirements were something like:
User visits any administration or account pages, and SSL is off, switch it on
User visits a page that is not an administration or account page, and SSL is on switch it off
As it was a Zend MVC project, we also had a rewrite rule that routed everything to /index.php in the document root.
This is Zend’s recommended .htaccess rule for routing:
For the uninitiated, the block says: If the request is a valid file that exists, or it is a directory, don’t rewrite the URL, otherwise, rewrite the whole string to read “index.php.” The framework will generally just read the query string server variable and go from there.
The above code checks the secure protocol, and then checks the requested path (in this case, /admin or /account). In finding that, it toggles the SSL accordingly.
Here’s the problem: because the two toggling rules only work if triggered as a redirect, the server’s request URL is rewritten twice, meaning that any “toggling” will result in a flat redirect to /index.php, breaking the application.
After hours of testing, rewriting, and Google-fu, I came up with this fix:
This means that the request is reattached to the end of the query all the time. This is hidden from the user (i.e. no ugly index.php/admin/login/ or what-have-you), and is successfully passed onto Zend to trigger the appropriate dispatcher. This works for any number of redirects.
Hope this saves someone else hours of trial-and-error.