1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
|
# Migrations
Below are some highlights on major refactoring/breaking changes
# v5.0.0
## Material Dialog Update
Material Dialog is now 3.x.
This leads to a whole new API, but fortunately it is based around kotlin.
Please refer to [MD's documents](https://github.com/afollestad/material-dialogs/tree/3.0.0-rc2/documentation) for the new methods.
Alongside such changes, `:colorpicker` is no longer as necessary. It exists mainly to provide an internal interface for other submodules.
After Material Dialog 2.x, a decision was made to enforce theming through xml styles only to avoid reflection.
As a result, options to supply custom dialog colors are now removed.
## Update ProgressAnimator
`ProgressAnimator` has been completely rewritten to be an extension of `ValueAnimator`.
This for the most part is not a breaking change, apart from the fact that creating an animator will not start it immediately.
Make sure to call `.start()` to begin the animation.
# v4.0.1-alpha02
* `kauParseFaq` is now synchronous.
## Anko has been removed
A lot of the methods are already implemented in KAU, and it was primarily imported for its `doAsync` methods. Now, they have been replaced with coroutines.
Some methods have been copied over:
* import org.jetbrains.anko.runOnUiThread > import ca.allanwang.kau.utils.runOnUiThread
* import org.jetbrains.anko.contentView > import ca.allanwang.kau.utils.contentView
* import org.jetbrains.anko.bundleOf > import ca.allanwang.kau.utils.bundleOf
# v4.0.0-alpha01
This is the first introduction of androidx. The goal is to just do a migration with minimal changes.
Nothing has been changed internally, but the dependencies are updated.
Notably, Android-Iconics [split their Community Icons](https://github.com/mikepenz/Android-Iconics/blob/develop/MIGRATION.md) into two enums.
Kotterknife is also no longer deprecated. There are some use cases where `kotlin-android-extensions` isn't the best, such as when multiple layout files are used, or when ids are defined in the id.xml.
It is still recommended to use the extension where applicable.
# v3.8.0
Along with the update to support Android Studio 3.1, a lot of changes have occurred with other dependencies and with lint.
## Invalid Resource Id Equality
Resource ids can be negatives due to the bit overflow.
Instead, `INVALID_ID` has been introduced to signify an unset or invalid id.
Methods such as `Context.string(id, fallback)` now check against `INVALID_ID` through equality rather than using an inequality to address this.
## Deprecate Kotterknife
Kotterknife has been deprecated in favour of `kotlin-android-extensions`.
See [official docs](https://kotlinlang.org/docs/tutorials/android-plugin.html#view-binding).
## Update KPref
KPref has been slightly refactored internally.
Preferences backed by `StringSet` can now go back to `Set<String>`
# v3.6.0
## startActivity
Before, startActivity attempted to bind a lot of options with defaults.
Instead, we will now rely on the builder pattern so users may supply their own.
Attributes like `transition` have been replaced with bundle functions such as `withSceneTransitionAnimation(context)`.
The ordering of the builder functions have also been unified so that `bundleBuilder` is always before `intentBuilder`.
## kpref-activity
### Click Events
Instead of passing parameters through the click functions, which were often unused,
they will now be provided through extensions from `KClick`.
`KClick` holds the same values you'd expect (`itemView`, `innerView` (renamed), `item`),
and adds on `context` and is loaded lazily where possible.
### Title Res
In an attempt to make kprefs functional and thus easy to configure,
two new functions, `titleFun` and `descFun` have been introduced.
They will be triggered whenever kprefs are updated to get an up to date stringRes
based on whatever conditions you specify. Most conditions are passed through anyways,
which is why these functions supply no additional information.
You are still free to use the original `descRes`
and the constructor title, which has been renamed to `titleId` to emphasis its immutability.
Reloading kprefs are always done through the original `titleId`,
regardless of the actual resource currently used.
|
