@langara properties are methods, in this case

If all the interface really does is to apply some value. i.e you only set, but not actually get, then the

set*

functions might be the way to go. Properties readily provide you with getters, and setters (if var). However, properties are not just that. You can decide what you want to do with the properties in your concrete classes. Delegation, backing field, etc. It all boils down to what it is you really want to achieve In this particular case of view facade, I think what you really want are methods to expose to your presenter

Let's say those are editable by enduser (so we need getters too). Isn't it more concise and idiomatic to use properties syntax instead of set* and get* methods?

Personally, I'd prefer if the interface exposes a method. The presenter can only call these methods, and the actual implementation can decide to do whatever it needs to. The internal detail of the implementor (get, set, what have you) need not be exposed.

Well, your last statements still hold for properties syntax too. Another reason I like properties syntax in such cases is that I can do something like:

operator fun TextView.setValue(obj: Any?, property: Any?, arg: CharSequence) { text = arg }
operator fun TextView.getValue(obj: Any?, property: Any?): String = text.toString()

And then:

class AndroUserDetailsView(layout: View) : UserDetailsView {
  var name by layout.some_edit_text
  var email by layout.some_other_edit_text
  ...
}

While this works, it doesn't look like something I would actually use. Feels like one could easily end up shooting himself in the foot

But that's just my opinion though

I guess I also feel like maybe I'm going a bit too far with this kind of tricks 🙂

Yea Thing is, with Kotlin, there's a lot of tricks one can readily perform. It's left to you to define what is acceptable. And otherwise.

This is influenced by factors like maintenance, team collaboration, etc

what is the standard way to separate code regions in kotlin?

is there something similar to #pragma marks in obj-c?

no

the ide can collapse functions and classes though

but, really i've found that # region (C#) and things like that are just excuses to not make your code cleaner and less coupled

anyone got a recommendation for some library to help show the user around in the ui?

@sreich do you mena like a JoyRide kind of a thing?

@sreich I used this in a project some time ago https://github.com/amlcurran/ShowcaseView

In java there is something like “ClassName.this" - Is there a similar one in kotlin ? please let me know

@aromal.s in kotlin its

this@ClassName

yes it is working !!!! 👍

How do I use Kotterknife in my project? It’s available on Sonatype Snapshots, so I guess I have to add that as a repository in my gradle file somehow?

Never mind, figured it out.

Has anyone tried moving from Android Studio to IDEA for Android dev? With 2016.3 (currently in EAP), the AS 2.2 features were ported, so I'm considering switching.

Also, JRebel for Android is now compatible with IDEA which is nice

@sreich I used to create customView(Activity: receive specific coordinates)

@kirillrakhman Wow! So, Can I use a Android Emulator?? 😀

you always could do that with IDEA. the emulator is not related to Android Studio

When I’m doing dependency injection with dagger2 and my Kotlin class has no explicit constructor, how do I annotate it with Inject? Do I need to declare a default constructor?