So, I decided to run a super-simple benchmark to see whether the move to Core Data would be worth the pain.

I created two apps, each with a single class that would be persisted to the database several times over, one that used Core Data and another using SQLPO. The initial aim of the test was to compare these two frameworks on older iPhone hardware. But, after seeing the results on an iPhone 4, I didn’t feel the need to blow the dust off of my 1st Gen iPhone:

So, Core Data is faster, but does it perform better with memory usage? We noticed SQLPO was a bit liberal with its memory usage, so we were glad to see Core Data’s result:

Clearly a move to Core Data is the smart way to go and it had been on the to-do list for a future release. But, with these numbers, I think it may get a bump in priority.

If the view was loaded in landscape and then rotated to portrait, the content size of the web view would remain at 1024 pixels wide even though the HTML content only took up 700px.

I finally found a helpful post that suggested I add the following inside the HEAD tag of my HTML:

<meta name="viewport" content="width=device-width; initial-scale=1.0; maximum-scale=1.0;">

That does the trick!

But, after setting everything up, I ran my first transaction and got this error: The merchant login ID or password is invalid or the account is inactive. I double checked my API Login ID and Transaction Key and they were correct. Finally, I stumbled on a helpful thread that set me in the right direction.

I was using the test.authorize.net URL but that is only for developer accounts. Even if you are in Test mode, but have a ‘Normal’ Authorize.NET account, you need to use the secure.authorize.net URL.

Found a tip that suggested a re-install of iTunes.

So, I re-installed iTunes and I’m back in business!

http://mobile.twitter.com/home?status=Hello%20World

The status update was dropped after the user logged in. So, I switched to:

http://www.twitter.com/home?status=Hello%20World

which looked fine even on a smaller screen. And, after the user logged in, the status message was retained. But, so was the URL encoding. Instead of “Hello World” the status would have been an unsightly “Hello%20World”.

I finally stumbled onto the fix and it’s an easy one. Just drop the www:

http://twitter.com/home?status=Hello%20World

And, now it works as expected after the user logs in.

Then, we’ll create a function requestCakePHP that requires the cakephp.php file:

function requestCakePHP($url)

}
?>


Then, whenever we need to call for some Cake, we just call requestCake with the URL minus the hostname:


echo requestCakePHP("/webpages/view/2");


In the example above, I have a webpages controller, a view action and am viewing webpage #2.

After several rounds of setting fixed widths inside the info window’s HTML content, I added the following CSS for .gmapmarker which is the class of the div that wraps all of my info window’s content:

.gmapmarker {
    max-height: 185px;
}

I just need to switch between http://localhost and http://fakeproductionurl.com depending on whether I was running in Flex Builder (via adl).

I found all sorts of articles about using conditional compilation (yikes) and reading XML files (I’m too lazy).

This is what I ended up using:

if (NativeApplication.nativeApplication.publisherID != "") {
   return "http://fakeproductionurl.com";
}
else {
   return "http://localhost";
}

It doesn’t give you the ability to switch between 3+ different environments, but it’s a very easy way to toggle between development / production environments.

The core issue was with my root .htaccess file which needed to be changed to:

      RewriteEngine on
      RewriteBase    /agents2/

      RewriteRule    ^$ app/webroot/    [L]

      RewriteCond %{REQUEST_FILENAME} !-f
      RewriteRule (.*) app/webroot/$1 [L]

And that did the trick.

Thanks, Kushaura.com!

Take a web form for example.  When the user clicks Save, the data is sent via POST back to the web application.  The web app saves the data to the database and then redirects the user to the next page within the application.  The user’s browser then requests that page via GET.  

The beauty of this pattern is made very clear by Phil.  This will eliminate the possibly confusing “Are you sure you want to resubmit this form data?” browser message.  But, for me, an even better reason is that it eliminates possible data issues when the browser re-posts the data after that refresh.  

Either way, I’m glad to have learned the name of this pattern and even more thankful that my use of it has been validated.