Project Status and Roadmap

AFib History

Soon after I began working with Flutter, sometime in late 2019, I began pulling out code that I thought I might re-use in future projects. Over the course of several years, that code evolved into AFib.

Because AFib remained private for an extended period, I was repeatedly able to extensively refactor it. For example, the the idea of the Screen Programming Interface (SPI) and state-testing, one of my favorite aspects of AFib, wasn't introduced until January 2022, and required a massive refactoring of both AFib's inciting app, and AFib itself.

It has now been a significant time since I felt the need to significantly refactor the core, developer-facing aspects of AFib. That, combined with the fact that the context concept should allow new APIs to be introduced while existing ones are preserved for backwards compatibility, makes me cautiously optimistic that despite its alpha status, AFib's core APIs will remain mostly stable.

AFib Weak Areas

AFib was created by a single developer at the time of its release. As a result, it is likely to have significant weaknesses. To some extent, AFib will need to gain additional users with more knowledge if it is to progress.

Some known weak areas include:

Time: AFib's model of time has worked well for me, but I am certain someone with more knowledge will point out fundamental deficiencies in it.
i18n: The app which spawned AFib is english-only. Nonetheless, I introduced a simple model of text translation, as Flutter's core internationalization support did not appear to support custom internationalizations for third party libraries conveniently. This system has been validated by an actual international application, though you are still free to use Flutter's native i18n support.
Incomplete Coverage of Core Flutter Widgets: AFib's UI tests, AFibs AFRouteParamWithFlutterState, and AFibs default theme, all offer incomplete coverage of Flutter's native widgets, limited to those I used in the inciting app. Although you can easily work around this, it would be better to add more complete coverage to AFib itself. If you run into this, submit a bug and/or submit a github change to add the addition widget type.

Candidate Areas for Refactoring

In all the cases above, obvious fixes can be made without significant refactoring. I am not currently aware of any area of AFib that I have a strong desire to significantly refactor.

AFib Roadmap

As of this writing, I am not aware of any major features that I wish to add to AFib. The existing features -- project styles, protoype mode, UI prototypes, state tests, context-development model, documentation, YouTube trailer and tutorial -- currently seem fairly complete to me.

As a result, the things I am most interested in adding relate to project maturity:

Developer Support: As of this writing, my primary goal is to discover whether other developers can derive value from AFib. Consequently, the primary thing on the roadmap is fixing bugs and offering support to developers who try AFib.
Release Inciting App: An equal priority is to finally release the inciting app, which is a consumer-facing application targeted at an embarrasingly small and unattractive market. It is currently waiting on final UI improvements, some potential business partnerships, and my finishing the first release of AFib.
Release of Additional AFib-aware libraries: The inciting app currently uses several more AFib-aware libaries that were designed to be open-sourced when time permits. If AFib werre to gain momentum, I am deeply interested in the idea that AFib-aware libraries from commercial vendors could make it easy to integrate commercial-quality features into AFib apps easily. For example, I am interested in the idea of an Olark chat support integration, a Net Promoter Score Integration, etc.
Improving the weak areas listed above: I would like to improve the weak areas listed above.