presentationLayer position property yielding bad values on iPad, no problem with iPhone - ipad

I have a game with several small objects animated using CAKeyframeAnimation. Objects animate perfectly for BOTH iPhone and iPad. However, the value of the position property of the animated CALayers' presentationLayers only yield reasonable values on the iPhone. I use the current position of the animating objects for hit testing. Any ideas of differences in this area between iPad and iPhone/iPod Touch?
The position points for iPhone show expected incremental change as objects animate; on iPad I see peculiar values, for example this sequence:
<-36893488147419103232.000000,2.607987>,
<-0.000000,2.658927>,
<0.000000,2.709929>,
<36893488147419103232.000000,2.755450>, ...
Other properties of the presentationLayer are correct (these are properties whose values don't change during the animation, however).
After the animation finishes, the presentationLayer position value IS accurate.

Exactly same problem here!! and it looks that is a bug starting with 3.2 version of the SDK...
Actually I did a iPhone app (using 3.1 SDK) that it is completely based on CAAnimation, when I installed and ran the the app on an iPhone with 3.2 nothing works!!!... but on devices that has 3.1 works perfectly. I google it and I found another people with exactly the same problem.
take a look at the bottom of the following forum
http://www.iphonedevsdk.com/forum/iphone-sdk-development/19622-current-position-animating-calayer.html
Could you solved this issue or found a workaround?

Related

ARKit - Extend the reach of "hitTest"

I want to perform a hit testing from a point on the screen to a Cube in a 3D world. I've been using hitTest from ARKit. It works when I'm standing close to the cube, but when I start moving backwards, it stops working. I'm assuming this is because it's locked to the camera's zRange.
I've tried to set the clipToZRange option to false, like so:
let hits = self.sceneView.hitTest(loc, options: [SCNHitTestOption.clipToZRange: false])`
but it doesn't seem to have any effect.
Am I not setting the option right, or is this a bug?
I am using the latest Xcode and iOS betas.
Turns out the showFeaturePoints debug option from ARKit interferes with hitTest...

Indentation of UITableViewCell changes after rotation only on iOS 8

I have an UITableView with three dynamic rows. When displaying the UITableViewController the first time everything works fine. After a rotation the rows which have a data in it get an indentation despite I set setLayoutMargins to zero. I cannot reproduce this issue in another project until now. It is only appearing in iOS 8 but but only on one table. The same source for the table is working in a test project without problems. The only difference here is that it is in a container with some other views.
I checked auto layout constraints, the rotation methods, commented things out - all without success. The change of the indentation occurs between willRotateToInterfaceOrientation and didRotateToInterfaceOrientation or after viewWillTransitionToSize. I even updated to iOS 8.1 with the same results.
Has someone expeerienced a similar behavior?
PS:
What I've also noticed that when setting the layout margins to zero on iOS 8 the animation is not as smooth as it would be with the default values (with indentation). On iOS 7 the animation is always smooth.
EDIT:
I tracked some things down. If a UITableViewController is embedded into an UINavigationController the indentation happens on rotation. If you rotate further it goes back to it's set indentation (no indentation in my case).
If the UITableViewController is embedded into a container (and this container is in a navigation controller) than after the rotation the cell get it's default indentation back. If you rotate further this behavior stays the same (always indented).
Are some events not send to the child view controller or none of you uses a UITableViewController embedded into an UINavigationController?
In my opinion it is a iOS 8 Bug or a Xamarin Bug. Perhaps one other could verify if it is the same with his installation. I'm using Xamarin Studio 5.5.2 with Xcode 6.1.
One ugly solution to this is this:
public override void DidRotate (UIInterfaceOrientation fromInterfaceOrientation)
{
base.DidRotate (fromInterfaceOrientation);
// otherwise cells are indented! iOS 8 Bug?
TableView.ReloadData ();
}
One could use reloadData or reloadSection in didRotateFromInterfaceOrientation, despite it is a deprecated function. But there is no viewDidTransitionToSize and I also have to support iOS 7.
Edit:
Another solution I have come up with is to draw a custom separator line. This only works for iOS 8 and would answer the question (despite I've another issue on iOS 7 where this approach doesn't help).

Size classes don't work for extensions on iOS8/XCode Beta 7

I'm following the exact steps from this video (from 7:49 onwards): http://youtu.be/IwSTXY0awng?t=7m49s
The UIButton I'm adding to my view when changing the size class to, for example, portrait iPhone, always shows up. Note: only acts this way in extension mode (building a custom keyboard for example). When using a storyboard/view controller/app (exactly like the video), it works as expected.
Is this a bug or expected behaviour? Any work arounds?

Underscan issue with AirPlay mirroring

I'm having some issues with AirPlay. The thing is, I'm developing with the ATV3, and my TV set supports 1080p. But when I start screen mirroring and receive the new instance of UIScreen, the bounds and the applicationFrame are both giving me a 720p resolution.
But it gets weird when I actually moved the subviews to a negative value, and the whole screen gets covered. So, technically my iPhone is streaming at 1080p, but the bounds returned by the UIScreen are underscanned.
I've tried modifying the overscanCompensation before getting the bounds or the applicationFrame (tried both with all 3 overscanCompensation values available) but I'm still getting the same result.
Here is a picture of what I'm getting (sorry, it's the worst picture in the planet, I know, but I was using my phone to stream the image to the ATV :) )
Red view is the 720p reported by bounds.
It gets even weirder when I actually try this out in my ATV2 (it is supposedly limited to 720p even if it supports 1080p) and the result is exactly the same.
Anyway, if someone knows the method to get the real screen display to avoid putting a settings view in my app, I'll really appreciate it.
Thanks in advance :)
When you mentioned that you tried all 3 overscanCompensation modes, I presume you mean the 3 documented modes:
typedef enum {
UIScreenOverscanCompensationScale,
UIScreenOverscanCompensationInsetBounds,
UIScreenOverscanCompensationInsetApplicationFrame,
} UIScreenOverscanCompensation;
However, there is a fourth mode, which is not there, but should fix your problems: just set your overscanCompensation to 3.
Also, take a look at this SO question.
The answer of Ivan solved the same issue for me! But I also had the borders when using AirPlay Mirroring. I got rid of the borders without setting the overscanCompensation property by changing a setting on my Apple TV: try setting 'Settings > Audio & Video > Adjust For AirPlay Overscan' to Off (default On).
The setting that works best for most TVs is:
externalScreen.overscanCompensation = UIScreenOverscanCompensationInsetBounds | UIScreenOverscanCompensationInsetApplicationFrame; // this is the same as setting it to 3
Just setting it to UIScreenOverscanCompensationInsetApplicationFrame can cause misalignment of the UIWindow contents.
3 is a bitmask of UIScreenOverscanCompensationInsetBounds(1) and UIScreenOverscanCompensationInsetApplicationFrame(2) for those wondering where that number comes from and why it works.

iOS5: UIScrollView dispaying and scrolling differently from iOS4

This is a curious one.
I have an IBOutlet UIScrollView playScrollView whose height is exactly 1/3 of it's contentSize's height. The app is in landscape. I call this code...
[playScrollView scrollRectToVisible:CGRectMake(0.0f, page * PLAY_VIEW_PAGE_HEIGHT,
480.0, PLAY_VIEW_PAGE_HEIGHT)
animated:animated];
... (the int page ranges from 0 to 2) to start on page 1 (displaying the middle third) then go up or down as needed when the user presses buttons.
This works fine for iOS4 both device and simulator, and has been live on the app store for months with no problems. Even iOS5 devices are fine with existing builds, it was only when the app was recompiled for iOS5 that it stopped working correctly on iOS5 devices.
Since updating to XCode 4.2, This doesn't work for iOS5. It goes one page too low, showing the bottom page when it should show the middle. I can get the code to work for iOS5 (device and simulator) by changing page to (page-1)...
[playScrollView scrollRectToVisible:CGRectMake(0.0f, (page-1) * PLAY_VIEW_PAGE_HEIGHT,
480.0, PLAY_VIEW_PAGE_HEIGHT)
animated:animated];
...but of course this breaks iOS4, which works fine with the old code, but gets stuck one page too high with this new code. iOS4 and iOS5 are exactly PLAY_VIEW_PAGE_HEIGHT out-of-step (288 pixels, a third of the height of playScrollView). The same thing happens if I use setContentOffset: instead.
One other curious thing, probably the key to this. If I don't do the scrollRectToVisible at all, then iOS4 sits at the top of playScrollView, wheras iOS5 shows the middle third, (ie PLAY_VIEW_PAGE_HEIGHT pixels down).
I could detect the iOS and use different code for each, but that's a horrible kludge. If it's an iOS5 bug and they fix it in a future release, that would break the live app.
Has anyone any ideas, or noticed anything similar? Thanks.

Resources