sessionStateStream issue with Getx about local_session_timeout

[SankethBK]

If you don't use GetMaterialApp this isn't a problem for me.

Cool, I'll raise the fix in 1-2 hours you can test if it solves your issue

[SankethBK]

Cool, I have released the next version 2.3.2 with this bug fix

[SankethBK]

Fyi to reference package from github, add this in your pubspec.yaml

 local_session_timeout:
    git:
      url: https://github.com/SankethBK/local_session_timeout.git
      ref: 44d876f19667100e552a65ee672694939b7ed298 

and run flutter pub get

[FullstackWEB-developer]

Brilliant!
It's working well now.
Thank you for your help.

[SankethBK]

When I call this code sessionStateStream.add(SessionState.startListening) my app refreshes and redirects to the first page.

Is it because of userInactivityTimeout or appFocusTimeout? you can print the timeoutEvent here

     if (timeoutEvent == SessionTimeoutState.userInactivityTimeout) {
        // logout logic
      } else if (timeoutEvent == SessionTimeoutState.appFocusTimeout) {
        // logout logic
      }

where are you calling startListening defined in SessionStateController?

[FullstackWEB-developer]

Hi @SankethBK
Thank you for your reply.

Is it because of userInactivityTimeout or appFocusTimeout? you can print the timeoutEvent here

No, it's only for the sessionStateController.startListening();.

where are you calling startListening defined in SessionStateController?

After logging in to My Project, the dashboard page opens.
So I tried adding it to this part of the dashboard page, but the project structure is completely redrawn and it returns to the initial state when I started the app.

class _DashboardScreenState extends State<DashboardScreen> {
  @override
  void initState() {
    final sessionStateController = Get.put(SessionStateController());
    WidgetsBinding.instance.addPostFrameCallback((timeStamp) {
      sessionStateController.startListening();
    });

    SystemChrome.setPreferredOrientations([
      DeviceOrientation.portraitUp,
    ]);
  }

  @override
  void dispose() {
    super.dispose();
  }

  @override
  Widget build(BuildContext context) {
     ...
  }

[FullstackWEB-developer]

When I debug, it goes to this part and then redraws, so I don't think this is because of Getx.
I am new to this package, are there any other use cases using this package and Getx?

[SankethBK]

Hi @FullstackWEB-developer , ideally calling setState in the package should not cause rebuilds in child. But I think since you're using GetX for MaterialApp, the child widget is no longer treated as a const widget and rebuilds the entire widget tree

[SankethBK]

Can you try replacing GetMaterialApp with MaterialApp widget to confirm if this is the issue

[FullstackWEB-developer]

Hi @FullstackWEB-developer , ideally calling setState in the package should not cause rebuilds in child. But I think since you're using GetX for MaterialApp, the child widget is no longer treated as a const widget and rebuilds the entire widget tree

So how can I fix this?
Shouldn't I use Getx?

Can you try replacing GetMaterialApp with MaterialApp widget to confirm if this is the issue

Let me try but in my project I need to use GetMaterialApp

[SankethBK]

So how can I fix this?
Shouldn't I use Getx?

I mean just to confirm if this is the bug. If using MaterialApp directly solves this issue, I'll raise the fix for this, instead of calling setState in my package, I'll handle it inside _recordPointerEvents function without calling setState

[FullstackWEB-developer]

If I don't use GetMaterialApp this isn't a problem.
But I am not sure how to integrate with Getx without using GetMaterialApp.

[FullstackWEB-developer]

Thanks

[SankethBK]

Try using this commit of the package 44d876f19667100e552a65ee672694939b7ed298, I have removed the setState that fires immediately after calling startListening. If it works I'll remove all setStates they aren't necessary anyway

[FullstackWEB-developer]

Ok
Let me check soon

[SankethBK]

I assume other setStates might be still causing same issue, can you confirm once

[FullstackWEB-developer]

Yes
I checked it

When debugging, these setStates were called, but re-rendering did not occur.
It's currently working well.
Nothing has changed on my end.

[SankethBK]

Great! can you check if it works with this commit as well 9bf30e872b3f8c1a7e662307a3ebbbf2f0598b86, i have removed all setStates none of the expected functionality seems to break, if it works well in your case also I'll make a new release with these changes

[FullstackWEB-developer]

I tested it and it also working now