Enfin libre de (ne plus) m’exprimer…

Personne n’ayant rien à faire de ce blog, hormis les moteurs de spam russes qui continueront d’envoyer des commentaires, mes profils sociaux, y compris mon profil professionnel sur linkedIn, ayant été supprimés, je peux enfin m’exprimer librement et donc déverser mes remarques acerbes dans la mesure où elles n’atteindront finalement personne.

C’est probablement la plus grande forme de liberté.

On me rétorquera que je souhaite, au fond de moi, qu’une âme pure tombe sur ce post et le relaie à mon corps défendant sur les réseaux sociaux. Je l’avoue. Mais ce sera pur hasard et, comme je viens de le dire, sans que j’ai cherché à le faire (on dirait à l’insu de mon plein grès, mais c’est déjà pris !), mais en l’espérant… L’inconsistance et la contradiction ne seront pas les seuls de mes défauts…

Ce blog est donc inutile, désastreux, sans intérêt, ne flatte que mon égo et c’est pour ça qu’il sera drôle (ou pas) et que ce qui s’y trouve ne regarde que moi. Il se trouve donc que, si vous le lisez, sauf à ce qu’il soit diffamant à votre égard, ce dont je doute car je n’ai aucun courage spécifique à diffamer des gens qui pourraient me mettre leur poing dans la gueule au mieux, tant mieux pour vous, mais je ne suis pas responsable de vos humeurs, de votre ressenti, des effets désirables ou non qu’il pourrait avoir sur vous. Je ne répondrai pas aux commentaires (de toute façon ils sont supprimés), n’en publierai aucun et ne changerai pas le contenu d’un article (sauf s’il s’avérait que ce qu’il contient est objectivement faux – je ne changerai donc pas mes opinions personnelles subjectives – ou que la justice m’impose sa Loi – je suis assez lâche pour ne pas m’opposer à l’appareil de répression de l’Etat).

Vous ne pourrez en outre plus me contacter, je supprime la page de Contact qui ne sert à rien.

Belle journée.

C’était le premier post libre de ce nouveau blog et probablement le dernier.

Dependency Injection in Swift (Mini Cake solution)

I already talked about the subject of Dependency Inversion here and of course the way to implement Dependency Inversion is to use Dependency Injection.

First let’s go back to what is Dependency Injection. Dependency injection is used to inject real implementations into a class that uses abstract interfaces instead. So let’s say a Presenter Class uses of View Class. If you are using SOLID, then your Presenter Class will “see” the View Class thru an abstract interface (a contract) and thus the dependency to the View Class will be reversed as you can see in the Fig-1.

Fig-1 : Presenter-Interface-View

When this is done, you can “insert” whatever View in the Presenter as long as it respects the View Protocol contract.

To do the insertion, you will use Dependency Injection. There are 2 types of Dependency Injection :

  1. Dependency Injection at instanciation
  2. Dependency Injection by modification

Continue reading “Dependency Injection in Swift (Mini Cake solution)”

ReactNative Native Modules in Swift – Part 3 (details, conclusion, …)

To give a conclusion to this subject treated in Part1 and Part2, I want to go back to how native module work and how to communicate between native modules and ReactNative modules.

First, let’s talk about the .m file that enables to link native to JS thru runtime. The code was this :

#import <React/RCTBridgeModule.h>

@interface RCT_EXTERN_MODULE(MyNativeModule, NSObject)
RCT_EXTERN_METHOD(triggerJSRequest)
@end

Continue reading “ReactNative Native Modules in Swift – Part 3 (details, conclusion, …)”

ReactNative Native Modules in Swift – Part 2 (ReactNative bridging)

In Part 1, we saw how to integrate ReactNative inside a Swift project using Cocoapods. Now, before starting to create a ReactNative View and integrate it into our project.

First, let’s take a quick tour of how ReactNative works.

I will not dive in depth (first because I don’t have enough expertise so far and second because it could take a complete book to make it) but at least I will reveal a little bit of the magic behind ReactNative from what I understood and read. There’s a very nice talk from Peggy Rayzis about this subject that you can watch here.

Continue reading “ReactNative Native Modules in Swift – Part 2 (ReactNative bridging)”

ReactNative Native Modules in Swift – Part 1 (Install ReactNative inside a Swift project…)

So I was working on a clean architecture example in Swift based on this post and the way I implement VIPR. I was adding/implementing a simplified version of it based on the graph represented in Fig-1.

Fig – 1 : VIPR Simplified in Swift

And then I decided to prove that this architecture is really decoupled and thus wanted to integrate a ReactNative View into it. Of course I was overestimated my knowledge of ReactNative because I did few small projects in ReactNative and it looked very easy (because I was not bridging to native modules…). Continue reading “ReactNative Native Modules in Swift – Part 1 (Install ReactNative inside a Swift project…)”

Help, I need to refactor, but where should I start ? (SDP to the rescue)

Of course it’s impossible to answer this question in one single post, or even in one single book (the best known book for this is the one from M.Feathers, “Working Effectively with Legacy Code” that you can buy here). In fact it’s impossible to answer this question at all as it will all depend on what is the current status of what you have to refactor and every situation is specific. But still, there are few things that can be said and that can/should be applied when it’s about refactoring. Continue reading “Help, I need to refactor, but where should I start ? (SDP to the rescue)”

From VIPER to VIP’R (VIP – pause – R) or how to eject Entity!

For this week, I want to give a clear example of the type of architecture that I’m trying to push on the projects I work on. Some of you probably already know VIPER. It tends to become a classical architecture in iOS development and in other platforms like Android. VIPER goes for :

  • V : View
  • I: Interactor
  • P: Presenter
  • E: Entitie
  • R: Router

It was inspired by the Onion Architecture or Clean Architecture pushed by Robert Cecil Martin, more known as Uncle Bob.

The Clean Architecture – © Robert Martin.

On the image The Clean Architecture, you can see an example of what it looks like. You see “skins”, or layers, that go from external to internal, crossing boundaries in one way and going right to the center where you find Entities. Continue reading “From VIPER to VIP’R (VIP – pause – R) or how to eject Entity!”

MVP pattern thru Dependency Inversion !

In general, MVP (Model View Présenter/Controller) is a very nice pattern presented in many different languages and used in tons of development, especially when it’s about frontend.

MVP Pattern
Ref – 1

On paper, MVP looks like in Ref – 1. That’s fine and as you can see, Presenter seems to depend on both the View and the Model. Continue reading “MVP pattern thru Dependency Inversion !”

Protect yourself from models !

You probably use models in your code every day and so do I. The major problem with a model is that it will surely evolve. It will evolve because the business will require a change or because a new feature will be needed and thus will require the model to change or because the api will have new fields or different informations. The best case is that this evolution will not touch your code, the worst case is that this evolution will destroy your code. But in any case you depend on this model and this is generally bad… Continue reading “Protect yourself from models !”

What is Dependency Inversion ?

Dependency Inversion is a very simple concept : “if a class B depends on a class A, you can revert this dependency by generating a contract that class A must implement”. Thus you became responsible for this contract and you do not depend anymore on anyone because they will have to implement your contract and not you… Continue reading “What is Dependency Inversion ?”