Performance using JSON is quite a bit better, but if you can get access to the server to write a Property List (.plist) file instead of (or alongside) the XML you will be much happier with the ease-of-coding and, more importantly, the speed in which the data loads into your app.

If you use mySQL/PHP for your backend, pretty much everything you need to know is explained in this excellent blog post by Aaron Dunnington:

Data-driven iPhone Apps with Property Lists and PHP.

Originally I had a text view (UITextView) to hold the story, but I wanted to do rich-text formatting, and since my database already used HTML to do italic and bold markup, a web view (UIWebView) was the obvious fit.

However, there are some caveats to using web views, most importantly to do with getting the size of the view after you’ve set the content. First, you must make sure the content has completed loading before you retrieve the size; you can do this in the delegate handlerwebViewDidFinishLoading:

Secondly, web views don’t respond correctly to sizeToFit: so you must do some more manual labor using a Javascript call to find the size of the web view after you’ve inserted the content. Some comments on other web sites mentioned that you can try [webView sizeThatFits:CGSizeZero] but this did not work for me.

Here’s the pertinent code from my current project. Also please note that I have a <div id="body"> surrounding my HTML content that I pass into the view. The javascript call uses this to grab the height of the web view after it loads. You’ll also notice that this calculation sometimes falls a little short so I add 12 points to it.

The code below creates a UIButton beneath the text copy, so I added 70 pixels to the contentSize of the enclosing scroll view. It works perfectly for me; hopefully it helps someone else, too.

If there’s a more kosher way to do it, I’d love to hear it. I had considered putting everything (including the headline and photo) inside the UIWebView, but then I would not have been able to have a UIButton beneath/outside it off screen; nor, more importantly would I be able to use my custom NetImageViewer class on the photo. (More on that later.)

I wrote a huge blog post last week about how to successfully integrate the old SDKs into the latest Xcode (version 3.2.3), since I wasted a whole trying to get it to work, I thought I would share.

Unfortunately, it still wasn’t working after all that work, so my recommendation to you, should you want to hang on to the older SDKs (for the time being) is to install the new XCode in a new folder outside of /Developer. The dialog in the installer for picking the install location is a little different from what might you might be used to seeing, so proceed carefully.

Initially we received a rejection letter from the App Store review team, saying that the app used bandwidth that was demanding on the cell network that was excessive “in Apple’s reasonable judgment.” With a 128kbps mp3 stream, I found this curious as I have used several streaming radio apps that connect to 128kbps streams, including the excellent WFMU app, but also the much higher profile AOL Radio app.

Some google searching revealed this helpful article on StackOverflow wherein the writer related being told verbally by App Store personnel that one megabyte per minute was the maximum allowed. I did some quick math on the calculator and it seemed that my app should be receiving 960KB/minute, so I should be good.  But following the StackOverflow poster’s advice related from Apple staff, I shut off all other notifications and used the Settings app>General>Usage  to reset the statistics and then track the app for 5 minutes. For some reason the app came in as receiving 5.4MB over 5 minutes, which means I was around 10% over the limit.

I am not sure if other 128kbps streams have this issue, or there’s mysterious overhead lurking in mine, but I had planned to knock down the quality to 96k anyway as 128k over 3G still has too many dropouts.

I wrote Apple an email back explaining that it was not an app issue but a stream issue, and I could easily knock the stream down a notch. Which I did, and I got an email saying the status of the app had been changed to “Pending” again. A couple days later, a very congenial Apple developer relations person called me and confirmed the rumor that the limit was indeed 1MB per minute. I said that I had already compressed the stream further and she said they’d rerun the metrics.

It was all very well handled, and to my satisfaction… but the question remains, if the limit for data transfer is a hard number (1MB/min) then why isn’t that written in the developer agreement? Why do they only communicate the details of the rules verbally after the fact? As with the no satire rule, it would would be nice to know what the specifics are in advance.

Backporch Revolution is an artist-run collective and netlabel based in New Orleans that specializes in releasing experimental electronic works by local musicians. The website is backporchrevolution.com

Regular readers will remember that Juggleware’s own app Freedom Time was actually the test case of this unwritten and up-til-then unknown policy, which had not been explicitly defined beyond the word “defamatory” briefly appearing.  For a timeline of other apps (there are at least 16 now) that have been banned for this silly charge, see this blog:

Apple’s Policy on Satire: 16 Apps Rejected for “Ridiculing Public Figures” [Cloud Four]

If there was an app rejected before September 2008 for political satire, we’d like to hear about it; please post in the comments below.

The interesting thing about the Mark Fiore case is that Apple has apparently reconsidered their rejection, and asked Fiore to resubmit his app. That’s great news, but does it really mean Apple is finally reconsidering their rather draconian policy? Or are they just trying to avoid the bad publicity that’s likely to escalate when the content is associated with the winner of a Pulitzer? I guess we’ll have to wait till the next rejection (or approval) to find out.

John Gruber of Daring Fireball makes the point that what’s most frustrating to developers is the grey area of ill-defined rules. Developers trying to navigate App Store policy plays out like trying to divine the will of a god, who is without a doubt omnipotent, but  rarely seems omniscient, and appears to mortals as vindictive and capricious at times. Or perhaps a closer amalgam could be a Kafka-esque bureaucracy, layers of obscure rules unseen by citizens, wheels moving cruelly behind the scenes towards some irreversible and arbitrary concept justice so thickly wrapped in red tape as to be impenetrable?

But back to the heart of it, what’s really so awful about demeaning public figures? Most of them need a swift kick in the ass. If it’s done in a way that’s not illegal or obscene,  that threatens violence or makes a patently untrue claim, then why the censorship? One possible answer might be that that’s it’s just wide cover for one public figure who is sacrosanct in the Apple canon, in which case I would like to suggest the following amendment to the satire rule:  No application may include images, text, or sound that demeans Steven P. Jobs.

At least that way we could still satirize everything else under the sun, and the rule would kind of be a parody of itself.

First of all, here’s what I am currently using; I am including versions in case that’s relevant to your situation:

• MySQL 5.0.81
• MySQL charset: UTF8-Unicode (utf8)
• MySQL connection collation: utf8_unicode_ci
• phpMyAdmin – 2.11.9.5
• SQLite Database Browser 1.3 (includes 3.3.5 of the SQLite database engine)
• iPhone Dev Kit – 3.0
• XCode 3.1.3
• SQLite 3 framework found at /Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS3.0.sdk/usr/lib/libsqlite3.dylib

You can try other solutions for importing the data into a SQLite format, but I’ve had the best luck with Mauricio Piacentini’s SQLite Database Browser. Other options you might want to try include a Firefox plugin.

Here are the steps, using SQLite Database Browser:

1. log into phpMyAdmin, select your database and go to Database> Export.
2. On the export tab, make sure all databases are selected, and the “SQL” radio button is selected.
3. Select ANSI from the pulldown for export compatibility.
4. Uncheck all options under Structure and Data, but leave each section checked.
5. Save as file should be checked, and probably be via ZIP or GZIP, just in case.
6. Click the Go button to download your file.
7. Extract the file and open it up in your favorite text editor (I use BBEdit).
8. Find the first CREATE TABLE line. We need to modify these by hand to simplify the table creation so that SQLite doesn’t get confused. For example, my file came down looking like this after the comment section ended:
   
CREATE TABLE dictionary (
id int(11) NOT NULL auto_increment,
word varchar(100) NOT NULL,
adjective tinyint(1) NOT NULL default '0' COMMENT 'is an adjective',
noun tinyint(1) NOT NULL default '0' COMMENT 'is a noun ',
intro tinyint(1) NOT NULL default '0' COMMENT 'is an intro',
PRIMARY KEY  (id),
UNIQUE KEY words (word)
);


   You’ll want to edit this to remove pretty much everything but the most basic information and normalize the data types to SQLite 3 Data Types, which are TEXT, NUMERIC, INTEGER, REAL, or BLOB. Your CREATE TABLE should look something like this:

   CREATE TABLE dictionary(
id INTEGER PRIMARY KEY ASC,
word TEXT,
adjective INTEGER,
noun INTEGER,
intro TEXT
);

   I was using id as a primary key so I’ve added “PRIMARY KEY ASC” after “id INTEGER”. (Primary Keys are aliases to row IDs in SQLite, if you have questions read this.)

   However, I’ve noticed that the SQLite Database browser exports SQL in the even more simplified format with no datatype specification as such, which also seemed to work for me and may work just as well for your needs:

   CREATE TABLE dictionary (id, word, adjective, noun, intro);


9. Continue going through your text file and fix all CREATE TABLE lines as in #8, above.
10. Check your file text encoding. BBEdit may default to Western (Mac OS Roman), which worked for me, but if you have problems you may need to set it to Unicode, depending on your character set.
11. Check your file for suspicious characters that might cause the import to choke. Single quotation marks used as apostrophes show up as escaped by themselves; for example you're becomes you''re. This seemed to import fine as long as the other guidelines are followed. Here’s what an example INSERT should look like:

    INSERT INTO dictionary VALUES(305, 'ne''er-do-well', 0, 1, 0);


12. Check your line endings. BBEdit defaulted to Unix (LF) which worked for me.
13. Open up SQLite Database Browser, create a new database (.db) file, and import your SQL text file by selecting File> Import> Database From SQL File from the menu.
14. Check your data by clicking the Browse Data tab and make sure everything came in all right. If not, go back over the steps. Look for weird characters, text and line encoding issues, and syntax issues. The only two commands in your file should be CREATE TABLE and INSERT, although technically it should probably begin with BEGIN TRANSACTION; and end with COMMIT;

Again these steps were derived mostly by trial-and-error, so there may be issues particular to your DB that these guidelines didn’t solve. Please feel free to add any corrections, tips, and questions to the comments area.

Also, I know that with the iPhone OS 3.0, Core Data can take care of a lot of database functionality for you. I’d love to hear how people made the transition, and especially how anyone got a pre-existing SQL database into a Core Data store.

http://www.apple.com/hotnews/apple-answers-fcc-questions/

Of course the FCC is primarily interested in its rejection of big, important apps like Google Voice, and not indie developer apps, so Apple was able to gloss over its political censorship of apps like Freedom Time (See section 5, above), and not even include any rejected political content app in its list of “representative applications.”

To me, rejecting an app for speech reasons is much worse than for technological competition reasons, but maybe that’s because I am someone who cares about the first Amendment, something that has been shoved to the back of the bus while greasing the wheels of the free market machine.

Thanks to Brad at Bent Media for pointing me to this excellent essay by Joe Hewitt demanding the end of the App Store approval process as we know it.