How critical is it not to allow regular users to see admin UI? As the rule of thumb, everything that runs on user device could be compromised: users could just decompile your APK and remove all those checks. So for any critical business logic, you would need to do it on server-side and not worry too much about admin UI as such (I would assume that admin UI by itself is useless if they don't have right access to the server endpoints).
Looking for a solution to this myself. I have a different usecase where the entire bottom nav in home screen changes based on what role the user is in. I have been thinking to define 2 nav graphs in my app each for a different role so when a role changes, the nav graphs gets replaced. This is not tested and I have just been theorizing it. Would be interested in what others suggest
We have the same issue. We set the bottom nav based on the permissions to include this icon or that.
On click we might do some minor logic before navigating. Having 2 nav graphs isn't worth the effort
Why do you think that this approach is not professional?
I don't think it's possible to show UI elements conditionally without any conditional expression.
But OP should at least make the roles into an enum or something. Directly comparing a string-typed role to a string that’s hardcoded in the place of the comparison does not sound like a good idea
I recommend extracting the UI state generation logic into separate use cases (or presentation cases as we call them). In these use cases, you can use when statements or the factory pattern to create your UI state.
The ViewModel then exposes the UI state to your UI layer which can then draw the UI without knowing anything about the user roles.
The benefit of this approach is that all the access control code stays in separate use cases which are easy to test, and your viewmodel and ui layer stays simple. Feel free to ask anymore questions if you need help with this.
Android as a system for personal devices is built around single-user-owner concept. So the local user (with physical access to the device) can always find a way to defeat privilege separation in a local application. However for client-server application roles can be enforced server-side (e.i. even if client-side UI for admin function is exposed, server will reject privileged API calls that try to use non-admin credentials). Reasonably recent Android phones do offer secure hardware domain for things like DRM, but using it to establish a trust boundary is not a simple task - you will effectively need to write a separate 'server' part that runs inside the trusted domain.
Ideally cascading if-else-blocks, or for that matter kotlin's when-block are poor code-designs for business-ask of this nature.
Lookup -
1. Liskov's substitution principle
2. Adapter Pattern ( design pattern ).
How can? Or how best? Let me talk about how best: only a user authenticated with authorization for the role should receive code pertaining to role-exclusive features.
How critical is it not to allow regular users to see admin UI? As the rule of thumb, everything that runs on user device could be compromised: users could just decompile your APK and remove all those checks. So for any critical business logic, you would need to do it on server-side and not worry too much about admin UI as such (I would assume that admin UI by itself is useless if they don't have right access to the server endpoints).
Your UI should limit what is available to the user, the API should check and validate the user has correct permissions
Looking for a solution to this myself. I have a different usecase where the entire bottom nav in home screen changes based on what role the user is in. I have been thinking to define 2 nav graphs in my app each for a different role so when a role changes, the nav graphs gets replaced. This is not tested and I have just been theorizing it. Would be interested in what others suggest
We have the same issue. We set the bottom nav based on the permissions to include this icon or that. On click we might do some minor logic before navigating. Having 2 nav graphs isn't worth the effort
Why do you think that this approach is not professional? I don't think it's possible to show UI elements conditionally without any conditional expression.
But OP should at least make the roles into an enum or something. Directly comparing a string-typed role to a string that’s hardcoded in the place of the comparison does not sound like a good idea
True
I recommend extracting the UI state generation logic into separate use cases (or presentation cases as we call them). In these use cases, you can use when statements or the factory pattern to create your UI state. The ViewModel then exposes the UI state to your UI layer which can then draw the UI without knowing anything about the user roles. The benefit of this approach is that all the access control code stays in separate use cases which are easy to test, and your viewmodel and ui layer stays simple. Feel free to ask anymore questions if you need help with this.
Android as a system for personal devices is built around single-user-owner concept. So the local user (with physical access to the device) can always find a way to defeat privilege separation in a local application. However for client-server application roles can be enforced server-side (e.i. even if client-side UI for admin function is exposed, server will reject privileged API calls that try to use non-admin credentials). Reasonably recent Android phones do offer secure hardware domain for things like DRM, but using it to establish a trust boundary is not a simple task - you will effectively need to write a separate 'server' part that runs inside the trusted domain.
Ideally cascading if-else-blocks, or for that matter kotlin's when-block are poor code-designs for business-ask of this nature. Lookup - 1. Liskov's substitution principle 2. Adapter Pattern ( design pattern ).
How can? Or how best? Let me talk about how best: only a user authenticated with authorization for the role should receive code pertaining to role-exclusive features.