📖 English Documentation | 📖 中文文档
- 0. Abstract
- 1. Module life-cycle event
- 2. Module registration
- 3. Programming
- 4. Integration
- 5. Author
- 6. License
0. Abstract
BeeHive
is a modular program of implementation in iOS , it absorbed the Spring Framework API service concept to avoid to directly coupling between modules.
0.1 The basic architecture
We can get to know the architecture of BeeHive from this picture.
0.2 Core concepts
- Module: Modules are separated by different function, every module can communicate with other one through their own services.
- Service: Services are the interface of the specifically module.
0.3 Achieved characteristics
- Plug-in module development of the operating framework
- Module implementation and interface calls Separation
- manage module life loop, extend the application of system events
0.4 Design
BeeHive
bases on Spring
Service concept, although you can make and implement specific interfaces decoupling between modules , but can not avoid interface class dependencies.
Why not use invoke and dynamic link library technology for decoupling interface , similar to Apache
's DSO
way?
Mainly on account of the difficulty and cost of learning to achieve , and dynamic invocation interface parameters can not be able to check phase change problems at compile time , dynamic programming techniques require a higher threshold requirement.
0.5 Project name origin
BeeHive
inspired by the honeycomb. Honeycomb
is the world's highly modular engineering structures, hexagonal design can bring unlimited expansion possibilities. So we used to do for this project BeeHive named.
1. Module life-cycle event
BeeHive's Each module will provide life-cycle events for the host environment and Each module necessary information exchange to BeeHive, you can observer the change in life run loop.
Events are divided into three types:
- System Event
- Universal Event
- Business Custom Event
1.1 System Event
System events are usually Application life-cycle events , such as DidBecomeActive, WillEnterBackground etc. System Event basic workflow is as follows:
1.2 Universal Event
On the basis of system events on the extended general application events , such modSetup, modInit , etc. , may be used to code each plug-in module initialization settings
Extended common events are as follows :
1.3 Business Custom Event
If you feel the system event , the event is not sufficient to meet the general needs , we will simplify the event packaged into BHAppdelgate, you can extend your own event by inheritance BHAppdelegate, while BHContext Lane modulesByName access each module entry class , to increase the trigger point through.
2. Module registration
Registration module divided into two types , static registration and dynamic registration
2.1 Static registration
2.2 Dynamic registration
Use BH_EXPORT_MODULE
macro module entry in the class implementation declares the class for the
implementation class entry module
@implementation HomeModule
BH_EXPORT_MODULE(YES)
-(void)modInit:(BHContext *)context;
@end
2.3 Asynchronous loading
If the module is set to export BH_EXPORT_MODULE (YES), it will initialize asynchronous execution module can be optimized before starting after the first screen shows the contents of the start time consuming
3. Programming
BHModuleProtocol
provides various modules each module can hook functions , and logic for implementing the plug-in code, you can fine protocol in BHModuleProtocol.h
.
3.1 Setting environment variables
By context.env we can judge our application environment state to decide how we configure our application
-(void)modSetup:(BHContext *)context
{
switch (context.env) {
case BHEnvironmentDev:
break;
case BHEnvironmentProd:
default:
break;
}
}
3.2 Module Init
If the module there is need to start initialization logic can modInit in the preparation of , for example, the module can register an external module interface to access the Service
-(void)modInit:(BHContext *)context
{
[[BeeHive shareInstance] registerService:@protocol(UserTrackServiceProtocol) service:[BHUserTrackViewController class]];
}
3.3 Event processing systems
Event system will be passed to each module, so that each module to decide to write business logic.
-(void)modQuickAction:(BHContext *)context
{
[self process:context.shortcutItem handler:context.scompletionHandler];
}
3.4 Inter-modal calls
Event prepared by treating the various business modules can plug-in programming , it has no dependencies between the various business modules , through the interaction between the core and the event module, to achieve a plug-in isolation . But sometimes we need to call each other between modules some collaborative features to completion.
Usually in the form of three types to access service:
- by interface(like
Spring
) - by
Export Method
(likePHP
/ReactNatve
extension) - by
URL Route
pattern(like interaction between iPhone apps)
Interface type of service access can take the advantages of compile-time checking is found to change the interface , so that timely correction interface issues . The disadvantage is the need to rely on the interface definition header file by the module increases the more the maintenance interface definition there is a certain amount of work .
3.4.1 Declare service interface
Case thought HomeServiceProtocol:
@protocol HomeServiceProtocol <NSObject, BHServiceProtocol>
-(void)registerViewController:(UIViewController *)vc title:(NSString *)title iconName:(NSString *)iconName;
@end
3.4.2 Register Service
There are three ways to register ViewController Service.
Declarative registration
@implementation HomeService
BH_EXPORT_SERVICE()
@end
API registration
[[BeeHive shareInstance] registerService:@protocol(HomeServiceProtocol) service:[BHViewController class]];
BHService.plist
registration
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>HomeServiceProtocol</key>
<string>BHViewController</string>
</dict>
</plist>
3.4.3 Service invocation
#import "BHService.h"
id< HomeServiceProtocol > homeVc = [[BeeHive shareInstance] createService:@protocol(HomeServiceProtocol)];
// use homeVc do invocation
3.5 Singleton or several instance
For some scenes , we visit each declared as service objects , objects can hope to retain some of the state , then we need to declare this service object is a singleton object .
We only need to implement the function declaration in the event service objects
-(BOOL) singleton
{
return YES;
}
The object was acquired by createService singleton object , if the function returns to achieve the above is NO, createService returns multiple cases
id< HomeServiceProtocol > homeVc = [[BeeHive shareInstance] createService:@protocol(HomeServiceProtocol)];
3.6 Global Context
Initial setup application project information , and share information across applications among modules
- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions
{
[BHContext shareInstance].env = BHEnvironmentDev;
[BHContext shareInstance].application = application;
[BHContext shareInstance].launchOptions = launchOptions;
[BHContext shareInstance].moduleConfigName = @"BeeHive.bundle/CustomModulePlist";
[BHContext shareInstance].serviceConfigName = @"BeeHive.bundle/CustomServicePlist";
[BHContext shareInstance].appkey = xxxxxx;
[BHContext shareInstance].Mtopkey = xxxxx;
[[BeeHive shareInstance] setContext:[BHContext shareInstance]];
[super application:application didFinishLaunchingWithOptions:launchOptions];
id<HomeServiceProtocol> homeVc = [[BeeHive shareInstance] createService:@protocol(HomeServiceProtocol)];
if ([homeVc isKindOfClass:[UIViewController class]]) {
UINavigationController *navCtrl = [[UINavigationController alloc] initWithRootViewController:(UIViewController*)homeVc];
self.window = [[UIWindow alloc] initWithFrame:[UIScreen mainScreen].bounds];
self.window.rootViewController = navCtrl;
[self.window makeKeyAndVisible];
}
return YES;
}
4. Integration
cocoapods
pod "BeeHive", '1.0.0'
5. Author
6. License
BeeHive is available under the GPL license. See the LICENSE file for more info.