Should the appdelegate be placed in the template

[qiuguohua]

previous issue

The main reason for putting appdelegate into the template layer before is to integrate a third-party SDK

At present, after putting main into the template layer, users can customize the platform and appdelegate. Although it is more troublesome, I think it is reasonable, which can clearly isolate the logic defined by the developer and the logic of the engine

Take the mac platform as an example, customize the platform and appdelegate
1、MyAppdelegate.h

@interface MyAppDelegate : AppDelegate

@end

@implementation MyAppDelegate

- (void)applicationDidFinishLaunching:(NSNotification*)aNotification {
    CC_LOG_INFO("MyAppDelegate applicationDidFinishLaunching");
    [super applicationDidFinishLaunching:aNotification];
}

- (void)windowWillMiniaturizeNotification {
    CC_LOG_INFO("MyAppDelegate windowWillMiniaturizeNotification");
    [super windowWillMiniaturizeNotification];
}

- (void)windowDidDeminiaturizeNotification {
    CC_LOG_INFO("MyAppDelegate windowDidDeminiaturizeNotification");
    [super windowDidDeminiaturizeNotification];
}

- (void)windowWillCloseNotification {
    CC_LOG_INFO("MyAppDelegate windowWillCloseNotification");
    [super windowWillCloseNotification];
}

@end

2、自定义平台，文件CustomPlatfor.h

class CustomMacPlatform : public cc::MacPlatform {
public:
    CustomMacPlatform(){};
    int32_t init() override {
        CC_LOG_INFO("CustomPlatform init");
        return cc::MacPlatform::init();
    }
    
    int32_t run(int argc, const char** argv) override {
        CC_LOG_INFO("CustomPlatform run");
        id delegate = [[MyAppDelegate alloc] init];
        NSApplication.sharedApplication.delegate = delegate;
        return NSApplicationMain(argc, argv);
    }
};

3、main.mm：

#include "CustomPlatform.h"

int main(int argc, const char * argv[]) {
    CustomMacPlatform platfrom;
    platfrom.init();
    return platfrom.run(argc, argv);
}

[qiuguohua]

I'd prefer to use MyAppDelegate, so that the developer could use other methods of UIApplicationDelegate.

Developers can directly override other member methods of UIApplicationDelegate, which is similar to direct inheritance. The inheritance relationship is
myappdelegate > appdelegate (or baseappdelegate) > UIApplicationDelegate
The difference is that the logic of the engine is added in the middle, the purpose is to decouple the logic of the developer and the engine

We can also combine the appdelegate in the engine and put it into myappdelegate, and myappdelegate can directly inherit UIApplicationDelegate.

class CustomAppDelegate : public UIApplicationDelegate {
public:

private:
   AppDelegate  _engineAppDeleagte;
}

But it seems like duplicated for "BaseAppDelegate/AppDelegate" and "BasePlatform", not quite sure if we need them both.

Appdelegate and platform are different concepts, and the message mechanism similar to windows is different from that of platform. appdelegate is a system-related operation, and platform is the operation logic inside the engine. In theory, there is no need to expose appdelegate too much

Also, Windows got a BaseApplication to be implemented, but hard to use too. Still need to hack engine code if we'd like to use it

In theory, we only care about the application, and don't need to pay attention to other things. The reason why the method provided here is only the way that the platform does not meet the requirements or has special needs. Here is just one way. It requires a threshold to do this. In fact, it is not recommended to do this. The upgrade and maintenance costs are relatively high.

[timlyeee]

...and the message mechanism similar to windows is different from that of platform. appdelegate is a system-related operation, and platform is the operation logic inside the engine. In theory, there is no need to expose appdelegate too much.

Man who would like to write c++ code always has his own needs, as register his own Window controller, he might think to control the view port by modifying AppDelegate? because we expose it, so people will use it, then troubles come.

[timlyeee]

In theory, we only care about the application

Application is hesitated as Game =>BaseGame =>Application right?

Yet it's in common dir, cannot modify it directory....

[qiuguohua]

Application is hesitated as Game =>BaseGame =>Application right?

Yes, in fact, you don't need basegame, you can directly inherit CocosApplication

Yet it's in common dir, cannot modify it directory....

i didn't understand

[timlyeee]

For example:

void Game::onPause() {
    BaseGame::onPause();
}

class MacPlatform{
 void onPause()
} 

I've got them both, which one should I use?

I can directly modify the Game.cpp, and no one told me if it will trigger some error.

[timlyeee]

Also, because it's in common dir, when I tried to write codes for Windows, it might not work on Android. Developers need to add macros by their own, yet at beginning they might not have to.

[qiuguohua]

The meanings of these two are different. If you are in an application, you only need to pay attention to the life cycle of the application. If you are in a platform, you only need to pay attention to the life cycle of the platform.

You can use onPlatformPause and onGamePause to understand.

These two concepts need to be separated, a platform can load multiple applications, each application has an independent life cycle

For example, windows can load multiple apps, and each app has a lifecycle.

[timlyeee]

Cool, that does make me understand.

For example, windows can load multiple apps, and each app has a lifecycle.

So is that easy to load multiple apps with codes right now? Maybe it's a feature?

[dumganhar]

Is there a better way to let developer know fewer detail of engine to write some platform relevant logic ?
Currently, on Mac platform, developer needs to know some concepts, e.g. MacPlatform, AppDelegate, main.mm .

[qiuguohua]

Is there a better way to let developer know fewer detail of engine to write some platform relevant logic ?

This is relatively simple. In any case, inheriting appdelegate is required, and registering appdelgate is also required.

The registration appdelegate entry can be provided in the platform, but it is difficult to achieve unity, because other platforms do not have appdelegate

[timlyeee]

Now I understand the concept of Platform and Application better, documentation is needed still.

My suggestion is that we place the AppDelegate in the template, as well as iOS, AppDelegateBridge is a good point and we can use it for all platforms of APPLE since there might be some needs for TVOS or Apple Watch, etc, who knows.

[qiuguohua]

I personally think that some thresholds should be set, because it is not recommended because of coupling, unity and future compatibility.

I am not sure about the strength of this requirement. If it is only a small number of users, I think it is not worth it to destroy the compatibility and coupling of the framework because of a small number of users.

[minggo]

These two concepts need to be separated, a platform can load multiple applications, each application has an independent life cycle.
For example, windows can load multiple apps, and each app has a lifecycle.

Can you describe when need to load multiple apps?

[qiuguohua]

I guess there are two cases

The first is similar to a window, and sometimes it may be necessary to run another independent rendering sub-window on top of a window.

The second possibility is to manage applications, open multiple games, and switch between games.

[minggo]

Currently, can we create multiple app instances?

[qiuguohua]

Not currently, but it was taken into consideration when designing. Currently most of the classes are static and are not bound to a single application. To create multiple applications, there are a lot of things that need to be modified.

[minggo]

Ok. If it doesn't make things complex, then not problem, as supporting multiple app instances is not our target.