The first impression about MBLTDev 2015

The first impression about MBLT Dev 2015 ... has not forgotten everything yet.

As an iOS developer, I confess that the beginning was a bit boring, but on the whole, in addition to the reports at the exhibition (conference) there were quite a few interesting points. Particularly noteworthy is the mention of the lovely sisters from releadion (thanks for the cute pictures!) And all the charming representatives of the beautiful half of humanity who have added a generous portion of beauty to this technical IT conference.

And now about the reports themselves. Again, as an iOS developer, I was primarily interested in reports on VIPER from Egor Tolstoy from Rambler & Co and “smooth TableView” from Alexander Orlov from Postforpost. The guys did not disappoint - it was very cool! I have been studying VIPER for a long time - there were several questions, the answers to which the speakers and participants of the conference helped me find.

For example, I was interested in the question “what to do if a part of the code from one Interactor needs to be used in another?”. The answer is very simple - select a special services layer (where all the reusable code will be).
')
However, I can’t agree that for services you need to use callback functions, since callbacks have a very unpleasant drawback: if you need to call another function with callback in a callback, then there is such a noodle:

[self someFunctionWithCallbackOnSucces:^{ [weakSelf anotherFunctionWithCallbackOnSucess:^{ // some code 1 } andFail:^{ // some code 1 }]; } andFail:^{ [weakSelf andTheOtherFunctionWithCallbackOnSucess:^{ // some code 2 } andFail:^{ // some code 2 }]; }]; 

What is my subjective, view greatly reduces the readability of the code. The same Delegates look more preferable in this respect (although the Delegate, when communicating one-to-many, does not look very good).

I will explain. As he said, Egor in the report “Secrets of VIPER” - “The router must route”. But the problem is that, for example, in the "reference" implementation of VIPER By Jeff Gilbert and Conrad Stoll (article on objc.io), some wireframe is mentioned, which:
1. creates all the components
2. configures dependencies (dependecy injection)
3. routing

Which is not very consistent with the principle of Single Responsibilty. In Rambler, as I understand it, the following scheme is used for this:
1. In the storyboard, we ask where to go from
2. in the router, we intercept prepareForSegue and perform initialization
3. Typhoon does Dependecy Injection

In my opinion, purely subjective, it creates a “sense of correctness,” but it would be more “correct” to put all these tasks into explicit classes. I.e:

 @interface ModuleA_Router () <ModuleA_Router_Protocol> @property id<ModuleA_DependencyInjector> di; @property id<ModueA_ViewFactory> viewFactory; @property id<ModuleA_InteractorFactory> interactorFactory; @property id<ModuleA_PresenterFactory> presenterFactory; @end @implementation ModuleA_Router - (void)showViewForModuleA { // create id view = [self.viewFactory createViewForModuleAWithParams:...]; id presenter = [self.presenterFactory createPresenterForModuleAWithParams:...]; id interactor = [self.interactorFactory createInteractorForModuleAWithParams:...]; // inject dependencies [self.di configureModuleAWithView:view presenter:presenter interactor:interactor]; [self.navigationController pushViewController:view]; } @end 

With this approach, it does not matter what tool is used for DI, and the creation of objects is completely transferred to the factory classes, which we actually test. This does not contradict the statement that “each of the terms 'View', 'Presenter', 'Interactor' is not a specific entity, but rather a layer (which, in general, may consist of more than one class)”.

Another speaker, Kule Fuller, clarified for me the question of what ideal routers should be. In his report, he said that the whole transition is a state machine. What became a kind of enlightenment for me.

Indeed, now it is possible to present the code of the router more precisely: let's draw for ourselves logical transitions from screen to screen as a state machine, for example, like this:

 + -------------------- + + --------------------- +  
 |  state: |  ----- {correct Login-Password} ----> |  state: |
 |  Authentication |  |  HomePage |
 |  |  |  |
 + -------------------- + + --------------------- +
            |
 {wrong Login-Password}
            |
            |
 + --------------------- +                                                          
 |  state: |   
 |  Registration | 
 |  |
 + --------------------- +

In this case, naturally, by a finite state machine, we mean an automaton with a partial transition function (and, using counters in state ah, for optimization). See also gang of four state pattern .

In addition, Egor and Rambler, presented to the world a lot of their developments related to VIPER. Thank you so much!

So, another report, which in my opinion is also worth mentioning, is the TableView optimization report. Unfortunately, the report itself was short and we did not have time to ask questions, but in a personal conversation I still managed to find out from Alexander Orlov about the differences between the Components Kit and AsyncDisplayKit. Also, Alexander, said that in order to optimize, it makes sense to abandon autolayout and do the layout yourself. Naturally, this should be done by thinking with your head, and not with what you will have ( no hardcode! ). A competent implementation of this principle can be found in github.com/plasmLC/PPlayer . Alexander also recommended not to use the CollectionView without good reason.

For the sake of fairness, I consider it necessary to say that the reports from Sally Shpeard "Developing for Apple TV", Brigit Lyons "Authentic testing for soundcloud", Chris Eidhof "Swift-like APIs" were also very informative and useful.

Thanks to the organizers for the decent “context” of the conference and the speakers for the informative day!