thats true but that option is not cool when you have a lot of params

I know that this is not the case

@danielgomezrico: It depends on what your planning to do. the second version can be more efficient if you have to deal with a lot of requests, since you don’t have to fetch the video from a datastore (assuming the video is persisted somewhere and a request only provides a videoId but not the Video object).

if you know that you’re only going to like videos with this method (makes sense as it is named

like

) you could also create a data class called

VideoLikeRequest

,

VideoLikeContext

, etc. . In case you have to add parameters you don’t have to change the interface (which is often cumbersome). This could silently break clients, but if you use data classes it won’t compile anyway, since the constructor changes.

Not sure if this belongs in this channel but trying to do some delegation and this is what has been achieved:

class FilterView(context: Context?, private val viewItem: ViewItem = ViewItem()) : SimpleDraweeView(context), Item by viewItem {
    init {
        viewItem.view = this
    }
}

ViewItem

needs the current

View

so this is the workaround that I've come up with. However, lint complains that "CustomView is missing ... constructor used by tools". So, is there a better way to do this? I also doubt that this might cause issues for the Android framework.

oh wow, custom setters are not available for properties with

lateinit

it't a case of leaked

this

?

Don't think it's a leak. The delegate takes the

View

and makes some modifications to it. It doesn't seem to be possible to refer to the

View

during construction so had to do it this way. I'm worried if it would cause issues during

View

recreation.

Quick question. The Kotlin reference docs for Collections has this line:

For creating maps in a not performance-critical code a simple idiom may be used:

mapOf(a to b, c to d)

What would be the preferred way to create a map in performance-critical code?

Not sure, but probably the standard Java way of adding pairs one by one

In that case, I guess you’d have to use a mutable map while building out the key-value pairs, but then you could assign the map back to an immutable reference so that you have a read-only view.

Something like this:

val readOnlyMap: Map<String, String> = with(HashMap<String, String>()) {
        put("first", "john")
        put("last", "doe")
        this
    }

If I understand correctly, it’s not technically immutable, but it’s at least a read-only view, and this construction is possibly more performant than creating a

Pair

for each entry via

to

.

val readOnlyMap: Map<String, String> = HashMap<String, String>().apply {
        put("first", "john")
        put("last", "doe")
    }

Use

apply

rather than

with

here. 🙂

Why not just

val readOnlyMap = mapOf(
    "first" to "john",
    "last" to "doe"
)

because the initial question ^^

Assuming pair creation is the slow bit in performance critical paths is jumping the gun

also if the map is that simple why not just create a dataclass instead

Is

0.002

milliseconds your bottleneck?

If so you have a nice life

hi all

is there a way to beautify this code?

val html = URL("<http://mysite.com>")
      .openConnection()
      .inputStream.use {
        InputStreamReader(it).use {
          it.readText()
        }
      }

    return object {
      val html = html
    }

why do you return it like this?

it is a Sping rest controller, I want to return JSON

@RestController
class LookupPropertyHandler {
  @RequestMapping("/api/lookup", method = arrayOf(RequestMethod.GET))
  fun handle(@RequestParam address: String): Any {
    val html = URL("<http://mysite.com>")
      .openConnection()
      .inputStream.use {
      InputStreamReader(it).use {
        it.readText()
      }
    }

    return object {
      val html = html
    }
  }
}

you could at least use

URL.openStream

Scratch that, kotlin provides a

URL.readText

fun. 🙂

So your code becomes:

return object { val html = URL("blabla").readText() }

. Tho you probably want to use some caching/retry/blabla layer?

wow, that’s awesome

It's kotlin

thanks