Expose all of the iOS UIApplicationDelegate methods as events in the application module #432

Activity

1. PanayotCankov

   added

   backlog

   feature

   os: ios

   severity: low

   on Jul 14, 2015
2. fealebenpae commented on Jul 14, 2015

   

   fealebenpae

   on Jul 14, 2015

   Contributor

   More actions

   Almost half of the methods on UIApplicationDelegate aren't really events - we're talking stuff like state restoration, user activity continuation, background fetch, etc. Most of them are expected to return a meaningful value, or accept a callback block to execute when their respective task is complete. I don't believe that can map to events.
3. atanasovg

   added

   severity: high

   and removed

   severity: low

   on Jul 24, 2015
4. atanasovg commented on Jul 24, 2015

   

   atanasovg

   on Jul 24, 2015

   Contributor

   More actions

   We just discussed with Panata that we are hitting more and more scenarios where we need various APIs available on the AppDelegate, which are currently not exposed at modules level. Hence, raising the priority of this issue.
5. PanayotCankov commented on Jul 24, 2015

   

   PanayotCankov

   on Jul 24, 2015

   ContributorAuthor

   More actions

   The methods returning BOOL seem to indicate whether the app reacted/can react to the notification, which can be mapped to an event being handled, and eventually a sort of "stopImmediatePropagation" should be implemented properly.

   In the case of the chain-of-command returning YES would mean the current delegate in the chain handled it / can handle it (and probably the rest should be ignored?). Returning YES if one of the delegates returned YES, and NO otherwise.

   For these that accept notification block, the clients should be able to capture the block and call it later. In the case with the events all UIApplicationDelegate method arguments should be provided as properties on the event.

   That's my thoughts about it. I am not sure these suggestions cover all cases.

   New use-cases opened in iOS 9 will move the focus on:

   • application:continueUserActivity:restorationHandler:
   • application:openURL:sourceApplication:annotation:

   We can cover them case by case, but at the end, the clients should be able to react to everything in the UIApplicationDelegate.
6. valentinstoychev

   added this to the 1.3.0 milestone on Jul 28, 2015
7. enchev

   self-assigned this

   on Jul 29, 2015
8. enchev commented on Jul 31, 2015

   

   enchev

   on Jul 31, 2015

   Contributor

   More actions

   I've researched this task and it seems that no matter what you return if you simply override some of the methods the framework will expect something from you. For example:

       applicationShouldSaveApplicationState(application: UIApplication, coder: NSCoder): boolean {
           return false/true/undefined/null;
       }

   In this case you will get:
   Warning: Unable to create restoration in progress marker file

   Furthermore there are callbacks such applicationDidReceiveRemoteNotificationFetchCompletionHandler that will expect special permission to be added that cannot be done automatically.

   Maybe we should teach people how to declare such callbacks for the whole application only when needed and call some module/plug-in desired method(s) in this app callback - no UIApplicationDelegate callbacks handling inside components/modules. This is actually how Facebook SDK works.

   Let me know your opinion.
9. enchev commented on Aug 4, 2015

   

   enchev

   on Aug 4, 2015

   Contributor

   More actions

   Hi,

   I believe that we've found solution for this issue. Please check #547 for more info.

   We do not have default UIApplicationDelegate anymore and developers can specify their own UIApplicationDelegate implementation using our brand new delegate property of iOSApplication class. For example:

   import application = require("application");
   class MyDelegate extends UIResponder implements UIApplicationDelegate {
       public static ObjCProtocols = [UIApplicationDelegate];
   
       applicationDidFinishLaunchingWithOptions(application: UIApplication, launchOptions: NSDictionary): boolean {
           console.log("applicationWillFinishLaunchingWithOptions: " + launchOptions)
   
           return true;
       }
   
       applicationDidBecomeActive(application: UIApplication): void {
           console.log("applicationDidBecomeActive: " + application)
       }
   }
   application.ios.delegate = MyDelegate;
   application.start();

   Instead our built-in delegate in the previews version we use now NSNotificationCenter to handle events like UIApplicationDidFinishLaunchingNotification, UIApplicationDidFinishLaunchingNotification, etc. Furthermore developer can attach their own observers using our new API addNotificationObserver. For example:

   import application = require("application");
   application.ios.addNotificationObserver(UIApplicationDidFinishLaunchingNotification, (notification: NSNotification) => {
       console.log("UIApplicationDidFinishLaunchingNotification: " + notification)
   });
   application.start();

   Let me know what you think!

   Thanks
10. enchev

    added

    done

    on Aug 4, 2015
11. enchev

    closed this as completedon Aug 4, 2015
12. lock commented on Aug 31, 2019

    

    lockbot

    on Aug 31, 2019

    More actions

    This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.
13. lock

    locked and limited conversation to collaborators on Aug 31, 2019