• Summary of 0.
    • 0.1 Basic Architecture
    • 0.2 Implementation Features
    • 0.3 Design Principles
    • 0.4 Source of project name
  • 1 Module life cycle events
    • 1.1 System Events
    • 1.2 Common Events
    • 1.3 Service User-defined Events
  • 2. Module registration
    • 2.1 Static Registration
    • 2.2 Dynamic Registration
    • 2.3 Asynchronous Loading
  • 3. Programming development
    • 3.1 Setting Environment Variables
    • 3.2 Module Initialization
    • 3.3 Handling System Events
    • 3.4 Inter-module Invocation
      • 3.4.1 Defining interfaces
      • 3.4.2 registeredService
        • Declarative registration
        • APIregistered
        • BHService.plistregistered
      • Rule 3.4.3 callService
    • 3.5 Single cases and multiple cases
    • 3.6 Context Context
  • 4. Integration mode
    • cocoapods
  • 5. The author
  • 6. Open Source licenses

Summary of 0.

BeeHive is a framework for iOS App modular programming, absorbing the concept of Spring framework Service to achieve API coupling between modules.

0.2 Implementation Features

  • Plug-in module development running framework
  • Module implementations are separated from interface calls
  • Module lifecycle management extends application system events

0.4 Source of project name

BeeHive was inspired by BeeHive. Honeycomb is one of the most highly modular engineering structures in the world, and the hexagonal design brings infinite expansion possibilities. So we used BeeHive as the name of this project.

1.1 System Events

System events are typically Application life cycle events, such as DidBecomeActive, WillEnterBackground, and so on.

The basic workflow of system events is as follows:

1.2 Common Events

On the basis of system events, the extension of the application of common events, such as modSetup, modInit, etc., can be used to code the setup and initialization of each plug-in module.

The extended generic events are as follows:

1.3 Service User-defined Events

If system events and generic events are not enough, we’ve also simplified event encapsulation to BHAppdelgate, which you can extend your own events by inheriting BHAppdelegate.

2.1 Static Registration

By registering the BHModuleProtocol compliant module class in the Beehive. plist file:

2.2 Dynamic Registration

@implementation HomeModule BH_EXPORT_MODULE() // declare this class as the module entry @endCopy the code

Use the BH_EXPORT_MODULE() macro in the module entry class implementation to declare the class as the module entry implementation class.

3. Programming development

BHModuleProtocol provides functions that each module can Hook to implement plug-in logic and code implementation.

3.2 Module Initialization

If a module has logic that needs to be initialized at startup, it can be written in modInit, such as a module registering a Service interface that external modules can access

-(void)modInit:(BHContext *)context {// register module interface service [[BeeHive shareInstance] registerService:@protocol(UserTrackServiceProtocol) service:[BHUserTrackViewController class]]; }Copy the code

3.4 Inter-module Invocation

Plug-in programming can be realized by writing each business module by processing events. There is no dependence between business modules, and plug-in isolation can be realized by interaction between core and Module through events. But sometimes we need to call some function between modules to accomplish the function cooperatively.

There are usually three forms of interface access:

  1. Interface-based implementationServiceAccess Mode (Java springFramework implementation)
  2. Based on the function call conventionExport Method(PHPtheextension.ReactNativeExtension mechanism)
  3. Based on cross-application implementationURL RouteMode (iPhone AppExchange of visits)

We are currently implementing the first approach and will gradually implement the latter two.

The advantage of interface-based Service access is that interface changes can be detected by compile-time inspection and interface problems can be corrected in time. The disadvantage is that you need to rely on the header file of the interface definition, and the more you add through modules, the more work it takes to maintain the interface definition.

3.4.2 registeredService

There are two ways:

BHService.plistregistered




    
        HomeServiceProtocol
        BHViewController
    

Copy the code

3.5 Single cases and multiple cases

For scenarios where we access each object that declares a Service and want the object to retain some state, we need to declare the Service object as a singleton.

We just need to implement the event function in the Service object

The statement

-(BOOL) singleton
{
    return YES;
}
Copy the code

The createService object is a singleton object. If the above function returns NO, the createService returns multiple instances.

id< HomeServiceProtocol > homeVc = [[BeeHive shareInstance] createService:@protocol(HomeServiceProtocol)];Copy the code

4. Integration mode

5. The author