Considering contributing, and have some questions about collaboration and culture.

[safield]

Hello!

I have been looking for a open source flutter project to contribute to for a long time. I have not found one yet, because I want to contribute to a project that is something I could also use on a daily basis. This podcast player fits the bill and I am very interested in contributing.

I have developed and maintained three flutter apps professionally, and one in my spare time. My career has found me doing only angular and C# at work, so I am definitely interested in getting back into Flutter for fun. I have looked through this codebase and have a few concerns I would like to bring up, before I actually consider jumping into the code.

Looking through the UI I notice ALOT of very large and sprawling build methods that a quite unwieldy. I think this makes for maintainability and approachability issues. These big, multipage, highly nested build method UI declarations make it very hard for a developer to look at a UI in app, and correlate a certain portion of that UI with the specific section of code responsible for laying out the region of the screen. I think it is a VERY common pitfall that flutter developers fall into, and the alternative I propose is like night and day.

I personally have found breaking out large build methods into bitsize stateless widgets makes for way better readability. These stateless widget do not need to be broken out into a separate file, and can always be private to the file they are being used it. By doing so, I have found I rarely need a build method over ~50 lines of code. Then by naming the stateless widgets very aptly, a developer can easily glance at a widgets build method and easily understand what portion is responsible for what.

Now with all that being said, my actual question is whether or not the existing contributors might be interested further in the UI code best practice I propose here. If so I would love to implement this cleanup on a single widget as an example for other developers to review and see what they think.

[amugofjava]

Hi @safield,

It's great to hear that you are considering contributing to Anytime.

I would agree that there are several UI build methods that are in need of refactoring to reduce their size and complexity, so I would welcome some help with that. It can be difficult sometimes to strike the right balance between reducing the size of a build method to make it more digestible and not having so many break-out widgets that you do a lot of navigating the tree to see what does what.

Do you have a particular build method in mind that you think badly needs refactoring? If you would like to implement a cleanup on a widget as an example, I would be very open to that.

[safield]

Great to hear. When I have time I will do a refactor of one widget with the style I prefer, and then I will submit a PR, and we can use that to discuss your thoughts.