Titanium JIRA Archive
Titanium SDK/CLI (TIMOB)

[TIMOB-5437] iOS: Expose applicationState property of UIApplication Class

GitHub Issuen/a
TypeNew Feature
PriorityHigh
StatusClosed
ResolutionDuplicate
Resolution Date2013-02-14T00:57:16.000+0000
Affected Version/sRelease 1.7.2
Fix Version/s2013 Sprint 04 API, 2013 Sprint 04
ComponentsiOS
LabelsSupportTeam
ReporterEduardo Gomez
AssigneeSabil Rahim
Created2011-10-05T06:39:36.000+0000
Updated2017-03-22T22:08:05.000+0000

Description

Feature

Expose the applicationState property through Titanium API so we can know the application was frontmost when it received a notification. http://developer.apple.com/library/ios/#documentation/UIKit/Reference/UIApplication_Class/Reference/Reference.html#//apple_ref/occ/instm/UIApplication/applicationState

Customer notes

The applicationState property is not exposed in titanium, thus, there is no way take proper action in response to a remote notification. Specifically, if the app is in the background and receives a push notification, the notification popup displays, and when the app is launched from the popup, the messageCallback is invoked. There is no way to determine from within this callback whether the system had already displayed the popup to the user.

Associated HD ticket

APP-185982

Comments

  1. Thomas Fischer 2011-10-05

    In regards to the original need for exposing this state for remote notifications: It seems that it may not possible to correctly inspect this state as specified in apple's documentation: "application:didReceiveRemoteNotification:" in the 'callback' method of the push notification handler. Specifically, if we inspect the application state property within the push message callback, it may always return UIApplicationStateActive. Perhaps this is because the javascript push message handler gets invoked asynchronously after the didReceiveRemoteNotification has returned? For this particular problem, it doesn't make sense to expose the applicationState if this problem is not fixed. I am going to perform additional tests to see if I can verify that this is in fact the behavior.
  2. Thomas Fischer 2011-10-06

    Nevermind my previous comment. The applicationState is in fact correct when receiving the push message callback within javascript. That is, when the app is in the background, and the javascript callback is invoked, the applicationState is inactive. When it is in the foreground, the applicationState is active. Exposing the applicationState should enable an application developer to determine if the app was in the background or foreground when the push message was originally received.
  3. Sabil Rahim 2013-02-13

  4. Sabil Rahim 2013-02-14

    Duplicate of TIMOB-3528
  5. Ben Sudbury 2013-05-22

    This Ticket should be reopened. It is currently not possible to detect the difference between a home button press and a sleep button press through events on ios. For IOS lower than 5.0 this was possible because ONLY the pause event fired for a sleep button press whereas BOTH the pause and paused events fired for a home button press. Since 5.0 the same events fire for both of these situations and the only way to tell the difference between the two is to inspect the applicationState property. See http://docs.appcelerator.com/titanium/latest/#!/api/Titanium.App An example of an app that needs this is one that plays audio in the background. When the screen is locked, the audio should continue to play, but when the user deliberately navigates away from the app, the audio should be stopped or paused. Please let me know that you acknowledge this comment or I will have to assume it is lost (due to being on a closed issue) and I will create a new issue with the same details. Regards, Ben
  6. Lee Morris 2017-03-22

    Closing ticket as duplicate and links to the related ticket have been provided above.

JSON Source