flutterflutter-layoutblocflutter-providerproject-planning

Is it convenient to fully code the UI and only after build the Business Logic [Flutter]?


I’m planning the development of my flutter application (solo developer).

It’s going to be a huge project (firestore integration, firebase remote configuration, revenuecat in-app purchases, algolia smart search, etc.) so I’m planning everything properly before the start, so when the project started I have all the steps laid down and I will just have to stick to the plan.

So to recap:

QUESTION

Is it convenient to fully develop the UI before diving into the logic behind the app? By developing the UI, I mean coding all the screens, like logins screen, home screen, even toasts bar to give success feedback to user, etc. So as much as possible the complete definitive UI. And only later build the logic of the app (firebase, models, server interaction, etc.) Is it the best strategy given My situation above mentioned?

P.s. I’m either going to use BLOC or provider for the architecture, would your answer change with different state management libraries?

P.s. 2 I already have ALL the screens fully drawn in Sketch, with color specification, font, font weight, etc.


Solution

  • Your thinking is correct, when working solo, its handy to have all the business logic built before the UI. But, that's so because then your business logic naturally informs your UI choices, thus making your development more coherent.

    But as you mention, you're already done with your mocking up, so I would highly recommend fleshing out the UI first, and then keep hooking up the business logic. This has two benefits, one, it'll let you test the final version of your screens. And secondly, as its a solo project, working on a visually done app really helps motivation.

    Also, regarding BLoC, my personal recommendation is to use it if you have many states, like for example a feed on the homepage, where you're constantly loading posts and updating the state. But if there are relatively few states, say in a feedback form for instance, then you'll save plenty of complexity (and time) by just going for a direct approach.

    Cheers and best of luck!