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.
Related
SwiftUI has a SecureField text field which doesn't show anything typed into it when viewed from screen recordings or screenshots. Similarly, iOS 15 is going to have a .privacySensitive() modifier that removes the View from widgets and such. Does anyone have any idea on how to implement Views like this? I want a View which blurs itself when it's contained in screen recordings, screenshots, app widgets, multitasking menu (so they can't cheat the system) etc.
Any suggestions on how to achieve this effect would be greatly appreciated.
Thanks in advance!
Edit: You can tell if someone has opened the multitasking menu by subscribing to NotifcationCenter.default.publisher(for: UIApplication.willResignActive, perform: { _ in }). However I still haven't been able to figure out the others
Edit 2: I also found that subscribing to UIScreen.capturedDidChangeNotification tells you if screen recording is active. Still stuck on screenshots and widgets
I'm not so sure if you can hide screenshots because UIApplication only has a .userDidTakeScreenshotNotification Notification Name. If you are trying to do it manually rather than using iOS 15s .privacySensitive(), you can overlay a View over the entire app. To do this, as you stated you could use the UIApplication.willResignActive to overlay such a view in the Multitasking menu.
To achieve this however you need to get the window and add the subview to it as follows
let currentWindow: UIWindow? = UIApplication.shared.keyWindow
currentWindow?.addSubview(myOverlayView)
For the screenshot problem, like I stated above, Swift only has a .userDidTakeScreenshotNotification and no .userWillTakeScreenshotNotification. So the best bet is to delete the last image by listening to the screenshot notification. You can see how to delete the last photo of the gallery here. This should provide the delete for all feature Whatsapp seems to use. Given that, you will still have to provide access to the gallery
This should give you something similar to the snapchat app. This code is not tested
I have issue when I try to push view controller in willTransitionToPresentationStyle:. The view was blinking for a split second before it fully expanded. It might be a small glitch or bug since iOS 10 and Xcode 8 are still in beta. But when I manually requested to change presentation style to MSMessagesAppPresentationStyleExpanded by calling requestPresentationStyle: after I push view controller, it went to expand mode more smoothly. Does anyone have similar issue?
I have had similar problems with transitions in iMessage apps. I think this should improve considerably when iOS 10 and Xcode 8 come out of beta, but for now we have to deal with Xcode's bugs.
There's a few things I've done to make this look better. Inside my extension I have a method that checks the presentation style every time the view changes. This method manages two different UIs - one for MSMessagesAppPresentationStyleExpanded and one for MSMessagesAppPresentationStyleCompact. This method hides and shows specific views accordingly. In my compact UI I have a button that allows the user to expand the interface by clicking it (this is basically the same as clicking the up arrow at the bottom right of the screen).
I've noticed that if you let the user expand the messages app after the view has been loaded for a while the transitions are much smoother and less buggy. Not sure why this is the case, but you should give it a try. Also, I've found segues to be extremely buggy, so that's why I went with keeping everything on one view controller.
Here is context for my question, this is an optional read:
I have to develop an app for a
school project. At the end of the year some people I don't know will
listen to me presenting my app, and review my presentation and my app
(note that they will probably not be app developers, they are usually
IT professors) (note also that I'm allowed to ask for help to anybody,
and I can use internet since I do this mostly on my "free time")
So since October I'm developing my app, that takes a lot of time
because this is my first app. And here comes the issue:
My app is a giant Scroll view with 5 NavigationsControllers, each containing a ViewController. These ViewControllers sometimes have buttons that leads to an other ViewController. The problem is when I use these buttons, and another view controller is displayed, when I swipe right or left the ScrollView scrolls and another ViewController from the scrollView is displayed. I don't want this to happen because most of the time the ViewController displayed after the tap on a button is not meant to stay, it's generally a form to send data to the server.
As I think this is difficult to understand, you can download the project on Github
Is there a way for me to disable scroll on chosen ViewControllers? or should I change everything to avoid using a ScrollView?
Bonus question:
Is it a really really bad idea to make an app this way, or did I just miss something?
Thanks for your help!
When i present a modal screen from a page in page based navigation, the whole screen shifts up and the status bar is no longer visible.
Here is a gif of the issue:
I am using xCode 6.2 version.
This was not happening in xCode 6.2 Beta 4..
I am not sure if this is a simulator issue or this will actually happen on a real device too.
Does anyone have the same issue? Is there a workaround?
I reported a bug to apple (20109240) and it was marked as a duplicate of (19862945), and that one is still open.
Thanks in advance
This is a known issue in the final release that exhibits itself in two cases:
When presenting a second modal controller (paging or single) over an existing paging modal controller
When presenting a menu using Force Touch over a paging modal controller
This has been discussed in the Apple Developer Forums, and the only workaround I've heard about is one that I use in my app. Unfortunately, there's no simple code to share that solves the problem, so I'll describe the approach (which I'd consider messy, but workable).
First, you need to keep track of interface controller presentations. I have a framework for this, but you may have to roll your own. When a child interface controller has its willActivate called two times in a row (in other words, without a call to a different child interface controller) you can assume that a modal was presented/dismissed on top of it.
Your presenting/parent controller can then inform all children that the modal menu bug has happened, and those child controllers can unhide a replacement status bar with its own Cancel/Close button. With some work, you can recreate a pixel-perfect version of the standard status bar with identical behavior.
The final twist is to detect when your Watch app is suspended, then resumes. In that case, willActivate is also called twice. If you don't handle that situation, you'll end up unhiding the replacement status bar and have two on the screen simultaneously. Not a great scenario.
Getting this right is very tricky, but it does work. I just wish I had a simple code sample that you could inject.
Update: I pushed some of my workaround code to GitHub: https://github.com/mikeswanson/JBInterfaceController
I am planning to use a couple of picker controls and segmented controls (as a kind of control panel) embedded in a container view controller to control the contents of a second child view controller. However, according to Apple iOS Human Interface Guidelines, on an iPad a picker may not be presented in the main screen and must be presented in a popover:
On iPad, present a picker only within a popover. A picker is not
suitable for the main screen.
How strict is this rule?
Would it be ok in my case to have the picker on the main screen in order to provide the required interactivity?
Clearly the answer to your question really depends on Apple, not on anything we developers might think or say. Your screen design looks very reasonable to me, but the issue is really whether Apple will approve it.
It might be better to ask if anyone has had an app approved with pickers outside of popovers.
Alternatively, you could ask if anyone has had an app rejected for using Pickers outside popovers.
Apple rules and common sense have a high degree of overlap, but where they differ the only thing that matters is Apple. Either ask them, or just submit your app for approval and see.
Good luck!
Here is my experience regarding picker.
I had an app (say appAA) approved, which use picker view in a modal view, three pickers, one followed by another.
I had another app (say appBB) which basically copies the modal view of appAA. This app was rejected because of a functional problem which I could not reproduce. I debuted in Resolution Center, then the reviewer rejected again with additional reason, saying the pickers are not presented in popover!
I guess I have to put the pickers into the popover if I want appBB to be approved since the review mentioned so.
I think the answer is simply How ugly does it make the UI look?
The left/right edges of the picker were originally intended to be flush with the edge of the iPhone screen (and it was hardcoded to be 320px wide, which failed to work sensibly in landscape mode). On the iPad, the UIPopover lets it be flush with the frame. The obvious way to achieve this effect without using a UIPopover is to draw your own frame, instead of leaving a flat grey background between the pickers.
However, the easiest (and better looking, IMO) solution is to take the picker background (as a 1px-wide image) and use a UIImageView to stretch it behind all the pickers so they look like part of a continuous bar. Remember to check both retina and non-retina versions.