I am using UIImagePickerController for selecting images from the photo library. But I am getting a message on the console saying "Using two-stage rotation animation. To use the smoother single-stage animation, this application must remove two-stage method implementations."
What is this due to ?
Thanks
Several people appear to be having the same problem. None of these links provide a solution (as far as I can tell), so this post is intended just as a starting point for more searching. I have made it CW.
stackoverflow: Single-Stage vs Two-Stage Animation for iPhone Apps
cocoabuilder: how to change to the smoother single stage animation
stackoverflow: tabbarcontroller and navigationcontrollers in landscape mode
Apple support: 11186784
That normally means you have implemented one of:
willAnimateFirstHalfOfRotationToInterfaceOrientation:duration:
willAnimateSecondHalfOfRotationFromInterfaceOrientation:duration:
on one of your view controllers, even if they are empty. This is neither wrong nor deprecated, the message just say it could possibly done better if you moved your implementation to: willAnimateRotationToInterfaceOrientation:duration:
Related
I notice some small graphical glitches while testing one of my app under iOS 8: some UIViews elements are not in the right place, others have not the right size.
In a first step, I use storyboard, Auto-Layout and constraints. Then I programmatically tune constraints to perfectly suits devices' screen size, using updateViewConstraints.
Perfect on iOS 7 but with some glitches on iOS8 as on following picture:
./Users/dominiquevial/Documents/Informatique/Dev/Novae Marathon/_log/captures/iOS8 - iPhone 6/pause.png
After investigation I found the problem: updateViewConstraints is not called. I don't understand why, maybe due to some optimizations...
Correcting this problem is easy :
use viewWillLayoutSubviews in place of updateViewConstraints
or add call to setNeedsUpdateConstraints in viewWillAppear
Which way is the best one ?
Depends if the user can cause the views to enter an invalid state after the view appears, if so the first option. If this is not possible the second.
The less work your app has to do the better.
I've created an in app email feature to ask a question that opens the mfmailcomposer and fills it with html content. Unfortunately it seems to cut off the final line of the email so it appears as the image below.
I have set the mfmailcomposer to self, followed every tutorial I can find, the only reference to fix it has said the following:
make sure your mfmailcomposer is set to self ie. [self presentModalViewController:email animated:YES];
make sure it's embedded within a navigation controller
Neither solution works.
I have found that if the email contents is short enough that the entire email fits on screen the problem doesn't appear but if you continue typing to push the contents off the edge it reappears.
Any ideas on a solution? Or is this an Apple xcode "design feature"?
I managed to resolve this issue, it seems to be a bug, that's the only explanation I can reach.
If the start of your content is a header (<h1>, <h2>, <h3>, etc) tag (even if it is within a HTML and BODY tag) it creates this issue.
If you want to start your email body with a header tag then the simplest way of fixing it is to add a non breaking spacer before the header tag, it seems to completely resolve the issue.
Possibly a framework bug. Does it occur on different versions of iOS? Try it with both older and newer versions of the operating system and on other devices.
Are you 100% certain that the view is not actually larger than its container view? Explore the view hierarchy. Perhaps in plaintext Apple adds some spacing, so it doesn't seem like the content is out of bounds of the parent view, although it is.
How do scroll indicators behave? Are they also clipped?
Are you presenting the message composer in a fullscreen view? If you're trying to present it in a view that is controlled by a sub-controller of the tab view controller, that might cause the composer view controller to be confused.
For what it's worth, I've just tested my code which generates HTML content, and there is no clipping. This is on iOS 4.2.1 on iPhone 3G, but I don't remember seeing the problem on iOS 5.1 either.
Some tips.
While debugging, don't forget: view controllers are actually just managing views that still have their own hierarchies. To clarify, view controllers may have a hierarchy, but their hierarchy does not necessarily correspond to view hierarchy. (Although it should in the near total majority of cases.) Same thing with views themselves: they have their hierarchy, but they still just control the underlying Core Animation layers, which have their own hierarchy.
You can always access view hierarchy itself and explore it in greater detail through debugging facilities you come up with yourself. What you shouldn't be doing is meddling too much in parts of the view hierarchy that's supposed to be managed by the view controllers, just like you shouldn't mess too much with the parts of the layer hierarchy that's supposed to be managed by the views.
Being a somewhat proficient iOS developer, I have just started working on a desktop OSX project in Cocoa and I'm running into issues that I just can't grasp. So this question is for the OSX developers out there.
I don't like the Interface Builder much, so I tend to write my views in code. The most prominent method I write my view layout code in is a view controller's loadView method, and at least on iOS I use autoresizingMasks for everything. Try out the view small, large, rotated landscape and portrait and if all is dandy, I continue with the next item on my list. Now on the desktop, the autoresizingMask works (or just looks) a little bit different. First of all the properties have different names, but their behavior also seems weird or unexpected.
When I ran into the issue below, I thought it must be my code was wrong, so after trying out long enough I re-created it with Interface Builder just for confirmation's sake, and guess what: I got the exact same result. Take a view with four vertically stacked subviews. Set the middle two to have flexible heights, the outer ones to be fixed. When you run it, size it down and back up again, I get two completely different layouts before and after the resize. See image:
Now I can follow why this happens from a mathematical standpoint between run loops, but from the point of an 'autosizing' or 'autoresizing' feature, this makes absolutely no sense.
Before I try to write the mother-of-all-resizing-topics here, might I ask you these questions? Feel free to elaborate some more on the resizing topic if you feel it adds to the post.
Am I a fool for not wanting to use the Interface Builder on desktop projects?
Should I depend on the autoresizingMask less than I would on iOS projects?
What are decent alternatives to making sure your layout lives up to standards without Interface Builder?
Cheers!
Yes, in my opinion. :)
You should depend on it when it does what you need. When it's insufficient, override resizeSubviewsWithOldSize: and/or resizeWithOldSuperviewSize: (or see below).
???
If you can target 10.7, look at the new constraint-based layout system. Check out the Cocoa Autolayout video from WWDC 2011.
You could also set minSize on your NSWindow to something large enough to prevent the singularity.
I'm not sure I'd say "fool," but refusing to use Interface Builder on the Mac is a very…avante-garde choice.
You should definitely use autosizing on your views.
Be maniacally attentive and spend lots of time making sure everything is right. (This is why I don't recommend going without Interface Builder. In general, what you get is a lot of wasted time that you could have spent doing something else.)
In this case, I think the best approach would be to set a sensible minimum height for the window. Don't let it get too small to display what it needs to display.
I have implemented a scrollview which uses a CATiledLayer. In UIDocumentInteractionController the view shows some kind of checkerboard background while loading its contents. I wonder if there is something similar to UIColor.ScrollViewTexturedBackgroundColor to get this checkerboard? Or do I have to use my own image?
No, there's none in the IOS documentation, unfortunately. Apple uses their custom backgrounds on a lot of apps, and in general you just need to create it and load it with the UIColor.FromPatternImage(UIImage.FromBundle("image")) command.
In Interface Builder.app (and some other cocoa apps), image dragging has a very nice/sexy effect of morphing the drag image while you drag a draggable item out of its window.
For example in Interface Buildler.app:
Show the Library Palette (⇧⌘L, or Tools Menu -> Library)
Drag an item out of the Library palette
NOTE: as you drag the item out of the Library Palette window, it morphs from an image of the original list item to an image of the icon of the dragged item.
I have fully implemented drag and drop in my Application using the normal Cocoa NSDragSource/NSDragDestination facilities.
However, I can't find a hook for doing this image morph while dragging. I'm returning the initial drag image by overriding
-[NSView dragImage:at:offset:event:pasteboard:source:slideBack:]
But this is only called at the beginning of the drag.
How do you signal that you would like to replace the current drag image (ideally using the sexy morph effect).
You guys beat me to it. :-)
Yes, JLNDragEffectManager is open source (with attribution in your apps, please) and available on my blog. It should work fine as-is with no modification back to 10.5, but I'm not sure back any further. Others linked to it (and it's easily googleable), so to avoid self-congratulatory blog linking, I'll leave it at that.
Issues: One developer commented on (and submitted code to fix) the lack of dragging offset support. I've just not gotten around to posting the update. That's the only outstanding issue I'm aware of.
Improvements: I'd like to add multiple "zones" (say, one per document, so dragging from doc to doc keeps table rows looking like table rows, but anywhere outside doc windows turns them into a file icon a la HFS Promise Drag). Some day ...
Design: The post itself details the reasoning behind the design and the relatively simple morphing effect (cross-fade plus size are animated using basic NSAnimation, etc.). The code (the class as well as the demo app) is thoroughly blocked out and commented.
Won't link to my own post but would love the karma of upvotes for my effort. ;-)
UPDATE: Similar (but better-integrated) functionality is available as of 10.7. If you are targeting 10.7 or higher, it's best to use the new API. JLNDragEffectManager works fine on 10.7, so it can be used for earlier-targeted versions.
JNLDragEffectManager does exactly that. :)
The API does not support this well. Joshua Nozzi gives a method that looks reasonable in this weblog post.
IB's effect isn't that fancy. It's a crossfade and scale. Hold down shift to see it more clearly.
As of 10.7+ the current approach is to use the
enumerateDraggingItemsWithOptions:
forView:
classes:
searchOptions:
usingBlock:
API on NSDraggingInfo. The documentation is really poor but the ADC samples like MultiPhotoFrame or TableViewPlayground can give a good idea on how to use the new mechanism.