The Android platform has millions of users and is growing each day. With this growth so do the number of people that want to explore the platform by creating their own Android app. While a lot of those people are professional software developers, there are many that have little to no experience in developing and publishing software. This led me to write this series on creating your own Android app: “Creating your own Android app, from vision to reality”
In this series I will be covering the development cycle from concept to deployment. I Will give my recommendations on what steps you should undertake to get your app to the public.
Keep in mind this series is meant to be a helpful guide and not a set of instructions that should be followed exactly step by step. Try out what steps work best for you and I hope you will have a software development cycle that gives great results.
I Hope you will enjoy reading the series as much as I have writing it.
Now comes the technical part of your journey. Actually developing the app can be a difficult task. If you have no programming experience you might want to consider outsourcing the work, but just as the design stage you should not cut corners by taking the cheapest offer. If you are going to hire a programmer to do work on your project make sure to check references. The worst you can do is hire a programmer with little to none experience with working for clients. The problem with not having programming experience and hiring a programmer to create your app is the fact that you cannot evaluate his source code, and that can give enormous problems in the future. Bad programmers might create an app that looks like it’s working but is impossible to maintain. Writing future proof code is something you don’t learn in a week, it normally takes years of experience.
If you decide to do the programming yourself these are some books I can recommend to anyone that is new to the Android platform:
I’ve also compiled a list of useful websites for Android developers in the following post:
Five great websites for Android developers
Before you write a single line of code you should write a technical design document. Writing technical design documents will make writing the actual code much easier. It forces you to come up with solutions to problems before you run into them when programming. This helps you to avoid re-factoring code when working on your project and it speeds up the actual development stage. The technical design document is also a great tool for developing unit tests because almost every feature written in the technical design can be tested with an automatic test.
The technical design document is based on the functional design document. In the technical design you write out exactly how you are implementing all the features. For example in the section “functional design” I’ve mentioned the feature to add, edit and delete contacts, in the technical design you will write out exactly what menu options, action bar actions or other implementations are needed for the feature. You will also write out how data is stored or other technical implementations.
Here is an example based on the contacts feature from the “functional design” section.
Contacts are stored in a database and are available from a content provider:
|Field name||Field type||Allow null||Check|
|first_name||Text||No||First letter must be a capital.|
|surname||Text||No||First letter must be a capital.|
|phone||Text||No||Valid international phone number|
|Text||Yes||Valid email address|
List contacts activity
This activity will have a list view that lists out all contacts sorted ASC by the fields “surname” “first_name”.
|Add||Adds a contact and starts edit contact activity|
|Edit||Edits a contact and starts edit contact activity|
|Delete||Shows confirmation dialog
“Permanently delete contact?”
“Delete contact” “Cancel”
After selecting “Delete contact” the contact will be removed from storage and removed in the list view.
The technical design document gives the programmer something to work with. It makes sure the code written will be created to exact specifications.
Finally you can start coding and actually create a working app. The previous stages will make this step much easier and you will find to be much more productive when you have all the documents and mockups available. I’m not going to going to explain how to program your app, there are far better tutorials and books on this subject (see my recommended books in the introduction of this chapter for example) But I do want to give you a few tips:
Use version control software, this will help you fix bugs in previous versions and guard your source code from mistakes or track down bug. There are many free tools available. I Like to use perforce at home, it’s an easy solution and free up to 20 users.
If you don’t want to run your own source control server Github is a great source control service hosted online.
My second tip is try to create your code future proof. This means it should be able to expand and easy to read when tracing bugs. So make comments in your source code to explain what you are doing, even if you are working on a project alone, and always keep in mind you might want to expand or reuse classes in the future. Also look at your road map, if you know you want to implement a feature in the future you can anticipate and maybe write your code accordingly.
Test early and often is a phrase used with extreme programming and it’s true. You should be testing every time you have written a piece of code that can be tested. This will make your code more robust and you can track down bugs in an early stage. It’s also highly recommended to use unit tests. These automatic tests can track down bugs before you even knew you broke something. Code can get so complex that by re factoring a piece of code you might break something you did not thought of, unit tests help you track down these bugs before you publish your app. A Good start for creating unit tests is your technical design, most tasks described in this document can be translated to a unit test. If you encounter a bug report from a user you can also try to reproduce the bug in a unit test, this will make sure the bug will not be reintroduced in a later version.
The last test phase should include a full test of all features on an emulator and a real device. Always test on a real device before publishing your app, I can talk from experience that some bugs (mainly layout error) might not show up on an emulator. So take your time and make testing a priority on your project, schedule in enough time to go through all the changes before you publish you app.
You should also test your signed package. Compilers can make errors and you do not want to publish an update that might break your database. I Always test the final signed APK by installing it on an emulator, and if the update includes a database update also test updating the app from previous versions and check if the data is correctly updated.
This is a list of resources mentioned in this post.
Till next time
That’s it for this post. In the next chapter I will cover how to deal with changes to the specifications or your app within your development life cycle, you can subscribe to my blog with the RSS icon on the top of this page.
Till next time, happy coding!