Nipodemos

update docs to reflect changes requested on review

also added the docs in the spanish doc
@@ -162,13 +162,13 @@ Get.create<S>( @@ -162,13 +162,13 @@ Get.create<S>(
162 162
163 ### Diferences between methods: 163 ### Diferences between methods:
164 164
165 -We will talk about the variables `_factory` and `_singl`. Both are essential in the process of creating  
166 - and using our dependencies, because is by it that we can store, dele and recreate the instances.  
167 -  
168 First, let's of the `fenix` of Get.lazyPut and the `permanent` of the other methods. 165 First, let's of the `fenix` of Get.lazyPut and the `permanent` of the other methods.
169 166
170 The fundamental difference between `permanent` and `fenix` is how you want to store your instances. 167 The fundamental difference between `permanent` and `fenix` is how you want to store your instances.
171 -Reinforcing: by default, GetX deletes instances when they are not is use (let's say screen 1 has controller 1 and screen 2 has controller 2. When you move from screen 1 to screen 2, the controller 1 lost its use so it is erased), but if you want to opt to `permanent:true`, then the controller will not be lost in this transition - which is very usefult for services that you want to keep alive thoughout the entire application. `fenix` in the other hand is for services that you don't worry in losing between screen changes, but when you need that service, you expect that it is alive. So basically, it will dispose the unused controller/service/class, but when you need that, it will "recreate from the ashes" a new instance. 168 +Reinforcing: by default, GetX deletes instances when they are not is use.
  169 +It means that: If screen 1 has controller 1 and screen 2 has controller 2 and you remove the first route from stack, (like if you use `Get.off()` or `Get.offName()`) the controller 1 lost it's use so it will be erased.
  170 +But if you want to opt to `permanent:true`, then the controller will not be lost in this transition - which is very usefult for services that you want to keep alive thoughout the entire application.
  171 +`fenix` in the other hand is for services that you don't worry in losing between screen changes, but when you need that service, you expect that it is alive. So basically, it will dispose the unused controller/service/class, but when you need that, it will "recreate from the ashes" a new instance.
172 172
173 Proceeding with the differences between methods: 173 Proceeding with the differences between methods:
174 174
@@ -69,11 +69,11 @@ Para eliminar una instancia de GetX: @@ -69,11 +69,11 @@ Para eliminar una instancia de GetX:
69 Get.delete<Controller>(); 69 Get.delete<Controller>();
70 ``` 70 ```
71 71
72 -## Options 72 +## Instancing methods
73 73
74 -When you use Get.put, lazyPut and putAsync you will have some options that you can change if you want 74 +Although Getx already delivers very good settings for use, it is possible to refine them even more so that it become more useful to the programmer. The methods and it's configurable parameters are:
75 75
76 -- On Get.put(): 76 +- Get.put():
77 77
78 ```dart 78 ```dart
79 Get.put<S>( 79 Get.put<S>(
@@ -103,7 +103,7 @@ Get.put<S>( @@ -103,7 +103,7 @@ Get.put<S>(
103 ) 103 )
104 ``` 104 ```
105 105
106 -- On Get.lazyPut: 106 +- Get.lazyPut:
107 107
108 ```dart 108 ```dart
109 Get.lazyPut<S>( 109 Get.lazyPut<S>(
@@ -124,7 +124,7 @@ Get.lazyPut<S>( @@ -124,7 +124,7 @@ Get.lazyPut<S>(
124 ) 124 )
125 ``` 125 ```
126 126
127 -- On Get.putAsync: 127 +- Get.putAsync:
128 128
129 ```dart 129 ```dart
130 Get.putAsync<S>( 130 Get.putAsync<S>(
@@ -142,6 +142,44 @@ Get.putAsync<S>( @@ -142,6 +142,44 @@ Get.putAsync<S>(
142 bool permanent = false 142 bool permanent = false
143 ``` 143 ```
144 144
  145 +- Get.create:
  146 +
  147 +```dart
  148 +Get.create<S>(
  149 + // required: a function that returns a class that will be "fabricated" every
  150 + // time `Get.find()` is called
  151 + // Example: Get.create<YourClass>(() => YourClass())
  152 + FcBuilderFunc<S> builder,
  153 + // optional: just like Get.put(), but it is used when you need multiple instances
  154 + // of a of a same class
  155 + // Useful in case you have a list that each item need it's own controller
  156 + // needs to be a unique string. Just change from tag to name
  157 + String name,
  158 + // optional: just like int`Get.put()`, it is for when you need to keep the
  159 + // instance alive thoughout the entire app. The difference is in Get.create
  160 + // permanent is true by default
  161 + bool permanent = true
  162 +```
  163 +
  164 +### Diferences between methods:
  165 +
  166 +First, let's of the `fenix` of Get.lazyPut and the `permanent` of the other methods.
  167 +
  168 +The fundamental difference between `permanent` and `fenix` is how you want to store your instances.
  169 +Reinforcing: by default, GetX deletes instances when they are not is use.
  170 +It means that: If screen 1 has controller 1 and screen 2 has controller 2 and you remove the first route from stack, (like if you use `Get.off()` or `Get.offName()`) the controller 1 lost it's use so it will be erased.
  171 +But if you want to opt to `permanent:true`, then the controller will not be lost in this transition - which is very usefult for services that you want to keep alive thoughout the entire application.
  172 +`fenix` in the other hand is for services that you don't worry in losing between screen changes, but when you need that service, you expect that it is alive. So basically, it will dispose the unused controller/service/class, but when you need that, it will "recreate from the ashes" a new instance.
  173 +
  174 +Proceeding with the differences between methods:
  175 +
  176 +- Get.put and Get.putAsync follow the same creation order, with the difference that asyn opt for applying a asynchronous method: those two methods create and initialize the instance. That one is inserted directly in the memory, using the internal method `insert` with the parameters `permanent: false` and `isSingleton: true` (this isSingleton parameter only porpuse is to tell if it is to use the dependency on `dependency` or if it is to use the dependency on `FcBuilderFunc`). After that, `Get.find()` is called that immediately initialize the instances that are on memory.
  177 +
  178 +- Get.create: As the name implies, it will "create" your dependency! Similar to `Get.put()`, it also call the internal method `insert` to instancing. But `permanent` became true and `isSingleton` became false (since we are "creating" our dependency, there is no way for it to be a singleton instace, that's why is false). And because it has `permanent: true`, we have by default the benefit of not losing it between screens! Also, `Get.find()` is not called immediately, it wait to be used in the screen to be called. It is created this way to make use of the parameter `permanent`, since then, worth noticing, `Get.create()` was made with the goal of create not shared instances, but don't get disposed, like for example a button in a listView, that you want a unique instance for that list - because of that, Get.create must be used together with GetWidget.
  179 +
  180 +- Get.lazyPut: As the name implies, it is a lazy proccess. The instance is create, but it is not called to be used immediately, it remains waiting to be called. Contrary to the other methods, `insert` is not called here. Instead, the instance is inserted in another part of the memory, a part responsable to tell if the instance can be recreated or not, let's call it "factory". If we want to create something to be used later, it will not be mix with things been used right now. And here is where `fenix` magic enters: if you opt to leaving `fenix: false`, and your `smartManagement` are not `keepFactory`, then when using `Get.find` the instance will change the place in the memory from the "factory" to common instance memory area. Right after that, by default it is removed from the "factory". Now, if you opt for `fenix: true`, the instance continues to exist in this dedicated part, even going to the common area, to be called again in the future.
  181 +
  182 +
145 ## Bindings 183 ## Bindings
146 184
147 Una de las grandes diferencias de este paquete, tal vez, es la posibilidad de una integración completa de las rutas, gestor de estado y dependencias. 185 Una de las grandes diferencias de este paquete, tal vez, es la posibilidad de una integración completa de las rutas, gestor de estado y dependencias.
@@ -158,15 +158,13 @@ Get.create<S>( @@ -158,15 +158,13 @@ Get.create<S>(
158 158
159 ### Diferenças entre os métodos: 159 ### Diferenças entre os métodos:
160 160
161 -Primeiramente, vamos falar das variáveis `_factory` e `_singl`. Ambas são essenciais no processo de criação e uso de suas dependências, pois é através delas que podemos armazenar, apagar, recriar nossas instâncias.  
162 -  
163 Primeiro, vamos falar do `fenix` do Get.lazyPut e o `permanent` dos outros métodos. 161 Primeiro, vamos falar do `fenix` do Get.lazyPut e o `permanent` dos outros métodos.
164 162
165 -- O `fenix` diz respeito ao armazenamento da instância. Quando você manipula os parâmetros `fenix` ou `smartManagement` para não perder as instâncias da sua dependência, elas serão salvas na para serem chamadas posteriormente.  
166 -  
167 -- O `permanent` diz respeito ao uso. Se a instância permanece ativa, ou se é apagada, quando não está em uso na tela.  
168 -  
169 -A diferença fundamental entre `permanent` e `fenix` está em como você quer armazenar as suas instâncias. Reforçando: por padrão, o Get apaga as instâncias quando elas não estão em uso (Digamos que a tela 1 tenha o controlador A e tela 2, controlador B. Ao mover-se de 1 para 2, o controlador A perde o uso e portanto é apagado), mas se você optar por algo `permanent: true`, então ela não se perde nessa transição - o que é muito útil para serviços que você quer manter rodando na aplicação inteira. Já o `fenix`, é para serviços que você não se preocupa em perder por uma tela ou outra, mas quando você precisar chamar o serviço, você espera que ele "retorne das cinzas" (`fenix: true`), criando uma nova instância. 163 +A diferença fundamental entre `permanent` e `fenix` está em como você quer armazenar as suas instâncias.
  164 +Reforçando: por padrão, o Get apaga as instâncias quando elas não estão em uso.
  165 +Isso significa que: Se a tela 1 tem o controller 1 e a tela 2 tem o controller 2 e você remove a primeira rota da stack (usando `Get.off()` ou `Get.offNamed`), o controller 1 perdeu seu uso portanto será apagado.
  166 +Mas se você optar por usar `permanent: true`, então ela não se perde nessa transição - o que é muito útil para serviços que você quer manter rodando na aplicação inteira.
  167 +Já o `fenix`, é para serviços que você não se preocupa em perder por uma tela ou outra, mas quando você precisar chamar o serviço, você espera que ele "retorne das cinzas" (`fenix: true`), criando uma nova instância.
170 168
171 Prosseguindo com as diferenças entre os métodos: 169 Prosseguindo com as diferenças entre os métodos:
172 170