You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Ideally, in the Sdk we want to support direct ports of the NBGL Use Case API; this way, most apps can think about what is shown on-screen, rather than how.
A low-level API would force to provide different ECALLs for different devices; while that might be unavoidable for some future applications with specific needs, it's overkill for most apps that just want to show some stuff on screen, and let the user verify.
Therefore, we want our UX ECALLs to be at a pretty high level, as differences between devices (screen size, touchscreen) would be too big otherwise. This will also allow to compile a single binary, and be able to run it on any device supported by the Vanadium VM.
However, the Use Case API does not fit the ECALL model: ECALLs need to use a relatively small amount of memory, since the Vanadium VM has to copy the required arguments to its local memory before calling the corresponding Bolos/Rust SDK functionality. A use case can have an unbounded number of pages, so the description can be too big.
I think the Page API is close to what we want, but it's only for Flex/Stax. On Nanos, the Nbgl Step API is at a similar level of abstraction. A step might involve multiple 'screens', but it's part of a semantically unitary piece of user interaction, with callbacks for the user action.
Therefore, an approach might be to focus on an ECALL to create an object that represents such "steps", mapping to the Step API or the Page API (depending on where the VM is running). The high-level use case API can be built in the V-App Sdk.
The text was updated successfully, but these errors were encountered:
Ideally, in the Sdk we want to support direct ports of the NBGL Use Case API; this way, most apps can think about what is shown on-screen, rather than how.
A low-level API would force to provide different ECALLs for different devices; while that might be unavoidable for some future applications with specific needs, it's overkill for most apps that just want to show some stuff on screen, and let the user verify.
Therefore, we want our UX ECALLs to be at a pretty high level, as differences between devices (screen size, touchscreen) would be too big otherwise. This will also allow to compile a single binary, and be able to run it on any device supported by the Vanadium VM.
NBGL API lhierarchy
However, the Use Case API does not fit the ECALL model: ECALLs need to use a relatively small amount of memory, since the Vanadium VM has to copy the required arguments to its local memory before calling the corresponding Bolos/Rust SDK functionality. A use case can have an unbounded number of pages, so the description can be too big.
I think the Page API is close to what we want, but it's only for Flex/Stax. On Nanos, the Nbgl Step API is at a similar level of abstraction. A step might involve multiple 'screens', but it's part of a semantically unitary piece of user interaction, with callbacks for the user action.
Therefore, an approach might be to focus on an ECALL to create an object that represents such "steps", mapping to the Step API or the Page API (depending on where the VM is running). The high-level use case API can be built in the V-App Sdk.
The text was updated successfully, but these errors were encountered: