This is one of Skoove's mobile development coding challenges.
Your task is to develop an application with a dynamic navigation flow depending on external results & delays.
Please read the root readme file.
The following abbreviations are used throughout the task description
- The
rprefix stands for request, e.g.rLoginresolves to request login
The application consists of several screens that are presented in a specific order. That order depends on various conditions.
-
The app launches
- Launching the application always triggers
rLoginwhich retrieves asessionId. - If the user is a first-time user the app shall present
screenA. - If the user is a returning user the app shall present the last screen of his previous session.
- Launching the application always triggers
-
Screen A
- If user enters
screenAthe app has to fetchrFetchExperimentsunless the result was already fetched and persisted successfully. - The result of
rFetchExperimentsleads to a specificscreenBxscreen.
- If user enters
-
Screen B
screenB1andscreenB2offer several exclusive choices to be selected. Those choices will be submitted viarSubmitSelectiononce the next button is pressed.- After
rSubmitSelectionwas successfulscreenB1leads toscreenC1screenB2leads toscreenC2
screenB3does not execute any requests and leads toscreenC2via the next buttonnoScreenBis a scenario, where no screen is shown. That means it navigates directly fromscreenAtoscreenC2
-
Screen C
- Both
screenCxshould be visible for 3 seconds minimum - Both
screenCxshould automatically navigate toscreenDwhenrLoginwas successful - Both
screenCxshow the selection of thescreenBx. If the path went throughscreenB3please leave the field blank and stretch the text field below towards the top with similar margins.
- Both
-
Screen D
- This screen does not have any interactive / automated behavior nor does it offer a back button
-
General
- Some screens support a back button, some don't.
rLoginshould have a retry logic (the other requests should fail after 1 try)- Contents of the the large text fields can be any lorem ipsum text
- The background colors of the screens don't have to match the exact rgb codes from the diagram.
-
Tips
- It is recommended to start the development of the mobile application with the network connectivity being hidden behind an abstraction layer and firstly being implemented by a simple, configurable, local mock. Once all functionality is verified with this non-networking implementation, the real network implementation can be added. Please preserve both implementations.
- Take into account that the server may respond with errors and varying response durations.
- Reuse components wherever applicable.
Here is an overview of the separate screens:

The server returns information for the requests mentioned above (e.g. rFetchExperiments).
You can find a server in the subfolder server. To start the server in a normal operating mode simply execute
npm install
node server.js
The local machine will serve the following endpoints with randomized delays (between 1 and 15 seconds) and randomized return values (success vs. failure and specific return values):
http://localhost:3000/rLogin
http://localhost:3000/rFetchExperiments
http://localhost:3000/rSubmitSelection
If you want to force the server to behave in a specific manner please use the following arguments
node server.js x y u v a b
x - override for rLogin delay
y - override for rLogin success
u - override for rFetchExperiments delay
v - override for rFetchExperiments success
a - override for rSubmitSelection delay
b - override for rSubmitSelection success
As an example node server.js 3 false 15 true 4 false will lead to a behavior that
- every
rLoginrequest returns an error after 3 seconds - every
rFetchExperimentsrequest returns successfully after 15 seconds - every
rSubmitSelectionrequest returns an error after 4 seconds
