Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Scaffold's drawer opening is not added to navigation stack #24

Closed
svadhis opened this issue Mar 21, 2020 · 11 comments
Closed

Scaffold's drawer opening is not added to navigation stack #24

svadhis opened this issue Mar 21, 2020 · 11 comments

Comments

@svadhis
Copy link

svadhis commented Mar 21, 2020

I don't know if this is intended, but opening a Scaffold's drawer doesn't add to the navigation stack, while Flutter default navigation does.

Navigator.pop(context) // closes the drawer in Flutter navigation
Get.back() // ignores the drawer in Get navigation
@jonataslaw
Copy link
Owner

Flutter creates a GlobalKey navigation for Drawers, another for snackbars, another for dialogs, another for bottomsheets, and accesses each one through the context. 'Get' goes contrary to this, and to save memory, put it all together in a single globalKey, instead of having one for each thing (since the documentation itself explains that globalKeys are expensive and should be avoided, but navigation unlike Framework that is incredible, falls short in several aspects). Drawer is not part of Get yet, so I have two options: add it to the package (I'm very busy, I wouldn't be able to do it in less than 1 month) or add the context as an option for to/back, to do as in the main navigation, navigate through the Navigator widget, passing the context than GlobalKey is using.
This looks ugly hack, but if it is a problem for you to wait, let me know I can do it in minutes.

@svadhis
Copy link
Author

svadhis commented Mar 21, 2020 via email

@jonataslaw
Copy link
Owner

It is not necessary to add Drawer to Get, because it uses the root browser, which in this case will be Get.
In the test case, Get.back (); had the same behavior as Navigator.pop (context);

void main() {
  runApp(MaterialApp(
   home:MyHomePage(),
    navigatorKey: Get.key,
    navigatorObservers: [
      GetObserver(), 
    ],
  ));
}

class MyHomePage extends StatelessWidget {
  MyHomePage({Key key}) : super(key: key);

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(title: Text("test")),
      body: Center(child: Text('My Page!')),
      drawer: Drawer(
        // Add a ListView to the drawer. This ensures the user can scroll
        // through the options in the drawer if there isn't enough vertical
        // space to fit everything.
        child: ListView(
          // Important: Remove any padding from the ListView.
          padding: EdgeInsets.zero,
          children: <Widget>[
            DrawerHeader(
              child: Text('Drawer Header'),
              decoration: BoxDecoration(
                color: Colors.blue,
              ),
            ),
            ListTile(
              title: Text('Item 1'),
              onTap: () {
                // Update the state of the app
                // ...
                // Then close the drawer
                //Navigator.pop(context);
                // Get.back();
              },
            ),
            ListTile(
              title: Text('Item 2'),
              onTap: () {
                // Update the state of the app
                // ...
                // Then close the drawer
                Get.back();
                // Navigator.pop(context);
              },
            ),
          ],
        ),
      ),
    );
  }
}

So, closing this.

@success-0627
Copy link

This issue still not fixed.
When drawer closed, controller would be immediately deleted from memory.

@success-0627
Copy link

My get version is 3.21.3

@eduardoflorence
Copy link
Collaborator

@zl910627, I did a test and the controller is not removed from memory when the drawer is closed. Create a new issue and place a sample code that shows this behavior.

@jonataslaw
Copy link
Owner

When the drawer is closed, nothing should be removed from memory. Drawer is not a route.

@success-0627
Copy link

Please try with GetView.
Thank you

@success-0627
Copy link

I just fixed it temporary by putting with permanent option

@success-0627
Copy link

Any update?
Get.back or Navigator.mayPop all same behavior.
They are all cleaning controller from memory when drawer closed.

@eduardoflorence
Copy link
Collaborator

Please try with GetView.
Thank you

I tested with GetView and the controller is not removed from memory, see an example below:

import 'package:flutter/material.dart';
import 'package:get/get.dart';

void main() {
  Get.put(HomeController());
  runApp(GetMaterialApp(
    initialRoute: '/home',
    getPages: [
      GetPage(
        name: '/home',
        page: () => MyHomePage(),
      ),
    ],
  ));
}

class MyHomePage extends GetView<HomeController> {
  MyHomePage({Key key}) : super(key: key);

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(title: Text("test")),
      body: Center(child: Obx(() => Text('Count ${controller.count}'))),
      drawer: Drawer(
        child: ListView(
          padding: EdgeInsets.zero,
          children: <Widget>[
            DrawerHeader(
              child: Text('Drawer Header'),
              decoration: BoxDecoration(
                color: Colors.blue,
              ),
            ),
            ListTile(
              title: Text('Item 1'),
              onTap: () {
                controller.increment();
                Get.back();
              },
            ),
            ListTile(
              title: Text('Item 2'),
              onTap: () {
                controller.increment();
                Get.back();
              },
            ),
          ],
        ),
      ),
    );
  }
}

class HomeController extends GetxController {
  final _count = 0.obs;

  int get count => _count.value;

  void increment() {
    _count.value += 1;
  }
}

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants