Package apple.gamecontroller

Class GCEventViewController

    • Constructor Detail

      • GCEventViewController

        protected GCEventViewController​(org.moe.natj.general.Pointer peer)

    • Method Detail

      • accessInstanceVariablesDirectly

        public static boolean accessInstanceVariablesDirectly()

      • allocWithZone

        public static java.lang.Object allocWithZone​(org.moe.natj.general.ptr.VoidPtr zone)

      • attemptRotationToDeviceOrientation

        public static void attemptRotationToDeviceOrientation()

      • automaticallyNotifiesObserversForKey

        public static boolean automaticallyNotifiesObserversForKey​(java.lang.String key)

      • cancelPreviousPerformRequestsWithTarget

        public static void cancelPreviousPerformRequestsWithTarget​(java.lang.Object aTarget)

      • cancelPreviousPerformRequestsWithTargetSelectorObject

        public static void cancelPreviousPerformRequestsWithTargetSelectorObject​(java.lang.Object aTarget,
                                                                         org.moe.natj.objc.SEL aSelector,
                                                                         java.lang.Object anArgument)

      • classFallbacksForKeyedArchiver

        public static NSArray<java.lang.String> classFallbacksForKeyedArchiver()

      • classForKeyedUnarchiver

        public static org.moe.natj.objc.Class classForKeyedUnarchiver()

      • clearTextInputContextIdentifier

        public static void clearTextInputContextIdentifier​(java.lang.String identifier)

      • debugDescription_static

        public static java.lang.String debugDescription_static()

      • description_static

        public static java.lang.String description_static()

      • hash_static

        public static long hash_static()

      • instanceMethodSignatureForSelector

        public static NSMethodSignature instanceMethodSignatureForSelector​(org.moe.natj.objc.SEL aSelector)

      • instancesRespondToSelector

        public static boolean instancesRespondToSelector​(org.moe.natj.objc.SEL aSelector)

      • isSubclassOfClass

        public static boolean isSubclassOfClass​(org.moe.natj.objc.Class aClass)

      • keyPathsForValuesAffectingValueForKey

        public static NSSet<java.lang.String> keyPathsForValuesAffectingValueForKey​(java.lang.String key)

      • new_objc

        public static java.lang.Object new_objc()

      • prepareInterstitialAds

        public static void prepareInterstitialAds()

      • resolveClassMethod

        public static boolean resolveClassMethod​(org.moe.natj.objc.SEL sel)

      • resolveInstanceMethod

        public static boolean resolveInstanceMethod​(org.moe.natj.objc.SEL sel)

      • setVersion_static

        public static void setVersion_static​(long aVersion)

      • superclass_static

        public static org.moe.natj.objc.Class superclass_static()

      • version_static

        public static long version_static()

      • controllerUserInteractionEnabled

        public boolean controllerUserInteractionEnabled()
        Controllers can be used to control the general UIKit user interface and for many views that is the default behavior. By using a controller event view controller you get fine grained control over whether the controller events go trough the UIEvent & UIResponder chain, or if they are decoupled from the UI and all incoming data is served via GCController. Defaults to NO - suppressing UIEvents from game controllers and presenting them via the GCController API whilst this controller's view or any of it's subviews are the first responders. If you are not using any UIView components or UIEvents in your application you should leave this as NO and process your game controller events via the normal GCController API. If set to YES the controller input will start flowing through UIEvent and the UIResponder chain will be used. This gives you fine grained control over the event handling of the controlled view and its subviews. You should stop using GCController instances and the corresponding profiles if you no longer need to read input from them. Note that unlike UIView.userInteractionEnabled this only controls the flow of game controller events.
        See Also:
        GCController, UIView.userInteractionEnabled

      • initWithNibNameBundle

        public GCEventViewController initWithNibNameBundle​(java.lang.String nibNameOrNil,
                                                   NSBundle nibBundleOrNil)
        Description copied from class: UIViewController
        The designated initializer. If you subclass UIViewController, you must call the super implementation of this method, even if you aren't using a NIB. (As a convenience, the default init method will do this for you, and specify nil for both of this methods arguments.) In the specified NIB, the File's Owner proxy should have its class set to your view controller subclass, with the view outlet connected to the main view. If you invoke this method with a nil nib name, then this class' -loadView method will attempt to load a NIB whose name is the same as your view controller's class. If no such NIB in fact exists then you must either call -setView: before -view is invoked, or override the -loadView method to set up your views programatically.
        Overrides:
        initWithNibNameBundle in class UIViewController

      • setControllerUserInteractionEnabled

        public void setControllerUserInteractionEnabled​(boolean value)
        Controllers can be used to control the general UIKit user interface and for many views that is the default behavior. By using a controller event view controller you get fine grained control over whether the controller events go trough the UIEvent & UIResponder chain, or if they are decoupled from the UI and all incoming data is served via GCController. Defaults to NO - suppressing UIEvents from game controllers and presenting them via the GCController API whilst this controller's view or any of it's subviews are the first responders. If you are not using any UIView components or UIEvents in your application you should leave this as NO and process your game controller events via the normal GCController API. If set to YES the controller input will start flowing through UIEvent and the UIResponder chain will be used. This gives you fine grained control over the event handling of the controlled view and its subviews. You should stop using GCController instances and the corresponding profiles if you no longer need to read input from them. Note that unlike UIView.userInteractionEnabled this only controls the flow of game controller events.
        See Also:
        GCController, UIView.userInteractionEnabled