I'm writing an iOS app that casts pictures. I want to make it in a way that when the user quits the picture viewing scene, it goes back to the homepage (the one displaying app's name) on the big screen. I've tried calling the stop method for mediaControlChannel and it's not going back to the homepage. So apparently this is not the one I'm looking for. So which method should I call to make it go back to homepage?
SDK doesn't have any understanding of your "homepage"; that is a concept in your app so you need to write your receiver so that if user ends the process of viewing picture, it switches to that page. Whether receiver on its own can determine that the above process has ended or sender has to signal the receiver depends on your application and its details but regardless, going to your home page is an action that you have to define and handle.
Related
is it possible to prevent the app from closing when my app asks for a fingerprint and the user presses the home button instead of only let the finger rest? I know and understand that it shouldn't be possible everywhere else, but it would be nice if the app wouldn't close when asking for the fingerprint.
It is not ever possible to change regular system behaviour, even though some users might press too hard and go back home that is the behaviour that everyone expects, want to go home, press the home button and it always works
This is not possible, what you are trying to do is getting out of the scope of your application and change the behavior of the device. Apple won't allow it, ever.
They might change the behavior if they think it's better to handle it like that, you can send them a message. But they'll probably never do that as they are killing Touch ID for the sake of Face ID.
I have an app that I call the method SKStoreReviewController.requestReview () after 10 times that the user performs some action. The prompt stoped to appear even the debug show me that the method requesrReview is being called.
What's can be happening?
From the Apple docs:
Although you should call this method when it makes sense in the user
experience flow of your app, the actual display of a rating/review
request view is governed by App Store policy. Because this method may
or may not present an alert, it's not appropriate to call it in
response to a button tap or other user action.
The popup will only display sometimes, and it's dictated by the SKStoreReviewController as to when this will be, so you can't guarantee it will ever be displayed.
For example, I have a Notification that occurs when there is an "unauthorized" error returned from the api server that should bring the user back to the login screen. This event could appear anywhere in the program.
Do I create a new viewless controller to manage states and have it monitor for this notification and then present the login view controller?
I'm thinking about push notifications too, received by the app delegate. Some of these may cause the data model to get updated and then the screen to change. Who should make the screen change? In the past I put all this in the AppDelegate. But there must be a more elegant way!
I also found out about FlowControllers. But they don't play nicely with Interface Builder, at least according to this solution.
Please let me know if you need more specific information about my project.
I'm writing an iOS app that uses chromecast to cast a series of pictures. When the user taps on the right edge of the current picture, the app presents the next picture, and the next picture is casted to the bigger screen. However, if the user taps fast enough and brings up the third picture before the second picture shows up on the bigger screen, the second picture, once shows up, will stay there even though the third picture shows up on the device. From the Google Cast SDK it looks like all the casting requests are queued up and the third one should show up automatically. So does this mean I have to queue the requests manually on the sender side?
I imagine your images are available on a server (which could be your phone as well). What receiver are you using? What is the behavior you expect to have? If, for example, you need to see all the images no matter how fast you cast them, then your receiver should queue the urls of images and when is completely loaded, loads the next one, etc. If you expect to skip over the previous images if a new one is casted, then your receiver should drop the previous requests as soon as a new one comes in.
You can queue them on the sender side as well (especially for the first scenario) and your sender should listen to "image is fully loaded so send in the next one) but that is not optimal since
your app creates a better experience if the next image is loaded behind the scene on the receiver while the first one is being shown so it can quickly transition to the next one and
You probably want to provide an experience that if you queue up some photos, your app can play them on the TV even if your phone gets disconnected (only relevant if images are served from a separate server).
Another factor to consider is what do you expect if a second device is connected to your Chromecsst while the first one is casting; do you want to the second one be able to "participate" in the activity and cast as well or not.
Regardless, there is a sample code on our github repo that shows a simple playlist for videos (queued up on the receiver).
I would like to perform a different action when my app moves to the background depending upon if its moving to that state because there is an incoming phone call, or if its moving to that state because the user has hit the home button.
In both cases the app delegate receives a willResignActive:, then a didEnterBackground: call. Therefore from the app delegate calls alone it would appear its not possible to determine the difference.
Is there some way?
UIApplicationDelegate Protocol has a variety of methods for Monitoring Application State Changes.
Unfortunately (for you), going into the background is going into the background, there is no differentiation as to why. Given Apple's app design of walling everything off (for security reasons) I don't see them providing you details about what's going on on the phone outside your application.
I would certainly question the need for different behavior in those two cases, but I don't know the details of your app.