Going from an idea in your head to a working application can be an overwhelming project, especially if you've never done it before or are navigating unfamiliar technologies.

This post is aimed at those who have ideas, at least some basic programming ability, and are trying to turn all of that into a usable application. It is based on the road I took and lessons I learned en route to creating my first hobby project application - Owl (check it out here).  If you've built and shipped apps yourself before or if you're trying to build an app to make money from, this probably isn't the article for you. If you're rolling up your sleeves to work on your first (or even second or third) hobby or portfolio project, especially in an unfamiliar technology, then you're in the right place.

1 - Design

It is important to define the requirements and desired behavior of your app up front. Writing this down is helpful to have a fixed point of reference for what you'll be working towards, and putting your goal in words will help when it comes to knowing what to search for when you're working through the "how to do X" phase of the project.

Write this down somewhere you can refer to later. It doesn't need to be formal, but it should be reasonably specific (you can put pieces where the specifics can be defered into "black box" sections to be filled in later). It should cover the cases you expect to need to handle, and should be updated along the way if the application turns in a different direction.

2 - Sandbox

This is the most important thing I learned building my first complete & robust application. What does it mean? As you identify what functionality your app depends on, it's helpful to group these into separate, independent black boxes, and to develop them in separate projects.

For example, if your app is going to need a background service, utilization of sensor input, or any other functionality unit, you'll want to build project which implements the kind of service you need in a verifiable / debuggable way, with just the bare minimum of surrounding functionally and dependencies.

You can even treat these as independent projects for your own education, portfolio, future use in other projects, or even write blogs posts about them! I've done this for the "Importing Contacts in Android" and "Scheduling Recurring Notifications in Android" blog posts (here and here *** if you're interested). journaldev has a great blog with many posts on independent topics that embodies this approach.

This is also helpful when troubleshooting problems. If something is not working, it's helpful to have a setting where your pieces are working with as few complexities and dependencies as possible. This will help when figuring out whether the issue is with your implementation of the specific feature, or with some interaction between the feature and your larger project.

This concept can be extended to include implementing related functionality together, such as with Room and databinding, or Room and LiveData.

3 - Take your time

One of the benefits of building your own app is that you're not beholden to deadlines and external constraints. Use this to do things the right way rahter than the easy way. Don't cut corners & take the opportunity to learn the ins and outs of the technologies you're using. Read actual documentation as well as supporting articles and forum posts / discussions.

Play around with different configurations - experiment & tinker. Without a professional obligation, you don't need to feel stupid cranking out potentially bad code over and over again as you take observe & take measurements. You'll be building a more informed foundation for using the technologies & techniques you're working with. Don't be afraid to get your hands dirty! At the other end of this project you'll have under your belt an actual application of the technologies and patterns you've put into your app, which is the best way to gain a deep understanding you can apply to projects in the futrure.

4 - Don't get bogged down

A bit contradictory to the last one, this. But there is a line (a fuzzy one, perhaps) between them.

You'll no doubt run into issues as you build your first app. Some of these you'll obviously need to solve to get things working. Keep your eyes open for the ones you don't have to solve.

There may be hurdles where, to overcome them & fulfill your original vision for your app would require an increase in scope, added complexity, or a departure from the actual core intent of what you're trying to do.

In an ideal world you'd work out every problem and build everything exactly how you'd envisioned when you stared out. In the real world, you may practically be best served by being open to redesign as you go, shaving off problematic or unnecessary pieces of the project. It's ok for your design to change as you progress in building your application. You may learn new information along the way - maybe something you assumed would be easily doable in fact doesn't have a standard solution. Be guided by this new information, even if that means changing direction in the end.

5 - Finish it!

It may seem strange to call out explicitly, but since many self-initiated projects end in some sort of unfinished state, it's worth calling direct attention to this.

Of course not everything needs to be a fully functional standalone app - sandbox projects are great and you should do lots of them. But if you set out to "build an app", getting across the finish line has tremendous value. Keeping in mind the note in the last section about being open to changes in scope, this should open the door to more potential finish lines.

For a sense of accomplishment, for a boost in confidence, for the experience of solving all the issues along the way, and for being able to say that you actualy "built an app", publishing an actual 1.0 release and everything - finishing an app can have so much more meaning than being in a state of "working on an app" for however long. So do what you can to tie a bow on that thing.

And there we have it! Those are what I found to be the most important points to call out about building a hobby application, having just finished one. Did I miss anything that was part of your app-building experience? I'd love to hear feedback or other perspectives on this - depending on what I learn later, I may post some updates or a part 2 in the future.