sukesukejijii

day2 update

@@ -78,10 +78,10 @@ @@ -78,10 +78,10 @@
78 - [GetxService](#getxservice) 78 - [GetxService](#getxservice)
79 - [Breaking changes from 2.0](#breaking-changes-from-20) 79 - [Breaking changes from 2.0](#breaking-changes-from-20)
80 - [なぜGetXなのか](#なぜGetXなのか) 80 - [なぜGetXなのか](#なぜGetXなのか)
81 -- [Community](#community)  
82 - - [Community channels](#community-channels)  
83 - - [How to contribute](#how-to-contribute)  
84 - - [Articles and videos](#articles-and-videos) 81 +- [コミュニティ](#コミュニティ)
  82 + - [コミュニティチャンネル](#コミュニティチャンネル)
  83 + - [貢献方法](#貢献方法)
  84 + - [GetXに関する記事とビデオ](#GetXに関する記事とビデオ)
85 85
86 # Getとは 86 # Getとは
87 87
@@ -137,8 +137,8 @@ Flutter縺ァ譁ー隕上繝ュ繧ク繧ァ繧ッ繝医r菴懈縺吶k髫帙↓陦ィ遉コ縺輔l繧九き繧ヲ繝ウ @@ -137,8 +137,8 @@ Flutter縺ァ譁ー隕上繝ュ繧ク繧ァ繧ッ繝医r菴懈縺吶k髫帙↓陦ィ遉コ縺輔l繧九き繧ヲ繝ウ
137 void main() => runApp(GetMaterialApp(home: Home())); 137 void main() => runApp(GetMaterialApp(home: Home()));
138 ``` 138 ```
139 139
140 -- 補足1: GetMaterialAppはFlutterのMaterialAppに手を加えたものではありません。MaterialAppをchildに持ち、諸々の追加設定をしてくれるWidgetに過ぎません。この設定は手動でも可能ですが、その必要はありません。GetMaterialAppは、Routeの作成・注入、言語翻訳の注入など、ナビゲーションに必要なものをすべて注入してくれます。Getを状態管理や依存性注入に限定して使用する場合は、GetMaterialAppを使用する必要はありません。GetMaterialAppは、Route、SnackBar、多言語対応、BottomSheet、Dialog、contextなしの高レベルAPIを利用する場合に必要です。  
141 -- 補足2: このステップは、Route管理機能(`Get.to()`や`Get.back()`など)を使用しない場合は、必要ありません。 140 +- 注1: GetMaterialAppはFlutterのMaterialAppに手を加えたものではありません。MaterialAppをchildに持ち、諸々の追加設定をしてくれるWidgetに過ぎません。この設定は手動でも可能ですが、その必要はありません。GetMaterialAppは、Routeの作成・注入、言語翻訳の注入など、ナビゲーションに必要なものをすべて注入してくれます。Getを状態管理や依存性注入に限定して使用する場合は、GetMaterialAppを使用する必要はありません。GetMaterialAppは、Route、SnackBar、多言語対応、BottomSheet、Dialog、contextなしの高レベルAPIを利用する場合に必要です。
  141 +- 注2: このステップは、Route管理機能(`Get.to()`や`Get.back()`など)を使用しない場合は、必要ありません。
142 142
143 - ステップ2: 143 - ステップ2:
144 ビジネスロジッククラスを作成し、そこに必要な変数、メソッド、コントローラをすべて配置します。 144 ビジネスロジッククラスを作成し、そこに必要な変数、メソッド、コントローラをすべて配置します。
@@ -239,13 +239,13 @@ Obx(() => Text("${controller.name}")); @@ -239,13 +239,13 @@ Obx(() => Text("${controller.name}"));
239 239
240 **状態管理のより詳細な説明を知りたい方は[こちら](./documentation/ja_JP/state_management.md)をご覧ください。より多くの例や、普通の状態管理とリアクティブな状態管理の違いについても説明されています。** 240 **状態管理のより詳細な説明を知りたい方は[こちら](./documentation/ja_JP/state_management.md)をご覧ください。より多くの例や、普通の状態管理とリアクティブな状態管理の違いについても説明されています。**
241 241
242 -GetXパワーの良さをより理解していただけると思います。 242 +GetXパワーがもたらす利点をより理解していただけると思います。
243 243
244 ## Route管理 244 ## Route管理
245 245
246 -contextなしでRoute/SnackBar/Dialog/BottomSheetを使用する場合、GetXはあなたにとっても優れています、見てみてください。 246 +GetXはcontextなしでRoute/SnackBar/Dialog/BottomSheetを使用することができます。具体的に見ていきましょう。
247 247
248 -MaterialAppの前に「Get」を追加すると、GetMaterialAppになります。 248 +いつものMaterialAppの前に「Get」を付け足して、GetMaterialAppにしましょう。
249 249
250 ```dart 250 ```dart
251 GetMaterialApp( // MaterialApp の前に Get 251 GetMaterialApp( // MaterialApp の前に Get
@@ -253,88 +253,85 @@ GetMaterialApp( // MaterialApp 縺ョ蜑阪↓ Get @@ -253,88 +253,85 @@ GetMaterialApp( // MaterialApp 縺ョ蜑阪↓ Get
253 ) 253 )
254 ``` 254 ```
255 255
256 -新しいRouteに画面遷移。 256 +新しいRouteに画面遷移するにはこの構文。
257 257
258 ```dart 258 ```dart
259 -  
260 Get.to(NextScreen()); 259 Get.to(NextScreen());
261 ``` 260 ```
262 261
263 -名前付きRouteに画面遷移。名前付きRouteの詳細は[こちら](./documentation/ja_JP/route_management.md#navigation-with-named-routes) 262 +名前付きRouteに画面遷移するにはこの構文。名前付きRouteの詳細は[こちら](./documentation/ja_JP/route_management.md#navigation-with-named-routes)
264 263
265 ```dart 264 ```dart
266 -  
267 Get.toNamed('/details'); 265 Get.toNamed('/details');
268 ``` 266 ```
269 267
270 -SnackBar、Dialog、BottomSheetなど、Navigator.pop(context)で閉じられるものはこれで閉じます。 268 +SnackBar、Dialog、BottomSheetなど、Navigator.pop(context)で閉じられるRouteはこれで閉じます。
271 269
272 ```dart 270 ```dart
273 Get.back(); 271 Get.back();
274 ``` 272 ```
275 273
276 -次の画面に移動した後、前の画面に戻るオプションがない場合(スプラッシュスクリーンやログイン画面などで利用) 274 +次の画面に移動した後、前の画面に戻れないようにする場合(スプラッシュスクリーンやログイン画面など)はこちら。
277 275
278 ```dart 276 ```dart
279 Get.off(NextScreen()); 277 Get.off(NextScreen());
280 ``` 278 ```
281 279
282 -次の画面に進み、前のRouteをすべてキャンセルする場合(ショッピングカート、アンケート、テストなどで有効) 280 +次の画面に進み、前のRouteをすべてキャンセルする場合(ショッピングカート、アンケート、テストなど)はこちら。
283 281
284 ```dart 282 ```dart
285 Get.offAll(NextScreen()); 283 Get.offAll(NextScreen());
286 ``` 284 ```
287 285
288 -以上のことを行うのに、contextを使わなかったことに気付きましたか?これが、GetでRoute管理を行う最大のメリットのひとつです。これによりcontrollerクラスの中でも、これらのメソッドを安心して実行することができます。 286 +以上、contextを一度も使わなかったことに気付きましたか?これがGetでRoute管理を行う最大のメリットのひとつです。contextを使わないので、たとえばcontrollerクラスの中でも、これらのメソッドを実行することができます。
289 287
290 ### Route管理についての詳細 288 ### Route管理についての詳細
291 289
292 **Getは名前付きRouteでも動作し、Routeの下位レベルの制御も可能です。詳細なドキュメントは[こちら](./documentation/ja_JP/route_management.md)にあります。** 290 **Getは名前付きRouteでも動作し、Routeの下位レベルの制御も可能です。詳細なドキュメントは[こちら](./documentation/ja_JP/route_management.md)にあります。**
293 291
294 -## Dependency management 292 +## 依存性注入の管理
295 293
296 -Get has a simple and powerful dependency manager that allows you to retrieve the same class as your Bloc or Controller with just 1 lines of code, no Provider context, no inheritedWidget: 294 +Getにはシンプルで強力な依存性注入機能があります。わずか1行のコードで、Provider contextやinheritedWidgetも使わず、BLoCやControllerのようなクラスのインスタンスを取得することができます。
297 295
298 ```dart 296 ```dart
299 -Controller controller = Get.put(Controller()); // Rather Controller controller = Controller(); 297 +Controller controller = Get.put(Controller()); // controller = Controller() とする代わりに
300 ``` 298 ```
301 299
302 -- Note: If you are using Get's State Manager, pay more attention to the bindings API, which will make it easier to connect your view to your controller. 300 +- 注: Getの状態管理機能を使用している場合は、Bindings APIにもご注目を。BindingsはViewとControllerを結びつけるのをより便利にしてくれます。
303 301
304 -Instead of instantiating your class within the class you are using, you are instantiating it within the Get instance, which will make it available throughout your App.  
305 -So you can use your controller (or class Bloc) normally 302 +一つのクラスの中でControllerクラスをインスタンス化するのではなく、Getインスタンスの中でインスタンス化することで、アプリ全体でControllerが利用できるようになります。
306 303
307 -**Tip:** Get dependency management is decoupled from other parts of the package, so if for example, your app is already using a state manager (any one, it doesn't matter), you don't need to rewrite it all, you can use this dependency injection with no problems at all 304 +**ヒント:** Getの依存性注入機能の部分は、パッケージ全体の中でも他の部分と切り離されているので、たとえば、あなたのアプリがすでに状態管理機能を一部で使用していたとしても、それらを書き直す必要はなく、この依存性注入機能をそのまま使用することができます。
308 305
309 ```dart 306 ```dart
310 controller.fetchApi(); 307 controller.fetchApi();
311 ``` 308 ```
312 309
313 -Imagine that you have navigated through numerous routes, and you need data that was left behind in your controller, you would need a state manager combined with the Provider or Get_it, correct? Not with Get. You just need to ask Get to "find" for your controller, you don't need any additional dependencies: 310 +色々なRouteを行き来した後に、あるControllerクラスのデータにアクセスする必要が生じたとしましょう。ProviderやGet_itなら再びそのクラスに依存性注入する必要がありますよね?Getの場合は違います。Getでは「find」と依頼するだけで、追加の依存性注入は必要ありません。
314 311
315 ```dart 312 ```dart
316 Controller controller = Get.find(); 313 Controller controller = Get.find();
317 -//Yes, it looks like Magic, Get will find your controller, and will deliver it to you. You can have 1 million controllers instantiated, Get will always give you the right controller. 314 +//マジックみたいですね。Getは正しいcontrollerをきちんと探してきてくれますよ。100万のcontrollerのインスタンスがあっても、Getは必ず正しいcontrollerを探し当てます。
318 ``` 315 ```
319 316
320 -And then you will be able to recover your controller data that was obtained back there: 317 +そして、findで取得したコントローラーのデータをこのように呼び出すことができます。
321 318
322 ```dart 319 ```dart
323 Text(controller.textFromApi); 320 Text(controller.textFromApi);
324 ``` 321 ```
325 322
326 -### More details about dependency management 323 +### 依存性注入の管理についての詳細
327 324
328 -**See a more in-depth explanation of dependency management [here](./documentation/ja_JP/dependency_management.md)** 325 +**依存性注入管理のより詳細な説明は[こちら](./documentation/ja_JP/dependency_management.md)をご覧ください。**
329 326
330 -# Utils 327 +# ユーティリティ
331 328
332 -## Internationalization 329 +## 多言語対応
333 330
334 -### Translations 331 +### 翻訳
335 332
336 -Translations are kept as a simple key-value dictionary map.  
337 -To add custom translations, create a class and extend `Translations`. 333 +翻訳ファイルはシンプルなキーと値のMapとして保持されます。
  334 +翻訳を追加するには、クラスを作成して `Translations` を継承します。
338 335
339 ```dart 336 ```dart
340 import 'package:get/get.dart'; 337 import 'package:get/get.dart';
@@ -352,22 +349,22 @@ class Messages extends Translations { @@ -352,22 +349,22 @@ class Messages extends Translations {
352 } 349 }
353 ``` 350 ```
354 351
355 -#### Using translations 352 +#### 翻訳の利用
356 353
357 -Just append `.tr` to the specified key and it will be translated, using the current value of `Get.locale` and `Get.fallbackLocale`. 354 +指定されたキーに `.tr` (translateのtr)を追加するだけで、`Get.locale` と `Get.fallbackLocale` の現在の値をに沿って適切な言語に翻訳されます。
358 355
359 ```dart 356 ```dart
360 Text('title'.tr); 357 Text('title'.tr);
361 ``` 358 ```
362 359
363 -#### Using translation with singular and plural 360 +#### 単数系と複数形に対応
364 361
365 ```dart 362 ```dart
366 var products = []; 363 var products = [];
367 Text('singularKey'.trPlural('pluralKey', products.length, Args)); 364 Text('singularKey'.trPlural('pluralKey', products.length, Args));
368 ``` 365 ```
369 366
370 -#### Using translation with parameters 367 +#### パラメーターに対応
371 368
372 ```dart 369 ```dart
373 import 'package:get/get.dart'; 370 import 'package:get/get.dart';
@@ -388,30 +385,30 @@ Text('logged_in'.trParams({ @@ -388,30 +385,30 @@ Text('logged_in'.trParams({
388 })); 385 }));
389 ``` 386 ```
390 387
391 -### Locales 388 +### ロケール
392 389
393 -Pass parameters to `GetMaterialApp` to define the locale and translations. 390 +ロケールと翻訳を定義するため、`GetMaterialApp`にパラメータを渡します。
394 391
395 ```dart 392 ```dart
396 return GetMaterialApp( 393 return GetMaterialApp(
397 - translations: Messages(), // your translations  
398 - locale: Locale('en', 'US'), // translations will be displayed in that locale  
399 - fallbackLocale: Locale('en', 'UK'), // specify the fallback locale in case an invalid locale is selected. 394 + translations: Messages(), // Translationsを継承したクラスのインスタンス
  395 + locale: Locale('en', 'US'), // このロケール設定に沿って翻訳が表示される
  396 + fallbackLocale: Locale('en', 'UK'), // 無効なロケールだったときのフォールバックを指定
400 ); 397 );
401 ``` 398 ```
402 399
403 -#### Change locale 400 +#### ロケールの変更
404 401
405 -Call `Get.updateLocale(locale)` to update the locale. Translations then automatically use the new locale. 402 +ロケールを変更するには、`Get.updateLocale(locale)`を呼び出します。翻訳は新しいロケールに沿ってなされます。
406 403
407 ```dart 404 ```dart
408 var locale = Locale('en', 'US'); 405 var locale = Locale('en', 'US');
409 Get.updateLocale(locale); 406 Get.updateLocale(locale);
410 ``` 407 ```
411 408
412 -#### System locale 409 +#### システムロケール
413 410
414 -To read the system locale, you could use `Get.deviceLocale`. 411 +システムのロケールを読み込むには、`Get.deviceLocale`を使用します。
415 412
416 ```dart 413 ```dart
417 return GetMaterialApp( 414 return GetMaterialApp(
@@ -419,42 +416,42 @@ return GetMaterialApp( @@ -419,42 +416,42 @@ return GetMaterialApp(
419 ); 416 );
420 ``` 417 ```
421 418
422 -## Change Theme 419 +## Themeの変更
423 420
424 -Please do not use any higher level widget than `GetMaterialApp` in order to update it. This can trigger duplicate keys. A lot of people are used to the prehistoric approach of creating a "ThemeProvider" widget just to change the theme of your app, and this is definitely NOT necessary with **GetX™**. 421 +`GetMaterialApp`より上位のWidgetを使ってThemeを変更しないでください。Keyの重複を引き起こす可能性があります。アプリのThemeを変更するためには「ThemeProvider」Widgetを作成するという前時代的なアプローチが採られることが多いですが、**GetX™**ではこのようなことは必要ありません。
425 422
426 -You can create your custom theme and simply add it within `Get.changeTheme` without any boilerplate for that: 423 +カスタムのThemeDataを作成したら、それを`Get.changeTheme`内に追加するだけです。
427 424
428 ```dart 425 ```dart
429 Get.changeTheme(ThemeData.light()); 426 Get.changeTheme(ThemeData.light());
430 ``` 427 ```
431 428
432 -If you want to create something like a button that changes the Theme in `onTap`, you can combine two **GetX™** APIs for that: 429 +もし、`onTap`でThemeを変更するボタンを作りたいのであれば、以下の2つの**GetX™** APIを組み合わせることができます。
433 430
434 -- The api that checks if the dark `Theme` is being used.  
435 -- And the `Theme` Change API, you can just put this within an `onPressed`: 431 +- Dark Theme が使われているかどうかをチェックするAPI
  432 +- Theme を変えるAPI(ボタンの`onPressed`の中に設置できます)
436 433
437 ```dart 434 ```dart
438 Get.changeTheme(Get.isDarkMode? ThemeData.light(): ThemeData.dark()); 435 Get.changeTheme(Get.isDarkMode? ThemeData.light(): ThemeData.dark());
439 ``` 436 ```
440 437
441 -When `.darkmode` is activated, it will switch to the _light theme_, and when the _light theme_ becomes active, it will change to _dark theme_. 438 +Darkモードが有効であれば、_light theme_に切り替わり、Lightモードが有効なら、_dark theme_に切り替わります。
442 439
443 ## GetConnect 440 ## GetConnect
444 441
445 -GetConnect is an easy way to communicate from your back to your front with http or websockets 442 +GetConnect は、http または websocket を使用してバックエンドとフロントエンド間の通信を行う機能です。
446 443
447 -### Default configuration 444 +### デフォルト設定
448 445
449 -You can simply extend GetConnect and use the GET/POST/PUT/DELETE/SOCKET methods to communicate with your Rest API or websockets. 446 +GetConnectを拡張することで、GET/POST/PUT/DELETE/SOCKETメソッドを使用して、Rest APIやウェブソケットと通信することができます。
450 447
451 ```dart 448 ```dart
452 class UserProvider extends GetConnect { 449 class UserProvider extends GetConnect {
453 - // Get request 450 + // Get リクエスト
454 Future<Response> getUser(int id) => get('http://youapi/users/$id'); 451 Future<Response> getUser(int id) => get('http://youapi/users/$id');
455 - // Post request 452 + // Post リクエスト
456 Future<Response> postUser(Map data) => post('http://youapi/users', body: data); 453 Future<Response> postUser(Map data) => post('http://youapi/users', body: data);
457 - // Post request with File 454 + // File付き Post リクエスト
458 Future<Response<CasesModel>> postCases(List<int> image) { 455 Future<Response<CasesModel>> postCases(List<int> image) {
459 final form = FormData({ 456 final form = FormData({
460 'file': MultipartFile(image, filename: 'avatar.png'), 457 'file': MultipartFile(image, filename: 'avatar.png'),
@@ -469,29 +466,27 @@ class UserProvider extends GetConnect { @@ -469,29 +466,27 @@ class UserProvider extends GetConnect {
469 } 466 }
470 ``` 467 ```
471 468
472 -### Custom configuration 469 +### カスタム設定
473 470
474 -GetConnect is highly customizable You can define base Url, as answer modifiers, as Requests modifiers, define an authenticator, and even the number of attempts in which it will try to authenticate itself, in addition to giving the possibility to define a standard decoder that will transform all your requests into your Models without any additional configuration. 471 +GetConnect は高度なカスタマイズが可能です。ベースUrlの定義はもちろん、リクエストヘッダーを足したり、レスポンスボディに変更を加えたり、認証情報を追加したり、認証回数の制限を設けたりすることができるほか、リクエストをModelに変換するデコーダを定義することもできます。
475 472
476 ```dart 473 ```dart
477 class HomeProvider extends GetConnect { 474 class HomeProvider extends GetConnect {
478 @override 475 @override
479 void onInit() { 476 void onInit() {
480 - // All request will pass to jsonEncode so CasesModel.fromJson() 477 + // デフォルトデコーダーをセット
481 httpClient.defaultDecoder = CasesModel.fromJson; 478 httpClient.defaultDecoder = CasesModel.fromJson;
482 httpClient.baseUrl = 'https://api.covid19api.com'; 479 httpClient.baseUrl = 'https://api.covid19api.com';
483 - // baseUrl = 'https://api.covid19api.com'; // It define baseUrl to  
484 - // Http and websockets if used with no [httpClient] instance 480 + // baseUrlをセット
485 481
486 - // It's will attach 'apikey' property on header from all requests 482 + // リクエストヘッダーに 'apikey' プロパティを付け足しています。
487 httpClient.addRequestModifier((request) { 483 httpClient.addRequestModifier((request) {
488 request.headers['apikey'] = '12345678'; 484 request.headers['apikey'] = '12345678';
489 return request; 485 return request;
490 }); 486 });
491 487
492 - // Even if the server sends data from the country "Brazil",  
493 - // it will never be displayed to users, because you remove  
494 - // that data from the response, even before the response is delivered 488 + // サーバーが"Brazil"を含むデータを送ってきてもユーザーに表示されることはありません。
  489 + // レスポンスがUIレイヤーに届けられる前にデータが取り除かれているからです。
495 httpClient.addResponseModifier<CasesModel>((request, response) { 490 httpClient.addResponseModifier<CasesModel>((request, response) {
496 CasesModel model = response.body; 491 CasesModel model = response.body;
497 if (model.countries.contains('Brazil')) { 492 if (model.countries.contains('Brazil')) {
@@ -502,13 +497,13 @@ class HomeProvider extends GetConnect { @@ -502,13 +497,13 @@ class HomeProvider extends GetConnect {
502 httpClient.addAuthenticator((request) async { 497 httpClient.addAuthenticator((request) async {
503 final response = await get("http://yourapi/token"); 498 final response = await get("http://yourapi/token");
504 final token = response.body['token']; 499 final token = response.body['token'];
505 - // Set the header 500 + // ヘッダーをセット
506 request.headers['Authorization'] = "$token"; 501 request.headers['Authorization'] = "$token";
507 return request; 502 return request;
508 }); 503 });
509 504
510 - //Autenticator will be called 3 times if HttpStatus is  
511 - //HttpStatus.unauthorized 505 + // HttpStatus が HttpStatus.unauthorized である限り、
  506 + // 3回まで認証が試みられます。
512 httpClient.maxAuthRetries = 3; 507 httpClient.maxAuthRetries = 3;
513 } 508 }
514 } 509 }
@@ -518,15 +513,15 @@ class HomeProvider extends GetConnect { @@ -518,15 +513,15 @@ class HomeProvider extends GetConnect {
518 } 513 }
519 ``` 514 ```
520 515
521 -## GetPage Middleware 516 +## GetPageのミドルウェア
522 517
523 -The GetPage has now new property that takes a list of GetMiddleWare and run them in the specific order. 518 +GetPageに新しいプロパティが追加され、GetMiddleWareのListを設定することができるようになりました。GetMiddleWareは設定した任意の順序で実行されます。
524 519
525 -**Note**: When GetPage has a Middlewares, all the children of this page will have the same middlewares automatically. 520 +**注**: GetPageにMiddlewareを設定すると、そのページの下にあるchildはすべて同じMiddlewareを自動的に持つことになります。
526 521
527 -### Priority 522 +### 実行順
528 523
529 -The Order of the Middlewares to run can be set by the priority in the GetMiddleware. 524 +GetMiddlewareに設定したpriority(優先度)の若い順にミドルウェアが実行されます。
530 525
531 ```dart 526 ```dart
532 final middlewares = [ 527 final middlewares = [
@@ -537,11 +532,11 @@ final middlewares = [ @@ -537,11 +532,11 @@ final middlewares = [
537 ]; 532 ];
538 ``` 533 ```
539 534
540 -those middlewares will be run in this order **-8 => 2 => 4 => 5** 535 +この場合の実行順序は **-8 => 2 => 4 => 5**
541 536
542 -### Redirect 537 +### redirect
543 538
544 -This function will be called when the page of the called route is being searched for. It takes RouteSettings as a result to redirect to. Or give it null and there will be no redirecting. 539 +redirect関数は、Routeを呼び出してページが検索されると実行されます。リダイレクト先のRouteSettingsが戻り値となります。もしくはnullを与えれば、リダイレクトは行われません。
545 540
546 ```dart 541 ```dart
547 RouteSettings redirect(String route) { 542 RouteSettings redirect(String route) {
@@ -552,8 +547,8 @@ RouteSettings redirect(String route) { @@ -552,8 +547,8 @@ RouteSettings redirect(String route) {
552 547
553 ### onPageCalled 548 ### onPageCalled
554 549
555 -This function will be called when this Page is called before anything created  
556 -you can use it to change something about the page or give it new page 550 +onPageCalled関数は、ページが呼び出された直後に実行されます。
  551 +この関数を使ってページの内容を変更したり、新しいページを作成したりすることができます。
557 552
558 ```dart 553 ```dart
559 GetPage onPageCalled(GetPage page) { 554 GetPage onPageCalled(GetPage page) {
@@ -562,10 +557,10 @@ GetPage onPageCalled(GetPage page) { @@ -562,10 +557,10 @@ GetPage onPageCalled(GetPage page) {
562 } 557 }
563 ``` 558 ```
564 559
565 -### OnBindingsStart 560 +### onBindingsStart
566 561
567 -This function will be called right before the Bindings are initialize.  
568 -Here you can change Bindings for this page. 562 +onBindingsStart関数は、Bindingsが初期化される直前に実行されます。
  563 +たとえば、ページのBindingsを変更することもできます。
569 564
570 ```dart 565 ```dart
571 List<Bindings> onBindingsStart(List<Bindings> bindings) { 566 List<Bindings> onBindingsStart(List<Bindings> bindings) {
@@ -577,10 +572,9 @@ List<Bindings> onBindingsStart(List<Bindings> bindings) { @@ -577,10 +572,9 @@ List<Bindings> onBindingsStart(List<Bindings> bindings) {
577 } 572 }
578 ``` 573 ```
579 574
580 -### OnPageBuildStart 575 +### onPageBuildStart
581 576
582 -This function will be called right after the Bindings are initialize.  
583 -Here you can do something after that you created the bindings and before creating the page widget. 577 +onPageBuildStart関数は、Bindingsが初期化された直後、ページWidetが作成される前に実行されます。
584 578
585 ```dart 579 ```dart
586 GetPageBuilder onPageBuildStart(GetPageBuilder page) { 580 GetPageBuilder onPageBuildStart(GetPageBuilder page) {
@@ -589,51 +583,51 @@ GetPageBuilder onPageBuildStart(GetPageBuilder page) { @@ -589,51 +583,51 @@ GetPageBuilder onPageBuildStart(GetPageBuilder page) {
589 } 583 }
590 ``` 584 ```
591 585
592 -### OnPageBuilt 586 +### onPageBuilt
593 587
594 -This function will be called right after the GetPage.page function is called and will give you the result of the function. and take the widget that will be showed. 588 +onPageBuilt関数は、GetPage.page(ページのビルダー)が呼び出された直後に実行され、表示されるWidgetを結果として受け取ることができます。
595 589
596 -### OnPageDispose 590 +### onPageDispose
597 591
598 -This function will be called right after disposing all the related objects (Controllers, views, ...) of the page. 592 +onPageDispose関数は、ページに関するすべてのオブジェクト(Controller、Viewなど)が破棄された直後に実行されます。
599 593
600 -## Other Advanced APIs 594 +## その他API
601 595
602 ```dart 596 ```dart
603 -// give the current args from currentScreen 597 +// 現在の画面に渡されているargs(引数)を取得
604 Get.arguments 598 Get.arguments
605 599
606 -// give name of previous route 600 +// 直前のRouteの名前("/" など)を取得
607 Get.previousRoute 601 Get.previousRoute
608 602
609 -// give the raw route to access for example, rawRoute.isFirst() 603 +// 現在のRouteオブジェクトを取得
610 Get.rawRoute 604 Get.rawRoute
611 605
612 -// give access to Routing API from GetObserver 606 +// GetObserverからRoutingを取得
613 Get.routing 607 Get.routing
614 608
615 -// check if snackbar is open 609 +// SnackBarが開いているかチェック
616 Get.isSnackbarOpen 610 Get.isSnackbarOpen
617 611
618 -// check if dialog is open 612 +// Dialogが開いているかチェック
619 Get.isDialogOpen 613 Get.isDialogOpen
620 614
621 -// check if bottomsheet is open 615 +// BottomSheetが開いているかチェック
622 Get.isBottomSheetOpen 616 Get.isBottomSheetOpen
623 617
624 -// remove one route. 618 +// Routeを削除
625 Get.removeRoute() 619 Get.removeRoute()
626 620
627 -// back repeatedly until the predicate returns true. 621 +// 引数のRoutePredicateがtrueを返すまで画面を戻る
628 Get.until() 622 Get.until()
629 623
630 -// go to next route and remove all the previous routes until the predicate returns true. 624 +// 引数で指定したRouteに進み、RoutePredicateがtrueを返すまで画面を戻る
631 Get.offUntil() 625 Get.offUntil()
632 626
633 -// go to next named route and remove all the previous routes until the predicate returns true. 627 +// 引数で指定した名前付きRouteに進み、RoutePredicateがtrueを返すまで画面を戻る
634 Get.offNamedUntil() 628 Get.offNamedUntil()
635 629
636 -//Check in what platform the app is running 630 +// アプリがどのプラットフォームで実行されているかのチェック
637 GetPlatform.isAndroid 631 GetPlatform.isAndroid
638 GetPlatform.isIOS 632 GetPlatform.isIOS
639 GetPlatform.isMacOS 633 GetPlatform.isMacOS
@@ -641,97 +635,96 @@ GetPlatform.isWindows @@ -641,97 +635,96 @@ GetPlatform.isWindows
641 GetPlatform.isLinux 635 GetPlatform.isLinux
642 GetPlatform.isFuchsia 636 GetPlatform.isFuchsia
643 637
644 -//Check the device type 638 +// アプリがどのデバイスで実行されているかのチェック
645 GetPlatform.isMobile 639 GetPlatform.isMobile
646 GetPlatform.isDesktop 640 GetPlatform.isDesktop
647 -//All platforms are supported independently in web!  
648 -//You can tell if you are running inside a browser  
649 -//on Windows, iOS, OSX, Android, etc. 641 +// プラットフォームとデバイスのチェックは独立
  642 +// 同じOSでもウェブで実行されているのか、ネイティブで実行されているのか区別
650 GetPlatform.isWeb 643 GetPlatform.isWeb
651 644
652 645
653 -// Equivalent to : MediaQuery.of(context).size.height,  
654 -// but immutable. 646 +// MediaQuery.of(context).size.height と同じ
  647 +// ただしimmutable
655 Get.height 648 Get.height
656 Get.width 649 Get.width
657 650
658 -// Gives the current context of the Navigator. 651 +// Navigatorの現在のcontextを取得
659 Get.context 652 Get.context
660 653
661 -// Gives the context of the snackbar/dialog/bottomsheet in the foreground, anywhere in your code.  
662 -Get.contextOverlay 654 +// SnackBar/Dialog/BottomSheet などフォアグラウンドのcontextを取得
  655 +Get.overlayContext
663 656
664 -// Note: the following methods are extensions on context. Since you  
665 -// have access to context in any place of your UI, you can use it anywhere in the UI code 657 +// 注: 以降のメソッドはcontextの拡張メソッドです。
  658 +// contextと同じくUIのどこからでもアクセスできます。
666 659
667 -// If you need a changeable height/width (like Desktop or browser windows that can be scaled) you will need to use context. 660 +// ウィンドウサイズの変更などに合わせて変わる height/width を取得
668 context.width 661 context.width
669 context.height 662 context.height
670 663
671 -// Gives you the power to define half the screen, a third of it and so on.  
672 -// Useful for responsive applications.  
673 -// param dividedBy (double) optional - default: 1  
674 -// param reducedBy (double) optional - default: 0 664 +// 画面の半分のサイズ,1/3のサイズなどを取得
  665 +// レスポンシブなデザインの場合に便利
  666 +// オプションのパラメーター dividedBy で割る数を指定
  667 +// オプションのパラメーター reducedBy でパーセンテージを指定
675 context.heightTransformer() 668 context.heightTransformer()
676 context.widthTransformer() 669 context.widthTransformer()
677 670
678 -/// Similar to MediaQuery.of(context).size 671 +/// MediaQuery.of(context).size とほぼ同じ
679 context.mediaQuerySize() 672 context.mediaQuerySize()
680 673
681 -/// Similar to MediaQuery.of(context).padding 674 +/// MediaQuery.of(context).padding とほぼ同じ
682 context.mediaQueryPadding() 675 context.mediaQueryPadding()
683 676
684 -/// Similar to MediaQuery.of(context).viewPadding 677 +/// MediaQuery.of(context).viewPadding とほぼ同じ
685 context.mediaQueryViewPadding() 678 context.mediaQueryViewPadding()
686 679
687 -/// Similar to MediaQuery.of(context).viewInsets; 680 +/// MediaQuery.of(context).viewInsets とほぼ同じ
688 context.mediaQueryViewInsets() 681 context.mediaQueryViewInsets()
689 682
690 -/// Similar to MediaQuery.of(context).orientation; 683 +/// MediaQuery.of(context).orientation とほぼ同じ
691 context.orientation() 684 context.orientation()
692 685
693 -/// Check if device is on landscape mode 686 +/// デバイスがランドスケープ(横長)モードかどうかチェック
694 context.isLandscape() 687 context.isLandscape()
695 688
696 -/// Check if device is on portrait mode 689 +/// デバイスがポートレート(縦長)モードかどうかチェック
697 context.isPortrait() 690 context.isPortrait()
698 691
699 -/// Similar to MediaQuery.of(context).devicePixelRatio; 692 +/// MediaQuery.of(context).devicePixelRatio とほぼ同じ
700 context.devicePixelRatio() 693 context.devicePixelRatio()
701 694
702 -/// Similar to MediaQuery.of(context).textScaleFactor; 695 +/// MediaQuery.of(context).textScaleFactor とほぼ同じ
703 context.textScaleFactor() 696 context.textScaleFactor()
704 697
705 -/// Get the shortestSide from screen 698 +/// 画面の短辺の長さを取得
706 context.mediaQueryShortestSide() 699 context.mediaQueryShortestSide()
707 700
708 -/// True if width be larger than 800 701 +/// 画面の横幅が800より大きい場合にtrueを返す
709 context.showNavbar() 702 context.showNavbar()
710 703
711 -/// True if the shortestSide is smaller than 600p 704 +/// 画面の短辺が600より小さい場合にtrueを返す
712 context.isPhone() 705 context.isPhone()
713 706
714 -/// True if the shortestSide is largest than 600p 707 +/// 画面の短辺が600より小さい場合にtrueを返す
715 context.isSmallTablet() 708 context.isSmallTablet()
716 709
717 -/// True if the shortestSide is largest than 720p 710 +/// 画面の短辺が720より大きい場合にtrueを返す
718 context.isLargeTablet() 711 context.isLargeTablet()
719 712
720 -/// True if the current device is Tablet 713 +/// デバイスがタブレットの場合にtrueを返す
721 context.isTablet() 714 context.isTablet()
722 715
723 -/// Returns a value<T> according to the screen size  
724 -/// can give value for:  
725 -/// watch: if the shortestSide is smaller than 300  
726 -/// mobile: if the shortestSide is smaller than 600  
727 -/// tablet: if the shortestSide is smaller than 1200  
728 -/// desktop: if width is largest than 1200 716 +/// 画面サイズに合わせて value<T> を返す
  717 +/// たとえば:
  718 +/// 短辺が300より小さい → watchパラメーターの値を返す
  719 +/// 短辺が600より小さい → mobileパラメーターの値を返す
  720 +/// 短辺が1200より小さい → tabletパラメーターの値を返す
  721 +/// 横幅が1200より大きい → desktopパラメーターの値を返す
729 context.responsiveValue<T>() 722 context.responsiveValue<T>()
730 ``` 723 ```
731 724
732 -### Optional Global Settings and Manual configurations 725 +### オプションのグローバル設定と手動設定
733 726
734 -GetMaterialApp configures everything for you, but if you want to configure Get manually. 727 +GetMaterialApp はすべてあなたの代わりに設定してくれますが、手動で設定を施したい場合は MaterialApp の navigatorKey と navigatorObservers の値を指定してください。
735 728
736 ```dart 729 ```dart
737 MaterialApp( 730 MaterialApp(
@@ -740,19 +733,18 @@ MaterialApp( @@ -740,19 +733,18 @@ MaterialApp(
740 ); 733 );
741 ``` 734 ```
742 735
743 -You will also be able to use your own Middleware within `GetObserver`, this will not influence anything. 736 +`GetObserver`内で独自のミドルウェアを使用することもできます。これは他に影響を及ぼすことはありません。
744 737
745 ```dart 738 ```dart
746 MaterialApp( 739 MaterialApp(
747 navigatorKey: Get.key, 740 navigatorKey: Get.key,
748 navigatorObservers: [ 741 navigatorObservers: [
749 - GetObserver(MiddleWare.observer) // Here 742 + GetObserver(MiddleWare.observer) // ここ
750 ], 743 ],
751 ); 744 );
752 ``` 745 ```
753 746
754 -You can create _Global Settings_ for `Get`. Just add `Get.config` to your code before pushing any route.  
755 -Or do it directly in your `GetMaterialApp` 747 +`Get` クラスに_グローバル設定_を施すことができます。Routeをプッシュする前のコードに `Get.config` を追加するだけです。もしくは、`GetMaterialApp` 内で直接設定することもできます。
756 748
757 ```dart 749 ```dart
758 GetMaterialApp( 750 GetMaterialApp(
@@ -771,9 +763,8 @@ Get.config( @@ -771,9 +763,8 @@ Get.config(
771 ) 763 )
772 ``` 764 ```
773 765
774 -You can optionally redirect all the logging messages from `Get`.  
775 -If you want to use your own, favourite logging package,  
776 -and want to capture the logs there: 766 +オプションで、すべてのログメッセージを `Get` からリダイレクトさせることができます。
  767 +好きなロギングのパッケージを使ってログを取得したい場合はこのようにしてください。
777 768
778 ```dart 769 ```dart
779 GetMaterialApp( 770 GetMaterialApp(
@@ -782,14 +773,14 @@ GetMaterialApp( @@ -782,14 +773,14 @@ GetMaterialApp(
782 ); 773 );
783 774
784 void localLogWriter(String text, {bool isError = false}) { 775 void localLogWriter(String text, {bool isError = false}) {
785 - // pass the message to your favourite logging package here  
786 - // please note that even if enableLog: false log messages will be pushed in this callback  
787 - // you get check the flag if you want through GetConfig.isLogEnable 776 + // ここでお好みのロギングパッケージにメッセージを渡してください
  777 + // enableLog: false にしても、ログメッセージはこのコールバックでプッシュされる点ご注意を
  778 + // ログが有効かどうかのチェックは Get.isLogEnable で可能
788 } 779 }
789 780
790 ``` 781 ```
791 782
792 -### Local State Widgets 783 +### ローカルステートWidget
793 784
794 These Widgets allows you to manage a single value, and keep the state ephemeral and locally. 785 These Widgets allows you to manage a single value, and keep the state ephemeral and locally.
795 We have flavours for Reactive and Simple. 786 We have flavours for Reactive and Simple.
@@ -1219,40 +1210,40 @@ GetMaterialApp( @@ -1219,40 +1210,40 @@ GetMaterialApp(
1219 1210
1220 # なぜGetXなのか 1211 # なぜGetXなのか
1221 1212
1222 -1- Many times after a Flutter update, many of your packages will break. Sometimes compilation errors happen, errors often appear that there are still no answers about, and the developer needs to know where the error came from, track the error, only then try to open an issue in the corresponding repository, and see its problem solved. Get centralizes the main resources for development (State, dependency and route management), allowing you to add a single package to your pubspec, and start working. After a Flutter update, the only thing you need to do is update the Get dependency, and get to work. Get also resolves compatibility issues. How many times a version of a package is not compatible with the version of another, because one uses a dependency in one version, and the other in another version? This is also not a concern using Get, as everything is in the same package and is fully compatible. 1213 +1- Flutterのアップデートが重なると、せっかく作ったパッケージがうまく動かなくなることがあります。コンパイルエラーを起こしたり、その時点で解決方法がないエラーが発生したり。開発者はそのエラーがどこから来たのか把握するために問題の追跡をし、該当リポジトリにissueを提起し、問題が解決されるのを見届ける必要があります。Getは開発に必要な主要リソース(状態管理、依存オブジェクトの管理、Route管理)を一元化し、Pubspecにパッケージを1つ追加するだけでコーディングを開始することができます。Flutterのアップデート後に必要なことは、Getも併せてアップデートすることだけです。それですぐに作業を再開できます。またGetはパッケージ間の互換性の問題も解消します。互いに依存するパッケージAの最新バージョンとBの最新バージョンの間に互換性がない、ということが何度あったでしょうか。Getを使えばすべてが同じパッケージ内にあるため、互換性の心配はありません。
1223 1214
1224 -2- Flutter is easy, Flutter is incredible, but Flutter still has some boilerplate that may be unwanted for most developers, such as `Navigator.of(context).push (context, builder [...]`. Get simplifies development. Instead of writing 8 lines of code to just call a route, you can just do it: `Get.to(Home())` and you're done, you'll go to the next page. Dynamic web urls are a really painful thing to do with Flutter currently, and that with GetX is stupidly simple. Managing states in Flutter, and managing dependencies is also something that generates a lot of discussion, as there are hundreds of patterns in the pub. But there is nothing as easy as adding a ".obs" at the end of your variable, and place your widget inside an Obx, and that's it, all updates to that variable will be automatically updated on the screen. 1215 +2- Flutterは手軽で素晴らしいフレームワークですが、`Navigator.of(context).push (context, builder [...]`のように、ほとんどの開発者にとって不要な定型文がまだ残っています。Getを使えばそのような定型文を簡素化できます。Routeを呼ぶためだけに8行のコードを書く代わりに、`Get.to(Home())`を実行すれば、次のページに行くことができるのです。またウェブURLを動的なものにするのは現在Flutterでは本当に骨の折れる作業ですが、GetXを使えば非常に簡単です。そしてFlutterにおける状態管理と依存オブジェクトの管理については、たくさんのパターンやパッケージがあるので多くの議論を生んでいます。しかしGetXのアプローチは大変簡単です。変数の最後に「.obs」を追加し、Obxクラスの中にWidgetを配置するだけで、その変数のすべての更新が自動的に画面に反映されます。
1225 1216
1226 -3- Ease without worrying about performance. Flutter's performance is already amazing, but imagine that you use a state manager, and a locator to distribute your blocs/stores/controllers/ etc. classes. You will have to manually call the exclusion of that dependency when you don't need it. But have you ever thought of simply using your controller, and when it was no longer being used by anyone, it would simply be deleted from memory? That's what GetX does. With SmartManagement, everything that is not being used is deleted from memory, and you shouldn't have to worry about anything but programming. You will be assured that you are consuming the minimum necessary resources, without even having created a logic for this. 1217 +3- パフォーマンスのことを気にせず開発できます。Flutterのパフォーマンスはそれだけで素晴らしいものですが、アプリ内で状態管理と併せて、BLoC/store/controllerなどのクラスを配布するサービスロケーターを使用することを想像してみてください。そのインスタンスが必要ないときはリソースを解放するメソッドを明示的に呼び出さなければなりません。しかし、使用されなくなったら単純に自動でメモリから削除してくれればいいのに、と考えたことはありませんか?それを実現してくれるのがGetXです。SmartManagement機能により未使用リソースはすべてメモリから削除されるので、本来のプログラミングに集中することができます。メモリ管理のためのロジックを作らなくても、常に必要最小限のリソースを使っていることが保証されるのです。
1227 1218
1228 -4- Actual decoupling. You may have heard the concept "separate the view from the business logic". This is not a peculiarity of BLoC, MVC, MVVM, and any other standard on the market has this concept. However, this concept can often be mitigated in Flutter due to the use of context.  
1229 -If you need context to find an InheritedWidget, you need it in the view, or pass the context by parameter. I particularly find this solution very ugly, and to work in teams we will always have a dependence on View's business logic. Getx is unorthodox with the standard approach, and while it does not completely ban the use of StatefulWidgets, InitState, etc., it always has a similar approach that can be cleaner. Controllers have life cycles, and when you need to make an APIREST request for example, you don't depend on anything in the view. You can use onInit to initiate the http call, and when the data arrives, the variables will be populated. As GetX is fully reactive (really, and works under streams), once the items are filled, all widgets that use that variable will be automatically updated in the view. This allows people with UI expertise to work only with widgets, and not have to send anything to business logic other than user events (like clicking a button), while people working with business logic will be free to create and test the business logic separately. 1219 +4- コードのデカップリング(分離)がしやすい。「Viewをビジネスロジックから分離する」というコンセプトを聞いたことがあるかもしれません。これはなにもBLoC、MVC、MVVMに限ったことではなく、どのアーキテクチャパターンにもこのコンセプトが底流にあると言っていいでしょう。しかし、Flutterではcontextの使用によりこのコンセプトが弱まってしまうことがあります。
  1220 +InheritedWidgetを参照するためにcontextが必要なとき、viewの中でそれを使用するか、パラメータとしてcontextを渡しますよね?私はこの方法は美しくないと感じます。特にチームで仕事をする場合において、常にView内のビジネスロジックに依存しなければならないなんて。GetXのアプローチは標準的なそれとは異質のもので、StatefulWidgetやinitStateなどの使用を禁止しているわけではありませんが、それよりもっとすっきり書ける類似のアプローチを備えています。controller自身にライフサイクルがあるため、たとえばREST APIのリクエストを行うときも、Viewの中の何かに依存するということがありません。controllerのライフサイクルの一つである onInit を使用してhttpを呼び出し、データが到着すると変数にセットされます。GetXはフルリアクティブなので(Streamが根底にあります)、インスタンス変数が値で埋まれば、その変数を使用するすべてのWidgetが自動的に更新されます。これにより、UIの専門家はWidgetの構築に注力することができ、ボタンクリックなどのユーザーイベント以外のものをビジネスロジックに渡す必要がなくなります。その一方で、ビジネスロジックを扱う人はビジネスロジックだけに集中して、個別テストを簡単に行うことができます。
1230 1221
1231 -This library will always be updated and implementing new features. Feel free to offer PRs and contribute to them. 1222 +このGetXライブラリは今後も更新され続け、新しい機能を実装していきます。気軽にプルリクエストを出していただき、ライブラリの成長に貢献していただければ幸いです。
1232 1223
1233 -# Community 1224 +# コミュニティ
1234 1225
1235 -## Community channels 1226 +## コミュニティチャンネル
1236 1227
1237 -GetX has a highly active and helpful community. If you have questions, or would like any assistance regarding the use of this framework, please join our community channels, your question will be answered more quickly, and it will be the most suitable place. This repository is exclusive for opening issues, and requesting resources, but feel free to be part of GetX Community. 1228 +GetXコミュニティは非常に活発で有益な情報であふれています。ご質問がある場合や、このフレームワークの使用に関して支援が必要な場合は、ぜひコミュニティチャンネルにご参加ください。このリポジトリは、issueの提起およびリクエスト専用ですが、気軽にコミュニティにご参加いただければ幸いです。
1238 1229
1239 | **Slack** | **Discord** | **Telegram** | 1230 | **Slack** | **Discord** | **Telegram** |
1240 | :-------------------------------------------------------------------------------------------------------------------------- | :-------------------------------------------------------------------------------------------------------------------------- | :-------------------------------------------------------------------------------------------------------------------- | 1231 | :-------------------------------------------------------------------------------------------------------------------------- | :-------------------------------------------------------------------------------------------------------------------------- | :-------------------------------------------------------------------------------------------------------------------- |
1241 | [![Get on Slack](https://img.shields.io/badge/slack-join-orange.svg)](https://communityinviter.com/apps/getxworkspace/getx) | [![Discord Shield](https://img.shields.io/discord/722900883784073290.svg?logo=discord)](https://discord.com/invite/9Hpt99N) | [![Telegram](https://img.shields.io/badge/chat-on%20Telegram-blue.svg)](https://t.me/joinchat/PhdbJRmsZNpAqSLJL6bH7g) | 1232 | [![Get on Slack](https://img.shields.io/badge/slack-join-orange.svg)](https://communityinviter.com/apps/getxworkspace/getx) | [![Discord Shield](https://img.shields.io/discord/722900883784073290.svg?logo=discord)](https://discord.com/invite/9Hpt99N) | [![Telegram](https://img.shields.io/badge/chat-on%20Telegram-blue.svg)](https://t.me/joinchat/PhdbJRmsZNpAqSLJL6bH7g) |
1242 1233
1243 -## How to contribute 1234 +## 貢献方法
1244 1235
1245 -_Want to contribute to the project? We will be proud to highlight you as one of our collaborators. Here are some points where you can contribute and make Get (and Flutter) even better._ 1236 +_GetXプロジェクトに貢献してみませんか?あなたをコントリビューターの一人としてご紹介できるのを楽しみにしています。GetおよびFlutterをより良いものにするためのコントリビュート例をご紹介します。_
1246 1237
1247 -- Helping to translate the readme into other languages.  
1248 -- Adding documentation to the readme (a lot of Get's functions haven't been documented yet).  
1249 -- Write articles or make videos teaching how to use Get (they will be inserted in the Readme and in the future in our Wiki).  
1250 -- Offering PRs for code/tests.  
1251 -- Including new functions. 1238 +- Readmeの多言語対応。
  1239 +- Readmeの追加ドキュメント執筆 (ドキュメントで触れられていない機能がまだまだたくさんあります)。
  1240 +- Getの使い方を紹介する記事やビデオの作成(Readmeに掲載させていただきます。将来的にWikiができればそこにも掲載予定)。
  1241 +- コードやテストのプルリクエスト。
  1242 +- 新機能の提案。
1252 1243
1253 -Any contribution is welcome! 1244 +どのような形の貢献であれ歓迎しますので、ぜひコミュニティにご参加ください!
1254 1245
1255 -## Articles and videos 1246 +## GetXに関する記事とビデオ
1256 1247
1257 - [Flutter Getx EcoSystem package for arabic people](https://www.youtube.com/playlist?list=PLV1fXIAyjeuZ6M8m56zajMUwu4uE3-SL0) - Tutorial by [Pesa Coder](https://github.com/UsamaElgendy). 1248 - [Flutter Getx EcoSystem package for arabic people](https://www.youtube.com/playlist?list=PLV1fXIAyjeuZ6M8m56zajMUwu4uE3-SL0) - Tutorial by [Pesa Coder](https://github.com/UsamaElgendy).
1258 - [Dynamic Themes in 3 lines using GetX™](https://medium.com/swlh/flutter-dynamic-themes-in-3-lines-c3b375f292e3) - Tutorial by [Rod Brown](https://github.com/RodBr). 1249 - [Dynamic Themes in 3 lines using GetX™](https://medium.com/swlh/flutter-dynamic-themes-in-3-lines-c3b375f292e3) - Tutorial by [Rod Brown](https://github.com/RodBr).
  1 +# Dependency Management
  2 +- [Dependency Management](#dependency-management)
  3 + - [Instancing methods](#instancing-methods)
  4 + - [Get.put()](#getput)
  5 + - [Get.lazyPut](#getlazyput)
  6 + - [Get.putAsync](#getputasync)
  7 + - [Get.create](#getcreate)
  8 + - [Using instantiated methods/classes](#using-instantiated-methodsclasses)
  9 + - [Specifying an alternate instance](#specifying-an-alternate-instance)
  10 + - [Differences between methods](#differences-between-methods)
  11 + - [Bindings](#bindings)
  12 + - [Bindings class](#bindings-class)
  13 + - [BindingsBuilder](#bindingsbuilder)
  14 + - [SmartManagement](#smartmanagement)
  15 + - [How to change](#how-to-change)
  16 + - [SmartManagement.full](#smartmanagementfull)
  17 + - [SmartManagement.onlyBuilders](#smartmanagementonlybuilders)
  18 + - [SmartManagement.keepFactory](#smartmanagementkeepfactory)
  19 + - [How bindings work under the hood](#how-bindings-work-under-the-hood)
  20 + - [Notes](#notes)
  21 +
  22 +Get has a simple and powerful dependency manager that allows you to retrieve the same class as your Bloc or Controller with just 1 lines of code, no Provider context, no inheritedWidget:
  23 +
  24 +```dart
  25 +Controller controller = Get.put(Controller()); // Rather Controller controller = Controller();
  26 +```
  27 +
  28 +Instead of instantiating your class within the class you are using, you are instantiating it within the Get instance, which will make it available throughout your App.
  29 +So you can use your controller (or Bloc class) normally
  30 +
  31 +- Note: If you are using Get's State Manager, pay more attention to the [Bindings](#bindings) api, which will make easier to connect your view to your controller.
  32 +- Note²: Get dependency management is decloupled from other parts of the package, so if for example your app is already using a state manager (any one, it doesn't matter), you don't need to change that, you can use this dependency injection manager with no problems at all
  33 +
  34 +## Instancing methods
  35 +The methods and it's configurable parameters are:
  36 +
  37 +### Get.put()
  38 +
  39 +The most common way of inserting a dependency. Good for the controllers of your views for example.
  40 +
  41 +```dart
  42 +Get.put<SomeClass>(SomeClass());
  43 +Get.put<LoginController>(LoginController(), permanent: true);
  44 +Get.put<ListItemController>(ListItemController, tag: "some unique string");
  45 +```
  46 +
  47 +This is all options you can set when using put:
  48 +```dart
  49 +Get.put<S>(
  50 + // mandatory: the class that you want to get to save, like a controller or anything
  51 + // note: "S" means that it can be a class of any type
  52 + S dependency
  53 +
  54 + // optional: this is for when you want multiple classess that are of the same type
  55 + // since you normally get a class by using Get.find<Controller>(),
  56 + // you need to use tag to tell which instance you need
  57 + // must be unique string
  58 + String tag,
  59 +
  60 + // optional: by default, get will dispose instances after they are not used anymore (example,
  61 + // the controller of a view that is closed), but you might need that the instance
  62 + // to be kept there throughout the entire app, like an instance of sharedPreferences or something
  63 + // so you use this
  64 + // defaults to false
  65 + bool permanent = false,
  66 +
  67 + // optional: allows you after using an abstract class in a test, replace it with another one and follow the test.
  68 + // defaults to false
  69 + bool overrideAbstract = false,
  70 +
  71 + // optional: allows you to create the dependency using function instead of the dependency itself.
  72 + // this one is not commonly used
  73 + InstanceBuilderCallback<S> builder,
  74 +)
  75 +```
  76 +
  77 +### Get.lazyPut
  78 +It is possible to lazyLoad a dependency so that it will be instantiated only when is used. Very useful for computational expensive classes or if you want to instantiate several classes in just one place (like in a Bindings class) and you know you will not gonna use that class at that time.
  79 +
  80 +```dart
  81 +/// ApiMock will only be called when someone uses Get.find<ApiMock> for the first time
  82 +Get.lazyPut<ApiMock>(() => ApiMock());
  83 +
  84 +Get.lazyPut<FirebaseAuth>(
  85 + () {
  86 + // ... some logic if needed
  87 + return FirebaseAuth();
  88 + },
  89 + tag: Math.random().toString(),
  90 + fenix: true
  91 +)
  92 +
  93 +Get.lazyPut<Controller>( () => Controller() )
  94 +```
  95 +
  96 +This is all options you can set when using lazyPut:
  97 +```dart
  98 +Get.lazyPut<S>(
  99 + // mandatory: a method that will be executed when your class is called for the first time
  100 + InstanceBuilderCallback builder,
  101 +
  102 + // optional: same as Get.put(), it is used for when you want multiple different instance of a same class
  103 + // must be unique
  104 + String tag,
  105 +
  106 + // optional: It is similar to "permanent", the difference is that the instance is discarded when
  107 + // is not being used, but when it's use is needed again, Get will recreate the instance
  108 + // just the same as "SmartManagement.keepFactory" in the bindings api
  109 + // defaults to false
  110 + bool fenix = false
  111 +
  112 +)
  113 +```
  114 +
  115 +### Get.putAsync
  116 +If you want to register an asynchronous instance, you can use `Get.putAsync`:
  117 +
  118 +```dart
  119 +Get.putAsync<SharedPreferences>(() async {
  120 + final prefs = await SharedPreferences.getInstance();
  121 + await prefs.setInt('counter', 12345);
  122 + return prefs;
  123 +});
  124 +
  125 +Get.putAsync<YourAsyncClass>( () async => await YourAsyncClass() )
  126 +```
  127 +
  128 +This is all options you can set when using putAsync:
  129 +```dart
  130 +Get.putAsync<S>(
  131 +
  132 + // mandatory: an async method that will be executed to instantiate your class
  133 + AsyncInstanceBuilderCallback<S> builder,
  134 +
  135 + // optional: same as Get.put(), it is used for when you want multiple different instance of a same class
  136 + // must be unique
  137 + String tag,
  138 +
  139 + // optional: same as in Get.put(), used when you need to maintain that instance alive in the entire app
  140 + // defaults to false
  141 + bool permanent = false
  142 +)
  143 +```
  144 +
  145 +### Get.create
  146 +
  147 +This one is tricky. A detailed explanation of what this is and the differences between the other one can be found on [Differences between methods:](#differences-between-methods) section
  148 +
  149 +```dart
  150 +Get.Create<SomeClass>(() => SomeClass());
  151 +Get.Create<LoginController>(() => LoginController());
  152 +```
  153 +
  154 +This is all options you can set when using create:
  155 +
  156 +```dart
  157 +Get.create<S>(
  158 + // required: a function that returns a class that will be "fabricated" every
  159 + // time `Get.find()` is called
  160 + // Example: Get.create<YourClass>(() => YourClass())
  161 + FcBuilderFunc<S> builder,
  162 +
  163 + // optional: just like Get.put(), but it is used when you need multiple instances
  164 + // of a of a same class
  165 + // Useful in case you have a list that each item need it's own controller
  166 + // needs to be a unique string. Just change from tag to name
  167 + String name,
  168 +
  169 + // optional: just like int`Get.put()`, it is for when you need to keep the
  170 + // instance alive thoughout the entire app. The difference is in Get.create
  171 + // permanent is true by default
  172 + bool permanent = true
  173 +```
  174 +
  175 +## Using instantiated methods/classes
  176 +
  177 +Imagine that you have navigated through numerous routes, and you need a data that was left behind in your controller, you would need a state manager combined with the Provider or Get_it, correct? Not with Get. You just need to ask Get to "find" for your controller, you don't need any additional dependencies:
  178 +
  179 +```dart
  180 +final controller = Get.find<Controller>();
  181 +// OR
  182 +Controller controller = Get.find();
  183 +
  184 +// Yes, it looks like Magic, Get will find your controller, and will deliver it to you.
  185 +// You can have 1 million controllers instantiated, Get will always give you the right controller.
  186 +```
  187 +
  188 +And then you will be able to recover your controller data that was obtained back there:
  189 +
  190 +```dart
  191 +Text(controller.textFromApi);
  192 +```
  193 +
  194 +Since the returned value is a normal class, you can do anything you want:
  195 +```dart
  196 +int count = Get.find<SharedPreferences>().getInt('counter');
  197 +print(count); // out: 12345
  198 +```
  199 +
  200 +To remove an instance of Get:
  201 +
  202 +```dart
  203 +Get.delete<Controller>(); //usually you don't need to do this because GetX already delete unused controllers
  204 +```
  205 +
  206 +## Specifying an alternate instance
  207 +
  208 +A currently inserted instance can be replaced with a similar or extended class instance by using the `replace` or `lazyReplace` method. This can then be retrieved by using the original class.
  209 +
  210 +```dart
  211 +abstract class BaseClass {}
  212 +class ParentClass extends BaseClass {}
  213 +
  214 +class ChildClass extends ParentClass {
  215 + bool isChild = true;
  216 +}
  217 +
  218 +
  219 +Get.put<BaseClass>(ParentClass());
  220 +
  221 +Get.replace<BaseClass>(ChildClass());
  222 +
  223 +final instance = Get.find<BaseClass>();
  224 +print(instance is ChildClass); //true
  225 +
  226 +
  227 +class OtherClass extends BaseClass {}
  228 +Get.lazyReplace<BaseClass>(() => OtherClass());
  229 +
  230 +final instance = Get.find<BaseClass>();
  231 +print(instance is ChildClass); // false
  232 +print(instance is OtherClass); //true
  233 +```
  234 +
  235 +## Differences between methods
  236 +
  237 +First, let's of the `fenix` of Get.lazyPut and the `permanent` of the other methods.
  238 +
  239 +The fundamental difference between `permanent` and `fenix` is how you want to store your instances.
  240 +
  241 +Reinforcing: by default, GetX deletes instances when they are not in use.
  242 +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.offNamed()`) the controller 1 lost its use so it will be erased.
  243 +
  244 +But if you want to opt for using `permanent:true`, then the controller will not be lost in this transition - which is very useful for services that you want to keep alive throughout the entire application.
  245 +
  246 +`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 it, it will "recreate from the ashes" a new instance.
  247 +
  248 +Proceeding with the differences between methods:
  249 +
  250 +- Get.put and Get.putAsync follows the same creation order, with the difference that the second uses an asynchronous method: those two methods creates and initializes 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 purpose 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.
  251 +
  252 +- Get.create: As the name implies, it will "create" your dependency! Similar to `Get.put()`, it also calls 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.
  253 +
  254 +- 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 responsible 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.
  255 +
  256 +## Bindings
  257 +
  258 +One of the great differentials of this package, perhaps, is the possibility of full integration of the routes, state manager and dependency manager.
  259 +When a route is removed from the Stack, all controllers, variables, and instances of objects related to it are removed from memory. If you are using streams or timers, they will be closed automatically, and you don't have to worry about any of that.
  260 +In version 2.10 Get completely implemented the Bindings API.
  261 +Now you no longer need to use the init method. You don't even have to type your controllers if you don't want to. You can start your controllers and services in the appropriate place for that.
  262 +The Binding class is a class that will decouple dependency injection, while "binding" routes to the state manager and dependency manager.
  263 +This allows Get to know which screen is being displayed when a particular controller is used and to know where and how to dispose of it.
  264 +In addition, the Binding class will allow you to have SmartManager configuration control. You can configure the dependencies to be arranged when removing a route from the stack, or when the widget that used it is laid out, or neither. You will have intelligent dependency management working for you, but even so, you can configure it as you wish.
  265 +
  266 +### Bindings class
  267 +
  268 +- Create a class and implements Binding
  269 +
  270 +```dart
  271 +class HomeBinding implements Bindings {}
  272 +```
  273 +
  274 +Your IDE will automatically ask you to override the "dependencies" method, and you just need to click on the lamp, override the method, and insert all the classes you are going to use on that route:
  275 +
  276 +```dart
  277 +class HomeBinding implements Bindings {
  278 + @override
  279 + void dependencies() {
  280 + Get.lazyPut<HomeController>(() => HomeController());
  281 + Get.put<Service>(()=> Api());
  282 + }
  283 +}
  284 +
  285 +class DetailsBinding implements Bindings {
  286 + @override
  287 + void dependencies() {
  288 + Get.lazyPut<DetailsController>(() => DetailsController());
  289 + }
  290 +}
  291 +```
  292 +
  293 +Now you just need to inform your route, that you will use that binding to make the connection between route manager, dependencies and states.
  294 +
  295 +- Using named routes:
  296 +
  297 +```dart
  298 +getPages: [
  299 + GetPage(
  300 + name: '/',
  301 + page: () => HomeView(),
  302 + binding: HomeBinding(),
  303 + ),
  304 + GetPage(
  305 + name: '/details',
  306 + page: () => DetailsView(),
  307 + binding: DetailsBinding(),
  308 + ),
  309 +];
  310 +```
  311 +
  312 +- Using normal routes:
  313 +
  314 +```dart
  315 +Get.to(Home(), binding: HomeBinding());
  316 +Get.to(DetailsView(), binding: DetailsBinding())
  317 +```
  318 +
  319 +There, you don't have to worry about memory management of your application anymore, Get will do it for you.
  320 +
  321 +The Binding class is called when a route is called, you can create an "initialBinding in your GetMaterialApp to insert all the dependencies that will be created.
  322 +
  323 +```dart
  324 +GetMaterialApp(
  325 + initialBinding: SampleBind(),
  326 + home: Home(),
  327 +);
  328 +```
  329 +
  330 +### BindingsBuilder
  331 +
  332 +The default way of creating a binding is by creating a class that implements Bindings.
  333 +But alternatively, you can use `BindingsBuilder` callback so that you can simply use a function to instantiate whatever you desire.
  334 +
  335 +Example:
  336 +
  337 +```dart
  338 +getPages: [
  339 + GetPage(
  340 + name: '/',
  341 + page: () => HomeView(),
  342 + binding: BindingsBuilder(() {
  343 + Get.lazyPut<ControllerX>(() => ControllerX());
  344 + Get.put<Service>(()=> Api());
  345 + }),
  346 + ),
  347 + GetPage(
  348 + name: '/details',
  349 + page: () => DetailsView(),
  350 + binding: BindingsBuilder(() {
  351 + Get.lazyPut<DetailsController>(() => DetailsController());
  352 + }),
  353 + ),
  354 +];
  355 +```
  356 +
  357 +That way you can avoid to create one Binding class for each route making this even simpler.
  358 +
  359 +Both ways of doing work perfectly fine and we want you to use what most suit your tastes.
  360 +
  361 +### SmartManagement
  362 +
  363 +GetX by default disposes unused controllers from memory, even if a failure occurs and a widget that uses it is not properly disposed.
  364 +This is what is called the `full` mode of dependency management.
  365 +But if you want to change the way GetX controls the disposal of classes, you have `SmartManagement` class that you can set different behaviors.
  366 +
  367 +#### How to change
  368 +
  369 +If you want to change this config (which you usually don't need) this is the way:
  370 +
  371 +```dart
  372 +void main () {
  373 + runApp(
  374 + GetMaterialApp(
  375 + smartManagement: SmartManagement.onlyBuilders //here
  376 + home: Home(),
  377 + )
  378 + )
  379 +}
  380 +```
  381 +
  382 +#### SmartManagement.full
  383 +
  384 +It is the default one. Dispose classes that are not being used and were not set to be permanent. In the majority of the cases you will want to keep this config untouched. If you new to GetX then don't change this.
  385 +
  386 +#### SmartManagement.onlyBuilders
  387 +With this option, only controllers started in `init:` or loaded into a Binding with `Get.lazyPut()` will be disposed.
  388 +
  389 +If you use `Get.put()` or `Get.putAsync()` or any other approach, SmartManagement will not have permissions to exclude this dependency.
  390 +
  391 +With the default behavior, even widgets instantiated with "Get.put" will be removed, unlike SmartManagement.onlyBuilders.
  392 +
  393 +#### SmartManagement.keepFactory
  394 +
  395 +Just like SmartManagement.full, it will remove it's dependencies when it's not being used anymore. However, it will keep their factory, which means it will recreate the dependency if you need that instance again.
  396 +
  397 +### How bindings work under the hood
  398 +Bindings creates transitory factories, which are created the moment you click to go to another screen, and will be destroyed as soon as the screen-changing animation happens.
  399 +This happens so fast that the analyzer will not even be able to register it.
  400 +When you navigate to this screen again, a new temporary factory will be called, so this is preferable to using SmartManagement.keepFactory, but if you don't want to create Bindings, or want to keep all your dependencies on the same Binding, it will certainly help you.
  401 +Factories take up little memory, they don't hold instances, but a function with the "shape" of that class you want.
  402 +This has a very low cost in memory, but since the purpose of this lib is to get the maximum performance possible using the minimum resources, Get removes even the factories by default.
  403 +Use whichever is most convenient for you.
  404 +
  405 +## Notes
  406 +
  407 +- DO NOT USE SmartManagement.keepFactory if you are using multiple Bindings. It was designed to be used without Bindings, or with a single Binding linked in the GetMaterialApp's initialBinding.
  408 +
  409 +- Using Bindings is completely optional, if you want you can use `Get.put()` and `Get.find()` on classes that use a given controller without any problem.
  410 +However, if you work with Services or any other abstraction, I recommend using Bindings for a better organization.
  1 +- [Route Management](#route-management)
  2 + - [How to use](#how-to-use)
  3 + - [Navigation without named routes](#navigation-without-named-routes)
  4 + - [Navigation with named routes](#navigation-with-named-routes)
  5 + - [Send data to named Routes](#send-data-to-named-routes)
  6 + - [Dynamic urls links](#dynamic-urls-links)
  7 + - [Middleware](#middleware)
  8 + - [Navigation without context](#navigation-without-context)
  9 + - [SnackBars](#snackbars)
  10 + - [Dialogs](#dialogs)
  11 + - [BottomSheets](#bottomsheets)
  12 + - [Nested Navigation](#nested-navigation)
  13 +
  14 +# Route Management
  15 +
  16 +This is the complete explanation of all there is to Getx when the matter is route management.
  17 +
  18 +## How to use
  19 +
  20 +Add this to your pubspec.yaml file:
  21 +
  22 +```yaml
  23 +dependencies:
  24 + get:
  25 +```
  26 +
  27 +If you are going to use routes/snackbars/dialogs/bottomsheets without context, or use the high-level Get APIs, you need to simply add "Get" before your MaterialApp, turning it into GetMaterialApp and enjoy!
  28 +
  29 +```dart
  30 +GetMaterialApp( // Before: MaterialApp(
  31 + home: MyHome(),
  32 +)
  33 +```
  34 +
  35 +## Navigation without named routes
  36 +
  37 +To navigate to a new screen:
  38 +
  39 +```dart
  40 +Get.to(NextScreen());
  41 +```
  42 +
  43 +To close snackbars, dialogs, bottomsheets, or anything you would normally close with Navigator.pop(context);
  44 +
  45 +```dart
  46 +Get.back();
  47 +```
  48 +
  49 +To go to the next screen and no option to go back to the previous screen (for use in SplashScreens, login screens and etc.)
  50 +
  51 +```dart
  52 +Get.off(NextScreen());
  53 +```
  54 +
  55 +To go to the next screen and cancel all previous routes (useful in shopping carts, polls, and tests)
  56 +
  57 +```dart
  58 +Get.offAll(NextScreen());
  59 +```
  60 +
  61 +To navigate to the next route, and receive or update data as soon as you return from it:
  62 +
  63 +```dart
  64 +var data = await Get.to(Payment());
  65 +```
  66 +
  67 +on other screen, send a data for previous route:
  68 +
  69 +```dart
  70 +Get.back(result: 'success');
  71 +```
  72 +
  73 +And use it:
  74 +
  75 +ex:
  76 +
  77 +```dart
  78 +if(data == 'success') madeAnything();
  79 +```
  80 +
  81 +Don't you want to learn our syntax?
  82 +Just change the Navigator (uppercase) to navigator (lowercase), and you will have all the functions of the standard navigation, without having to use context
  83 +Example:
  84 +
  85 +```dart
  86 +
  87 +// Default Flutter navigator
  88 +Navigator.of(context).push(
  89 + context,
  90 + MaterialPageRoute(
  91 + builder: (BuildContext context) {
  92 + return HomePage();
  93 + },
  94 + ),
  95 +);
  96 +
  97 +// Get using Flutter syntax without needing context
  98 +navigator.push(
  99 + MaterialPageRoute(
  100 + builder: (_) {
  101 + return HomePage();
  102 + },
  103 + ),
  104 +);
  105 +
  106 +// Get syntax (It is much better, but you have the right to disagree)
  107 +Get.to(HomePage());
  108 +
  109 +
  110 +```
  111 +
  112 +## Navigation with named routes
  113 +
  114 +- If you prefer to navigate by namedRoutes, Get also supports this.
  115 +
  116 +To navigate to nextScreen
  117 +
  118 +```dart
  119 +Get.toNamed("/NextScreen");
  120 +```
  121 +
  122 +To navigate and remove the previous screen from the tree.
  123 +
  124 +```dart
  125 +Get.offNamed("/NextScreen");
  126 +```
  127 +
  128 +To navigate and remove all previous screens from the tree.
  129 +
  130 +```dart
  131 +Get.offAllNamed("/NextScreen");
  132 +```
  133 +
  134 +To define routes, use GetMaterialApp:
  135 +
  136 +```dart
  137 +void main() {
  138 + runApp(
  139 + GetMaterialApp(
  140 + initialRoute: '/',
  141 + getPages: [
  142 + GetPage(name: '/', page: () => MyHomePage()),
  143 + GetPage(name: '/second', page: () => Second()),
  144 + GetPage(
  145 + name: '/third',
  146 + page: () => Third(),
  147 + transition: Transition.zoom
  148 + ),
  149 + ],
  150 + )
  151 + );
  152 +}
  153 +```
  154 +
  155 +To handle navigation to non-defined routes (404 error), you can define an unknownRoute page in GetMaterialApp.
  156 +
  157 +```dart
  158 +void main() {
  159 + runApp(
  160 + GetMaterialApp(
  161 + unknownRoute: GetPage(name: '/notfound', page: () => UnknownRoutePage()),
  162 + initialRoute: '/',
  163 + getPages: [
  164 + GetPage(name: '/', page: () => MyHomePage()),
  165 + GetPage(name: '/second', page: () => Second()),
  166 + ],
  167 + )
  168 + );
  169 +}
  170 +```
  171 +
  172 +### Send data to named Routes
  173 +
  174 +Just send what you want for arguments. Get accepts anything here, whether it is a String, a Map, a List, or even a class instance.
  175 +
  176 +```dart
  177 +Get.toNamed("/NextScreen", arguments: 'Get is the best');
  178 +```
  179 +
  180 +on your class or controller:
  181 +
  182 +```dart
  183 +print(Get.arguments);
  184 +//print out: Get is the best
  185 +```
  186 +
  187 +### Dynamic urls links
  188 +
  189 +Get offer advanced dynamic urls just like on the Web. Web developers have probably already wanted this feature on Flutter, and most likely have seen a package promise this feature and deliver a totally different syntax than a URL would have on web, but Get also solves that.
  190 +
  191 +```dart
  192 +Get.offAllNamed("/NextScreen?device=phone&id=354&name=Enzo");
  193 +```
  194 +
  195 +on your controller/bloc/stateful/stateless class:
  196 +
  197 +```dart
  198 +print(Get.parameters['id']);
  199 +// out: 354
  200 +print(Get.parameters['name']);
  201 +// out: Enzo
  202 +```
  203 +
  204 +You can also receive NamedParameters with Get easily:
  205 +
  206 +```dart
  207 +void main() {
  208 + runApp(
  209 + GetMaterialApp(
  210 + initialRoute: '/',
  211 + getPages: [
  212 + GetPage(
  213 + name: '/',
  214 + page: () => MyHomePage(),
  215 + ),
  216 + GetPage(
  217 + name: '/profile/',
  218 + page: () => MyProfile(),
  219 + ),
  220 + //You can define a different page for routes with arguments, and another without arguments, but for that you must use the slash '/' on the route that will not receive arguments as above.
  221 + GetPage(
  222 + name: '/profile/:user',
  223 + page: () => UserProfile(),
  224 + ),
  225 + GetPage(
  226 + name: '/third',
  227 + page: () => Third(),
  228 + transition: Transition.cupertino
  229 + ),
  230 + ],
  231 + )
  232 + );
  233 +}
  234 +```
  235 +
  236 +Send data on route name
  237 +
  238 +```dart
  239 +Get.toNamed("/profile/34954");
  240 +```
  241 +
  242 +On second screen take the data by parameter
  243 +
  244 +```dart
  245 +print(Get.parameters['user']);
  246 +// out: 34954
  247 +```
  248 +
  249 +or send multiple parameters like this
  250 +
  251 +```dart
  252 +Get.toNamed("/profile/34954?flag=true&country=italy");
  253 +```
  254 +or
  255 +```dart
  256 +var parameters = <String, String>{"flag": "true","country": "italy",};
  257 +Get.toNamed("/profile/34954", parameters: parameters);
  258 +```
  259 +
  260 +On second screen take the data by parameters as usually
  261 +
  262 +```dart
  263 +print(Get.parameters['user']);
  264 +print(Get.parameters['flag']);
  265 +print(Get.parameters['country']);
  266 +// out: 34954 true italy
  267 +```
  268 +
  269 +
  270 +
  271 +And now, all you need to do is use Get.toNamed() to navigate your named routes, without any context (you can call your routes directly from your BLoC or Controller class), and when your app is compiled to the web, your routes will appear in the url <3
  272 +
  273 +### Middleware
  274 +
  275 +If you want to listen Get events to trigger actions, you can to use routingCallback to it
  276 +
  277 +```dart
  278 +GetMaterialApp(
  279 + routingCallback: (routing) {
  280 + if(routing.current == '/second'){
  281 + openAds();
  282 + }
  283 + }
  284 +)
  285 +```
  286 +
  287 +If you are not using GetMaterialApp, you can use the manual API to attach Middleware observer.
  288 +
  289 +```dart
  290 +void main() {
  291 + runApp(
  292 + MaterialApp(
  293 + onGenerateRoute: Router.generateRoute,
  294 + initialRoute: "/",
  295 + navigatorKey: Get.key,
  296 + navigatorObservers: [
  297 + GetObserver(MiddleWare.observer), // HERE !!!
  298 + ],
  299 + ),
  300 + );
  301 +}
  302 +```
  303 +
  304 +Create a MiddleWare class
  305 +
  306 +```dart
  307 +class MiddleWare {
  308 + static observer(Routing routing) {
  309 + /// You can listen in addition to the routes, the snackbars, dialogs and bottomsheets on each screen.
  310 + ///If you need to enter any of these 3 events directly here,
  311 + ///you must specify that the event is != Than you are trying to do.
  312 + if (routing.current == '/second' && !routing.isSnackbar) {
  313 + Get.snackbar("Hi", "You are on second route");
  314 + } else if (routing.current =='/third'){
  315 + print('last route called');
  316 + }
  317 + }
  318 +}
  319 +```
  320 +
  321 +Now, use Get on your code:
  322 +
  323 +```dart
  324 +class First extends StatelessWidget {
  325 + @override
  326 + Widget build(BuildContext context) {
  327 + return Scaffold(
  328 + appBar: AppBar(
  329 + leading: IconButton(
  330 + icon: Icon(Icons.add),
  331 + onPressed: () {
  332 + Get.snackbar("hi", "i am a modern snackbar");
  333 + },
  334 + ),
  335 + title: Text('First Route'),
  336 + ),
  337 + body: Center(
  338 + child: ElevatedButton(
  339 + child: Text('Open route'),
  340 + onPressed: () {
  341 + Get.toNamed("/second");
  342 + },
  343 + ),
  344 + ),
  345 + );
  346 + }
  347 +}
  348 +
  349 +class Second extends StatelessWidget {
  350 + @override
  351 + Widget build(BuildContext context) {
  352 + return Scaffold(
  353 + appBar: AppBar(
  354 + leading: IconButton(
  355 + icon: Icon(Icons.add),
  356 + onPressed: () {
  357 + Get.snackbar("hi", "i am a modern snackbar");
  358 + },
  359 + ),
  360 + title: Text('second Route'),
  361 + ),
  362 + body: Center(
  363 + child: ElevatedButton(
  364 + child: Text('Open route'),
  365 + onPressed: () {
  366 + Get.toNamed("/third");
  367 + },
  368 + ),
  369 + ),
  370 + );
  371 + }
  372 +}
  373 +
  374 +class Third extends StatelessWidget {
  375 + @override
  376 + Widget build(BuildContext context) {
  377 + return Scaffold(
  378 + appBar: AppBar(
  379 + title: Text("Third Route"),
  380 + ),
  381 + body: Center(
  382 + child: ElevatedButton(
  383 + onPressed: () {
  384 + Get.back();
  385 + },
  386 + child: Text('Go back!'),
  387 + ),
  388 + ),
  389 + );
  390 + }
  391 +}
  392 +```
  393 +
  394 +## Navigation without context
  395 +
  396 +### SnackBars
  397 +
  398 +To have a simple SnackBar with Flutter, you must get the context of Scaffold, or you must use a GlobalKey attached to your Scaffold
  399 +
  400 +```dart
  401 +final snackBar = SnackBar(
  402 + content: Text('Hi!'),
  403 + action: SnackBarAction(
  404 + label: 'I am a old and ugly snackbar :(',
  405 + onPressed: (){}
  406 + ),
  407 +);
  408 +// Find the Scaffold in the widget tree and use
  409 +// it to show a SnackBar.
  410 +Scaffold.of(context).showSnackBar(snackBar);
  411 +```
  412 +
  413 +With Get:
  414 +
  415 +```dart
  416 +Get.snackbar('Hi', 'i am a modern snackbar');
  417 +```
  418 +
  419 +With Get, all you have to do is call your Get.snackbar from anywhere in your code or customize it however you want!
  420 +
  421 +```dart
  422 +Get.snackbar(
  423 + "Hey i'm a Get SnackBar!", // title
  424 + "It's unbelievable! I'm using SnackBar without context, without boilerplate, without Scaffold, it is something truly amazing!", // message
  425 + icon: Icon(Icons.alarm),
  426 + shouldIconPulse: true,
  427 + onTap:(){},
  428 + barBlur: 20,
  429 + isDismissible: true,
  430 + duration: Duration(seconds: 3),
  431 +);
  432 +
  433 +
  434 + ////////// ALL FEATURES //////////
  435 + // Color colorText,
  436 + // Duration duration,
  437 + // SnackPosition snackPosition,
  438 + // Widget titleText,
  439 + // Widget messageText,
  440 + // bool instantInit,
  441 + // Widget icon,
  442 + // bool shouldIconPulse,
  443 + // double maxWidth,
  444 + // EdgeInsets margin,
  445 + // EdgeInsets padding,
  446 + // double borderRadius,
  447 + // Color borderColor,
  448 + // double borderWidth,
  449 + // Color backgroundColor,
  450 + // Color leftBarIndicatorColor,
  451 + // List<BoxShadow> boxShadows,
  452 + // Gradient backgroundGradient,
  453 + // TextButton mainButton,
  454 + // OnTap onTap,
  455 + // bool isDismissible,
  456 + // bool showProgressIndicator,
  457 + // AnimationController progressIndicatorController,
  458 + // Color progressIndicatorBackgroundColor,
  459 + // Animation<Color> progressIndicatorValueColor,
  460 + // SnackStyle snackStyle,
  461 + // Curve forwardAnimationCurve,
  462 + // Curve reverseAnimationCurve,
  463 + // Duration animationDuration,
  464 + // double barBlur,
  465 + // double overlayBlur,
  466 + // Color overlayColor,
  467 + // Form userInputForm
  468 + ///////////////////////////////////
  469 +```
  470 +
  471 +If you prefer the traditional snackbar, or want to customize it from scratch, including adding just one line (Get.snackbar makes use of a mandatory title and message), you can use
  472 +`Get.rawSnackbar();` which provides the RAW API on which Get.snackbar was built.
  473 +
  474 +### Dialogs
  475 +
  476 +To open dialog:
  477 +
  478 +```dart
  479 +Get.dialog(YourDialogWidget());
  480 +```
  481 +
  482 +To open default dialog:
  483 +
  484 +```dart
  485 +Get.defaultDialog(
  486 + onConfirm: () => print("Ok"),
  487 + middleText: "Dialog made in 3 lines of code"
  488 +);
  489 +```
  490 +
  491 +You can also use Get.generalDialog instead of showGeneralDialog.
  492 +
  493 +For all other Flutter dialog widgets, including cupertinos, you can use Get.overlayContext instead of context, and open it anywhere in your code.
  494 +For widgets that don't use Overlay, you can use Get.context.
  495 +These two contexts will work in 99% of cases to replace the context of your UI, except for cases where inheritedWidget is used without a navigation context.
  496 +
  497 +### BottomSheets
  498 +
  499 +Get.bottomSheet is like showModalBottomSheet, but don't need of context.
  500 +
  501 +```dart
  502 +Get.bottomSheet(
  503 + Container(
  504 + child: Wrap(
  505 + children: <Widget>[
  506 + ListTile(
  507 + leading: Icon(Icons.music_note),
  508 + title: Text('Music'),
  509 + onTap: () {}
  510 + ),
  511 + ListTile(
  512 + leading: Icon(Icons.videocam),
  513 + title: Text('Video'),
  514 + onTap: () {},
  515 + ),
  516 + ],
  517 + ),
  518 + )
  519 +);
  520 +```
  521 +
  522 +## Nested Navigation
  523 +
  524 +Get made Flutter's nested navigation even easier.
  525 +You don't need the context, and you will find your navigation stack by Id.
  526 +
  527 +- NOTE: Creating parallel navigation stacks can be dangerous. The ideal is not to use NestedNavigators, or to use sparingly. If your project requires it, go ahead, but keep in mind that keeping multiple navigation stacks in memory may not be a good idea for RAM consumption.
  528 +
  529 +See how simple it is:
  530 +
  531 +```dart
  532 +Navigator(
  533 + key: Get.nestedKey(1), // create a key by index
  534 + initialRoute: '/',
  535 + onGenerateRoute: (settings) {
  536 + if (settings.name == '/') {
  537 + return GetPageRoute(
  538 + page: () => Scaffold(
  539 + appBar: AppBar(
  540 + title: Text("Main"),
  541 + ),
  542 + body: Center(
  543 + child: TextButton(
  544 + color: Colors.blue,
  545 + onPressed: () {
  546 + Get.toNamed('/second', id:1); // navigate by your nested route by index
  547 + },
  548 + child: Text("Go to second"),
  549 + ),
  550 + ),
  551 + ),
  552 + );
  553 + } else if (settings.name == '/second') {
  554 + return GetPageRoute(
  555 + page: () => Center(
  556 + child: Scaffold(
  557 + appBar: AppBar(
  558 + title: Text("Main"),
  559 + ),
  560 + body: Center(
  561 + child: Text("second")
  562 + ),
  563 + ),
  564 + ),
  565 + );
  566 + }
  567 + }
  568 +),
  569 +```
  1 +* [State Management](#state-management)
  2 + + [Reactive State Manager](#reactive-state-manager)
  3 + - [Advantages](#advantages)
  4 + - [Maximum performance:](#maximum-performance)
  5 + - [Declaring a reactive variable](#declaring-a-reactive-variable)
  6 + - [Having a reactive state, is easy.](#having-a-reactive-state-is-easy)
  7 + - [Using the values in the view](#using-the-values-in-the-view)
  8 + - [Conditions to rebuild](#conditions-to-rebuild)
  9 + - [Where .obs can be used](#where-obs-can-be-used)
  10 + - [Note about Lists](#note-about-lists)
  11 + - [Why i have to use .value](#why-i-have-to-use-value)
  12 + - [Obx()](#obx)
  13 + - [Workers](#workers)
  14 + + [Simple State Manager](#simple-state-manager)
  15 + - [Advantages](#advantages-1)
  16 + - [Usage](#usage)
  17 + - [How it handles controllers](#how-it-handles-controllers)
  18 + - [You won't need StatefulWidgets anymore](#you-wont-need-statefulwidgets-anymore)
  19 + - [Why it exists](#why-it-exists)
  20 + - [Other ways of using it](#other-ways-of-using-it)
  21 + - [Unique IDs](#unique-ids)
  22 + + [Mixing the two state managers](#mixing-the-two-state-managers)
  23 + + [GetBuilder vs GetX vs Obx vs MixinBuilder](#getbuilder-vs-getx-vs-obx-vs-mixinbuilder)
  24 +
  25 +# State Management
  26 +
  27 +GetX does not use Streams or ChangeNotifier like other state managers. Why? In addition to building applications for android, iOS, web, linux, macos and linux, with GetX you can build server applications with the same syntax as Flutter/GetX. In order to improve response time and reduce RAM consumption, we created GetValue and GetStream, which are low latency solutions that deliver a lot of performance, at a low operating cost. We use this base to build all of our resources, including state management.
  28 +
  29 +* _Complexity_: Some state managers are complex and have a lot of boilerplate. With GetX you don't have to define a class for each event, the code is highly clean and clear, and you do a lot more by writing less. Many people have given up on Flutter because of this topic, and they now finally have a stupidly simple solution for managing states.
  30 +* _No code generators_: You spend half your development time writing your application logic. Some state managers rely on code generators to have minimally readable code. Changing a variable and having to run build_runner can be unproductive, and often the waiting time after a flutter clean will be long, and you will have to drink a lot of coffee.
  31 +
  32 +With GetX everything is reactive, and nothing depends on code generators, increasing your productivity in all aspects of your development.
  33 +
  34 +* _It does not depend on context_: You probably already needed to send the context of your view to a controller, making the View's coupling with your business logic high. You have probably had to use a dependency for a place that has no context, and had to pass the context through various classes and functions. This just doesn't exist with GetX. You have access to your controllers from within your controllers without any context. You don't need to send the context by parameter for literally nothing.
  35 +* _Granular control_: most state managers are based on ChangeNotifier. ChangeNotifier will notify all widgets that depend on it when notifyListeners is called. If you have 40 widgets on one screen, which have a variable of your ChangeNotifier class, when you update one, all of them will be rebuilt.
  36 +
  37 +With GetX, even nested widgets are respected. If you have Obx watching your ListView, and another watching a checkbox inside the ListView, when changing the CheckBox value, only it will be updated, when changing the List value, only the ListView will be updated.
  38 +
  39 +* _It only reconstructs if its variable REALLY changes_: GetX has flow control, that means if you display a Text with 'Paola', if you change the observable variable to 'Paola' again, the widget will not be reconstructed. That's because GetX knows that 'Paola' is already being displayed in Text, and will not do unnecessary reconstructions.
  40 +
  41 +Most (if not all) current state managers will rebuild on the screen.
  42 +
  43 +## Reactive State Manager
  44 +
  45 +Reactive programming can alienate many people because it is said to be complicated. GetX turns reactive programming into something quite simple:
  46 +
  47 +* You won't need to create StreamControllers.
  48 +* You won't need to create a StreamBuilder for each variable
  49 +* You will not need to create a class for each state.
  50 +* You will not need to create a get for an initial value.
  51 +
  52 +Reactive programming with Get is as easy as using setState.
  53 +
  54 +Let's imagine that you have a name variable and want that every time you change it, all widgets that use it are automatically changed.
  55 +
  56 +This is your count variable:
  57 +
  58 +``` dart
  59 +var name = 'Jonatas Borges';
  60 +```
  61 +
  62 +To make it observable, you just need to add ".obs" to the end of it:
  63 +
  64 +``` dart
  65 +var name = 'Jonatas Borges'.obs;
  66 +```
  67 +
  68 +That's all. It's *that* simple.
  69 +
  70 +From now on, we might refer to this reactive-".obs"(ervables) variables as _Rx_.
  71 +
  72 +What did we do under the hood? We created a `Stream` of `String` s, assigned the initial value `"Jonatas Borges"` , we notified all widgets that use `"Jonatas Borges"` that they now "belong" to this variable, and when the _Rx_ value changes, they will have to change as well.
  73 +
  74 +This is the **magic of GetX**, thanks to Dart's capabilities.
  75 +
  76 +But, as we know, a `Widget` can only be changed if it is inside a function, because static classes do not have the power to "auto-change".
  77 +
  78 +You will need to create a `StreamBuilder` , subscribe to this variable to listen for changes, and create a "cascade" of nested `StreamBuilder` if you want to change several variables in the same scope, right?
  79 +
  80 +No, you don't need a `StreamBuilder` , but you are right about static classes.
  81 +
  82 +Well, in the view, we usually have a lot of boilerplate when we want to change a specific Widget, that's the Flutter way.
  83 +With **GetX** you can also forget about this boilerplate code.
  84 +
  85 +`StreamBuilder( … )` ? `initialValue: …` ? `builder: …` ? Nope, you just need to place this variable inside an `Obx()` Widget.
  86 +
  87 +``` dart
  88 +Obx (() => Text (controller.name));
  89 +```
  90 +
  91 +_What do you need to memorize?_ Only `Obx(() =>` .
  92 +
  93 +You are just passing that Widget through an arrow-function into an `Obx()` (the "Observer" of the _Rx_).
  94 +
  95 +`Obx` is pretty smart, and will only change if the value of `controller.name` changes.
  96 +
  97 +If `name` is `"John"` , and you change it to `"John"` ( `name.value = "John"` ), as it's the same `value` as before, nothing will change on the screen, and `Obx` , to save resources, will simply ignore the new value and not rebuild the Widget. **Isn't that amazing?**
  98 +
  99 +> So, what if I have 5 _Rx_ (observable) variables within an `Obx` ?
  100 +
  101 +It will just update when **any** of them changes.
  102 +
  103 +> And if I have 30 variables in a class, when I update one, will it update **all** the variables that are in that class?
  104 +
  105 +Nope, just the **specific Widget** that uses that _Rx_ variable.
  106 +
  107 +So, **GetX** only updates the screen, when the _Rx_ variable changes it's value.
  108 +
  109 +```
  110 +
  111 +final isOpen = false.obs;
  112 +
  113 +// NOTHING will happen... same value.
  114 +void onButtonTap() => isOpen.value=false;
  115 +```
  116 +
  117 +### Advantages
  118 +
  119 +**GetX()** helps you when you need **granular** control over what's being updated.
  120 +
  121 +If you do not need `unique IDs` , because all your variables will be modified when you perform an action, then use `GetBuilder` ,
  122 +because it's a Simple State Updater (in blocks, like `setState()` ), made in just a few lines of code.
  123 +It was made simple, to have the least CPU impact, and just to fulfill a single purpose (a _State_ rebuild) and spend the minimum resources possible.
  124 +
  125 +If you need a **powerful** State Manager, you can't go wrong with **GetX**.
  126 +
  127 +It doesn't work with variables, but __flows__, everything in it are `Streams` under the hood.
  128 +
  129 +You can use _rxDart_ in conjunction with it, because everything are `Streams`,
  130 +you can listen to the `event` of each "_Rx_ variable",
  131 +because everything in it are `Streams`.
  132 +
  133 +It is literally a _BLoC_ approach, easier than _MobX_, and without code generators or decorations.
  134 +You can turn **anything** into an _"Observable"_ with just a `.obs` .
  135 +
  136 +### Maximum performance:
  137 +
  138 +In addition to having a smart algorithm for minimal rebuilds, **GetX** uses comparators
  139 +to make sure the State has changed.
  140 +
  141 +If you experience any errors in your app, and send a duplicate change of State,
  142 +**GetX** will ensure it will not crash.
  143 +
  144 +With **GetX** the State only changes if the `value` change.
  145 +That's the main difference between **GetX**, and using _ `computed` from MobX_.
  146 +When joining two __observables__, and one changes; the listener of that _observable_ will change as well.
  147 +
  148 +With **GetX**, if you join two variables, `GetX()` (similar to `Observer()` ) will only rebuild if it implies a real change of State.
  149 +
  150 +### Declaring a reactive variable
  151 +
  152 +You have 3 ways to turn a variable into an "observable".
  153 +
  154 +1 - The first is using **`Rx{Type}`**.
  155 +
  156 +``` dart
  157 +// initial value is recommended, but not mandatory
  158 +final name = RxString('');
  159 +final isLogged = RxBool(false);
  160 +final count = RxInt(0);
  161 +final balance = RxDouble(0.0);
  162 +final items = RxList<String>([]);
  163 +final myMap = RxMap<String, int>({});
  164 +```
  165 +
  166 +2 - The second is to use **`Rx`** and use Darts Generics, `Rx<Type>`
  167 +
  168 +``` dart
  169 +final name = Rx<String>('');
  170 +final isLogged = Rx<Bool>(false);
  171 +final count = Rx<Int>(0);
  172 +final balance = Rx<Double>(0.0);
  173 +final number = Rx<Num>(0);
  174 +final items = Rx<List<String>>([]);
  175 +final myMap = Rx<Map<String, int>>({});
  176 +
  177 +// Custom classes - it can be any class, literally
  178 +final user = Rx<User>();
  179 +```
  180 +
  181 +3 - The third, more practical, easier and preferred approach, just add **`.obs`** as a property of your `value` :
  182 +
  183 +``` dart
  184 +final name = ''.obs;
  185 +final isLogged = false.obs;
  186 +final count = 0.obs;
  187 +final balance = 0.0.obs;
  188 +final number = 0.obs;
  189 +final items = <String>[].obs;
  190 +final myMap = <String, int>{}.obs;
  191 +
  192 +// Custom classes - it can be any class, literally
  193 +final user = User().obs;
  194 +```
  195 +
  196 +##### Having a reactive state, is easy.
  197 +
  198 +As we know, _Dart_ is now heading towards _null safety_.
  199 +To be prepared, from now on, you should always start your _Rx_ variables with an **initial value**.
  200 +
  201 +> Transforming a variable into an _observable_ + _initial value_ with **GetX** is the simplest, and most practical approach.
  202 +
  203 +You will literally add a " `.obs` " to the end of your variable, and **that’s it**, you’ve made it observable,
  204 +and its `.value` , well, will be the _initial value_).
  205 +
  206 +### Using the values in the view
  207 +
  208 +``` dart
  209 +// controller file
  210 +final count1 = 0.obs;
  211 +final count2 = 0.obs;
  212 +int get sum => count1.value + count2.value;
  213 +```
  214 +
  215 +``` dart
  216 +// view file
  217 +GetX<Controller>(
  218 + builder: (controller) {
  219 + print("count 1 rebuild");
  220 + return Text('${controller.count1.value}');
  221 + },
  222 +),
  223 +GetX<Controller>(
  224 + builder: (controller) {
  225 + print("count 2 rebuild");
  226 + return Text('${controller.count2.value}');
  227 + },
  228 +),
  229 +GetX<Controller>(
  230 + builder: (controller) {
  231 + print("count 3 rebuild");
  232 + return Text('${controller.sum}');
  233 + },
  234 +),
  235 +```
  236 +
  237 +If we increment `count1.value++` , it will print:
  238 +
  239 +* `count 1 rebuild`
  240 +
  241 +* `count 3 rebuild`
  242 +
  243 +because `count1` has a value of `1` , and `1 + 0 = 1` , changing the `sum` getter value.
  244 +
  245 +If we change `count2.value++` , it will print:
  246 +
  247 +* `count 2 rebuild`
  248 +
  249 +* `count 3 rebuild`
  250 +
  251 +because `count2.value` changed, and the result of the `sum` is now `2` .
  252 +
  253 +* NOTE: By default, the very first event will rebuild the widget, even if it is the same `value`.
  254 +
  255 + This behavior exists due to Boolean variables.
  256 +
  257 +Imagine you did this:
  258 +
  259 +``` dart
  260 +var isLogged = false.obs;
  261 +```
  262 +
  263 +And then, you checked if a user is "logged in" to trigger an event in `ever` .
  264 +
  265 +``` dart
  266 +@override
  267 +onInit() async {
  268 + ever(isLogged, fireRoute);
  269 + isLogged.value = await Preferences.hasToken();
  270 +}
  271 +
  272 +fireRoute(logged) {
  273 + if (logged) {
  274 + Get.off(Home());
  275 + } else {
  276 + Get.off(Login());
  277 + }
  278 +}
  279 +```
  280 +
  281 +if `hasToken` was `false` , there would be no change to `isLogged` , so `ever()` would never be called.
  282 +To avoid this type of behavior, the first change to an _observable_ will always trigger an event,
  283 +even if it contains the same `.value` .
  284 +
  285 +You can remove this behavior if you want, using:
  286 + `isLogged.firstRebuild = false;`
  287 +
  288 +### Conditions to rebuild
  289 +
  290 +In addition, Get provides refined state control. You can condition an event (such as adding an object to a list), on a certain condition.
  291 +
  292 +``` dart
  293 +// First parameter: condition, must return true or false.
  294 +// Second parameter: the new value to apply if the condition is true.
  295 +list.addIf(item < limit, item);
  296 +```
  297 +
  298 +Without decorations, without a code generator, without complications :smile:
  299 +
  300 +Do you know Flutter's counter app? Your Controller class might look like this:
  301 +
  302 +``` dart
  303 +class CountController extends GetxController {
  304 + final count = 0.obs;
  305 +}
  306 +```
  307 +
  308 +With a simple:
  309 +
  310 +``` dart
  311 +controller.count.value++
  312 +```
  313 +
  314 +You could update the counter variable in your UI, regardless of where it is stored.
  315 +
  316 +### Where .obs can be used
  317 +
  318 +You can transform anything on obs. Here are two ways of doing it:
  319 +
  320 +* You can convert your class values to obs
  321 +
  322 +``` dart
  323 +class RxUser {
  324 + final name = "Camila".obs;
  325 + final age = 18.obs;
  326 +}
  327 +```
  328 +
  329 +* or you can convert the entire class to be an observable
  330 +
  331 +``` dart
  332 +class User {
  333 + User({String name, int age});
  334 + var name;
  335 + var age;
  336 +}
  337 +
  338 +// when instantianting:
  339 +final user = User(name: "Camila", age: 18).obs;
  340 +```
  341 +
  342 +### Note about Lists
  343 +
  344 +Lists are completely observable as are the objects within it. That way, if you add a value to a list, it will automatically rebuild the widgets that use it.
  345 +
  346 +You also don't need to use ".value" with lists, the amazing dart api allowed us to remove that.
  347 +Unfortunaly primitive types like String and int cannot be extended, making the use of .value mandatory, but that won't be a problem if you work with gets and setters for these.
  348 +
  349 +``` dart
  350 +// On the controller
  351 +final String title = 'User Info:'.obs
  352 +final list = List<User>().obs;
  353 +
  354 +// on the view
  355 +Text(controller.title.value), // String need to have .value in front of it
  356 +ListView.builder (
  357 + itemCount: controller.list.length // lists don't need it
  358 +)
  359 +```
  360 +
  361 +When you are making your own classes observable, there is a different way to update them:
  362 +
  363 +``` dart
  364 +// on the model file
  365 +// we are going to make the entire class observable instead of each attribute
  366 +class User() {
  367 + User({this.name = '', this.age = 0});
  368 + String name;
  369 + int age;
  370 +}
  371 +
  372 +// on the controller file
  373 +final user = User().obs;
  374 +// when you need to update the user variable:
  375 +user.update( (user) { // this parameter is the class itself that you want to update
  376 +user.name = 'Jonny';
  377 +user.age = 18;
  378 +});
  379 +// an alternative way of update the user variable:
  380 +user(User(name: 'João', age: 35));
  381 +
  382 +// on view:
  383 +Obx(()=> Text("Name ${user.value.name}: Age: ${user.value.age}"))
  384 +// you can also access the model values without the .value:
  385 +user().name; // notice that is the user variable, not the class (variable has lowercase u)
  386 +```
  387 +
  388 +You don't have to work with sets if you don't want to. you can use the "assign 'and" assignAll "api.
  389 +The "assign" api will clear your list, and add a single object that you want to start there.
  390 +The "assignAll" api will clear the existing list and add any iterable objects that you inject into it.
  391 +
  392 +### Why i have to use .value
  393 +
  394 +We could remove the obligation to use 'value' to `String` and `int` with a simple decoration and code generator, but the purpose of this library is precisely avoid external dependencies. We want to offer an environment ready for programming, involving the essentials (management of routes, dependencies and states), in a simple, lightweight and performant way, without a need of an external package.
  395 +
  396 +You can literally add 3 letters to your pubspec (get) and a colon and start programming. All solutions included by default, from route management to state management, aim at ease, productivity and performance.
  397 +
  398 +The total weight of this library is less than that of a single state manager, even though it is a complete solution, and that is what you must understand.
  399 +
  400 +If you are bothered by `.value` , and like a code generator, MobX is a great alternative, and you can use it in conjunction with Get. For those who want to add a single dependency in pubspec and start programming without worrying about the version of a package being incompatible with another, or if the error of a state update is coming from the state manager or dependency, or still, do not want to worrying about the availability of controllers, whether literally "just programming", get is just perfect.
  401 +
  402 +If you have no problem with the MobX code generator, or have no problem with the BLoC boilerplate, you can simply use Get for routes, and forget that it has state manager. Get SEM and RSM were born out of necessity, my company had a project with more than 90 controllers, and the code generator simply took more than 30 minutes to complete its tasks after a Flutter Clean on a reasonably good machine, if your project it has 5, 10, 15 controllers, any state manager will supply you well. If you have an absurdly large project, and code generator is a problem for you, you have been awarded this solution.
  403 +
  404 +Obviously, if someone wants to contribute to the project and create a code generator, or something similar, I will link in this readme as an alternative, my need is not the need for all devs, but for now I say, there are good solutions that already do that, like MobX.
  405 +
  406 +### Obx()
  407 +
  408 +Typing in Get using Bindings is unnecessary. you can use the Obx widget instead of GetX which only receives the anonymous function that creates a widget.
  409 +Obviously, if you don't use a type, you will need to have an instance of your controller to use the variables, or use `Get.find<Controller>()` .value or Controller.to.value to retrieve the value.
  410 +
  411 +### Workers
  412 +
  413 +Workers will assist you, triggering specific callbacks when an event occurs.
  414 +
  415 +``` dart
  416 +/// Called every time `count1` changes.
  417 +ever(count1, (_) => print("$_ has been changed"));
  418 +
  419 +/// Called only first time the variable $_ is changed
  420 +once(count1, (_) => print("$_ was changed once"));
  421 +
  422 +/// Anti DDos - Called every time the user stops typing for 1 second, for example.
  423 +debounce(count1, (_) => print("debouce$_"), time: Duration(seconds: 1));
  424 +
  425 +/// Ignore all changes within 1 second.
  426 +interval(count1, (_) => print("interval $_"), time: Duration(seconds: 1));
  427 +```
  428 +
  429 +All workers (except `debounce` ) have a `condition` named parameter, which can be a `bool` or a callback that returns a `bool` .
  430 +This `condition` defines when the `callback` function executes.
  431 +
  432 +All workers returns a `Worker` instance, that you can use to cancel ( via `dispose()` ) the worker.
  433 +
  434 +
  435 +* **`ever`**
  436 +
  437 + is called every time the _Rx_ variable emits a new value.
  438 +
  439 +* **`everAll`**
  440 +
  441 + Much like `ever` , but it takes a `List` of _Rx_ values Called every time its variable is changed. That's it.
  442 +
  443 +* **`once`**
  444 +
  445 +'once' is called only the first time the variable has been changed.
  446 +
  447 +* **`debounce`**
  448 +
  449 +'debounce' is very useful in search functions, where you only want the API to be called when the user finishes typing. If the user types "Jonny", you will have 5 searches in the APIs, by the letter J, o, n, n, and y. With Get this does not happen, because you will have a "debounce" Worker that will only be triggered at the end of typing.
  450 +
  451 +* **`interval`**
  452 +
  453 +'interval' is different from the debouce. debouce if the user makes 1000 changes to a variable within 1 second, he will send only the last one after the stipulated timer (the default is 800 milliseconds). Interval will instead ignore all user actions for the stipulated period. If you send events for 1 minute, 1000 per second, debounce will only send you the last one, when the user stops strafing events. interval will deliver events every second, and if set to 3 seconds, it will deliver 20 events that minute. This is recommended to avoid abuse, in functions where the user can quickly click on something and get some advantage (imagine that the user can earn coins by clicking on something, if he clicked 300 times in the same minute, he would have 300 coins, using interval, you you can set a time frame for 3 seconds, and even then clicking 300 or a thousand times, the maximum he would get in 1 minute would be 20 coins, clicking 300 or 1 million times). The debounce is suitable for anti-DDos, for functions like search where each change to onChange would cause a query to your api. Debounce will wait for the user to stop typing the name, to make the request. If it were used in the coin scenario mentioned above, the user would only win 1 coin, because it is only executed, when the user "pauses" for the established time.
  454 +
  455 +* NOTE: Workers should always be used when starting a Controller or Class, so it should always be on onInit (recommended), Class constructor, or the initState of a StatefulWidget (this practice is not recommended in most cases, but it shouldn't have any side effects).
  456 +
  457 +## Simple State Manager
  458 +
  459 +Get has a state manager that is extremely light and easy, which does not use ChangeNotifier, will meet the need especially for those new to Flutter, and will not cause problems for large applications.
  460 +
  461 +GetBuilder is aimed precisely at multiple state control. Imagine that you added 30 products to a cart, you click delete one, at the same time that the list is updated, the price is updated and the badge in the shopping cart is updated to a smaller number. This type of approach makes GetBuilder killer, because it groups states and changes them all at once without any "computational logic" for that. GetBuilder was created with this type of situation in mind, since for ephemeral change of state, you can use setState and you would not need a state manager for this.
  462 +
  463 +That way, if you want an individual controller, you can assign IDs for that, or use GetX. This is up to you, remembering that the more "individual" widgets you have, the more the performance of GetX will stand out, while the performance of GetBuilder should be superior, when there is multiple change of state.
  464 +
  465 +### Advantages
  466 +
  467 +1. Update only the required widgets.
  468 +
  469 +2. Does not use changeNotifier, it is the state manager that uses less memory (close to 0mb).
  470 +
  471 +3. Forget StatefulWidget! With Get you will never need it. With the other state managers, you will probably have to use a StatefulWidget to get the instance of your Provider, BLoC, MobX Controller, etc. But have you ever stopped to think that your appBar, your scaffold, and most of the widgets that are in your class are stateless? So why save the state of an entire class, if you can only save the state of the Widget that is stateful? Get solves that, too. Create a Stateless class, make everything stateless. If you need to update a single component, wrap it with GetBuilder, and its state will be maintained.
  472 +
  473 +4. Organize your project for real! Controllers must not be in your UI, place your TextEditController, or any controller you use within your Controller class.
  474 +
  475 +5. Do you need to trigger an event to update a widget as soon as it is rendered? GetBuilder has the property "initState", just like StatefulWidget, and you can call events from your controller, directly from it, no more events being placed in your initState.
  476 +
  477 +6. Do you need to trigger an action like closing streams, timers and etc? GetBuilder also has the dispose property, where you can call events as soon as that widget is destroyed.
  478 +
  479 +7. Use streams only if necessary. You can use your StreamControllers inside your controller normally, and use StreamBuilder also normally, but remember, a stream reasonably consumes memory, reactive programming is beautiful, but you shouldn't abuse it. 30 streams open simultaneously can be worse than changeNotifier (and changeNotifier is very bad).
  480 +
  481 +8. Update widgets without spending ram for that. Get stores only the GetBuilder creator ID, and updates that GetBuilder when necessary. The memory consumption of the get ID storage in memory is very low even for thousands of GetBuilders. When you create a new GetBuilder, you are actually sharing the state of GetBuilder that has a creator ID. A new state is not created for each GetBuilder, which saves A LOT OF ram for large applications. Basically your application will be entirely Stateless, and the few Widgets that will be Stateful (within GetBuilder) will have a single state, and therefore updating one will update them all. The state is just one.
  482 +
  483 +9. Get is omniscient and in most cases it knows exactly the time to take a controller out of memory. You should not worry about when to dispose of a controller, Get knows the best time to do this.
  484 +
  485 +### Usage
  486 +
  487 +``` dart
  488 +// Create controller class and extends GetxController
  489 +class Controller extends GetxController {
  490 + int counter = 0;
  491 + void increment() {
  492 + counter++;
  493 + update(); // use update() to update counter variable on UI when increment be called
  494 + }
  495 +}
  496 +// On your Stateless/Stateful class, use GetBuilder to update Text when increment be called
  497 +GetBuilder<Controller>(
  498 + init: Controller(), // INIT IT ONLY THE FIRST TIME
  499 + builder: (_) => Text(
  500 + '${_.counter}',
  501 + ),
  502 +)
  503 +//Initialize your controller only the first time. The second time you are using ReBuilder for the same controller, do not use it again. Your controller will be automatically removed from memory as soon as the widget that marked it as 'init' is deployed. You don't have to worry about that, Get will do it automatically, just make sure you don't start the same controller twice.
  504 +```
  505 +
  506 +**Done!**
  507 +
  508 +* You have already learned how to manage states with Get.
  509 +
  510 +* Note: You may want a larger organization, and not use the init property. For that, you can create a class and extends Bindings class, and within it mention the controllers that will be created within that route. Controllers will not be created at that time, on the contrary, this is just a statement, so that the first time you use a Controller, Get will know where to look. Get will remain lazyLoad, and will continue to dispose Controllers when they are no longer needed. See the pub.dev example to see how it works.
  511 +
  512 +If you navigate many routes and need data that was in your previously used controller, you just need to use GetBuilder Again (with no init):
  513 +
  514 +``` dart
  515 +class OtherClass extends StatelessWidget {
  516 + @override
  517 + Widget build(BuildContext context) {
  518 + return Scaffold(
  519 + body: Center(
  520 + child: GetBuilder<Controller>(
  521 + builder: (s) => Text('${s.counter}'),
  522 + ),
  523 + ),
  524 + );
  525 + }
  526 +
  527 +```
  528 +
  529 +If you need to use your controller in many other places, and outside of GetBuilder, just create a get in your controller and have it easily. (or use `Get.find<Controller>()` )
  530 +
  531 +``` dart
  532 +class Controller extends GetxController {
  533 +
  534 + /// You do not need that. I recommend using it just for ease of syntax.
  535 + /// with static method: Controller.to.increment();
  536 + /// with no static method: Get.find<Controller>().increment();
  537 + /// There is no difference in performance, nor any side effect of using either syntax. Only one does not need the type, and the other the IDE will autocomplete it.
  538 + static Controller get to => Get.find(); // add this line
  539 +
  540 + int counter = 0;
  541 + void increment() {
  542 + counter++;
  543 + update();
  544 + }
  545 +}
  546 +```
  547 +
  548 +And then you can access your controller directly, that way:
  549 +
  550 +``` dart
  551 +FloatingActionButton(
  552 + onPressed: () {
  553 + Controller.to.increment(),
  554 + } // This is incredibly simple!
  555 + child: Text("${Controller.to.counter}"),
  556 +),
  557 +```
  558 +
  559 +When you press FloatingActionButton, all widgets that are listening to the 'counter' variable will be updated automatically.
  560 +
  561 +### How it handles controllers
  562 +
  563 +Let's say we have this:
  564 +
  565 + `Class a => Class B (has controller X) => Class C (has controller X)`
  566 +
  567 +In class A the controller is not yet in memory, because you have not used it yet (Get is lazyLoad). In class B you used the controller, and it entered memory. In class C you used the same controller as in class B, Get will share the state of controller B with controller C, and the same controller is still in memory. If you close screen C and screen B, Get will automatically take controller X out of memory and free up resources, because Class a is not using the controller. If you navigate to B again, controller X will enter memory again, if instead of going to class C, you return to class A again, Get will take the controller out of memory in the same way. If class C didn't use the controller, and you took class B out of memory, no class would be using controller X and likewise it would be disposed of. The only exception that can mess with Get, is if you remove B from the route unexpectedly, and try to use the controller in C. In this case, the creator ID of the controller that was in B was deleted, and Get was programmed to remove it from memory every controller that has no creator ID. If you intend to do this, add the "autoRemove: false" flag to class B's GetBuilder and use adoptID = true; in class C's GetBuilder.
  568 +
  569 +### You won't need StatefulWidgets anymore
  570 +
  571 +Using StatefulWidgets means storing the state of entire screens unnecessarily, even because if you need to minimally rebuild a widget, you will embed it in a Consumer/Observer/BlocProvider/GetBuilder/GetX/Obx, which will be another StatefulWidget.
  572 +The StatefulWidget class is a class larger than StatelessWidget, which will allocate more RAM, and this may not make a significant difference between one or two classes, but it will most certainly do when you have 100 of them!
  573 +Unless you need to use a mixin, like TickerProviderStateMixin, it will be totally unnecessary to use a StatefulWidget with Get.
  574 +
  575 +You can call all methods of a StatefulWidget directly from a GetBuilder.
  576 +If you need to call initState() or dispose() method for example, you can call them directly;
  577 +
  578 +``` dart
  579 +GetBuilder<Controller>(
  580 + initState: (_) => Controller.to.fetchApi(),
  581 + dispose: (_) => Controller.to.closeStreams(),
  582 + builder: (s) => Text('${s.username}'),
  583 +),
  584 +```
  585 +
  586 +A much better approach than this is to use the onInit() and onClose() method directly from your controller.
  587 +
  588 +``` dart
  589 +@override
  590 +void onInit() {
  591 + fetchApi();
  592 + super.onInit();
  593 +}
  594 +```
  595 +
  596 +* NOTE: If you want to start a method at the moment the controller is called for the first time, you DON'T NEED to use constructors for this, in fact, using a performance-oriented package like Get, this borders on bad practice, because it deviates from the logic in which the controllers are created or allocated (if you create an instance of this controller, the constructor will be called immediately, you will be populating a controller before it is even used, you are allocating memory without it being in use, this definitely hurts the principles of this library). The onInit() methods; and onClose(); were created for this, they will be called when the Controller is created, or used for the first time, depending on whether you are using Get.lazyPut or not. If you want, for example, to make a call to your API to populate data, you can forget about the old-fashioned method of initState/dispose, just start your call to the api in onInit, and if you need to execute any command like closing streams, use the onClose() for that.
  597 +
  598 +### Why it exists
  599 +
  600 +The purpose of this package is precisely to give you a complete solution for navigation of routes, management of dependencies and states, using the least possible dependencies, with a high degree of decoupling. Get engages all high and low level Flutter APIs within itself, to ensure that you work with the least possible coupling. We centralize everything in a single package, to ensure that you don't have any kind of coupling in your project. That way, you can put only widgets in your view, and leave the part of your team that works with the business logic free, to work with the business logic without depending on any element of the View. This provides a much cleaner working environment, so that part of your team works only with widgets, without worrying about sending data to your controller, and part of your team works only with the business logic in its breadth, without depending on no element of the view.
  601 +
  602 +So to simplify this:
  603 +You don't need to call methods in initState and send them by parameter to your controller, nor use your controller constructor for that, you have the onInit() method that is called at the right time for you to start your services.
  604 +You do not need to call the device, you have the onClose() method that will be called at the exact moment when your controller is no longer needed and will be removed from memory. That way, leave views for widgets only, refrain from any kind of business logic from it.
  605 +
  606 +Do not call a dispose method inside GetxController, it will not do anything, remember that the controller is not a Widget, you should not "dispose" it, and it will be automatically and intelligently removed from memory by Get. If you used any stream on it and want to close it, just insert it into the close method. Example:
  607 +
  608 +``` dart
  609 +class Controller extends GetxController {
  610 + StreamController<User> user = StreamController<User>();
  611 + StreamController<String> name = StreamController<String>();
  612 +
  613 + /// close stream = onClose method, not dispose.
  614 + @override
  615 + void onClose() {
  616 + user.close();
  617 + name.close();
  618 + super.onClose();
  619 + }
  620 +}
  621 +```
  622 +
  623 +Controller life cycle:
  624 +
  625 +* onInit() where it is created.
  626 +* onClose() where it is closed to make any changes in preparation for the delete method
  627 +* deleted: you do not have access to this API because it is literally removing the controller from memory. It is literally deleted, without leaving any trace.
  628 +
  629 +### Other ways of using it
  630 +
  631 +You can use Controller instance directly on GetBuilder value:
  632 +
  633 +``` dart
  634 +GetBuilder<Controller>(
  635 + init: Controller(),
  636 + builder: (value) => Text(
  637 + '${value.counter}', //here
  638 + ),
  639 +),
  640 +```
  641 +
  642 +You may also need an instance of your controller outside of your GetBuilder, and you can use these approaches to achieve this:
  643 +
  644 +``` dart
  645 +class Controller extends GetxController {
  646 + static Controller get to => Get.find();
  647 +[...]
  648 +}
  649 +// on you view:
  650 +GetBuilder<Controller>(
  651 + init: Controller(), // use it only first time on each controller
  652 + builder: (_) => Text(
  653 + '${Controller.to.counter}', //here
  654 + )
  655 +),
  656 +```
  657 +
  658 +or
  659 +
  660 +``` dart
  661 +class Controller extends GetxController {
  662 + // static Controller get to => Get.find(); // with no static get
  663 +[...]
  664 +}
  665 +// on stateful/stateless class
  666 +GetBuilder<Controller>(
  667 + init: Controller(), // use it only first time on each controller
  668 + builder: (_) => Text(
  669 + '${Get.find<Controller>().counter}', //here
  670 + ),
  671 +),
  672 +```
  673 +
  674 +* You can use "non-canonical" approaches to do this. If you are using some other dependency manager, like get_it, modular, etc., and just want to deliver the controller instance, you can do this:
  675 +
  676 +``` dart
  677 +Controller controller = Controller();
  678 +[...]
  679 +GetBuilder<Controller>(
  680 + init: controller, //here
  681 + builder: (_) => Text(
  682 + '${controller.counter}', // here
  683 + ),
  684 +),
  685 +
  686 +```
  687 +
  688 +### Unique IDs
  689 +
  690 +If you want to refine a widget's update control with GetBuilder, you can assign them unique IDs:
  691 +
  692 +``` dart
  693 +GetBuilder<Controller>(
  694 + id: 'text'
  695 + init: Controller(), // use it only first time on each controller
  696 + builder: (_) => Text(
  697 + '${Get.find<Controller>().counter}', //here
  698 + ),
  699 +),
  700 +```
  701 +
  702 +And update it this form:
  703 +
  704 +``` dart
  705 +update(['text']);
  706 +```
  707 +
  708 +You can also impose conditions for the update:
  709 +
  710 +``` dart
  711 +update(['text'], counter < 10);
  712 +```
  713 +
  714 +GetX does this automatically and only reconstructs the widget that uses the exact variable that was changed, if you change a variable to the same as the previous one and that does not imply a change of state , GetX will not rebuild the widget to save memory and CPU cycles (3 is being displayed on the screen, and you change the variable to 3 again. In most state managers, this will cause a new rebuild, but with GetX the widget will only is rebuilt again, if in fact his state has changed).
  715 +
  716 +## Mixing the two state managers
  717 +
  718 +Some people opened a feature request, as they wanted to use only one type of reactive variable, and the other mechanics, and needed to insert an Obx into a GetBuilder for this. Thinking about it MixinBuilder was created. It allows both reactive changes by changing ".obs" variables, and mechanical updates via update(). However, of the 4 widgets he is the one that consumes the most resources, since in addition to having a Subscription to receive change events from his children, he subscribes to the update method of his controller.
  719 +
  720 +Extending GetxController is important, as they have life cycles, and can "start" and "end" events in their onInit() and onClose() methods. You can use any class for this, but I strongly recommend you use the GetxController class to place your variables, whether they are observable or not.
  721 +
  722 +## StateMixin
  723 +
  724 +Another way to handle your `UI` state is use the `StateMixin<T>` .
  725 +To implement it, use the `with` to add the `StateMixin<T>`
  726 +to your controller which allows a T model.
  727 +
  728 +``` dart
  729 +class Controller extends GetController with StateMixin<User>{}
  730 +```
  731 +
  732 +The `change()` method change the State whenever we want.
  733 +Just pass the data and the status in this way:
  734 +
  735 +```dart
  736 +change(data, status: RxStatus.success());
  737 +```
  738 +
  739 +RxStatus allow these status:
  740 +
  741 +``` dart
  742 +RxStatus.loading();
  743 +RxStatus.success();
  744 +RxStatus.empty();
  745 +RxStatus.error('message');
  746 +```
  747 +
  748 +To represent it in the UI, use:
  749 +
  750 +```dart
  751 +class OtherClass extends GetView<Controller> {
  752 + @override
  753 + Widget build(BuildContext context) {
  754 + return Scaffold(
  755 +
  756 + body: controller.obx(
  757 + (state)=>Text(state.name),
  758 +
  759 + // here you can put your custom loading indicator, but
  760 + // by default would be Center(child:CircularProgressIndicator())
  761 + onLoading: CustomLoadingIndicator(),
  762 + onEmpty: Text('No data found'),
  763 +
  764 + // here also you can set your own error widget, but by
  765 + // default will be an Center(child:Text(error))
  766 + onError: (error)=>Text(error),
  767 + ),
  768 + );
  769 +}
  770 +```
  771 +
  772 +## GetBuilder vs GetX vs Obx vs MixinBuilder
  773 +
  774 +In a decade working with programming I was able to learn some valuable lessons.
  775 +
  776 +My first contact with reactive programming was so "wow, this is incredible" and in fact reactive programming is incredible.
  777 +However, it is not suitable for all situations. Often all you need is to change the state of 2 or 3 widgets at the same time, or an ephemeral change of state, in which case reactive programming is not bad, but it is not appropriate.
  778 +
  779 +Reactive programming has a higher RAM consumption that can be compensated for by the individual workflow, which will ensure that only one widget is rebuilt and when necessary, but creating a list with 80 objects, each with several streams is not a good one idea. Open the dart inspect and check how much a StreamBuilder consumes, and you'll understand what I'm trying to tell you.
  780 +
  781 +With that in mind, I created the simple state manager. It is simple, and that is exactly what you should demand from it: updating state in blocks in a simple way, and in the most economical way.
  782 +
  783 +GetBuilder is very economical in RAM, and there is hardly a more economical approach than him (at least I can't imagine one, if it exists, please let us know).
  784 +
  785 +However, GetBuilder is still a mechanical state manager, you need to call update() just like you would need to call Provider's notifyListeners().
  786 +
  787 +There are other situations where reactive programming is really interesting, and not working with it is the same as reinventing the wheel. With that in mind, GetX was created to provide everything that is most modern and advanced in a state manager. It updates only what is necessary and when necessary, if you have an error and send 300 state changes simultaneously, GetX will filter and update the screen only if the state actually changes.
  788 +
  789 +GetX is still more economical than any other reactive state manager, but it consumes a little more RAM than GetBuilder. Thinking about it and aiming to maximize the consumption of resources that Obx was created. Unlike GetX and GetBuilder, you will not be able to initialize a controller inside an Obx, it is just a Widget with a StreamSubscription that receives change events from your children, that's all. It is more economical than GetX, but loses to GetBuilder, which was to be expected, since it is reactive, and GetBuilder has the most simplistic approach that exists, of storing a widget's hashcode and its StateSetter. With Obx you don't need to write your controller type, and you can hear the change from multiple different controllers, but it needs to be initialized before, either using the example approach at the beginning of this readme, or using the Bindings class.