hyperoslo / android-playbook Goto Github PK

Standardize how we do bracketing in general and ifs in particular.

//oneliners
if (foo) doSomething();
else doSomethingElse();

//no brackets
if (foo)
    doSomething();
else
    doSomethingElse();

//brackets
if (foo) {
    doSomething();
}
else {
    doSomethingElse();
}

• Never hardcode color/textColor/textSize in XML layout. (source code is not allowed either)

• Use styles, but don't combine layout related attributes. Such the following

  <item name="android:layout_width">match_parent</item>

• For resources names (both file names & entry names) such as layout, drawable, styles and color, use prefix, if it's a project comprises multiple modules, to avoid naming collision.

I'm guessing we all agree on using spaces, not tabs, for indentation, right? Good. 👍

However, while the Java convention for indentation is four (4) spaces, I personally think that's a bit overkill. Two spaces for indenting code blocks actually feels more readable to me and also keeps lines shorter (so I guess it sort of ties into #3 in that sense). Would love to hear your thoughts on this.

• What do we name our packages?
• When do we create packages?
• What do we put in the packages?

And I'm sure there are more things to application structure than just packages. 😃

What do you think about the formatting for data classes ? Which one do you prefer ?

data class ProductColorBlock(val title: String, val description: String, val products: Array<Product>,
                                                val colors: Array<String>, val link: String)

vs

data class ProductColorBlock(
        val title: String, 
        val description: String, 
        val products: Array<Product>,
        val colors: Array<String>, 
        val link: String
)

Per the current guidelines, we should “always” lazily initialize member variables. However, I'm not sure if this is a good idea. I agree that we should lazily initialize final members that cannot be initialized in a constructor (quite common in Android, due to the framework not being available until a hook method like onCreate has been called), and in those cases the lazy delegate is awesome. But for cases where you can directly initialize members in a constructor (init { ... }) or even directly when declaring it, I prefer those methods.

As far as I can see, there are two main ways of doing null checks in if statements and the like:

fun main(args: Array<String>) {
    val swag: String? = null

    // The King of Rock way
    if (swag?.isNotBlank() ?: false) {
        println("Hello, world!")
    }

    // The standard/Java way
    if (swag != null && swag.isNotBlank()) {
        println("Hello, world!")        
    }
}

Which one do you prefer? Albeit a teensy bit strange, I definitely think I prefer the second example with the Elvis operator.

For example:

• Should view classes have a “View” postfix (e.g. CommentView)?
• Should instance variables be prefixed with “m”s (e.g. mSubmitButton)?

Static object could be recycled when the app is in the background at any time. If the states of the static object is changed. Such changing will be lost.

What do you think @Damian-Lopata @ealmdahl @sindrenm @jeantuffier

• Tabs vs. spaces
• Number of spaces per indentation
• Indentation rules for multi-line statements

It would be nice to have naming conventions, application structure conventions and version conventions, as well as guidelines and walkthroughs as to how to create new modules in Android Studio, how to handle deployment, where to deploy etc. 😃

Some examples of libraries can be:

• Picasso vs. [Volley] for image loading
• Otto as an event bus
• Retrofit for dealing with REST APIs.
• OkHttp for other HTTP calls
• ActiveAndroid for Object-Relational Mapping (ORM) vs Realm

I propose to avoid using butterknife. Because they can't be used in modules, which means if we are going to refactor some code as a reusable module, it would be painful.

This ties into issue #1 (and maybe also #2?) and puts whatever we figure out there in a format file for Android Studio. By importing that file once, we'll be able to use the auto-formatter to make the file look the way it's supposed to look.

It's supposed to be relatively simple to automatically test Android apps these days. Let's dig into that and see if we can figure out some good conventions and best practices, then jot them down here for future reference. 😃

Particularly with regards to capitalization. Use the textAllCaps property for TextViews for relevant views?