Posted by Doug Hays on the 30th of September, 2010 at 10:20 pm under iPhone Development.    This post has no comments.

We are working on a legacy iPhone app that uses the awesome SQLPO to persist my objects to a sqlite database. The app doesn’t have a lot of data (100’s of rows) but, in our testing, believe that we are experiencing a bit of lag with SQLPO especially when inserting records.

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:

Time Test SQLPO Core Data
500 Record Insert 27.5s 0.43s
500 Record Update 15.13 sec 0.44 sec
10000 Record Insert 360 sec* 5.72 sec
10000 Record Update 300 sec* 5.82 sec
* Test did not finish. App crashed

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:

Memory Test SQLPO Core Data
Max Live Bytes 99.5 MB 2.54 MB
Idle Live Bytes 3.02 MB 1.74 MB
Time to release 63 sec 1 sec

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.

Posted by Doug Hays on the 22nd of September, 2010 at 9:04 am under iPhone Development.    This post has no comments.

I had the simplest of UIWebView implementations throwing me an odd issue. It was an iPad app with a UIWebView, stretched to fill the entire screen, loaded from a local HTML file.

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!

Posted by Doug Hays on the 14th of September, 2010 at 10:28 pm under E-commerce.    This post has no comments.

I’m adding Authorize.NET to one of my client’s CakePHP apps and used the Authorize.NET CakePHP Component which saved me a world of time.

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 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 URL.

Posted by Doug Hays on the 13th of September, 2010 at 1:19 pm under Apple.    This post has no comments.

Just a quick tip if your iPad or iPhone is not appearing in Xcode or iTunes. This was happening to me even after a complete machine restart.

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

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

Posted by Doug Hays on the 19th of May, 2010 at 2:43 pm under iPhone Development.    This post has no comments.

I am developing an iPhone app that allows the user to tweet information from the app. For simplicity’s sake, I chose to use the URL method of sending the user off to Twitter to sign in and finish their status update. When I redirected the user to:

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

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:

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