I am really stuck on this problem and I need your help!
I'm doing an ipad game with unity and the social network plugin from prime31.
The situation:
When you arrive to the end of level, the game gives you your score and ask if you want to submit it to facebook. If you do, In my script I've done a system that checks if you are logged in, if you aren't it ask you to login and then the system checks if the app has the publish permissions and if not it ask you the permission. If all theses if are true it posts a message to your wall straight. So hopefully the login/asking part needs to be done only once.
The problem:
When the ipad swap between the game and the facebook app to login, the ipad shutdown the game for saving memory. I've tried to reduce the scene, but it's hard to reduce it more than it is. So I thought maybe I should open that facebook login and authorisation inGame. For that I tried working with this:
setSessionLoginBehavior(FacebookSessionLoginBehavior.ForcingWebView);
And it does exactly what I want, it opens a small window in game, doesn't crash all good really. But the problem, in this solution, is that it only works for the login, and when I ask the publish permission it switches back to the facebook app to ask the permission and therefore crashes.
After more research, it seems that it's not doable to control the ask permission behavior.
So back to square one, how can I prevent IOS to shutdown my game while the user connects to facebook. I'm still looking to reduce the scene.
I heard of using the app url and sending data for the app (my game) launch after leaving the facebook app and therefore ask the ipad to relaunch the app at a specific scene. But that would be really the last solution because it's going to take a lot of rework to make that happened.
If you have another suggestions to work around this problem I'm up for it. All I need is login -> ask for publish permissions -> post and come back to the end of level screen of my game.
Thanks for the help
Put simply, once your app is backgrounded, if iOS wants to shut it down, you can't prevent that from happening.
The best thing you can do is save the state of your app before handing over to the facebook app for the authentication side of things, and then reload your state when the app starts up again. You'll want to handle applicationWillResignActive:, applicationDidEnterBackground:, applicationDidBecomeActive: and applicationWillBecomeActive:.
The App States and Multitasking section of the iOS App Programming Guide explains how you can do this.
I think you should check for FBDialog for iOS 5 and beneath. And FBNativeDialogs for iOS 6.
These will pop a window on the top of your app, so I guess it will still be running. And for iOS 6's FBNativeDialogs
Provides methods to display native (i.e., non-Web-based) dialogs to
the user. Currently the iOS 6 sharing dialog is supported.
Related
This question already has answers here:
Toggling Privacy settings will kill the app
(2 answers)
Closed 4 years ago.
I am making an iOS app and I am new in iOS world. In this app, I want to access user contacts. Everything is going good and working well. But I experienced a amazing behavior which I have not seen in Android since I am android developer.
In iOS to access user contacts I am using Contacts Framework. I think it is relatively more easy and fast then anyother else in the iOS. However, I did not able to completely take advantage of that. Let me tell you what I did and what Problem did I faced.
What I have done I cask for permission on ViewController and User is prompt with Dialog asking for contacts permission. If user allow permission, everything goes well, but when user dont allow the permission here comes the trouble.
Accessing User contacts are more necessary since My app's whole working and basic business idea is upon user contacts. Now to handle this, when user Do not allow permission I am showing another dialog telling him that He must allow permission so that App can continue, So far so good.
Now I am taking user to settings where he can allow the permission or he can simply go again back. Now checkout 2 cases
CASE 1: When User come on Settings screen and go back again without
allowing permission
When I take user to Settings screen and instead of allowing permission he gets back to my app I try to show him same dialog again to enable permission in every case. This is going good. I mean for testing purpose I repeat same procedure manytimes, I mean I do not allow my self Contacts permission, It takes me to setting scree, from settings screen I get back to my app and again I am able to see same dialog that took me to settings scree. THIS IS FINE
CASE 2: When User is taken to settings screen and he permits the
permission:
Here when user allows the permission I get message in the log that is "Message from debugger: Terminated due to signal 9". And when I get back to my app, it starts over again. Looks like my app gets re-open or crashed being in background.
Important: For this I examined my memory or task anything that is being performed in background, but there is nothing going on in background. My memory size before crashing is 54.78 mb. And I do not think so it is worth worying.
Any one have idea what is going on??
Your app is not crashing its just forced to restart by iOS with new privacy settings. iOS will SIGKILL the app. (it's default behaviour of iOS). You can checkout - WWDC 2012 Session Videos: Privacy Support in iOS and OS X for more info on this.
This does not hold true for Location permissions.
It is expected behaviour. iOS terminates the app when user changes permission for Contacts, Camera, Microphone and Photos (and possibly some others).
Apple rejected our app with the following response:
We noticed an issue in your app that contributes to a lower quality user experience than Apple users expect:
- Upon launching the app, a web page in mobile Safari opens first, then returns to the app. The user should be able to use the app immediately upon launch.
Next Steps
To resolve this issue, please revise your app to address all instances of this type of issue.
The app we're developing is a keyboard extension. The use-cases do not require a user to actually open the app and use it. As a result, in the app itself (should you launch it from home/springboard), we redirect the user to our website, which informs the user how to use the product (there's no registration or immediate tutorial required, but we certainly cant have the app do absolutely nothing). From Apple's response, this clearly isn't the right way. My questions:
If a user were to be redirected to Messages, could this solve the problem? The reason I ask this instead of just trying it is so that I dont waste time and end up getting rejected again.
Part of the problem seems that opening the app through springboard is misleading since it doesnt do anything. But my understanding is that we cannot have apps without icons (Create iOS app without menu icon). Do keyboard apps need to be published differently so that we dont have an icon in springboard? If so, please direct me to some documentation/Xcode configuration/resources to achieve this.
This is my first attempt at mobile development
The answer provided by #particleman was the right one. Just loading a WebView within the app was enough for Apple to accept the app.
I have designed an app where the app needs to enable the GPS. There is a page for the user which ask use GPS? To this answer there are 2 options YES and NO. Now my concern is when user clicks on YES he should be directed to settings page and that part is done but now after enabling the GPS from this page the user should redirect to the app again but unfortunately there is no way as there is no back button in the setting page.. Please suggest what I can do in this regards?
As far as I know, the only way to open your app (aside from user tap your app or a related notification) is to do some custom url handling. but unfortunately you can't do such a thing. The other thing you can try is to:
Setup a background thread when your app goes to background
check for location service availability
if it changed to your desired value, open a custom url which in turn will open your app (you should register for hat particular url in your info.plist and such)
but There are some things to keep in mind:
Such Behavior will almost surely get your app rejected by Apple.
in iOS 9+ Apple added a new feature that will help you in this particular problem. when an app gets opened from another app (settings.app for you here) it will add a Back to xxxx in place for network indicator to help user get back were he was.
So, IMHO leave the user experience be as it is for all other applications and don't worry about how he would get back to your app.
In IOS, it is possible to launch another app from your app using a URL scheme.
But is it possible to have it then return to the calling app if the home button is then pressed?
What if Guided Access is enabled?
No sorry, The Home button will always lead to the users home, there is no way for developers to override that.
You can however have a button in the "called" app that will take the user back to the app that opened it. Facebook does this when going back and forth between their main app and their messages app.
edit Good answer from #shim about guided access in the comments. Basically if its on, you won't be able to leave the app so it doesn't do any good with this problem. /edit
I know Apple frowns upon closing the app because the user might think it crashed.
So how do I make it quit intentionally with an exception that doesn't get caught when the user goes back to the home screen? Also, would this be rejected by the App Store?
I wrote this answer to another question. It an extract from the Apple Human interface guidelines and should help you understand why you shouldn't quit programatically.
You shouldn't force close an app as the standard way to terminate an application is to press the home button (or use the multitasking bar)
Don’t Quit Programmatically
Never quit an iOS application programmatically because people tend to
interpret this as a crash. However, if external circumstances prevent
your application from functioning as intended, you need to tell your
users about the situation and explain what they can do about it.
Depending on how severe the application malfunction is, you have two
choices.
Display an attractive screen that describes the problem and suggests a
correction. A screen provides feedback that reassures users that
there’s nothing wrong with your application. It puts users in control,
letting them decide whether they want to take corrective action and
continue using your application or press the Home button and open a
different application
If only some of your application's features are not working, display
either a screen or an alert when people activate the feature. Display
the alert only when people try to access the feature that isn’t
functioning.
Source
Apple will most likely reject it as a violation of the human interface guidelines, so it really doesn't matter how to do it.
So how do I make it quit intentionally with an exception that doesn't
get caught when the user goes back to the home screen?
You don't. If your app is "done," just go back to the initial state. Reset all your variables, release your view controllers, whatever. Pretend that the app actually did terminate, and that the user started it up again. You'll be happy, your users will be happy, and Apple will be happy.
An alternative, if your app truly can't continue for some reason, is to display a message that explains the situation to the user and tells them how to resolve the problem. Leave that message visible until the user leaves the app by pressing the Home button. This can be the only reasonable way to deal with situations where some resource such as network access is missing.
Also, would this be rejected by the App Store?
Nobody can say that for certain other than Apple, but I think the probability of rejection is high.
Please see the answer to this question:
Forcing a background application to terminate in iOS simulator
It will tell you how to setup your application to terminate instead of backgrounding when the user hits the home button.
If you don't want to do that, I recommend you should instead release resources when your delegate's applicationDidEnterBackground fires. I think that is your safest bet. More than one of us say what you're wanting to do is not ideal.