Comments (10)
This is why I have blocked #273 , currently onBackPressed
API does not cover alot of cases like yours, a new API has to be think here. The currently implementation for the scope of the library, is almost perfect and simple, out of the scope of the library, not much.
from voyager.
I have tested on the Voyager samples, and the back press closes the app when the onBackPressed = { true }
, can you share more examples of your issue?
from voyager.
Sorry, I previously did understand your use case, now I do.
The idea is that when there is only on Screen on the Stack, you will never be notified on the onBackPressed
.
This design is a side effect caused because we want, where there is only one Screen on the stack, fallback to the System back press callback (for example, closing the app)
from voyager.
@DevSrSouza Any reason for that inconsistency? All i want is to close the app's drawer when user go back, but my app only have one activity. Application with single activity is common now with Compose. So Voyager's BackHandler feature is literally useless with any application that has a single activity. I dont think this is a good idea since this "side effect" is not consistent. And instead of
the most cases, you want to user to close the app
I can decide whenever system should have the control over BackHandler. Isn't that much more easier than the current design which I can't do anything. Design should be consistent between activities, not disabled when there's one activity in the stack.
from voyager.
Can you try something like this:
class MyScreenWithDrawer : Screen {
@Composable
fun Content() {
...
val coroutineScope = rememberCoroutineScope()
val scaffoldState = rememberScaffoldState()
BackHandler(enabled = scaffoldState.drawerState.isOpen) {
coroutineScope.launch { scaffoldState.drawerState.close() }
}
}
from voyager.
Yes I'm writing code in expect/actual, that works normally. But it's just uncomfortable
from voyager.
To be clear, Voyager implementation works like this:
BackHandler is only applied when there is more the one Screen in the Stack, if there is only one, then, it is disabled on the system back handler will be executed.
If I recall correctly, the Scaffold API does not hold a BackHandler on it implementation to Close the Drawer, you have to implement by hand.
I can decide whenever system should have the control over BackHandler. Isn't that much more easier than the current design which I can't do anything. Design should be consistent between activities, not disabled when there's one activity in the stack.
Yes, if you want to have your own Custom BackHandler, you can pass the onBackPressed = null
and implement your self how will Pop Navigation and how you will handle the Scaffold state, but your use case, I would recommend using a new BackHandler.
Yes I'm writing code in expect/actual, that works normally. But it's just uncomfortable
Yes, I can see how it can be, but I how the Android implementation works for Compose, with Voyager or without Voyager, this will be the same I think.
from voyager.
I tested here and I was right, without the BackHandler and without Voyager it just close the app.
Screen.Recording.2024-02-28.at.23.52.40.mov
So, the Voyager onBackPressed API is only for navigation purpose.
But still... Even that your use case is not actually a Voyager problem, is how things works in the Scaffold API, there actually is a use case that has a problem with Voyager onBackPressed, is that, when there is only one screen, the onBackPressed
is never called. This would be useful if you want to prompt the user if they are sure they want to close the app for a example, but at same time, it can be implemented by Screen, by using the BackHandler
API.
from voyager.
I tested here and I was right, without the BackHandler and without Voyager it just close the app.
Well sure thing that it will close the app. I'm building my app from scratch that even my Drawer is neither from the Material API nor the Scaffold API, it's customized, I'm not using the API you mentioned. So i need the control over the BackHandler to know when to close my Drawer.
So, the Voyager onBackPressed API is only for navigation purpose.
Right, It's not a big deal to me, I'm just discussing about the consistency of the BackHandler feature, since it's supported by Voyager but useless to me. Have to write expect/actual really lost the meaning of a multiplatform library and an API that it supports
from voyager.
How I mention before, the Voyager onBackPressed
API is only meant for Navigation used. Is different from the BackHandler API.
This is actually something that I have being look into, Being truly honest with your, is not the first time I have complete disabled Voyager backPressed for doing a more specific use case, maybe provide the BackHandler
API as Multiplatform only for Android used can help other uses cases, but I'm not sure this is the right move, because we are providing APIs for Navigation, this can out of the Scope of the library.
from voyager.
Related Issues (20)
- Can't pop root in Compose for Desktop
- [Desktop] Density is not updated on changing the window to a screen with different density
- [KMP ViewModels][Voyager][Koin] Crush if you try to navigate back
- Override the back press in each Screen in Compose Multiplatform HOT 3
- Snackbar overlapped by BottomSheet when using BottomSheetNavigator
- HorizontalPager HOT 1
- [WASM] [Font] tofu are displayed instead of the actual font HOT 1
- Android Activity Lifecycle events stop being forwarded by AndroidScreenLifecycleOwner after screen rotation
- BottomSheetNavigator - IOS Build error HOT 4
- Navigation testing
- Problem with @Transient during Screen serialization
- 最新版本打包ios 会报错
- Need a dialog box style screen navigator
- Pass data to previous composable screens
- Crash when take picture HOT 4
- Voyager-Worker HOT 1
- Wasm URL routing support HOT 1
- Lifecycle Events Not Triggered During Screen Navigation HOT 4
- ScreenModel function goes into infinite loop when calling from screen HOT 2
- Screen Overridable Content function call multipleTimes when pass data from one Screen to another in Android project.
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from voyager.