How can I detected when user touch to hide or show the MPMoviePlayerController controls ?
Is there a notification or other way ?
The official answer would be; not possible.
Reasoning:
The MPMoviePlayerController is to be regarded entirely opaque and should not be modified / accessed other than the documentation supports.
From its reference:
Consider a movie player view to be an opaque structure. You can add
your own custom subviews to layer content on top of the movie but you
must never modify any of its existing subviews.
However, you may get away by adding you own gesture recognizer to the view hierachy exposed by that controller. Make sure that your newly introduced gestures dont interfere with the existing (requireGestureRecognizerToFail etc.).
But note, that is subject to break on every new iOS release as you will need to modify its existing gesture recognizers and that might be considered as a dealbreaker for submitting to iTunes. From my personal experience, that is not commonly detected by apple's review team and therefore could be an option.
The only "perfectly legal" option you have is disabling the control interface altogether (setting MPMovieControlStyle, to MPMovieControlStyleNone) and adding your own, resembling the original interface as far as you need it. Note that the complete functionality of that original interface is not entirely trivial - plan more than a day for that task. I have done loads of stuff like that and I can tell you that even after that experience, I would plan a week for fully implementing those things.
Related
I would like to have a tool tip show up over a set of UIImageView when a user hovers over it. I don't see see any methods to leverage that do this in the UIImageView class.
How can I accomplish this?
Tool tip support is not directly available in iOS at this time. But you can accomplish the same effect with a couple of approaches:
Using an existing tool tip framework
There are open source solutions available that solve the problem, which you can pull into your own project and use and save a lot of time, as long as you ensure the license is compatible with Apple's policies (many of them are, but require that you credit the author somewhere in your project source). You could study their code to learn the technique. For example there is AmPopTip project on github
Here's a corresponding YouTube video:
Here is a similar StackOverflow.com question (there may be more):
Is it possible to show a tooltip in an iOS app?
Trying to code it yourself
You'd probably use a long press gesture, see Apple's Gesture Recognizers documentation and perform some kind of Hit Test to determine when the finger was over UIView subview (in this case UIImageView) and then time the entry of it, and how long it was held in that view without moving out or lifted.
At that point you'd want to overlay a UITextView or a class that contained one but drew a custom border around it, containing with the tool tip by either adding it as a subview over the top or near where the finger was placed, or make it the pop up as a separate UIViewController.
I am looking to implement a custom toolbar that sits above my keyboard for a text field with some custom values. I've found a ton of tutorials online but this question is for asking what's the best way to do this.
This tutorial here http://blog.carbonfive.com/2012/03/12/customizing-the-ios-keyboard/ provides the most common way I can see across many tutorials, with creating a new subclass of UIView and using delegates to get that information across.
That's the commonality. However, I came across this tutorial which in the view controller itself just creates the toolbar, assigns it to the textField inputAccessory and it's good to go. In fact, I tried out the code and without any effort, I have now a custom keyboard.
http://easyplace.wordpress.com/2013/03/29/adding-custom-buttons-to-ios-keyboard/
This just seems a bit too easy to me though and I'd think the proper, Apple recommended way would be to create that UIView subclass and use delegates so that the view controller with the text fields acts as that delegate.
I'm specifically targeting iOS 7 in my app.
What are people's thoughts on this? If the second easier link is supported and is likely to pass Apple's guidelines, it's a good starting point but if delegates are the way to go, I'd rather look into that from the start.
Your thoughts will be appreciated.
There is no 'Apple Approved' way to do this, and its hard to believe anything you do here would get your app rejected. The custom keyboard you reference in your post has the iOS6 look and will appear outdated in an iOS6 app. I'll mention some iOS7 suggestions shortly, but the constant danger of mimicking what the System looks like today is guaranteed to look outdated later. In Mac/Cocoa development, Apple use to say at the WWDC that if you did something custom, make it look custom, don't take a standard Apple widget and try to duplicate it. But that advice is mostly ignored.
For iOS 7, you can create buttons that appear just like the system ones do (not pressed), but of course when someone presses them, they won't act like system buttons (i.e. animate up and "balloon" out.
I'm currently using a fantastic add-on keyboard, my fork of KOKeyboard (which uses the buttons above). This is such a cool addition. While the buttons look like iPad buttons, each one has 5 keys in it. By dragging to a corner you select one of the four, and tapping in the middle gives you that key. This might be overkill for your app, but it really helped me with mine. It looks like this:
(the Key / Value is in the under laying view.) The center control lets you move the cursor - its like a joy stick - and can be used to both move and select text. Amazing class, I wish I'd invented it!
Also, for any solution, you want to use a UIToolbar as the view holding the keys, for the reason that it supports blur of the view it overlays, just like the keyboard does. You can use the UIToolbar with no bar button items in it (if you want), and just add subviews. This is a "trick" I learned here, as there is no other way to get blur!
David's KOKeyboard (er…, the one he used - see David's comment below) looks nice. I suspect that he is using the official Apple mechanism:
inputAccessoryView
Typically, you'd set that value on a UITextView, but it can be any class that allows itself to become the first responder.
The provided view will be placed above the default apple keyboard.
It is correct that there is no official mechanism (and it is suggested against) to modify any system provided keyboard. You can add to it, as above. You can also entirely replace it for with your own mechanism. Apply will forgo the keyboard setting on your view and use a custom input mechanism if you set
inputView
set it to any view - Apple will still manage its appearance and dismissal as it does the custom keyboards.
Edit: Of course, iOS 8.x added significant access to keyboards. (not mentioned here)
I want to create an app with 6 views like the sides of a cube, and be able to swipe in each direction to move to another side of the cube.
So I want an animation between view controllers that looks like a cube being rotated.
Some old posts (eg cube structure view controllers) mention the use of #"cube" for the transition type to use in a CATransition, and call UIViewController's transitionFromViewController:toViewController:duration:options:animations:completion method to easily animate between two view controllers.
However, the iOS 6 documentation and header files make no mention of using #"cube" or any other of the string literals mentioned in the old (iOS 5 era) posts.
And I can't find anything about that being deprecated in the iOS 6 release notes or API diffs.
The animation works, but I'm worried my app will be rejected if I use it.
Will it? What's the alternative?
Taken from here:
http://iphonedevsdk.com/forum/iphone-sdk-development/102300-undocumenten-catransition-type.html
"I asked Apple's engineers about this specific issue. They said that officially, undocumented transition effects are just like any other undocumented API feature, and are not allowed.
However, their automated tools are not set up to detect using undocumented transitions like they are using undocumented methods, so you may get away with it, and you may not. It's a gamble."
I know that UIAppearance has been introduced in iOS 5, but is there any way of using the new protocol to reskin the MPMoviePlayerController, or do I still need to get my hands dirty using drawRect methods and the like?
Does anyone have any good examples of reskinned movie players for the iPad?
MPMoviePlayerController's user interface is entirely transparent for you as a developer. You can not change its appearance at all. You can only replace the UI by hiding the default interface and showing your own as explained in detail within the following SO answers:
To what extent can the iOS Movie Player be customized and styled?
Adding custom controls to a full screen movie
One additional note though:
Even though this does enable you to create a customized movie player, Apple clearly recommends against doing that - and once again for good reason. The player, as is, does provide a well functioning, good looking and accustomed UI to the end user. Customizing the interface, in almost all attempts, will reduce the usability. Trust me, I have done it numerous times for various customers that insisted in having their branded player - yet I have never encountered a design that feels as good as the one Apple provides you with.
I am working with a small camera app for a client and I have now finished all functionality of it. In the standard camera controls i need to modify one thing , the cancel button should say gallery instead.
But unless i am missing something i will need to remove the overlay by setting showsCameraControls to NO and then building my entire overlayView from scratch.
I have found this solution but I am afraid to go this route due to the warning in the beginning of the post.
So is there any valid way of doing simple small modifications to the existing camera overlay control UI or do you have to build it from scratch if you need to change one tiiiiiiny thing?
Unfortunately, having been in this situation I can safely say you need to build the controls from scratch. You really only have two options: create your own camera overlay, or use the default one.
Now, you could use the techniques described in the link you cite, and iterate through the various subviews and modify them 'blind'. The rather large danger with this is every time Apple change the internal structure of the image picker it could potentially break your solution. So I'd definitely stay clear of it.