I'm working with the new interactive notifications in iOS 8; it fails to get the action buttons (in "banner mode") to show up by default. As it is now I have to slide down on top of the notification to see them.
Is this the default behavior, or is my code rotten?
For the images below I am using XCode 6.1.1 + iOS 8.1 (Simulator)
What I get:
What I want:
This is the default behaviour and no problem with your code.
For more details refer to the below tutorial, result is same as yours.
http://www.thinkandbuild.it/interactive-notifications-with-notification-actions/
Its a default behaviour. Don't worry about this. Apple says:
When a notification is delivered, the system displays a button for each custom action associated with the notification. Tapping a button launches your app (either in the foreground or background) and gives you a chance to perform the indicated action. You use this class to specify the text that is displayed in the button and the information your app needs to perform the corresponding action.
The options are not default behaviour. That can be done via - UIUserNotificationCategory
Refer this WWDC video - https://developer.apple.com/videos/wwdc/2014/?include=713
It's pretty straight forward and easy to implement. Let me know if you face any issues.
Everything is behaving normally. All that needs to be done is to drag down the bottom horizontal bar in the banner and the action buttons would be visible in the banner.
PS - As of iOS8. Once iOS9 comes in in a few more days, no guarantees if this is how it will still be.
Related
In our app we are tracking screen views manually by adding relevant codes in viewWillAppear functions. With iOS 13, with the non fullscreen modals, the viewWillAppear of the parent screen won't get called when the modal is dismissed and hence wrong screen names are reported there after, for events originating from the parent screen.
I have checked the Detecting sheet was dismissed on iOS 13 , but the solution to implement UIAdaptivePresentationControllerDelegate helps when you manually swipes down.
I then turned off manual tracking and turned on Automatic tracking and surprisingly the screen classes are determined right. Question is how Firebase is figuring that out?
Of-course I can't use auto tracking as we need custom screen names.
I believe this could be a generic issue for whoever using manual screen name tracking and have non full screen modals. Just wanted to check what's the best way to solve this.
Couple of ideas I had was
Make all modals full screen. Not nice for our app
Implement extra delegates in those modals to let the parent know its dismissed. Not sure its a nice way
Setting screen names on each event? Could that be even possible?
If there are any other nicer/ cleaner option let me know.
I’ve been struggling with a bug since I changed the version of Xcode 10.3 to 11 beta and iOS 12 to 13.
This bug is related to UIVisualEffectView and the value of the blur changing while navigating through the App.
Basically It’s a bank App where the user has the possibilty to choose the visibility of his balance
In the first view therefore the first view(DashBoard) has a view with the user balance where he can
Hide or unhide it. As you can image to hide the balance we are using the UIVisualEffectView with blur effect.
Where the view is settled in a Xib and linked to the class keeping it’s reference by outlet.
Everything works fine when we open the app for the first time and we see the blur covering the balance 100 %
Not giving the possibility to the user to see it. The user can see it only if he touch on the view and switch to the
visible option.
If the user goes out from the app or present another view over the dashboard ( the view holding the blur area )
Each time the user comes back to dashboard the blur decreases its value. It happens only if the user close and open the app or if the user presents some view over the dashboard and come back.
Everything worked fine in iOS 12 but in iOS 13 it decrease along the interaction the user is having with the app and turning back to the dashboard.
Compiling the app in iOS 12 with Xcode 10.3 I observer that the value of filters.gaussianBlur remains the same
If the user present view over the dash board going around and coming back. I mean ( THE BLUR DOESN’T CHANGE FOR ANY REASON )
While compiling the same code with the same logic without change anything in Xcode 11 with IOS 13 the value of
filters.gaussianBlur.inputRadius decrease randomly until comes to 0 and showing all the are that should be hidden.
I can understand that is a weird behavior because everything works fine in iOS 12 but while changing version the value starts to decrease while the user is going around the app and turning back to dashboard until the user be capable to see the balance without touch on it.
I don't think it's necessary to show any code because the behavior works perfectly well in iOS 12.
But if necessary I'm open to post it.
Here I have some picture of this behavior
If you observe the value remains the same always 20. (USING IOS 12)
Here the values decrease until arrives in 0 ( USING IOS 13)
These is the behavior I'm getting while presenting views over the dashboard and coming back.
I solved this problem by updating the instance of the UIVisualEffectView each time the viewAppears. So I’m not using outlet anymore. I’m creating a new instance and adding it to the view after remove the previous one. It’s a good work around but I think it’s a bug in iOS 13 that apple should take a look.
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 will word this question embarrassingly awkward and primitive as I have spent ten minutes searching for the answer and failed miserably. Please help/nudge to resolve!
Desired IOS Feature
Setting the upper navigation bar over all Apps to a custom color and text value that navigates to a specific App when tapped
Example
The App SleepCycle when it is set to Alarm-Clock mode, and when the User is in any other App other than SleepCycle. The top of the screen then becomes red with the text 'SleepCycle' and when you single-tap it you navigate to SleepCycle
Question
What is this feature called and how do you programmatically implement it?
When I've dabbled with this in the past, the hack(?) I used was to register as a Voice Over IP / audio app in Background Modes. WARNING: I have never tried to ship such an app to the App Store, as it seemed like a dubious approach.
I'm working on an iOS app that uses dark keyboards. One such keyboard is affiliated with a UITextView. I create the UITextView and play around with it for a bit and every thing works as it should.
The problem occurs when I dismiss the keyboard and then click the home button and dismiss the app into the background. By reopening my app, I return to the screen on which I just was. When I click on the UITextView, it gives it firstResponder status and the UIKeyboard reappears.
If you check the properties of the UIKeyboard, the appearance is still set to dark but for the first second the keyboard is on the screen it shows as light.
Does anyone know how to force a refresh of the keyboard between the app entering the foreground and the keyboard being displayed?
I do not believe there is anything you can do at this time to fix this. I had a simple project I had just done to send in a bug report to Apple, but it didn't fail in the demo project as it does in my code. I was going to toss that project away when I saw your problem.
So I have verified that even in the very latest unreleased Xcode and iOS beta this still happens. But, since I had the project already, I did enter a bug report on it with the demo project so Apple can see it for themselves.
15586497 "Keyboard flashes from white to dark under one specific test"
If you want to enter your own bug you can say its a dup of the number above, then no need for a demo project.
IMHO, these things do get fixed, but not for a while - maybe iOS 8 if you're lucky, so I think you're just going to have to live with it, or switch to using a white keyboard.