Kotlin back field

Kotlin中,幕后字段是什么东西?又什么作用????

官方文档 中看到的幕后字段,大大的问号,也看不懂文档,于是我们要去找例子来理解。

这里的例子来自 stackoverflow

需要先去看看官方文档再来看这下面才比较容易

class Sample {
    var counter = 0 // the initializer value is written directly to the backing field
    set(value) {
        if (value >= 0) field = value
    }
}

上面的这种写法产生疑问,为何不能是下面这种写法替代呢?

class Sample {
	var counter = 0
	set(value) {
		if (value >= 0) counter = value // ERROR StackOverflow: Using actual name 'counter' would make setter recursive
	}
}

理由已经再注释中给出了,使用Java代码来解释,如下:

class Sample {
    private int counter = 0;
    public void setCounter(int value) {
        if (value >= 0) setCounter(value);	// 无限递归
    }
    public int getCounter() {
        return counter;
    }
}

再结合下面这些博客看看应该可以进一步理解:
理解 Koltin 中的幕后字段和幕后属性
Backing properties in Kotlin

### EditorInfo in Android Development In the context of Android development, `EditorInfo` is a crucial class that describes attributes of an input field receiving text from an Input Method Framework (IMF). This includes properties such as content type and additional flags affecting how text should be processed or displayed[^2]. The structure within which this information resides can significantly influence interactions between applications and soft keyboards on devices running Android OS. For instance, when developing custom views intended to accept user inputs via touchscreens or other peripherals, understanding what parameters are available through `EditorInfo` becomes essential. #### Key Attributes Within EditorInfo Class Several important fields exist inside the `EditorInfo` object: - **inputType**: Specifies types of data expected by the target view; examples include plain text (`TYPE_CLASS_TEXT`), numbers (`TYPE_CLASS_NUMBER`), phone numbers(`TYPE_CLASS_PHONE`) among others. - **imeOptions**: Defines options related specifically to interaction with IMEs like action buttons shown at bottom-right corner during typing sessions—common values here might encompass "send", "go", "search". - **hintText**: Provides placeholder text visible until actual characters start getting entered into associated UI component. Below demonstrates setting up these settings programmatically using Kotlin code snippet: ```kotlin val editorInfo = EditText(context).editorInfo.apply { inputType = InputType.TYPE_CLASS_TEXT or InputType.TYPE_TEXT_VARIATION_PASSWORD imeOptions = EditorInfo.IME_ACTION_DONE } ``` This configuration ensures any attached software keyboard knows it's dealing with password entry where 'Done' key appears instead of default next/done actions based upon platform conventions. --related questions-- 1. How does one customize appearance aspects linked directly back towards specific instances of `EditText` widgets? 2. What mechanisms allow developers to intercept events triggered after pressing special keys defined under `imeOptions` property? 3. Can multiple different kinds of hints be applied simultaneously onto single editable areas without causing conflicts? 4. Are there scenarios wherein altering `inputType` dynamically post-initialization proves beneficial over static assignments made earlier during layout inflation stages? 5. In terms of accessibility support provided out-of-the-box alongside standard implementations found across various versions of SDK levels supported today, how well do changes propagated via `EditorInfo` integrate overall experience offered end-users relying heavily upon assistive technologies while navigating apps built targeting wide range device profiles?
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值