Oct 09

Ok, this might seem like a simple thing to do – and in most cases it is, unless you’re using core data and have some row additions coming in dynamically.

- (void) tableView:(UITableView *)tableView willDisplayCell:(UITableViewCell *)cell forRowAtIndexPath:(NSIndexPath *)indexPath {
    cell.backgroundColour = (indexPath.row % 2) ? [Constants darkTableCellBackgroundColor] : [Constants lightTableCellBackgroundColor];
}

You see the problem I had was, that row zero is white, row one is blue, row two is white….etc, and when I synced with my remote server and new data arrived, it was inserted at row zero  - which is white! The other rows were pushed down, so row zero and row one were both white! No more alternate. I could have just refreshed the UITableView – or the visible rows, but I didn’t want to do that! I wanted it to figure out the correct row colour from the insert.

I got it working by combining the row index with the total rows, using the inverse of one and XOR’ing the result! Sounds complicated? Look at this table:

A: Row B: Row Modulus (%2) C: Row Count D: Count Modulus (%2) E: Inverse Count Modulus F: XOR B ^ E
0 0 6 0 1 1
1 1 6 0 1 0
2 0 6 0 1 1
3 1 6 0 1 0
4 0 6 0 1 1
5 1 6 0 1 0

As can be seen above, I can get alternate row colours from Column B or Column F. However, if you then add another row at index zero – the row modulus can no longer be used, but Column F, still preserves the alternate row colours!

A: Row B: Row Modulus (%2) C: Row Count D: Count Modulus (%2) E: Inverse Count Modulus F: XOR B ^ E
0 0 7 1 0 0
0 0 6 0 1 1
1 1 6 0 1 0
2 0 6 0 1 1
3 1 6 0 1 0
4 0 6 0 1 1
5 1 6 0 1 0

This can be achieved with this bit of code:

- (void) tableView:(UITableView *)tableView willDisplayCell:(UITableViewCell *)cell forRowAtIndexPath:(NSIndexPath *)indexPath {
    int rowFlag = (indexPath.row % 2);
    int totalFlag = [self tableView:tableView numberOfRowsInSection:indexPath.section] % 2;
    cell.backgroundColor = (rowFlag ^ !totalFlag) ? [Constants darkTableCellBackroundColor] : [Constants lightTableCellBackroundColor];
}

Let me know if I’ve missed something obvious here and there was a more common way of doing this.

written by admin \\ tags: , , ,

Sep 08

CodeSign error: Code Signing Identity ‘iPhone Distribution: XXXXX’ does not match any code-signing certificate in your keychain.

I’ve been getting this intermittent issue from our Bamboo build server, which builds our iOS project using xcodebuild. It seems to resolve itself after a restart of the mac, however.. a few builds later and it fails again. We’re using XCode 4.1 on OS X Lion 10.7.1.

I inserted this into the build script

security list-keychains

..and I can see that Bamboo has access to the login and the System keychains

Listing the current keychains
08-Sep-2011 12:43:26     “/Users/mac0004/Library/Keychains/login.keychain”
08-Sep-2011 12:43:26     “/Library/Keychains/System.keychain”

….however, after a few builds (and something else that I don’t know what happens), this command reports

Listing the current keychains
08-Sep-2011 13:23:16     “/Library/Keychains/System.keychain”
08-Sep-2011 13:23:16     “/Library/Keychains/System.keychain”

It’s strange how it reports the System.keychain twice, and that it can no longer find the login keychain.

Anyway, the solution for me was to copy/move my iOS certificates to the System.keychain.

I also had another error: ‘CSSM_ERRCODE_INTERNAL_ERROR’, which I resolved by installing the intermediate certificate from Apple again. You can get this from the provisioning portal, certificates section. Or from this link: Apple WWDRCA Intermediate Certificate

If you have similar problems and this doesn’t resolve it, post a comment.

written by admin \\ tags: , , , ,