I’m working on a new total rewrite of the code of Idea Growr. The main point is that the database will have a new structure that will allow for more question sets and will make it easier to add more features in the future.
A simpler, but slower database
This new update will require a database migration. For the new version I will make use of a library called ActiveAndroid. It makes it much easier to work with the database. A small price to pay, is that it’s slower. Just a couple of microseconds slower for a user. So there is nothing to notice.
The only time when a user does notice the slowness of the library is when all the new ideas will be migrated to the new database. After a number of tweaks I have been able to get the migration time down to 7.5 sconds for the migration of 250 ideas with lots of content for every idea.
To be a lazy coder or not be a lazy coder
The easiest thing for me would be to run this database migration when the user starts the app before any screen is shown to the user.
The disadvantage is that the screen of the user will freeze during this upgrade. Now my question was, how bad would this be? It will require me probably a 16 hours of extra coding and testing to do this differently in a way that gives the user good feedback on what is going on.
So how much would some of the most active users have to wait?
First let me state that I had contact with someone who claimed to have created over 500 ideas. He created 10 ideas every day. So the main goal is actually to see if this is realistic, or if this person was just stating this to impress me.
I track how often the save button is pressed, and it’s true that a couple of users have pressed that button over 500 hundred times. Surprisingly someone also deleted most of those ideas. I don’t know that that means, but it’s still interesting.
Either way, the hundreds of ideas are the most loyal users. If they happen to have a bit of a slow device, perhaps they would have to wait over 30 seconds for their database to migrate. That would give them the idea the app has crashed, perhaps stop the app, and will never have enough patience to do the full update, assume the app is broken and delete it. That way they would lose all their (500+ !!) ideas. Converting my most happy users into the most unhappy users in just a couple of minutes..
So I just wanted to share with you that I will be making the extra effort to give decent feedback on the migration update.
Now my todo list for the Idea Growr update contains:
- Do the database migration the nice way, including feedback on progress
- Build a ‘plan b’ for migration failure, where at least the user can export their ideas from the old database to a text file/e-mail. I can export the ideas from the old database that will not be deleted from the app (since it doesn’t take up much space). I will do many tests on emulators and real devices, and it should be impossible that anything goes wrong. Still, it’s always good to implement a plan B when the consequences of failure are quite profound.
- Update Google Analytics code (there is a new api).
- Update the layout of the app, making consistent use of the Material Design elements.
- Update About texts. Also I will remove the donation button, so I no longer need the in-app payment permission for the app.
- Clean up the translation files (strings.xml)
- Check the feedback e-mails I’ve gotten over the last year and see what features I might be able to do right away and would be put on my todo list.
After that, I can put the update live. For the user the new visual design will be the most prominent update. But for me the database will be the most important part.
After that I’m thinking about adding the following updates:
- ‘Star’ an idea, so you can easily find it back [ DONE ]
- Improved interface for settings, enabling you to select what question sets are shown for every idea. [ DONE ]
- Add images to idea [ DONE ]
- Add audio to idea [ DONE ]
- Add more question sets [ SOMEWHAT DONE ]
These are the things that I know I can do. After that I would have to learn myself some new coding skills. I’ll probably take another look at how a user could back-up and import, or even sync their ideas for different devices. Either by exporting and importing a text file, or by using a service like Dropbox or by developing a proper back-end with a service like FireBase.