In current code WebSocketManager gets initialized in constructor and it expects GlobalSettings to be already initialized. For example, you cannot write
_operationManager = new OperationManager();GlobalSettings.Init(Name, PostingKey, KnownChains.Steem);
you always have to do it the other way around, otherwise you'll get NullReferenceException. This is quite inconvenient as it's natural to create objects in class constructor, i.e.:
public Robot(){this.operationManager = new OperationManager();}
and configure it later:
public void Configure(){this.Account = ConfigurationManager.AppSettings["account"];this.PostingKey = ConfigurationManager.AppSettings["postingKey"];GlobalSettings.Init(Account, PostingKey, KnownChains.Golos);}
This scenario is not possible in current setup. I suggest lazy initialization of WebSocketManager to address this with minimal impact. Please see my fork for details.
Thanks for the comment. Initialization was divided into parts:
1 _operationManager = new OperationManager(); (lightweight constructor)
2 _operationManager.TryConnectTo(new List { "wss://..." }, Token);
GlobalSettings no longer exists.
In current code WebSocketManager gets initialized in constructor and it expects GlobalSettings to be already initialized. For example, you cannot write
_operationManager = new OperationManager();
GlobalSettings.Init(Name, PostingKey, KnownChains.Steem);
you always have to do it the other way around, otherwise you'll get NullReferenceException. This is quite inconvenient as it's natural to create objects in class constructor, i.e.:
public Robot(){
this.operationManager = new OperationManager();
}
and configure it later:
public void Configure(){
this.Account = ConfigurationManager.AppSettings["account"];
this.PostingKey = ConfigurationManager.AppSettings["postingKey"];
GlobalSettings.Init(Account, PostingKey, KnownChains.Golos);
}
This scenario is not possible in current setup. I suggest lazy initialization of WebSocketManager to address this with minimal impact. Please see my fork for details.