The Android Development Studio ecosystem does not fully maturely support cross project commonalities, but they are getting there. As a result I find I still have to go back and migrate older projects to my more “modern” or better informed way of tackling a particular problem.
You are always learning better ways to implement your apps. The more you code, the better you are able to compartmentalise code, abstract out commonalities and encourage code reuse.
As an independent developer in a team of size 1 (there really is only “me” in team (as well as lots of tea)), efficient use of time is everything. Time spent updating code that is not causing any problems in production, but is becoming more and more a maintenance headache when I want to add a “modern” Android feature to it, is time not spent developing the next app, marketing existing and future apps or spreading the word of other independent developers working on nice concepts. We all have to support each other.
So there is always a decision to be made:-
- Pull that codebase up to the current way of working and make future work easier
- Take the hit when you want to put that new feature in.
- Work the codebase as and potentially hack the new feature in
- Leave the feature out
It is often not easy to see how much work modernising the code will be and sometimes you just have to make a start and see how much pain it is. Sometimes this turns out to be too much pain and you have to abandon that branch or rework or backup and revert the stream (if you don’t like branches) and leave it for another day.
We’d always love to say that we analyse, design in and foresee all problems, but as a resource stretched indie developer, time to market and growing that market is key, so great intentions sometimes get nudged aside and it’s down to experience to know what corners can safely be cut.
You can take a look at my work on Google Play
My latest app is “Your word against mine”. A word search and creation game with a new tactical mode featuring an AI opponent.