Altering the Flow of an App
5 screens to 1
--
If you wish to modify the flow of an App there are many different things that you should be aware of and think about before embarking on the change in your latest sprint.
So what should you be thinking about if (say) your login process is to move from 5 screens to a single screen of information?
Estimation of the change
A good rule of thumb is that it can take 3 / 4 days to implement a screen (depending on the features involved) — remember that you need to adequately test the screens and pass through your code review and AQ process before merging into main!
A sprint with 3 screens and a handful of features within the screens can already be quite hectic and developers should ensure that they are not overloaded, especially since a number of busy sprints (releasing on Friday!) can mean that future productivity can experience a negative impact.
Opportunity for improvements
Your application may well benefit from refactoring and quality improvements as you go. While making a change like changing the login process this can be a great opportunity to look at, perhaps dependency injection or
App structure
How has data been passed between the screens? Are we assuming some validation on a previous screen, or is there only a single path through the screens.
Which resources are used within the App? Are there dependencies between these? How are notifications impacted by the change? Are there flows to a specific screen that need to be changed?
Dependencies may be different. If you are making API calls from View Models (and after all, you should be) this may well remove repeated code and slimline your application.
State transitions need to be handled — what will happen in terms of persistence if the App is put into the background while the user is some way through the registration process.
Performance
For something rather simple like a registration screen you would not expect issues with performance. However, adding multiple components into a scrollview can give awful performance…
