-
-

Complex UI management - Stax

+
+

Complex UI management - Flex / Stax

Interacting programmatically with an application tends to be a non-trivial thing, as complex processes (like performing a complete transaction) have to be implemented through low-level actions on the device: forging bytes payloads (the @@ -117,8 +117,8 @@ specifically about the UI, we saw previously that Ragger had some capabilities allowing to cope with simple physical interactions (like on the Nano devices: only two buttons). But what to do with more complex interfaces?

-

In particular, interacting with the Stax screen can be bothersome. It is hard to -track of button positions, pages layouts and such.

+

In particular, interacting with the touch screen devices (Stax or Flex) can be +bothersome. It is hard to track of button positions, pages layouts and such.

Study case

For instance let’s imagine you develop an application with a welcome screen with @@ -169,7 +169,7 @@

Study casePages or UseCase) changes the position - nothing prevents them to move the “info” button to the top left -, all this code becomes deprecated.

-

That’s why Ragger mimics the Stax SDK graphics library and provides +

That’s why Ragger mimics the Flex/Stax SDK graphics library and provides Layout and Use Case (Page will also come soon) classes that keep track of every interactive screen elements and expose meaningful methods to interact with them.

@@ -180,8 +180,8 @@

LayoutsMetaScreen metaclass. For instance, with the previously described application:

-
1from ragger.firmware.stax.screen import MetaScreen
-2from ragger.firmware.stax.layouts import CancelFooter, ExitFooter, InfoHeader
+
1from ragger.firmware.touch.screen import MetaScreen
+2from ragger.firmware.touch.layouts import CancelFooter, ExitFooter, InfoHeader
 3
 4class RecoveryAppScreen(metaclass=MetaScreen)
 5    layout_quit = ExitFooter
@@ -222,7 +222,7 @@ 
Layouts(x, y) positions, so why bother declaring them twice?

 
First of all, the buttons may be at the same place, but they don’t carry the
 same purpose, and it is a good idea to reflect that on the code.

-
Second, if in a future version the Stax design changes and one of these
+
Second, if in a future version the Flex/Stax design changes and one of these
 button moves somewhere else on the screen’s footer, the layouts will be
 updated accordingly in Ragger, and the CancelFooter or ExitFooter
 will still be valid, hence all code using this class remains valid too.

@@ -248,8 +248,8 @@ 
Use casesMetaScreen metaclass,
 and start with use_case_:

-
 1from ragger.firmware.stax.screen import MetaScreen
- 2from ragger.firmware.stax.use_case import UseCaseHome, UseCaseSettings
+
 1from ragger.firmware.touch.screen import MetaScreen
+ 2from ragger.firmware.touch.use_case import UseCaseHome, UseCaseSettings
  3
  4class RecoveryAppScreen(metaclass=MetaScreen)
  5    use_case_welcome = UseCaseHome
@@ -290,7 +290,7 @@ 
All-in-one solution: the 
-
 1from ragger.firmware.stax.screen import FullScreen
+
 1from ragger.firmware.touch.screen import FullScreen
  2
  3screen = FullScreen(backend, firmware)
  4