I am trying to emulate a behavior of the home indicator on iPhone X but can't figure out how. In some apps, the home indicator goes dim, and you have to swipe it to activate normal behavior. I have found an option in the Controller to hide the indicator, but that isn't what I am looking for. In Clash Royale and Clash of Clans, for example, the home indicator dims, then when you swipe up on it the indicator gets brighter, and if you do it again it activates 'home'. Hiding the indicator using an API I found really just makes it behave weirdly.
This is the API I am using, but it doesn't work like I have seen in other apps. With auto hide on, the indicator will disappear until you swipe and immediately invokes the home action. That is no good because the purpose is to prevent inadvertent swipes going to the home screen:
override func prefersHomeIndicatorAutoHidden() -> Bool {
return true
}
The behavior I prefer is for the indicator to dim, and then activate (get brighter) when you swipe up (but not go to home), then if you swipe up again to trigger home. This behavior is constant in Supercell apps, but perhaps it isn't a built-in behavior.
In order to see the difference, you can look at one of those Supercell apps (on an iPhone X), and look at an app with just the property set.
I researched the question more and finally found the answer in this article: iPhone X: Dealing with Home Indicator
Emphasis here (I changed .top to .bottom since that is where the home indicator lives):
override func preferredScreenEdgesDeferringSystemGestures() -> UIRectEdge {
return .top
}
What that does is defer the home action until the user performs the gesture once to activate the home control, and then a second time to invoke home. Now that I have found this I (ironically) probably won't use it. I will probably just leave enough extra room at the bottom. My problem isn't with the gesture, but with the indicator covering my content (probably needs a UI update, but I don't have time for that now).
Hopefully, someone else will find this useful since this behavior is pretty cool but difficult to discover.
Related
I have an iOS game with a few controls near the bottom of the screen that may be swiped. When a player is swiping down, if their finger slides off the bottom of the screen, the Reachability accessibility gesture is also triggered. This then slides down the screen, moving those controls off the page and hiding half of the game. Obviously, this is not the players intention and requires them to be very specific with their swipes which isn't very intuitive or fun.
On the rounded suite of iPhones, the controls are roughly 100pt from the bottom of the screen to give space for the home indicator which helps to prevent this issue in many situations, but on squared devices, they are much closer at 10pt:
In my rudimentary testing, I've discovered that even if a swipe started as high as 300pt on the screen continues all the way to the base of the screen, Reachability will be triggered. So raising my controls higher isn’t a solution since that puts them dead center on the screen (also blocking the focus of the game) and out of reach of fingers comfortably on some phones.
Since Reachability doesn't have any use in my game (there are no controls in the upper third of the screen for the purpose of keeping your hand(s) in the lower part of the screen) I'd really like a way to prevent this. Ideally, some way to inform the system it is unnecessary during gameplay, so I can allow it during non-gameplay menus - but I may be dreaming with that part.
I also don't think it's A great solution to ask a user to disable this system wide, as it's my app's conflict and that requires them changing their behavior everywhere else.
Is there any guidance, examples, or advice on how to handle conflicts with this specific accessibility gesture?
You do not want to disable it, you want to defer it.
see https://developer.apple.com/documentation/uikit/uiviewcontroller/2887512-preferredscreenedgesdeferringsys
To use this, you want to override preferredScreenEdgesDeferringSystemGestures to defer the part of the screen you need to delay.
In your case:
override func preferredScreenEdgesDeferringSystemGestures() -> UIRectEdge {
return [.bottom]
}
Now if you are doing this in a dynamic fashion, you are also going to need to call setNeedsUpdateOfScreenEdgesDeferringSystemGestures() to notify iOS that your rules are changing.
I'm working on a webapp built with Cordova for both iOS and Android. Everything was fine until I launched tests on the new Apple's iPhoneX. As you may know, Apple decided to remove the physical home button by replacing it by a home indicator at the bottom of the screen:
This home indicator is always visible on your screen and it goes over your webapp content. When user want to navigate between apps or to go back to the home screen, he has to swip up this home indicator (which is very sensitive). This wonderful invention brought to my webapp 2 main problems:
This break my webapp design because it goes over the content.
The system gesture enter in conflict with my webapp gesture. My entire gameplay is based on drag & drop and all draggable icon are at the bottom of the screen, under the home indicator.
1. How to hide the home indicator?
To solve the first point I found a plugin called cordova-plugin-hide-home-indicator. This will hide (with fadeIn/Out effect) the home indicator after a few second of inactivity. But every times a touchscreen event is detected, the home button is visible again... I have red here that even if the Objective C (Xcode) function prefersHomeIndicatorAutoHidden() (which I guess is used by this Cordova plugin) return true it doesn't mean that the home indicator will be hidden for ever. Well... if somebody has a better solution I would appreciate your help!
2. How to lock system gesture?
I found a Xcode function called preferredScreenEdgesDeferringSystemGestures() They explain that normally the system will always take precedence on an app gesture, but in some cases (for immersive games for exemple) you can ask for your app to take precedence on the system. This sounds great! But unfortunately I don't know anything of Objective C :) I didn't find any plugin about that point.
In this video from Apple at 10:33, they talk about edge protection, which should do the trick by giving the app gesture the precedence, but again, I didn't find any plugin for Cordova...
Any ideas? Thanks!
Don't hide the home indicator. The solution by Apple is to use the new CSS constants as padding for the safe areas of the device. Read this to get starting point: iPhone X support
You can use this plugin in order to avoid edge gestures at iOS
https://github.com/distinctdan/cordova-plugin-screen-edges
It's very easy to use, i used in a cordova project and it works as expected
I have members complaining that they are unable to tap certain buttons located in a custom navigation bar at the top of my iOS app. The common complaint is that when they do attempt to tap, they see UI that looks like this:
This is about a 200x200 pixel square that appears over the middle of the screen.
We have no code in our app that is capable of drawing that kind of UI. I can only assume this is being triggered by some kind of iOS UI or Usability setting. The only thing I can think of is that we also have a UITabBarController, and the user (in this case) happens to be on the "Browse" tab of my app. If possible, I would like to either a) programmatically disable this or b) inform the user how he can manually disable this UI via an iOS setting someplace.
Can anyone identify what might trigger the UI you see above?
It is a new feature of iOS 11. Take a look at Bar Item Images.
To disable this you should remove an image from Accessibility on Bar Item (see link). But I am not sure how (or even whether) you can define that a user has enabled large content text.
For more info take a look at What's New in Accessibility.
I have a scroll view, and few buttons/images there. on clicking I would like such animation :
(image opens like )book cover opens, and related view controller opens with ease in animation and gets full screen.
Any thoughts ?
Something similar happening in cook app
Link of cook app : https://itunes.apple.com/us/app/cook/id687560846?mt=8
Edit : I have added animation, gif will run uninterrupted once completely loaded.
Might I suggest iBooksOpen, a library that provides a book opening animation. It's pretty lightweight and should meet your needs.
(Only drawback: it opens a single page to the whole screen, but you could adapt the geometry if you wanted a page-folding-open effect.)
I have been developing hybrid apps on iOS and the most glaring problem I am having is the back button that emulates the native back button on the top navbar has a much smaller area.
This may be due to the button being on the edge of the top edge of the screen and the webview doesn't interpret taps on the edge to be intended for the webview, maybe the status bar.
I have even enlarged the padding on the button element to the point where it takes up the whole top left corner of the screen and wont register a tap unless you aiming for 3.5mm beneath the top of the webview. On a native app you can aim 0mm away from the edge and it registers.
This may not seem that bad, however when you allow a long term iOS user that 3.5mm is very apparent, and their mental model of where a touch should register makes them immediately think the app is broken, instead of them tapping the wrong area.
I am interested in any other information regarding ways to minimize this discrepancy between native and hybrid, or proposed solutions/information leading to a better understanding on why this occurs.
Using Cordova / PhoneGap and Kendo Mobile to implement the app