Week 3: How to Create an App in 24 Hours
When a freelancer or employee of a company works on a mobile application, it is more often than not a large undertaking. Multiple developers are involved, a large set of features is requested, and most importantly, it takes a long time to create a finished product.
However, there are many problems that each and every one of us faces every day that can be solved with mobile applications. Furthermore, these problems can be solved with small amounts of code and little overhead. We should embrace the fact that mobile apps are tools that improve your life. Therefore, if you have a small problem that can be solved using your phone, why not quickly develop a solution?
In this week’s tutorial, we will cover the process of developing an Android application in less than 24 hours. By considering the points made below, you too should be able to create a quick application that can solve a small problem in your own life. To see what I came up with, keep reading, or view the code here:
1. Find a real world problem that is relevant to you
I recently found a problem in my everyday life that could be solved with a quickly-made mobile application. Every day I use my whiteboard to record the tasks and jobs that I need to do within the immediate days, as shown in the image above. While I uses services such as Trello and Todoist to organize all of my tasks over a longer period of time, I like to write down the small and specific tasks that I might do during the day. For instance, I am not going to put reading time onto my Trello board, but I certainly want to remember to do it during the day!
However, you can see that there are quite a few issues with using this whiteboard model for organization. My handwriting is awful, and so sometimes tasks get lost or unreadable. When tomorrow becomes today, I need to move all of the items from tomorrow into today, and from overmorrow (I am very proud of finding this word by the way) to tomorrow, once again opening up a chance for error to occur. Finally, my friends often like to draw obscenities on my whiteboard, making my attempts at organization futile.
With only four categories of tasks (today, tomorrow, overmorrow, and completed), I thought that it would be quite easy to make an application that kept track of these tasks for me. I therefore made an app, or tool, called Morrow.
2. Make a realistic plan
After you figure out which problem you would like to solve, it is important to devise a solid plan for developing your application. You should plan out the basic features and functionality that your tool should include, and also work out some of the details on how you will develop each of these features. For instance, the features and methods for developing Morrow were as follows:
- Should be able to create new tasks - Use a floating action button + material dialog
- Tasks should be editable - Use a dialog which allows the user to change the day and task content
- Provide some quick actions, such as making all tasks due today, completing all tasks, and deleting all tasks - Use an Android options menu to provide these options
These were the three main features that I wanted to support within my application. A key point here is that you need to decide how feature-rich your application needs to be. In the case of building a tool for your own personal use, with your goal being to finish it in a quick manner, you will need to figure out when the right time is to stop adding more features! Most importantly, you also need to realize your limitations in this step; don’t overestimate your abilities, since bugs and roadblocks may be common, even for a seasoned developer!
Using this list of features, you should at least have a general plan in your head for tackling the development of this application. If it helps, make a todo list where you break down these tasks even further into their development-specific components. Reference this list as you develop the application. I hear that there is this cool new application called Morrow that might help with this task planning.
3. Stay organized
After you devise a plan for your personal application, it is important that you begin development in an organized manner. If your programming or design process leads to a messy pile of work, about halfway through you may get stuck and confused with your own code. Even within 24 hours, it is extremely possible that you will not remember a piece of code that you wrote near the beginning of the process.
In developing Morrow, I stayed organized in three primary ways. First, I decided to tackle the main design and graphics that I would need within the application. Since I use Sketch, I made sure to keep a page with all of my iconography and ideas for the application. By keeping everything organized in one place, I was able to quickly iterate on icons and designs throughout the project.
The second way that I stayed organized was through file choice and documentation of my code. Before even writing my code, I wrote class stubs and method stubs that outlined the general functioning of my application, along with documentation for each. This step only takes about 15–20 minutes, and seeing the layout of your entire application from the code viewpoint is incredibly helpful in finding initial infrastructure and design bugs.
Finally, the third way to stay organized is to think ahead. I cannot stress this point enough; thinking ahead during development is the easiest way to avoid cluttered and non-DRY code. For instance, take this code snippet that I wrote about halfway through the development process:
I was setting listeners for buttons within a dialog that I had made (when a button is clicked, it is changed to look ‘selected’), but initially I decided that I would simply test it for one button, rather than handling all buttons. Because of this mindset, I created a block of code that I then copied and pasted for each other button. If I had redone this piece of code, I certainly would have simply reset all buttons with one loop, and then applied changes to the selected button. If I had looked ahead to the functionality of the other buttons, I could have avoided this issue from the start.
4. Know when to stop
While developing the application, I thought of a few additional features for my application:
- Add an “after overmorrow” category
- Allow syncing of the tasks across devices
- Provide both day and night modes for the UI (i.e. a dark theme vs a bright theme)
While these would be cool features to implement, you must always decide when to stop. Without this point, you will never stop developing your app! Just like a piece of writing that you can continuously reread and make many edits to, software can be continuously iterated upon. If you do not choose when to stop developing, you will continue to add more features, which introduces more bugs, which introduces more coding. At some point, it’s good to say “The app has the features and stability that I am looking for; let me take a break and test it out.”
5. Support extendability
Although you should choose when to stop, this doesn’t mean that you shouldn’t pick up the development at some point later in time! You may find that your software might be useful to other people, or that you have some free time to add additional features. It is important to keep this in mind while you develop the application. Do not hardcode everything, and write your code in a way that promotes the ability to extend your application to new areas. Modularize your software, which results in ease-of-development should you return to your code.
Conclusion
Through this tutorial you learned about the main points that you should focus on if you decide to develop a quick tool for personal use. Most developers get caught in this mindset that software development is meant for large projects and products, but more often than not, we can improve our lives through the development of a small application. Just as a reminder, here are the main points for this type of development:
- Find a real world problem that is relevant to you
- Make a realistic plan
- Stay organized
- Know when to stop
- Support extendability
Thanks for reading this week’s post, and I hope to see you next week!