Frustrated by fragments? Intrigued by dependency injection? It may be tempting to switch approaches to solve your current pain.
Don’t throw away that code just yet! Think through the following questions first.
1. What problem am I solving?
Sounds simple, but we often skip this basic step! Take time to write out the problems you are facing and a few ways that you might approach solving it.
Great. Now you understand the issue. But is the pain strong enough to invest in using a new framework or different approach? This could lead to rewriting large swaths of your code and may introduce to new and different pains.
2. What behavior needs to change?
Does the solution require huge structural changes? If so, make sure to fully consider your path forward.
For example, Square’s view-based approach requires some combination of custom views, mortar, flow, and dagger (read more here). RoboGuice favors dependency injection and differs from standard Android approaches.
You can start experimenting by creating a small app. See what works for you and what doesn’t. Does it integrate nicely with your testing framework (you are using one, right?)?
Another option is to incrementally work it into your current app. If it causes huge problems, it’s much easier to revert changes in an isolated section.
3. How active is the community?
When you look at the commit history do you see tumbleweeds or a blooming garden? Are fixes merged often? Is the wiki or issues list active? Are conversations happening on Twitter or other social media sites? Are there stack overflow questions with answers?
Is there a supportive community or will you be blazing a trail on your own? There are advantages and disadvantages to both. Large corporate budgets have an easier time absorbing experimental coding approaches than smaller firms.
Related Posts
What do you consider before adapting new approaches? Share your experience in the comments and/or join my mailing list.