flutter_package / fluttertpc_get

Go to a project
Toggle navigation Toggle navigation pinning
Switch branch/tag
README.pt-br.md 45.5 KB

Languages: English, Brazilian Portuguese.

pub package building Gitter Awesome Flutter

Get é uma biblioteca poderosa e extra-leve para Flutter que vai te dar superpoderes e aumentar sua produtividade. Navegue sem context, abre dialogs, snackbars ou bottomsheets de qualquer lugar do código, gerencie estados e injete dependências de uma forma simples e prática! Get é seguro, estável, atualizado e oferece uma enorge gama de APIs que não estão presentes no framework padrão.

// Flutter navigator padrão
Navigator.of(context).push(
  context,
  MaterialPageRoute(
      builder: (BuildContext context) {
      return Home();
    },
  ),
);

// Sintaxe do Get
Get.to(Home());

Começando

A navegação convencional do Flutter tem uma grande quantidade de boilerplate (muito código que se repete demais), requer o context para navegar entre telas, abrir dialogs e usar snackbars no framework é entediante. Somando a isso, quando uma rota é enviada, o MaterialApp inteiro pode ser reconstruído causando travamentos. Isso não acontece com o Get. Essa biblioteca vai mudar a forma que você trabalha com o Framework e salvar seu código dos boilerplates, aumentando sua produtividade, e eliminando os bugs de reconstrução da sua aplicação.

Você pode contribuir no projeto de várias formas:

  • Ajudando a traduzir o README para outras linguagens.
  • Adicionando mais documentação ao REAME (nem metado das funcionalidade do Get foram documentadas ainda).
  • Fazendo artigos/videos sobre o Get (eles serão inseridos no README, e no futuro na nossa Wiki).
  • Fazendo PRs (Pull-Requests) para código/testes.
  • Incluindo novas funcionalidades.

Qualquer contribuição é bem-vinda!

Como usar?

Adicione Get ao seu arquivo pubspec.yaml

Troque seu MaterialApp por GetMaterialApp e aproveite!

import 'package:get/get.dart';

GetMaterialApp( // Before: MaterialApp(
  home: MyHome(),
)

Navegação sem rotas nomeadas

Para navegar para uma próxima tela:

Get.to(ProximaTela());

Para retornar para a tela anterior:

Get.back();

Para ir para a próxima tela e NÃO deixar opção para voltar para a tela anterior (bom para SplashScreens, telas de login e etc.):

Get.off(ProximaTela());

Para ir para a próxima tela e cancelar todas as rotas anteriores (útil em telas de carrinho, votações e testes):

Get.offAll(ProximaTela());

Para navegar para a próxima rota, e recebar ou atualizar dados assim que retornar da rota:

var dados = await Get.to(Pagamento());

Na outra tela, envie os dados para a rota anterior:

Get.back(result: 'sucesso');

E use-os:

if (dados == 'sucesso') fazerQualquerCoisa();

Não quer aprender nossa sintaxe? Apenas mude o Navigator (letra maiúscula) para navigator (letra minúscula), e você terá todas as funcionalidades da navigation padrão, sem precisar usar context

Exemplo:

// Navigator padrão do Flutter
Navigator.of(context).push(
  context,
  MaterialPageRoute(
      builder: (BuildContext context) {
      return HomePage();
    },
  ),
);

// Get usando a sintaxe Flutter sem precisar do context
navigator.push(
  MaterialPageRoute(
      builder: (_) {
      return HomePage();
    },
  ),
);

// Sintaxe do Get (é bem melhor, mas você tem o direito de discordar)
Get.to(HomePage());

SnackBars

Para ter um SnackBar simples no Flutter, você precisa pegar o context do Scaffold, ou você precisa de uma GlobalKey atrelada ao seu Scaffold

final snackBar = SnackBar(
  content: Text('Olá!'),
  action: SnackBarAction(
    label: 'Eu sou uma SnackBar velha e feia :(',
    onPressed: (){}
  ),
);
// Encontra o Scaffold na árvore de Widgets e
// o usa para mostrar o SnackBar
Scaffold.of(context).showSnackBar(snackBar);

Com o Get:

Get.snackbar('Olá', 'eu sou uma SnackBar moderna e linda!');

Com Get, tudo que você precisa fazer é chamar Get.snackbar de qualquer lugar no seu código, ou custumizá-lo da forma que quiser!

Get.snackbar(
  "Ei, eu sou uma SnackBar Get!", // título
  "É inacreditável! Eu estou usando uma SnackBar sem context, sem " +
  "boilerplate, sem Scaffold, é algo realmente maravilhoso!", // mensagem
  icon: Icon(Icons.alarm),
  shouldIconPulse: true,
  onTap:(){},
  barBlur: 20,
  isDismissible: true,
  duration: Duration(seconds: 3),
);


  ////////// TODOS OS RECURSOS //////////
  //     Color colorText,
  //     Duration duration,
  //     SnackPosition snackPosition,
  //     Widget titleText,
  //     Widget messageText,
  //     bool instantInit,
  //     Widget icon,
  //     bool shouldIconPulse,
  //     double maxWidth,
  //     EdgeInsets margin,
  //     EdgeInsets padding,
  //     double borderRadius,
  //     Color borderColor,
  //     double borderWidth,
  //     Color backgroundColor,
  //     Color leftBarIndicatorColor,
  //     List<BoxShadow> boxShadows,
  //     Gradient backgroundGradient,
  //     FlatButton mainButton,
  //     OnTap onTap,
  //     bool isDismissible,
  //     bool showProgressIndicator,
  //     AnimationController progressIndicatorController,
  //     Color progressIndicatorBackgroundColor,
  //     Animation<Color> progressIndicatorValueColor,
  //     SnackStyle snackStyle,
  //     Curve forwardAnimationCurve,
  //     Curve reverseAnimationCurve,
  //     Duration animationDuration,
  //     double barBlur,
  //     double overlayBlur,
  //     Color overlayColor,
  //     Form userInputForm
  ///////////////////////////////////

Se você prefere a SnackBar tradicional, ou quer customizar por completo, incluindo até adicionar apenas uma linha (Get.snackbar usa um title e message obrigatórios), você pode usar Get.rawSnackbar(); que fornece a RAW API na qual Get.snackbar foi contruído.

Dialogs

Para abrir um dialog:

Get.dialog(SeuDialogWidget());

Para abrir um dialog padrão:

Get.defaultDialog(
  onConfirm: () => print("Ok"),
  middleText: "Dialog made in 3 lines of code",
);

Você também pode usar Get.generalDialog em vez de showGeneralDialog.

Para todos os outros Widgets dialog do Flutter, incluindo os do Cupertino, você pode usar Get.overlayContext em vez do context, e abrir em qualquer lugar do seu código.

Para widgets que não usam overlayContext, você pode usar Get.context. Esses dois contextos vão funcionar em 99% dos casos para substituir o context da sua UI, exceto em casos onde o inheritedWidget é usado sem a navigation context.

BottomSheets

Get.bottomSheet() é tipo o showModalBottomSheet(), mas não precisa do context.

Get.bottomSheet(
  Container(
    child: Wrap(
      children: <Widget>[
        ListTile(
          leading: Icon(Icons.music_note),
          title: Text('Música'),
          onTap: () => {}
        ),
        ListTile(
          leading: Icon(Icons.videocam),
          title: Text('Vídeo'),
          onTap: () => {},
        ),
      ],
    ),
  ),
);

Gerenciador de estado simples

Há atualmente vários gerenciadores de estados para o Flutter. Porém, a maioria deles envolve usar ChangeNotifier para atualizar os widgets e isso é uma abordagem muito ruim no quesito performance de aplicações de médio ou grande porte. Você pode checar na documentação oficial do Flutter que o ChangeNotifier deveria ser usado com um ou no máximo dois listeners, fazendo-o praticamente inutilizável em qualquer aplicação média ou grande. Outros gerenciadores de estado são bons, mas tem suas nuances. BLoC é bem seguro e eficiente, mas é muito complexo (especialmente para iniciantes), o que impediu pessoas de desenvolverem com Flutter. MobX é mais fácil que o BLoc e é reativo, quase perfeito eu diria, mas você precisa usar um code generator que, para aplicações de grande porte, reduz a produtividade (você terá que beber vários cafés até que seu código esteja pronto denovo depois de um flutter clean, o que não é culpa do MobX, o code generatoe que é muito lento!). Provider usa o InheritedWidget para entregar o mesmo listener, como uma forma de solucionar o problema reportado acima com o ChangeNotifier, o que indica que qualquer acesso ao ChangeNotifier dele tem que ser dentro da árvore de widgets por causa do context necessário para acessar o Inherited.

Get não é melhor ou pior que nenhum gerenciador de estado, mas você deveria analisar esses pontos tanto quanto os argumentos abaixo para escolher entre usar Get na sua forma pura (Vanilla), ou usando-o em conjunto com outro gerenciador de estado. Definitivamente, Get não é o inimigo nenhum gerenciador, porque Get é um microframework, não apenas um gerenciador, e pode ser usado tanto sozinho quanto em conjunto com eles.

Get tem um gerenciador de estado que é extremamente leve e fácil (escrito em apensar 95 linha de código), que não usa ChangeNotifier, vai atender a necessidade especialmente daqueles novos no Flutter, e não vai causar problemas em aplicações de grande porte.

Que melhoras na performance o Get traz?

  1. Atualiza somente o widget necessário.

  2. Não usa o ChangeNotifier, é o gerenciador de estado que utiliza menos memória (próximo de 0mb até agora).

  3. Esqueça StatefulWidget's! Com Get voce nunca mais vai precisar. Com outros gerenciadores de estado, você provavelmente precisa usar um StatefulWidget para pegar a instância do seu Provider, BLoc, MobX controller, etc. Mas já parou para pensar que seu AppBar, seu Scaffold e a maioria dos widgets que estão na sua classe são stateless? Então porque salvar o estado de uma classe inteira, se você pode salvar somente o estado de um widget stateful? Get resolve isso também. Crie uma classe Stateless, faça tudo stateless. Se vocÊ precisar atualizar um único componente, envolvar ele com o GetBuilder, e seu estado será mantido.

  4. Organize seu projeto de verdade! Controllers não devem ficar na sua UI, coloque seus TextEditController, ou qualquer controller que você usa dentro da classe Controller.

  5. Você precisa acionar um evento para atualizar um widget assim que ele é renderizado? GetBuilder tem a propriedade initState assim como um StatefulWidget, e você pode acionar eventos a partir do seu controller, diretamente de lá. Sem mais de eventos serem colocados no initState.

  6. Você precisa acionar uma ação como fechar Streams, timers, etc? GetBuilder também tem a propriedade dispose, onde você pode acionar eventos assim que o widget é destruído.

  7. Use Streams somente se necessário. Você pode usar seus StreamControllers dentro do seu controller normalmente, e usar StreamBuilder normalmente também, mas lembre-se, um Stream consume uma memória razoável, programação reativa é linda, mas você não abuse. 30 Streams abertos simultaneamente podem ser ainda piores que o ChangeNotifier (e olha que o ChangeNotifier é bem ruim)

  8. Atualizar widgets sem gastar memória com isso. Get guarda somente a ID do criador GetBuilder, e atualiza esse GetBuilder quando necessário. O consumo de memória do ID do Get é muito baixo mesmo para milhares de GetBuilders. Quando você cria um novo GetBuilder, na verdade você está compartilhando o estado do GetBuilder quem tem um ID do creator. Um novo estado não é criado para cada GetBuilder, o que reduz MUITO o consumo de memória RAM em aplicações grandes. Basicamente sua aplicação vai ser toda stateless, e os poucos widgets que serão Stateful (dentro do GetBuilder) vão ter um estado único, e assim atualizar um deles vai atualizar todos eles. O estado é só um.

  9. Get é onisciente e na maioria dos casos sabe o momento exato de tirar um controller da memória. Você não precisa se preocupar com quando descartar o controller, Get sabe o melhor momento para fazer isso. Exemplo:

Class A => Class B (tem o controller X) => Class C (tem o controller X)

Na classe A o controller não está ainda na memória, porque você ainda não o usou (Get carrega só quando precisa). Na classe B você usou o controller, e ele entrou na memória. Na classe C você usou o mesmo controller da classe B, Get vai compartilhar o estado do controller B com o controller C, e o mesmo controller ainda esta na memória. Se você fechar a classe C e classe B, Get vai tirar o controller X da memória automaticamente e liberar recursos, porque a classe A não está usando o controller. Se você navegar para a Classe B denovo, o controller X vai entrar na memória denovo. Se em vez de ir para a classe C você voltar para a classe A, Get vai tirar o controller da memória do mesmo jeito. Se a classe C não usar o controller, e você tirar a classe B da memória, nenhuma classe estaria usando o controller X, e novamente o controller seria descartado. A única exceção que pode atrapalhar o Get, é se Você remover classe N da rota de forma inesperada, e tentasse usar o controller na classe C. Nesse caso, o ID do creator do controller que estava em B seria deletado, e o Get foi programado para remover da memória todo controller que não tem nenhum ID de creator. Se é sua intenção fazer isso, adicione a config autoRemove: false no GetBuilder da classe B, e use adoptID = true; no GetBuilder da classe C.

Simple state manager usage

// Crie a classe Controller e entenda ela do GetController 
class Controller extends GetController {
  int counter = 0;
  void increment() {
    counter++;
    update(this); // use update(this) para atualizar a variável counter na UI quando increment for chamado
  }
}
// Na sua classe Stateless/Stateful, use o GetBuilder para atualizar o texto quando a função increment for chamada
GetBuilder<Controller>(
  init: Controller(), // INICIE O CONTROLLER SOMENTE NA PRIMEIRA VEZ
  builder: (controller) => Text(
    '${controller.counter}',
  ),
),
// Inicialize seu controller somente uma vez. Na segunda vez que você for usar  GetBuilder para o mesmo controller, não Inicialize denovo. Seu controller será automaticamente removido da memória. Você não precisa se preocupar com isso, Get vai fazer isso automaticamente, apenas tenha certeza que você não vai inicializar o mesmo controller duas vezes.

Done!

  • You have already learned how to manage states with Get.

  • 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.

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):

class OtherClasse extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return Scaffold(
      body: Center(
        child: GetBuilder<Controller>(
          builder: (s) => Text('${s.counter}'),
        ),
      ),
    );
  }

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>())

class Controller extends GetController {

  /// You do not need that. I recommend using it just for ease of syntax.
  /// with static method: Controller.to.counter();
  /// with no static method: Get.find<Controller>().counter();
  /// 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.
  static Controller get to => Get.find(); // add this line 

  int counter = 0;
  void increment() {
    counter++;
    update(this); 
  }
}

And then you can access your controller directly, that way:

FloatingActionButton(
        onPressed:(){
         Controller.to.increment(), 
        } // This is incredibly simple!
        child: Text("${Controller.to.counter}"),
      ),

When you press FloatingActionButton, all widgets that are listening to the 'counter' variable will be updated automatically.

No StatefulWidget:

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, which will be another StatefulWidget. 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! Unless you need to use a mixin, like TickerProviderStateMixin, it will be totally unnecessary to use a StatefulWidget with Get.

You can call all methods of a StatefulWidget directly from a GetBuilder. If you need to call initState() or dispose() method for example, you can call them directly;

GetBuilder<Controller>(
          initState(_) => Controller.to.fetchApi(),
          dispose(_) => Controller.to.closeStreams(),
          builder: (s) => Text('${s.username}'),
        ),

A much better approach than this is to use the onInit() and onClose() method directly from your controller.

@override
void onInit() {
  fetchApi();
  super.onInit();
}
  • 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. 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.

So to simplify this: 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. 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.

Do not call a dispose method inside GetController, 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:

class Controller extends GetController {
StreamController<User> user = StreamController<User>();
StreamController<String> name = StreamController<String>();

/// close stream = onClose method, not dispose.
@override
void onClose() {
  user.close();
  name.close();
  super.onClose();
}

Controller life cycle:

  • onInit() where it is created.
  • onClose() where it is closed to make any changes in preparation for the delete method
  • 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.
Forms of use:
  • Recommended usage:

You can use Controller instance directly on GetBuilder value:

GetBuilder<Controller>(  
    init: Controller(),
    builder: (value) => Text(
              '${value.counter}', //here
              )),

You may also need an instance of your controller outside of your GetBuilder, and you can use these approaches to achieve this:

class Controller extends GetController {
  static Controller get to => Get.find(); 
[...]
}
// on stateful/stateless class
GetBuilder<Controller>(  
    init: Controller(), // use it only first time on each controller
    builder: (_) => Text(
              '${Controller.to.counter}', //here
              )),
or 

class Controller extends GetController {
 // static Controller get to => Get.find(); // with no static get
[...]
}
// on stateful/stateless class
GetBuilder<Controller>(  
    init: Controller(), // use it only first time on each controller
    builder: (_) => Text(
              '${Get.find<Controller>().counter}', //here
              )),
  • 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:

Controller controller = Controller();
[...]
GetBuilder( // you dont need to type on this way
    init: controller, //here
    builder: (_) => Text(
              '${controller.counter}', // here
              )),

This approach is not recommended, as you will have to manually dispose of your controllers, close your streams manually, and literally give up one of the great benefits of this library, which is intelligent memory control. But if you trust your potential, go ahead!

If you want to refine a widget's update control with GetBuilder, you can assign them unique IDs:

GetBuilder<Controller>( 
    id: 'text' 
    init: Controller(), // use it only first time on each controller
    builder: (_) => Text(
              '${Get.find<Controller>().counter}', //here
              )),

And update it this form:

update(this,['text']);

You can also impose conditions for the update:

update(this,['text'], counter < 10);

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). 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. However, there are situations where you want only the widget where a certain variable has been changed to be rebuilt, and this is what GetX does with a mastery never seen before.

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.

You can use both in any situation, but if you want to tune their application to the maximum possible performance, I would say that: if your variables are changed at different times, use GetX, because there is no competition for it when the subject is to rebuild only what is necessary, if you do not need unique IDs, because all your variables will be changed when you perform an action, use GetBuilder, because it is a simple state updater in blocks, made in a few lines of code, to make just what he promises to do: update state in blocks. There is no way to compare RAM, CPU, or anything else from a giant state manager to a simple StatefulWidget (like GetBuilder) that is updated when you call update(this). It was done in a simple way, to have the least computational logic involved, just to fulfill a single purpose and spend the minimum resources possible for that purpose. If you want a powerful state manager, you can go without fear to GetX. It does not work with variables, but flows, everything in it is streams under the hood. You can use rxDart in conjunction with it, because everything is stream, you can hear the event of each "variable", because everything in it is stream, it is literally BLoC, easier than MobX, and without code generator or decorations .

Reactive State Manager

If you want power, Get gives you the most advanced state manager you could ever have. GetX was built 100% based on Streams, and give you all the firepower that BLoC gave you, with an easier facility than using MobX. Without decorations, you can turn anything into Observable with just a ".obs".

Maximum performance: In addition to having a smart algorithm for minimal reconstruction, Get uses comparators to make sure the state has changed. If you experience any errors in your application, and send a duplicate change of state, Get will ensure that your application does not collapse. The state only changes if the values ​​change. That's the main difference between Get, and using Computed from MobX. When joining two observables, when one is changed, the hearing of that observable will change. With Get, if you join two variables (which is unnecessary computed for that), GetX (similar to Observer) will only change if it implies a real change of state. Example:

final count1 = 0.obs;
final count2 = 0.obs;
int get sum => count1.value + count2.value;
 GetX<Controller>(
              builder: (_) {
                print("count 1 rebuild");
                return Text('${_.count1.value}');
              },
            ),
            GetX<Controller>(
              builder: (_) {
                print("count 2 rebuild");
                return Text('${_.count2.value}');
              },
            ),
            GetX<Controller>(
              builder: (_) {
                print("count 3 rebuild");
                return Text('${_.sum}');
              },
            ),

If we increment the number of count 1, only count 1 and count 3 are reconstructed, because count 1 now has a value of 1, and 1 + 0 = 1, changing the sum value.

If we change count 2, only count2 and 3 are reconstructed, because the value of 2 has changed, and the result of the sum is now 2.

If we add the number 1 to count 1, which already contains 1, no widget is reconstructed. If we add a value of 1 for count 1 and a value of 2 for count 2, only 2 and 3 will be reconstructed, simply because GetX not only changes what is necessary, it avoids duplicating events.

In addition, Get provides refined state control. You can condition an event (such as adding an object to a list), on a certain condition.

list.addIf(item<limit, item);

Without decorations, without a code generator, without complications, GetX will change the way you manage your states in Flutter, and that is not a promise, it is a certainty!

Do you know Flutter's counter app? Your Controller class might look like this:

class CountCtl extends RxController {
  final count = 0.obs;
}

With a simple:

ctl.count.value++

You could update the counter variable in your UI, regardless of where it is stored.

You can transform anything on obs:

class RxUser {
  final name = "Camila".obs;
  final age = 18.obs;
}

class User {
  User({String name, int age});
  final rx = RxUser();

  String get name => rx.name.value;
  set name(String value) => rx.name.value = value;

  int get age => rx.age.value;
  set age(int value) => rx.age.value = value;
}

void main() {
  final user = User();
  print(user.name);
  user.age = 23;
  user.rx.age.listen((int age) => print(age));
  user.age = 24;
  user.age = 25;
}
___________
out:
Camila
23
24
25

Before you immerse yourself in this world, I will give you a tip, always access the "value" of your flow when reading it, especially if you are working with lists where this is apparently optional. You can access list.length, or list.value.length. Most of the time, both ways will work, since the GetX list inherits directly from the dart List. But there is a difference between you accessing the object, and accessing the flow. I strongly recommend you to access the value:

final list = List<User>().obs;
ListView.builder (
itemCount: list.value.lenght

or else create a "get" method for it and abandon "value" for life. example:

final _list = List<User>().obs;
List get list => _list.value;
ListView.builder (
itemCount: list.lenght

You could add an existing list of another type to the observable list using a list.assign (oldList); or the assignAll method, which differs from add, and addAll, which must be of the same type. All existing methods in a list are also available on GetX.

We could remove the obligation to use value with a simple decoration and code generator, but the purpose of this lib is precisely not to need any external dependency. It is to offer an environment ready for programming, involving the essentials (management of routes, dependencies and states), in a simple, light and performance way without needing any external package. You can literally add 3 letters to your pubspec (get) and start programming. All solutions included by default, from route management to state management, aim at ease, productivity and performance. 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. 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. 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.

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.

Simple Instance Manager

Are you already using Get and want to make your project as lean as possible? 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:

Controller controller = Get.put(Controller()); // Rather Controller controller = Controller();

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. So you can use your controller (or class Bloc) normally

controller.fetchApi();// Rather Controller controller = Controller();

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:

Controller controller = Get.find();
//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.

And then you will be able to recover your controller data that was obtained back there:

Text(controller.textFromApi);

Looking for lazy loading? You can declare all your controllers, and it will be called only when someone needs it. You can do this with:

Get.lazyPut<Service>(()=> ApiMock());
/// ApiMock will only be called when someone uses Get.find<Service> for the first time

To remove a instance of Get:

Get.delete<Controller>();

Navigate with named routes:

  • If you prefer to navigate by namedRoutes, Get also supports this.

To navigate to nextScreen

Get.toNamed("/NextScreen");

To navigate and remove the previous screen from the tree.

Get.offNamed("/NextScreen");

To navigate and remove all previous screens from the tree.

Get.offAllNamed("/NextScreen");

To define routes, use GetMaterialApp:

void main() {
  runApp(GetMaterialApp(
    initialRoute: '/',
    namedRoutes: {
      '/': GetRoute(page: MyHomePage()),
      '/second': GetRoute(page: Second()),
      '/third': GetRoute(page: Third(),transition: Transition.cupertino);
    },
  ));
}

Send data to named Routes:

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.

Get.toNamed("/NextScreen", arguments: 'Get is the best');

on your class or controller:

print(Get.arguments);
//print out: Get is the best

Dynamic urls links

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.

Get.offAllNamed("/NextScreen?device=phone&id=354&name=Enzo");

on your controller/bloc/stateful/stateless class:

print(Get.parameters['id']);
// out: 354
print(Get.parameters['name']);
// out: Enzo

You can also receive NamedParameters with Get easily:

void main() {
  runApp(GetMaterialApp(
    initialRoute: '/',
    namedRoutes: {
      '/': GetRoute(page: MyHomePage()),
      /// Important!  :user is not a new route, it is just a parameter
      /// specification. Do not use '/second/:user' and '/second'
      /// if you need new route to user, use '/second/user/:user' 
      /// if '/second' is a route.
      '/second/:user': GetRoute(page: Second()), // receive ID
      '/third': GetRoute(page: Third(),transition: Transition.cupertino);
    },
  ));
}

Send data on route name

Get.toNamed("/second/34954");

On second screen take the data by parameter

print(Get.parameters['user']);
// out: 34954

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

Middleware

If you want listen Get events to trigger actions, you can to use routingCallback to it

GetMaterialApp(
  routingCallback: (route){
    if(routing.current == '/second'){
      openAds();
    }
  }

If you are not using GetMaterialApp, you can use the manual API to attach Middleware observer.

void main() {
  runApp(MaterialApp(
    onGenerateRoute: Router.generateRoute,
    initialRoute: "/",
    navigatorKey: Get.key,
    navigatorObservers: [
        GetObserver(MiddleWare.observer), // HERE !!!
    ],
  ));
}

Create a MiddleWare class

class MiddleWare {
  static observer(Routing routing) {
    /// You can listen in addition to the routes, the snackbars, dialogs and bottomsheets on each screen. 
    ///If you need to enter any of these 3 events directly here, 
    ///you must specify that the event is != Than you are trying to do.
    if (routing.current == '/second' && !routing.isSnackbar) {
      Get.snackbar("Hi", "You are on second route");
    } else if (routing.current =='/third'){
      print('last route called');
    }
  }
}

Now, use Get on your code:

class First extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(
        leading: IconButton(
          icon: Icon(Icons.add),
          onPressed: () {
            Get.snackbar("hi", "i am a modern snackbar");
          },
        ),
        title: Text('First Route'),
      ),
      body: Center(
        child: RaisedButton(
          child: Text('Open route'),
          onPressed: () {
            Get.toNamed("/second");
          },
        ),
      ),
    );
  }
}

class Second extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(
        leading: IconButton(
          icon: Icon(Icons.add),
          onPressed: () {
            Get.snackbar("hi", "i am a modern snackbar");
          },
        ),
        title: Text('second Route'),
      ),
      body: Center(
        child: RaisedButton(
          child: Text('Open route'),
          onPressed: () {
            Get.toNamed("/third");
          },
        ),
      ),
    );
  }
}

class Third extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(
        title: Text("Third Route"),
      ),
      body: Center(
        child: RaisedButton(
          onPressed: () {
            Get.back();
          },
          child: Text('Go back!'),
        ),
      ),
    );
  }
}

Change Theme

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 Get.

You can create your custom theme and simply add it within Get.changeTheme without any boilerplate for that:

Get.changeTheme(ThemeData.light());

If you want to create something like a button that changes the theme with onTap, you can combine two Get APIs for that, the api that checks if the dark theme is being used, and the theme change API, you can just put this within an onPressed:

Get.changeTheme(Get.isDarkMode? ThemeData.light(): ThemeData.dark());

When darkmode is activated, it will switch to the light theme, and when the light theme is activated, it will change to dark.

If you want to know in depth how to change the theme, you can follow this tutorial on Medium that even teaches the persistence of the theme using Get:

Optional Global Settings

You can create Global settings for Get. Just add Get.config to your code before pushing any route or do it directly in your GetMaterialApp


GetMaterialApp(    
    enableLog: true,
    defaultTransition: Transition.fade,
    opaqueRoute: Get.isOpaqueRouteDefault,
    popGesture: Get.isPopGestureEnable,
    transitionDuration: Get.defaultDurationTransition,
    defaultGlobalState: Get.defaultGlobalState,
    );

Get.config(
      enableLog = true,
      defaultPopGesture = true,
      defaultTransition = Transitions.cupertino}

Other Advanced APIs and Manual configurations

GetMaterialApp configures everything for you, but if you want to configure Get Manually using advanced APIs.

MaterialApp(
      navigatorKey: Get.key,
      navigatorObservers: [GetObserver()],
    );

You will also be able to use your own Middleware within GetObserver, this will not influence anything.

MaterialApp(
      navigatorKey: Get.key,
      navigatorObservers: [GetObserver(MiddleWare.observer)], // Here
    );
Get.arguments // give the current args from currentScreen

Get.previousArguments // give arguments of previous route

Get.previousRoute // give name of previous route

Get.rawRoute // give the raw route to access for example, rawRoute.isFirst()

Get.routing // give access to Rounting API from GetObserver

Get.isSnackbarOpen // check if snackbar is open

Get.isDialogOpen // check if dialog is open

Get.isBottomSheetOpen // check if bottomsheet is open

Get.removeRoute() // remove one route.

Get.until() // back repeatedly until the predicate returns true.

Get.offUntil() // go to next route and remove all the previous routes until the predicate returns true.

Get.offNamedUntil() // go to next named route and remove all the previous routes until the predicate returns true.

GetPlatform.isAndroid/isIOS/isWeb... //(This method is completely compatible with FlutterWeb, unlike the framework. "Platform.isAndroid")

Get.height / Get.width // Equivalent to the method: MediaQuery.of(context).size.height

Get.context // Gives the context of the screen in the foreground anywhere in your code.

Get.contextOverlay // Gives the context of the snackbar/dialog/bottomsheet in the foreground anywhere in your code.

Nested Navigators

Get made Flutter's nested navigation even easier. You don't need the context, and you will find your navigation stack by Id.

  • 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.

See how simple it is:

             Navigator(
                key: nestedKey(1), // create a key by index
                initialRoute: '/',
                onGenerateRoute: (settings) {
                  if (settings.name == '/') {
                    return GetRouteBase(
                      page: Scaffold(
                        appBar: AppBar(
                          title: Text("Main"),
                        ),
                        body: Center(
                          child: FlatButton(
                              color: Colors.blue,
                              onPressed: () {
                                Get.toNamed('/second', id:1); // navigate by your nested route by index
                              },
                              child: Text("Go to second")),
                        ),
                      ),
                    );
                  } else if (settings.name == '/second') {
                    return GetRouteBase(
                      page: Center(
                        child: Scaffold(
                          appBar: AppBar(
                            title: Text("Main"),
                          ),
                          body: Center(
                            child:  Text("second")
                          ),
                        ),
                      ),
                    );
                  }
                }),

This library will always be updated and implementing new features. Feel free to offer PRs and contribute to them.