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

Replace WindowManagerFlags with ndk::WindowFlags #48

Open
MarijnS95 opened this issue Dec 14, 2022 · 3 comments
Open

Replace WindowManagerFlags with ndk::WindowFlags #48

MarijnS95 opened this issue Dec 14, 2022 · 3 comments

Comments

@MarijnS95
Copy link
Member

https://docs.rs/ndk/0.7.0/ndk/native_activity/struct.WindowFlags.html

The ndk crate provides the same bitflag enum based on generated rather than hardcoded constants, albeit without documentation. Should android-activity just use that (after helping the ndk take over the docs)?

@rib
Copy link
Collaborator

rib commented Dec 20, 2022

maybe. I'm a little bit in two minds about whether to go in the other direction though and generally keep the ndk crate as an implementation detail that's not exposed in the public API.

E.g. in the case of the input API I started out by exposing ndk crate types but that's been particularly problematic considering the differences between GameActivity and NativeActivity.

The overall surface area for the android-activity crate isn't that big, so I'm not massively concerned about some redundancy, when it also helps decouple the dependency so we e.g. don't have to worry about synchronizing semver changes.

That said though - On a case by case basis though if it's clear we can just have an enum / bitfield type in one place with docs, and it can be autogenerated and also account for maintaining backwards compatibility (e.g. with non_exhaustive where appropriate) then that should be OK. (In those cases then semver bumps for the ndk create don't actually affect the public API here anyway)

@rib
Copy link
Collaborator

rib commented Dec 20, 2022

the question of exposing the ndk crate API is also relevant here: #45

@MarijnS95
Copy link
Member Author

I feel like the ndk type is the way to go if that API is wrapped directly, which seems to be the case here?

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

2 participants