Can't change UITableView background colour on iPad (Solution Inside)

If your app is an universal app and you changed the background colour of an UITableView, you will see it works on iPhone but does not work on iPad.

The reason is we can't modify the background colour of the backgroundView of the tableview on iPad. (I think it is a bug. But Apple does not fix it for years.)

Solution: create a new backgroundView.

_tableView.backgroundView = nil;

_tableView.backgroundView = [[[UIView alloc] init] autorelease];

_tableView.backgroundColor = [UIColor clearColor];

Validate Mac App Store Receipt 2012

As many Mac developer did to validate Mac app store receipt, I use roddi's code (https://github.com/roddi/ValidateStoreReceipt Thanks!). But recently I found it does not work! The code fails to validate the sample receipt.

Because I just restored my machine from TimeMachine. I thought maybe there was something wrong in my dev environment. I spent a lot of hours to make sure my development provisioning and certificates are correct. But it still fails to validate the sample receipt.

I read Apple's doc carefully (https://developer.apple.com/library/mac/#releasenotes/General/ValidateAppStoreReceipt/_index.html), and find the solution.

roddi's code is still working. You need not change it. (Just need to get the latest version)

Follow these steps (internet required):

1. Log out from Mac App Store app.

2. Remove USE_SAMPLE_RECEIPT flag from your project settings -> Preprocessor Macros.

3. Compile your project

4. Find this app in Finder

5. Double click it in Finder to run. Do not run it in Xcode.

6. The OS will ask you to log in with your Apple ID. Do not log in with your real iTunes account. You need to log in with the test account. Find it or create it in the iTunesconnect website.

7. The OS will say something like "Your app is broken. Download it in App Store". Ignore this message. If you "Show Package Contents" of this app in Finder, you will see there is a file _MASReceipt/receipt. The OS installed a development receipt. We will not need the old sample receipt any more. That's why we remove USE_SAMPLE_RECEIPT debugging flag.

Done. You can debug your app now.

Debug Ruby on Rails with Aptana Studio 3

1. Check if ruby-debug-ide is installed

$ gem list

2. If not installed, install ruby-debug-ide

$ gem install ruby-debug-ide

3. Open the project in Aptana Studio 3, App Explorer -> Gear icon's drop down menu -> Debug Server



4. Set a breakpoint in a file, e.g. index.html.erb
5. Open http://localhost:3000/<your path>/index.html in your browser
6. Aptana will ask you if open Debug perspective. Of cause. You can see the server stops at the break point.

Rebuilding Code Sense and Syntax Highlighting on Xcode 4

Sometimes syntax highlighting does not work on Xcode 4. Syntax highlighting is an important feature to developers. But there is no "Rebuild Code Sense" menu on Xcode 4. We can do it with following steps:

1. Xcode menu: Window->Organizer

2. Go to Projects tab

3. Choose your project on the left panel.

4. Click "Delete…" button after the Derived Data on the right panel.

Xcode will start to rebuild code sense of your project.

Diff and Merge Localizable.strings in git

The default code set of Localizable.strings is UTF-16. Actually I don't care what code set it is. But git/gitX/SourceTree does not recognize UTF-16 (Stupid!). They treat UTF-16 Localizable.strings as a binary file and reject to diff or merge. This is a very big problem if you work in a team.

Google says we can make git support UTF-16. I tried, but failed. I have to convert Localizable.strings into UTF-8. (Actually before converting, I have manually merged by myself.) Surprisingly, git/SourceTree still says it is a binary file and cannot diff. It's OK. Just commit. Git says it just because the history files are still UTF-16. If you make any new changes, git can diff and merge it. Great!

Keyboard notification bug on iOS 5

When the soft keyboard appears, we need to re-arrange the UI controls. I move the control up a little bit in keyboardWillShow handler:

frame.origin.y -= CONSTANT;

control.frame = frame;

But there is an annoying bug (or behavior) about non-English language keyboard on iOS 5. If you are using English keyboard, you will receive keyboardWillShow notification once. It is good. But if you are using some language keyboard like Chinese, you will receive the same notification TWICE! That means the above code will move the control up twice.

Some non-English language keyboard has an additional line at the top, used to choose words. Sounds like that additional line causes this problem.

The solution is simple. Just use hard-coded positions. And the additional line on some non-English language keyboards may cover parts of your UI on iOS 5. You have to leave enough space for keyboards. If your textField requires English characters only, you can force the keyboard to show English:

textField.keyboardType = UIKeyboardTypeASCIICapable;