1. Bundle ID is case-sensitive. If it is com.moke.app in the iTunes Connect but com.moke.App in App-Info.plist — that is default Bundle ID set in your app if you named your Xcode project “App” — IAP will not work.
2. “Waiting for Screenshot” is not a good status. At least you should upload a placeholder screenshot and let the product status be “Ready to Submit”.
3. No new Development Provisioning Profile is required. Though Technical Note TN2259 tells you to “Create, download, and install a new Development Provisioning Profile that uses your App ID enabled for In-App Purchase as seen in…”, it is not required if you are using a Development Provisioning Profile “Managed by Xcode” — it works for IAP apps even though it has a different App ID. Of course, it works for development installations only and you need setup Distribution Provisioning Profiles to distribute any apps no matter they have IAP or not.

One more thing. It’s not Apple’s One More Thing. In fact, it is one more thing that Apple does not like. If you are using a jailbroken device, make sure you uninstall AppSync from Cydia before testing IAP.

Today is such a day.

I have a UIButton that when tapped will trigger a custom view transition with animations. Animations mean duration — it takes some time to complete. Though the transition is still in progress, the button does not refuse more taps — it just loves taps!

I guess you see the problem here: What happens if the button is tapped again during the view transition?

Another view transition is triggered, of course, and I don’t want it.

So I must filter out taps during the view transition.

Notice that you can’t reproduce this problem by double tapping a button that triggers a standard view transition such as pushing a view controller using pushViewController:animated: or presenting a view controller using presentViewController:animated:completion:. I guess it is because the view the button is on is being covered during these standard view transitions so the button can not receive taps.

喜欢的话，可从 GitHub 上获取。

There are two bugs in the NSFetchedResultsChangeUpdate case:

1. newIndexPath may be non-nil and different from indexPath, for example, when some rows are deleted or inserted while some other rows are updated in the same session. In these cases, one should use the old indexPath to locate the table cell but use the newIndexPath to fetch the object from the NSFetchedResultsController because controller:didChange… and table view is being updated. So the correct code should be:
   [self configureCell:[tableView cellForRowAtIndexPath:indexPath] atIndexPath:(newIndexPath ? newIndexPath : indexPath)];
2. With the code above, you have correctly updated the table cell. However, the cell on screen is still displayed as before. That’s because even though you’ve re-configured the cell with updated data, you’ve not refreshed it. To force a refresh, you need to call the table cell’s setNeedsLayout or/and setNeedsDisplay depending on your cell’s implementation. Refer to Stack Overflow for the discussion. You can also resort to reloadRowsAtIndexPaths:withRowAnimation: of course, albeit it seems a bit overkill to me.

开发者火是因为新浪微博开放平台对开发者很不友好，其 API 从实现到文档都很粗糙。

API 实现不标准还能忍，但是文档不说明清楚，要开发者自己摸索就离谱了。¹看来新浪尚未有暇顾及第三方开发者，开放平台现在也只是“开门放出来”而已。结果就是开发者在很多毫无意义的事情上折腾，浪费时间！

我写这一系列文章的目的就是避免后来者遭同样的罪。

这是第一篇，关于 upload API 的 OAuth 验证失败问题。去论坛搜索一下 upload 就知道有多少人深受其害了。²

Upload API 的 OAuth 之所以难搞，部分是因为其 HTTP 请求格式的特殊性，主要是因为新浪微博那匪夷所思的实现。

Upload API 的特殊性在于其请求“采用 multipart/form-data 编码方式提交”³。根据 OAuth 1.0 协议，Content-Type 为 multipart/form-data 的 HTTP 请求，其 entity body 不参与 OAuth 签名。照此，upload API 的 OAuth 应该比其他普通 API 更简单，因为只有 OAuth 参数（oauth_ 开头的一系列特别参数）参与签名。所以，标准的 Signature Base String 应该是：
POSThttp%3A%2F%2Fapi.t.sina.com.cn%2Fstatuses%2Fupload.jsonoauth_consumer_key%3Dxxxxxxxxxx%26oauth_nonce%3D15492994958798014939%26oauth_signature_method%3DHMAC-SHA1%26oauth_timestamp%3D1312912324%26oauth_token%3Dyyyyyyyyyy%26oauth_version%3D1.0

与其对应的标准的 Authorization header 应该是：
OAuth oauth_consumer_key=xxxxxxxxxx, oauth_token=yyyyyyyyyy, oauth_signature_method=HMAC-SHA1, oauth_version=1.0, oauth_nonce=15492994958798014939, oauth_timestamp=1312912324, oauth_signature=2RxNudXqdeSLXSxxRSgpIWUa3HI%3D”

然而，迎接你的将是：
40107:Oauth Error: signature_invalid!

这是因为新浪微博 upload API 的实现要求 Signature Base String 包含除 pic 以外的参数。所以新浪微博需要的 Signature Base String 是这样的：
POSThttp%3A%2F%2Fapi.t.sina.com.cn%2Fstatuses%2Fupload.jsonlat%3D37.78711200%26long%3D-122.40846000%26oauth_consumer_key%3Dxxxxxxxxxx%26oauth_nonce%3D18218585476538551879%26oauth_signature_method%3DHMAC-SHA1%26oauth_timestamp%3D1312912886%26oauth_token%3Dyyyyyyyyyy%26oauth_version%3D1.0%26status%3DPic

问题来了：status、lat、long 这些参数是在 entity body 中提交的，如前所述，它们不参与 OAuth 签名。为了遵循 OAuth 协议，必须将这些参数加入 URL query string 或 Authorization header。

规范的开发者这么做了，结果“错”了，新浪微博 server 还是返回：
40107:Oauth Error: signature_invalid!

事实上，无论你怎么折腾，只要你遵循 OAuth 协议，你一定折腾不出来，因为新浪微博是不遵循 OAuth 协议的。

对于 Content-Type 为 multipart/form-data 的 HTTP 请求，新浪微博要求非 binary 参数（如 upload API 中的 pic 参数）参与 OAuth 签名，同时还要求这些参数是“无由来”的。也就是说，Signature Base String 要包含这些参数，但这些参数不能出现在 URL query string 或 Authorization header。这意味着新浪微博 server 端接收到请求后从 entity body 中提取了这些参数来进行 OAuth 签名验证。再强调一遍，对于 Content-Type 为 multipart/form-data 的 HTTP 请求，这是违反 OAuth 协议的。但在新浪微博上，我们就要是要违反 OAuth 协议才能通过 OAuth 验证。

即便不考虑像我这样耗时耗力的摸索过程，新浪微博的这种非标准实现也给开发者带来了很大麻烦，因为这导致了很多遵循 OAuth 协议实现的 OAuth 库无法直接使用。

在折腾的过程中，我还发现了另一个要命的 bug。如果 pic 的 Content-Disposition header 缺少 filename 参数的话，新浪微博也会返回“40107:Oauth Error: signature_invalid!”，虽然 pic 跟 OAuth 毛关系都没有，虽然根据标准 filename 不是必须的，虽然事实上 filename 在这里是没用的。

最后总结一下搞定新浪微博 upload API 的“正确”方法：

1. 所有参数用 multipart/form-data 格式提交，不能出现在 URL query string 或 Authorization header。
2. 除 pic 以外的所有参数进入 Signature Base String 参与 OAuth 签名。
3. pic 的 Content-Disposition header 必须包含 filename 参数。

The most used and simple one is duration:

duration
Specifies the basic duration of the animation, in seconds.

Nothing needs further explanation here.

The duration you specify may differ from the real duration you experience, depending on the parent time space or speed:

speed
Specifies how time is mapped to receiver’s time space from the parent time space.

So an animation with duration of 1 second and speed of 1 is the same as an animation with duration of 2 seconds and speed of 2, when mapped to real time space.

The two repeating properties — repeatCount and repeatDuration — are as clear as they are named. So is autoreverses.

Finally, we are talking about the three interesting but not intuitive properties:

beginTime

beginTime
Specifies the begin time of the receiver in relation to its parent object, if applicable.

If an animation is in an animation group, beginTime is the offset from the beginning of its parent object — the animation group. So if beginTime of the animation is 5, it begins 5 seconds after the animation group begins.

If an animation is added directly to a layer, beginTime is still the offset from the beginning of its parent object — the layer. But since the beginning of a layer is in the past¹, I can not simply set beginTime to 5 to delay the animation 5 seconds, because 5 seconds after the beginning of a layer is probably still a past time. What I usually really want is a delay relative to when the animation is added to the layer — denoted by addTime. So

animation.beginTime = addTime + delay;

In order to get addTime, I can use CACurrentMediaTime and convertTime:fromLayer::

addTime = [layer convertTime:CACurrentMediaTime() fromLayer:nil];

If beginTime of the layer itself is to be set, addTime must be calculated after it is set because beginTime shifts the time space of the layer.

These things can be chained up:

CFTimeInterval currentTime = CACurrentMediaTime();
CFTimeInterval currentTimeInSuperLayer = [superLayer convertTime:currentTime fromLayer:nil];
layer.beginTime = currentTimeInSuperLayer + 2;
CFTimeInterval currentTimeInLayer = [layer convertTime:currentTimeInSuperLayer fromLayer:superLayer];
CFTimeInterval addTime = currentTimeInLayer;
CAAnimationGroup *group = [CAAnimationGroup animation];
group.beginTime = addTime + 1;
group.animations = [NSArray arrayWithObject:anim];
group.duration = 2;
anim.beginTime = 0.5;
[layer addAnimation:group forKey:nil];

timeOffset

timeOffset
Specifies an additional time offset in active local time.

It’s not clear what it means from the words. But with a very simple example you’ll get it.

Supposing a 3-second animation with states s₀, s₁, s₂, s₃, wherein s_n denotes the state at second n. The normal state sequence without timeOffset is:
s₀ ➔ s₁ ➔ s₂ ➔ s₃

With timeOffset set to 1, the state sequence becomes:
s₁ ➔ s₂ ➔ s₃ ➔ s₀

With timeOffset set to 2:
s₂ ➔ s₃ ➔ s₀ ➔ s₁

Shift and wrap around. That’s it.

fillMode

fillMode is really badly documented. I can figure out kCAFillModeRemoved and kCAFillModeForwards but have no idea what kCAFillModeBackwards and kCAFillModeBoth are about.

Fortunately, they turn out very straightforward if you see them in practice.

Supposing an animation in an animation group configured as follow:

anim.beginTime = 1;
anim.duration = 3;
CAAnimationGroup *group = [CAAnimationGroup animation];
group.animations = [NSArray arrayWithObject:anim];
group.duration = 5;

Denote initial state of anim as s_i and final state as s_f. Hence in group’s time space:
s_i = s₁
s_f = s₄

Normally, there is no s₀ or s₅, because anim is not in effect during [0, 1) or (4, 5]. And it is what kCAFillModeRemoved means.

With kCAFillModeForwards, the state sequence of anim extends forward to the end of its parent time space, that is:
s₁ ➔ s₂ ➔ s₃ ➔ s₄ ➔ s₅

But what should s₅ be? I believe you can guess it.
s₅ = s_f = s₄

After anim is completed, it remains. It is what filling forward means. Quite intuitive, if put clearly, isn’t it?

kCAFillModeBackwards is the mirror of kCAFillModeForwards, which we can easily tell from their names. Actually, it is.

If fillMode of anim is set to kCAFillModeBackwards, the state sequence extends backward to the beginning of its parent time space, that is:
s₀ ➔ s₁ ➔ s₂ ➔ s₃ ➔ s₄
with
s₀ = s_i = s₁

Before anim begins, it appears. It is, indeed, filling backward.

At this time, kCAFillModeBoth is a nothing mysterious at all. It is just kCAFillModeForwards + kCAFillModeBackwards, filling both way:
s₀ ➔ s₁ ➔ s₂ ➔ s₃ ➔ s₄ ➔ s₅
with
s₀ = s_i = s₁
s₅ = s_f = s₄

To do you a further favor, I re-document fillMode below, in the way it should have been documented in the first place:

fillMode
Determines the receiver’s presentation during its inactive duration.

Discussion
The possible values are described in “Fill Modes”. The default is kCAFillModeRemoved.

Fill Modes
These constants determine how the timed object behaves in its inactive duration. They are used with the fillMode property.

NSString * const kCAFillModeRemoved;
NSString * const kCAFillModeForwards;
NSString * const kCAFillModeBackwards;
NSString * const kCAFillModeBoth;
NSString * const kCAFillModeFrozen;

Constants
kCAFillModeRemoved
The receiver does not appear until it begins and is removed from the presentation when it is completed.

kCAFillModeForwards
The receiver does not appear until it begins but remains visible in its final state when it is completed.

kCAFillModeBackwards
The receiver appears in its initial state before it begins but is removed from the presentation when it is completed.

kCAFillModeBoth
The receiver appears in its initial state before it begins and remains visible in its final state when it is completed.

That’s all. I think I’ve filled your mind quite full. You can get the sample code on github.

First of all, you should RTFM(Read The Fabulous Manual). Secondly, of course, you should watch the nice Session Video 424 of WWDC 2010 and play with the sample code Animation101.

Now, I assume you’ve done all the prerequisite work so you must be familiar with that bouncing ball which is our protagonist.

Bouncing is one of the simplest form of animation, just moving from a position to another position and back. But as you are going to see below, with some extra flexibility requirements, such a straight moving is not so straightforward in code.

Here is bouncing I want:

1. First tap triggers the fall of the ball.
2. Second tap triggers the rise of the ball.
3. Second tap can happen half-way along the fall and the bouncing should start immediately at that time and position.

Method 1 — Property animation

This is the most straightforward and recommended method. Nothing could go wrong.

if(viewState == 0) { // First tap.
        [CATransaction setAnimationDuration:2];
        ball.position = p2;
}  else { // Second tap.
        ball.position = p1;
}

Method 2 — Explicit animation with cancelation via delegate

Because the second animation may happen half-way during the first animation, I need to cancel the first one.

But when?

To ask this question, you should know how Core Animation interpolates values.

The relevant rule here is the fifth one:

toValue is non-nil. Interpolates between the current value of keyPath in the target layer’s presentation layer and toValue.

It is a good one for my purpose – bouncing from the current presentation position. If only I can keep the current presentation position value.

As soon as an property animation is canceled, the presentation value of the property is gone, and the model value is used instead. So if I cancel the first animation before the second one begins, the start position(the model value, which is never changed and always the initial position) and end position will be the same, hence no visible animation will happen.

Following preceding analysis, I should not cancel the first animation until the second one begins; and I must cancel it no later than the second one ends, otherwise the first one may continue after the second one ends — assuming the first one is longer than the second one.

Fortunately, CAAnimation has two delegate methods reporting animation progress:
–animationDidStart:
–animationDidStop:finished:

Taking them at face value, I think –animationDidStart: offers a perfect cancel point. However, it turns out that it is a bit too early¹, so I have to use –animationDidStop:finished:.

if(viewState == 0) { // First tap.
        CABasicAnimation *move = [CABasicAnimation animationWithKeyPath:@"position"];
        move.removedOnCompletion = NO;
        move.fillMode = kCAFillModeForwards;
        move.duration = 2;
        move.toValue = [NSValue valueWithCGPoint:p2];
        [ball addAnimation:move forKey:@"move"];
}  else { // Second tap.
        CABasicAnimation* stop = [CABasicAnimation animationWithKeyPath:@"position"];
        [stop setValue:@"stop" forKey:@"tag"];
        stop.delegate = self;
        stop.toValue = [NSValue valueWithCGPoint:p1];
        [ball addAnimation:stop forKey:@"stop"];
}

- (void)animationDidStop:(CAAnimation *)anim finished:(BOOL)flag {
        NSString *tag = [anim valueForKey:@"tag"];
        if ([tag isEqualToString:@"stop"]) {
                [ball removeAnimationForKey:@"move"];
        }
}

Method 3 — Explicit animation with overwriting

As you can see, canceling the first animation after the second one begins is tricky. And to be honest, I’m not sure what’s the behavior of two animations of the same property occurring simultaneous.

A better approach is to capture the current presentation value myself and use it as the fromValue, and to cancel the first animation before the second one begins. It is much cleaner logically and reliable behaviorally.

There is a nice feature I can use to cancel an animation with another by overwriting — simply assigning the same key as the first one to the second one when adding the second one to the layer.

if(viewState == 0) { // First tap.
        CABasicAnimation *move = [CABasicAnimation animationWithKeyPath:@"position"];
        move.removedOnCompletion = NO;
        move.fillMode = kCAFillModeForwards;
        move.duration = 2;
        move.toValue = [NSValue valueWithCGPoint:p2];
        [ball addAnimation:move forKey:@"position"];
}  else { // Second tap.
        CGPoint startPoint = ((CALayer *)ball.presentationLayer).position;
        CABasicAnimation* stop = [CABasicAnimation animationWithKeyPath:@"position"];
        stop.fromValue = [NSValue valueWithCGPoint:startPoint];
        stop.toValue = [NSValue valueWithCGPoint:p1];
        [ball addAnimation:stop forKey:@"position"];
}

Method 4 — Fall with property animation and rise with explicit animation

Though I don’t know why you would want to use this manner, I want to show you how to properly implement it.

The fall part is exactly the same as that of Method 1, while the rise part is almost the same as that of Method 3. Reasonable enough. However, there are two things you must pay attention to:

1. Property animations carry implicit keys named after their key paths. So the key “position” is used for the second animation to overwrite the first one which is a position property animation.
2. Even though I’m using explicit animation for the rise part, I still need to reset the model value because presentation changes do not update modal layers while modal changes do update presentation layers.

if(viewState == 0) { // First tap.
        [CATransaction setAnimationDuration:2];
        ball.position = p2;
}  else { // Second tap.
        CGPoint startPoint = ((CALayer *)ball.presentationLayer).position;
        ball.position = p1;
        CABasicAnimation* stop = [CABasicAnimation animationWithKeyPath:@"position"];
        stop.fromValue = [NSValue valueWithCGPoint:startPoint];
        stop.toValue = [NSValue valueWithCGPoint:p1];
        [ball addAnimation:stop forKey:@"position"];
}

Method 5 — Fall with explicit animation and rise with property animation

Just to be complete. Still two notice points:

1. The key “position” is used for the first animation so that the second one, which is a position property animation, can implicitly overwrite the first one.
2. I must set the model value of position away from the initial value², otherwise when I set the modal value back to the initial value Core Animation will not notice any change of the model value and will not trigger any animation.

if(viewState == 0) { // First tap.
        CGPoint startPoint = ball.position;
        ball.position = p2;
        CABasicAnimation *move = [CABasicAnimation animationWithKeyPath:@"position"];
        move.removedOnCompletion = NO;
        move.fillMode = kCAFillModeForwards;
        move.duration = 2;
        move.fromValue = [NSValue valueWithCGPoint:startPoint];
        move.toValue = [NSValue valueWithCGPoint:p2];
        [ball addAnimation:move forKey:@"position"];
}  else { // Second tap.
        ball.position = p1;
}

You can get the sample code on github.

Yes, most of the time.

No, not really:

1. What’s the value of b? It’s just two lines of code, so don’t resort to your awesome compiler, simply give me the answer.
   NSUInteger a = 7;
   NSInteger b = MAX(4 - a, 1);
2. What’s the problem of this trivial loop? You are allowed to use compiler this time, but be cautious that sometimes you don’t have enough time to finish even such a simple loop.
   for (int i = 0; i <= [someArray count] - 1; i++) {
       // Do something.
   }

If you can figure out the answers by yourself, you are AWESOME! If you can’t, it is OK, really, because int is difficult. Take it easy and check out the discussion here(Apple Developer Program member only).

If you can’t access Apple Developer Forums but still want to know what’s going on, here is the revelation from C99:

Otherwise, if the operand that has unsigned integer type has rank greater or equal to the rank of the type of the other operand, then the operand with signed integer type is converted to the type of the operand with unsigned integer type.

After some reverse engineering, I found it is because when a UITableViewCell gets highlighted it also cleverly highlight all its subviews. It is reasonable in some aspects but unfavorable sometimes. And it is especially annoying and confusing in Voodo.

I noticed this problem the first time I do selection in Task List view, however, I left it aside because

1. It is a very small and transient visual defect;
2. I see the exactly same problem in many other UITableView based apps with UIButtons inside UITableViewCells;
3. I didn’t find a simple fix;
4. No one complains about it.

Yes, not a single one user has ever complained about this problem to me – I love you Voodoers, you are so forgiving – except one, my wife.

Though she just began using Voodo for her MBA study¹, she found quite some little problems with her picky eyes. Maybe it is because she likes painting so is more visually sensitive.

So I decided to fix it, finally.

I first tried several plain old ways with the hope that new SDK make UITableViewCell more easily configurable, to no avail. I searched the whole web, to no avail. OK, I said to my self, I know I can do it, maybe I should try every plausible properties and methods of UITableViewCell. Once again, I made it, as every time before when I told myself I wanted it done whatever. Determination works!

It turns out very straightforward. You just need to override the two relevant methods of UITableViewCell – setHighlighted:animated: and setSelected:animated: as follows:
- (void)setHighlighted:(BOOL)highlighted animated:(BOOL)animated {
        [super setHighlighted:highlighted animated:animated];
        // Don't highlight check button to confuse users.
        self.checkButton.highlighted = NO;     
}

- (void)setSelected:(BOOL)selected animated:(BOOL)animated {
        [super setSelected:selected animated:animated];
        // Don't highlight check button to confuse users.
        self.checkButton.highlighted = NO;
}

Notice that overriding the inanimate peers does not work, maybe because the whole thing occurs during a transition animation.

Hope it is useful to other iOS developers with the same problem.

However, I recently found some annoying problems of KVO while building some reusable programming components¹ for Voodo and future iOS projects.

Observers can not be queried

Observers are stored in dictionaries², so it should be very easy to query whether an object A is a registered observer of object B. But one can’t do that.

Unregistering an unregistered observer throws exception

One can not query whether A is an observer of B in the first place, and can neither try to unregister it from B when one wants to ensure that A is unregistered from B. It is just ridiculous! And why is removing a nonexistent observer so fatal while removing a nonexistent entry from a collection is reasonably ignored?³

Observers/observees don’t auto-dissolve the KVO relationship in dealloc

It can be easily done in KVO framework code since it already has the data structure keeping the observer-observee relationship information, and is very reasonable things to do – when any part of a relationship is gone the relationship is ended. Without the auto-unregistration, developers’ responsibility is unnecessarily heavier. In fact, it is no easy work in cases where observers outlive observees, because an observee needs to notify its observers of its death so the observers can detach themselves from the dying observee.⁴

All in all

KVO leaves some extra, tedious, and burdensome relationship management work to us while it could be easily and efficiently done at the root of itself.⁵

The KVO relationship management is especially stressful for observers watching many dynamic observees which is not unusual for generic components – UINavigationController and UITabBarController both manage a dynamic group of UIViewControllers and may observe some properties of them. It is even worse in my component because not only the observee but also the observed properties of them are dynamic. May Apple save me (and you?).