This is a simple question and I can not seem to find any information on it, but I just want to know if the following code will get my app rejected or not. Basically, is this a private API
[application setIdleTimerDisabled:YES];
I want to add this to my AppDelegate under didFinishLaunchingWithOptions. I just do not want to use something so simple and get my app rejected. Thanks for any information!
It's public, though apple advises:
Important You should set this property only if necessary and should be
sure to reset it to NO when the need no longer exists. Most
applications should let the system turn off the screen when the idle
timer elapses. This includes audio applications. With appropriate use
of Audio Session Services, playback and recording proceed
uninterrupted when the screen turns off. The only applications that
should disable the idle timer are mapping applications, games, or
similar programs with sporadic user interaction.
So you should be okay if your app is as they describe, or if you use it sparingly.
Related
I have an application where I need to create local notifications via polling without doing push - primarily due to client infrastructure limitations and their security model.
I've read: http://www.objc.io/issue-5/multitasking.html, I've seen David Chan's WWDC presentation - where single push messages kick off download tasks - but what I truly need is background fetch - on a regular basis - like every ten minutes - in iOS 7.
I've seen the VOIP hacks. No. What non-hack way is there to do this without user interaction or push messages? Any examples you can point me to?
Here's what I know:
Background data tasks will work in the debugger but if you can get a console on an IPA, you'll quickly find out they really are prohibited (thereby invalidated many examples).
Background URL tasks require custom delegates - but fetch completion handlers are iffy. This too I found with an IPA and console.
I would love to avoid using the AFNetworking lib - for something quite simple.
Background fetch is not a reliable solution - you are at the mercy of the OS, and it is not very merciful. Abusing iOS background modes is not a reliable solution - Apple is known to reject applications that enable background modes, such as location, VOIP and music playback, without a legitimate reason. Background URL tasks are not something you can rely upon to wake your app; they will wake it, but the app will not be awake enough in the background to enqueue a background URL task.
Your best and most intended method is still background fetch, but be prepared to be disappointed. Your app will not be woken app in the interval you need. Also, the user can kill the app in the app switcher screen, causing your app to never wake up until opened.
No real reliable method other than push. You need to insist with your client for the sake of user experience.
Unfortunately there is no "reliable" way to do that on iOS. With the background fetch API you are not guaranteed to have process run when you would like it run. As you've said, you've already looked at the API so i'm probably telling you something that you already know. A local notification wouldn't solve your issue either as this isn't a way that you can wake your application up and kick off network events. This is behavior that Apple doesn't want as this would negate the whole purpose of their background task coalescing.
You really need to have a push mechanism in place for something like this, so if this is something that is needed, then you may have to stress that to the client.
I am working on a Win8-UI-App (previously called Metro...) and trying to implement Periodic (Documentation for different methods) Tile Updates (Live Tiles) for the first time.
I found a couple of very good resources on the internet and was able to do it. Unfortunately the question of where I should register for the notifications remained unsolved:
Do I have to register for Notifications every time the app starts (e.g. in the App.xaml.cs OnLaunched() Method)? - Or is there an other, more professional way to do so? (I could imagine to save if I already registered for the service or is there a variable I can access to see whether notifications are registered?)
thank you!
PS: For everyone who is also new to this see this StackOverflow post, this example, the tile template types and the Dev Center for quick starting :)
Periodic updates will continue until they are explicitly stopped or your app is uninstalled. Technically, you only have to do that once. But, the Guidelines and checklist for periodic updates states
Call the StartPeriodicUpdate or StartPeriodicUpdateBatch method each
time your app is launched or brought into focus. This ensures that the
tile content will be updated each time the user launches or switches
to the app.
According to that, App launch and App resume are good candidates for a call to StartPeriodicUpdate.
So I've read that in iOS, all timers will pause when your app is running in the background. I've also read that you can run tasks in the bg using beginBackgroundTaskWithExpirationHandler (like so).
What I am trying to achieve is to call a method once every 3 minutes, and another method a fixed-amount of time before the first one. I have managed to do this within one NSTimer which repeats in a way that lets me do this. It works fine but is obviously disabled (or paused) when the app is in the background - I can only assume because of the reason described above.
Does anyone know if there's a way to run a timer or at least call something after a specific amount of time so I can do this?
Basically if you want to continue running active in the background you have to meet one of the following requirements. From the Apple docs:
Implementing Long-Running Background Tasks
For tasks that require more execution time to implement, you must
request specific permissions to run them in the background without
their being suspended. 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
Apps that implement these services must declare the services they
support and use system frameworks to implement the relevant aspects of
those services. Declaring the services lets the system know which
services you use, but in some cases it is the system frameworks that
actually prevent your application from being suspended.
http://developer.apple.com/library/ios/documentation/iPhone/Conceptual/iPhoneOSProgrammingGuide/ManagingYourApplicationsFlow/ManagingYourApplicationsFlow.html#//apple_ref/doc/uid/TP40007072-CH4-SW24
I'm a new ObjC dev and after searching the Web and Apple's developer docs, I can't find a good succinct explanation of the various iOS device modes, and what goes on in these modes. I see a lot of little discussions, but nothing overarching about the big picture.
For example, I see that some Alarm applications for iPhone/iPad claim to be able to execute alarms (presumably not just system alerts) in the morning. I'm struggling to understand how that happens, even if the user lets the app just keep running overnight, assuming the device goes into sleep mode after no use.
So I don't know what happens when the device goes into sleep or standby mode. Is it just the screen dimming? Does the application in the foreground continue to execute code, go into some interim state like background mode in a saved state, or does it completely (even if temporarily) shut down?
I'd just like to be pointed to a website, a book or the portion of the Apple documentation that explains the various device states, what's going on under iOS 3 & 4 with the application in each state, and how to manage that if you'd like to build an app similar to a simulated bedside alarm clock that's "always on," etc.
Thanks in advance.
Those 'alarms' are Local Notifications, and are very handy. They're fired even when an application is closed, and even when the device is asleep.
The concept of asleep is not too tricky; when the user 'quits' your application (pressing the home button), your application will either be halted and placed into a frozen state (4.x), or quit entirely (3.x). Nonetheless, you are given the opportunity to do a few cleanup operations before the latter happens with the - (void)applicationWillTerminate:(UIApplication *)application method, and before the former happens with the - (void)applicationDidEnterBackground:(UIApplication *)application method (both are called upon your delegate class).
The concept of 'sleep' means that in both iPhone OS 3 and iOS 4 you'll receive the following method when your app loses focus (and also when an SMS comes in, or an alert, etc):
- (void)applicationWillResignActive:(UIApplication *)application
Really, most applications (with the exceptions of applications that are designed to work in the background, like voip, audio streaming, etc) simply quit on close. But if you need to, you can also suspend the freezing of your app and ask for more time to complete a task.
This was a lot easier to grasp in the 3.x days, but now with 4.x's 'multitasking' it becomes a bit harder. It's not too daunting though, and a read of this will help a bit.
This may be of help:
http://developer.apple.com/library/ios/#documentation/UIKit/Reference/UIApplication_Class/Reference/Reference.html
see the applicationState for UIApplicationState.
I am currently developing a chat application and am trying to include:
Various states, like MSN does, available, busy and away.
If the user doesn't touch the keyboard for one minute, the state of the user isto be changed into Away.
Or something similar to these.
I also need the program to be able to play a sound while running.
Can the community aid me with resources to help me implement this and perhaps any code if anyone has experience with a similar application?
To manage an inactive state, what you can do is use a timer paired with a global keyboard hook (the article is for C#, but you can easily translate it to VB.NET). Each time your application receives a keyboard message, the timer will be reset to the inactivity interval. If the timer runs out, you can set the status of your application to be inactive.