Android Friday: Things I want to see in the README file

parchment-with-quill.png

Some level of documentation is necessary in software projects.

We like to say that “the code should speak for itself” and “docs always get outdated anyway”. Both of these arguments are valid, but they should not be an excuse to drop documentation altogether.

Having some documentation in place both:

A) makes it easier to onboard new colleagues,

B) gives you checklists for critical tasks, and

C) makes it easier to get back up to speed again if you’ve been away from the project.

At a minimum, I expect to see the following points covered in Android README files:

Continue reading “Android Friday: Things I want to see in the README file”

Programmer Friday: Make it work, make it right, make it fast

twistypath.png

When you build software, it’s easy to get wrapped up in the wrong details or to get ahead of yourself.

Programmers sometimes optimize code prematurely. Or we apply unnecessary patterns, structures and frameworks. This makes our work more complex than it needs to be.

Newer programmers seem to fall into this trap more, but experienced people also get things mixed up occasionally. I certainly do. So: one thing at a time. Continue reading “Programmer Friday: Make it work, make it right, make it fast”

Android Friday: Help your designer bridge the app gap

ravine.png

Sometimes you, the Android developer, will work with designers who have the time and knowledge to think of everything. They create complete, detailed designs for every screen and interaction. They cover both web, iOS and Android. They regularly use both Android and iOS themselves. They understand the strengths and conventions of each platform.

These projects are delightful. Unfortunately, all projects are not like this.

Continue reading “Android Friday: Help your designer bridge the app gap”

Programmer Friday: Estimating 101

close_measure_stick.png

How do you determine how much time you need to build a piece of software?

We sometimes need to know roughly how long something will take before we start working on it. This is basic product management. “This new feature will take more than four months to add to our product? Maybe we have better things to do with our time, then.” The viability of a new project, product or feature is (in part) derived from the initially estimated cost of building it.

I’ve settled on the following approach for doing estimates: Continue reading “Programmer Friday: Estimating 101”

Android Friday: Let Activities encapsulate their creation

stone-doors-within-doors.png

Opening screens from other screens in Android apps is straight forward: create an Intent object, stuff some parameters into it, use it to launch the other Activity, and dig out the passed parameters at the other end.

Unfortunately, if you blindly follow Googles standard examples of how to do this, you will end up sprinkling potential bugs around your codebase. Let’s look at how to tighten it up a bit.

Continue reading “Android Friday: Let Activities encapsulate their creation”

Android Friday: How should you distribute test builds of your app?

delivery.png

Your company is developing an Android app. Along the way you want to distribute test builds of the app. The designer needs to do user testing out in the field, the backend developer wants to end-to-end-test the whole system from the app… oh and by the way: the CEO wants to check in periodically as well.

If you were building a web-app it would be easy: just email a link to everyone.  Distribution happens every time they reload their browser. However, with native apps you need to periodically push out new versions of the app to their phones.

Continue reading “Android Friday: How should you distribute test builds of your app?”