This was always impossible in iOS6 and below however with the new multitasking API's etc in iOS7 I was wondering if it has become possible. I am developing an app that is for personal security... The user needs to be able to trigger an "an" inside of the app when in background mode... The shake function would be the best approach however so far it seems impossible..
Any help would be greatly appreciated. T
The background tasking feature is not what you think. Apple heavily regulates it's use. You're probably thinking of the new iOS 7 background feature called "Background fetch". You can count on being activated for partial background execution as a batch job every few hours.
The new background fetch feature is to be used when: "The app regularly downloads and processes small amounts of content from the network."
This will let you update the state of your app in the background so that the new iOS 7 multitasking feature lets you see an updated state of the app in that view. There is no iOS 7 background state that does what you want.
Related
I would like to build a helper app for gamers, and to build some extra functionality I would like to observe/time certain third party games behaviors, more specifically when the game actually launches the full screen process.
For example: my app is a system tray app, the game has a "launcher" app with lobby and menu screens. Once the game launches the extra process, usually OS X will switch resolutions (optionally) and my App would be notified somehow. Then I can start a timer. Once game match finishes, either the process is closed, or the game is not full screen anymore, my app gets a second notification and I can stop the timer.
Are there official Apple APIs that provide any way to observe/poll for the app going full screen and/or launch additional windows that I can reliably assume it's the actual game screen?
I doubt you're going to find a completely comprehensive solution. There are many ways for apps to achieve a full-screen experience and most don't provide a notification about that fact.
A full-screen app can modify the presentationOptions of NSApplication to hide the Dock and menu bar. Another app can use key-value observing to monitor its application object's currentSystemPresentationOptions property, which will reflect the current system status.
A full-screen app can capture the displays (although Apple discourages this technique). You can try to detect this by calling CGDisplayIsCaptured(), although it's been deprecated since 10.9 with no replacement. It may be possible that, if you register a callback with CGDisplayRegisterReconfigurationCallback(), you'll get called when something captures the display. However, capturing the display is sort of about preventing other processes from noticing such changes, so maybe not. In that case, you'd have to poll. You might also poll for the current display mode; changing the mode is the primary reason why a game would capture the display in the first place.
A full-screen game could also just create a borderless window the size of the screen and set its window level to be in front of the Dock and menu bar (and other apps' windows). There's not really a notification about this. You could detect it using the CGWindowList API, but you would have to poll. For example, you could call CGWindowListCopyWindowInfo(kCGWindowListOptionOnScreenOnly, kCGNullWindowID) and iterate through the dictionaries looking for one the size of the screen and at a window level above kCGStatusWindowLevel.
(You might be able to use the Accessibility API to get a notification when the frontmost window changes, so you'd only have to poll when that happens.)
You cannot observe a notification if there is none. So firstly you need to know if the app you want to observe is actually sending a notification that is observable. You cannot 'hook' into other apps without their planned consent.
I'm developing an app which uses ibeacon to determine if the user entered a specific region.
Now I'm using the CoreLocation framework to implement this geofencing-based feature.
I've read the document below.
https://developer.apple.com/library/mac/documentation/CoreLocation/Reference/CLLocationManager_Class/CLLocationManager/CLLocationManager.html
in which the Apple is saying that:
"In iOS, the regions you register with the location manager persist between launches of your application. If a region crossing occurs while your iOS app is not running, the system automatically wakes it up (or relaunches it) in the background so that it can process the event. When relaunched, all of the regions you configured previously are made available in the monitoredRegions property of any location manager objects you create. "
I discovered that it's true just before the ios 7.
From ios 7, An app will be waken-up from background but it will actually no longer could be re-launched from terminated-state (slided out from the task manager which displayed by double-clicking the home button).
If it's due to the Apple's policies, why does Apple not update the above official document?
So I'm thinking of an ios7's bug because the Reminder App (a built-in app) is also not relaunched in ios7 even though it's relaunched in ios6.
Is this issue due to Apple's policies? or an ios7's bugs?
It takes me more than 2 days to google for a solution.
Any ideas for this issue?
The documentation is simply out of date. This is intended behavior in iOS7. Apple produced a video explicitly discussing this change. The idea is that if the user explicitly terminates the app, the user does not want it running. See this thread.
Is this such a big deal? How often will users really do this? Remember, if users are annoyed by you app, they can always uninstall it, too. This was true in iOS6.
iOS 7.1 reversed this policy. That is even if the user kills your app the iOS still launches your app upon crossing the region.
I am bit confused about these two states. Following is my understanding;
when app is in background and if you have "Application does not run
in background" set to NO in App plist file then App continues running
in background. In suspend mode App stays in memory but does not
execute code! System doesn't notify App when it moves to Suspended
state and wipes out App from memory in low memory situation to create space for foreground Apps.
Is my understanding correct? If it is so then why don't I get my NSLog printed on console when App running in background and executing code? What actually happens to my TCP socket connection where I am continuously gets the data from server? Why do we need Suspended state as anyway System eventually wipes out App from memory in low memory situation. Is there any difference between App becoming active from suspended state or starting fresh?
You should look in the IOS App Programming Guide section "App States and Multitasking".
Find that by searching the Xcode documentation with the phrase "App States and Multitasking" and "Hits Must" item set to "Match Search Term". Another useful search phrase: "background execution".
The summary answer is that an application can continue "executing" in the background indefinitely for only a limited number of reasons:
in iOS, only specific app types are allowed to run in the background:
Apps that play audible content to the user while in the background,
such as a music player app
Apps that keep users informed of their
location at all times, such as a navigation app
Apps that support Voice over Internet Protocol (VoIP)
Newsstand apps that need to download and process new content
Apps that receive regular updates from external accessories
Aside from those specific operations, an app can ask to continue to execute for a very short time which the documentation covers in the section "Executing a Finite-Length Task in the Background". After a short time either your app tells the system it is done (and is then suspended) or it is forcibly terminated. Details in the doc.
Another useful bit of that document, with nice state diagrams, is the section "Managing App State Changes". That section talks about going into the background and returning to the foreground. It should answer your question about the difference between starting fresh versus starting from the suspended state. The short (not quite correct) answer is that if you start from the suspended state and you don't take any special actions when entering the background or (re)entering the foreground then you just continue more-or-less from where you were. Also, starting from the suspended state is faster. Read the doc since it says it much better than my paraphrase would.
App State
Not running: Your app is in this state before it starts up.
Active: Once your app is started, receiving events.
Inactive: When your app is running but something happens to interrupt it, like a phone call, it becomes inactive. Inactive means that the app is still running in the foreground but it’s not receiving events.
Backgrounded: In this state, your app is not in the foreground anymore but it is still able to run code.
Suspended: Your app enters this state when it’s no longer able to run code.
Background:
Executing code - Code is executed while the app is in a background state.
An app must go into a background state before it can go into a suspended state.
ie. Suppose you're on Facebook and you upload a video and you quickly switch to another app immediately after pressing the POST button. Although you switched to another app w/o terminating the app, the app can be configured to perform background processes to complete the upload.
An app that is in background does not necessarily mean it is suspended but an app that is suspended is in background.
An app can request to stay in background mode for extra time (for purposes of playing audio in the background or completing a network request, for example); afterward it will either go to suspended state or it will be forcibly terminated by the system.
Suspended:
Not executing code - Code is not executed while the app is in a suspended state.
An app that is in a suspended state is also in a background state.
The system moves apps to this state w/o notifying you beforehand.
An app in a suspended state is still in memory.
Some additional information that may help you on this topic:
UIApplication notifies the app of state transitions through methods in the AppDelegate.
Most state transitions are accompanies by these methods.
These methods are part of the UIApplicationDelegate protocol.
They provide you with a chance to respond to state changes.
The method below, for example, tells the delegate when the app is about to terminate. - It's only called if the app's in background before being terminated; not suspended.
func applicationWillTerminate(_ application: UIApplication) { ... }
In addition to Charlie Price's answer from 2013, iOS now also allows background for:
REMOTE NOTIFICATIONS that signal there is new content available for download. When a remote notification arrives, the system launches or resumes the app in the background and gives it a small amount of time to download the new content.
CORE BLUETOOTH to communicate with a bluetooth accessory while in background.
Click here for more details
UIApplication.shared.backgroundTimeRemaining tells you how many seconds is remaining until the system terminates the application. 3 minutes is the maximum time limit, but this time restarts each time the app is woken up in background mode.
You can prevent your app from ever entering a background or suspended state & instead immediately terminating by setting the UIApplicationExitsOnSuspend key to YES in the info.plist.
Additional links you may find useful:
https://developer.apple.com/library/archive/documentation/iPhone/Conceptual/iPhoneOSProgrammingGuide/BackgroundExecution/BackgroundExecution.html
https://developer.apple.com/documentation/uikit/core_app/managing_your_app_s_life_cycle/preparing_your_app_to_run_in_the_background/about_the_background_execution_sequence
https://medium.com/#abhimuralidharan/finite-length-tasks-in-background-ios-swift-60f2db4fa01b
https://qph.fs.quoracdn.net/main-qimg-473264d5d9f0ec16d57b8dffcc9824d8
i am migrating my iOS app onto mac. the loading time is a bit long (around 5 seconds) thus i need a splash loading screen (Just like Default.png image for iOS) but the project made from cocos2d template just shows a white screen. not sure about other apps. so is there anyway to set it?
I know that the screen size is not fixed on a mac app. but i have set a default size. and use auto scale in case of full screen mode.
EDIT:
I have tried a light weight loading scene as well but failed since the MainScene itself is light weight as well. I think the major loading time is due to the cocos2d environment set up.
In OS X a window appears when the application launches, it's not designed to use splash screens.You might want to reconsider that choice.
But if the window is still to slow to load or to display its contents, you can still do that but manually, it isn't easy like in iOS.You need to display another view inside the window until it loads.
EDIT
A little more of context: for example you can set in your xib file an image view containing the image do display.
Then you make start another thread that loads all the content that you need.After this, run a selector on the main thread that updates the window.
Based on my tests in Cocos2d 1.0.1 & 2.0 the basic Cocos2d OS X app launches really quickly.
This makes it seem pretty likely that it's something about your first scene that is taking a long time to load, or something else. Instruments can help you gather information about what your app is doing.
I suggest you make an initial lightweight cocos2d scene that will load quickly at startup and then load your second scene and transition to it. Ideally the loading of the assets for your second scene would be asynchronous (at least the ones that are slow). There are numerous blog posts on how to do this. (search for "cocos2d asynchronous loading" and you'll find many, such as this one: How to preload your game assets in a loading scene, though something more recent might be preferable).
I have a simple app that uses location services, and registers to run in the background. I update a simple tableView with location data. This data is still being received when the user leaves the app and does something else.
Currently I am calling a method in my - (void)applicationWillEnterForeground:(UIApplication *)application to update the UI, but there is still a split second when the app opens, and the UI gets updated.
I have also tried to do periodic UI updates when in the background, but not surprisingly this doesn't seem to work.
Are there any solutions out there so that I can have the UI fully updated when the user brings the app back into the foreground?
The best solution would probably be to profile and see why you have any delay at all before displaying new data. It's quite possible you could do some things to get ready for the display to arrive, like doing Core Data queries ahead of time (they can take a significant amount of time).
An alternative would be to dump a blank UI bitmap from the screen as you were being suspended, and write to it directly based on activity - then when the application resumes, briefly show that bitmap as a screen overlay before showing the real complete UI.