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.
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.
In my app, I have performed the following listed below and have added counter to the app fetch routine to highlight the number of times fetch is called by iOS 8.1.
Turned on Background Modes and enabled background fetch.
Wrote code for “performFetchWithCompletionHandler”. NSLog message indicate the start and end of the fetch process. Counters are between these messages.
Added code in “didFinishLaunchingWithOptions”. However, instead of using “setMinimumBackgroundFetchInterval” I am using double of 60 assuming seconds.
When I test the code in Debug by setting “Simulate Background Fetch” all works perfectly as expected with absolutely no problems. Counters work and show expected values.
However, when I go live on the iPhone, launch the app, then hit the home button to put in background, wait one or two hours or overnight. Nothing happens, no fetch, no downloads and all counters remain at zero.
If I cannot get this to work, I will need to create my own background thread and manage it directly, which I would prefer not to do.
Any input or ideas are deeply appreciated.
As of iOS 8, I started having this same problem with both of my apps. In iOS 7, background refresh triggered pretty reliably. In iOS 8, it just stopped. If I launch either app from xcode into the background fetch mode, everything works like it should. Background refreshes themselves just stopped triggering on their own in iOS. I have a hopeful theory that I'm trying out right now. Here's my thinking...
iOS will exclude your app from background refresh if the user force kills it from the multi-tasking screen. How might Apple have implemented this behavior? One way would be to just set your minimum fetch interval to UIApplicationBackgroundFetchIntervalNever. Easy peasy. Let's assume that's how they do it. Does your app set the minimum fetch interval every time it launches, or does it only set it on the initial launch?
In my case, I was only setting the minimum fetch interval as part of the initial setup of my app. If the user force killed the app, and iOS is in fact setting the minimum fetch interval to UIApplicationBackgroundFetchIntervalNever, then my apps are stuck in the state of never. I made a minor change in one of my apps, so that it sets the minimum fetch interval on every launch. So far so good.
Update:
All is well in my background fetch land.
Both my app that's currently in development and my app that's in the app store are once again triggering background fetches reliably.
The code for doing this can be pretty simple...
[[UIApplication sharedApplication] setMinimumBackgroundFetchInterval:minimumBackgroundFetchInterval];
Calling that every time your application launches will do the trick, however, you'll want to consider whether setting that value is appropriate to the current state of your app. In my case, one of my apps is a concert listings app. There's no point in setting a minimum background fetch interval if the user hasn't selected a location for concerts yet. I have an NSUserDefault to track whether a location has been set. Here's an approximation of my code for setting the fetch interval ...
- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions
{
if ([INCUserDefaults isLocationConfigured]) {
[[UIApplication sharedApplication] setMinimumBackgroundFetchInterval:kSecondsIntervalForUpcomingShowsBackgroundFetch];
}
return YES;
}
Prior to the bug fix that I issued, I was only setting the minimum background fetch interval as part of the setup process. Now I set it during the setup process, and on application startup if the setup process was previously completed.
Apple uses a secret algorithm to determine the frequency of fetch events. This algorithm is presumably based upon app usage patterns (ie: how frequently and when the user users the app). It can take several days before fetch events begin to arrive consistently.
If fetch event works in simulator, that proves that everything is correctly set up. There's nothing you can do but wait.
iOS does the background fetch in certain way. It wakes up apps it believes the user uses often. Try opening the app after you wake the phone for a few times.
As kkarayannis wrote, iOS will learn how often to call your app. I've seen the same behaviour as I wrote my first background fetch. I believe, that you should not only open your app manually, but also trigger a manual refresh then. IOS will learn that the user wants to load data regularly and will start to do it on it's own.
Have you also tried to use "setMinimumBackgroundFetchInterval" instead of 120sec? Maybe it's a too short intervall. However you could also past your code for better understanding.
I'm building a Windows Store app and it pops up toast notifications from time to time. I also have an animation that plays to show when something has updated. Both of these happen at the same time.
What I would like is to not show the toast when the app is running.
So, is there a nice easy way to determine this or do I have to manually track the state via the suspending/resuming events?
Edited info:
The solution has a background task project which goes off, gets the data, then decides if anything has changed that the user needs to know about.
If so, it creates a toast, updates the tile badge, and plays an animation to fade in the new data.
The issue is that I don't want to show the toast and update the tile badge if the user has the app full screen. Similarly, playing the animation isn't needed until the app is resumed (that's the easy part though).
I realize I could solve it by having one timer that works when the app is running, and a separate background task for when it's suspended but that seems like overkill in this case.
The simple answer here is that if your app is suspended, your code won't be running.
If you want to pop up toasts when your app is suspended, you'll either need to use the WPNS or a background task to track changes.
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 am making an app where I need to know
every button that was ever pushed by the user in the app, and when it was pushed, and
where the iPhone has gone (using gps), but there are no cell towers in the area so I can't use that significant location changes method everyone uses.
It seems to me like the Plist method for data saving won't work because I don't want the app to start where it left off, I want it to start at the beginning every time.
Also, if any of you have any idea how I can make my app wake up at certain specific times, and/or how I can make it impossible to exit, that would be awesome. This is for an experiment with the University of Queensland St. Lucio Psych Department and the Grute Eylandt Aborigines.
You can know everything the user does in your app if you want. You could use your own solution with an SQLite database for example, and dispatch the data to a server every once in a while.
The GPS is also easy, you could just track the user with the Core Location framework.
You can't make the app wake at specific times, the best you can do is implement push notifications but it's up to the user to open the app via the notification or by themselves by tapping the app icon on the iPhone home screen.
Otherwise you could set up a local notification just before exiting the application, this is faster and easier to implement then setting up push notifications.
There is also no way to stop the app being closed, that is until iOS 6 comes along with it's accessibility features, you can disable the home button then. But not now.