This PR adds a support for custom clock renderers. A clock renderer become stateless (it was connected with the view before). An user can easily change default clock renderer to preferred one. But the render performance may degrade a lit bit because of virtualization.

By doing so, we could improve rendering speed a little bit.

Benchmarks

• ZTE Blade V9 (API 27): old -> 203,021 ns new -> 196,979 ns
• Huawei ATU-L32 (API 27): new -> 267 188 ns old -> 269 167 ns

Benchmark

This bechmark checks rendering speed on bitmap. This is not 'pure' benchmark' but if we make such one, obviously getting values from array is faster than calling trigonometric functions.

If invalid value is passed to enum property, we will get a build error: AAPT: error: '420' is incompatible with attribute trp_hourFormat (attr) enum [FORMAT_SYSTEM=0, FORMAT_12=1, FORMAT_24=2]

Code:

<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:app="http://schemas.android.com/apk/res-auto"
    xmlns:tools="http://schemas.android.com/tools"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    tools:context=".MainActivity">

    <nl.joery.timerangepicker.TimeRangePicker
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        app:trp_hourFormat="420" />

</LinearLayout>

But, nevertheless, if we pass a reference to integer with invalid value, we won't get any build error and code compiles successfully: ints.xml

<resources>
    <integer name="some_invalid_value">3</integer>
</resources>

activity_main.xml

<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:app="http://schemas.android.com/apk/res-auto"
    xmlns:tools="http://schemas.android.com/tools"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    tools:context=".MainActivity">

    <nl.joery.timerangepicker.TimeRangePicker
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        app:trp_hourFormat="@integer/some_invalid_value" />

</LinearLayout>

Full code

In runtime, we will get exception with no message:

     Caused by: java.lang.IllegalArgumentException
        at nl.joery.timerangepicker.TimeRangePicker$HourFormat$Companion.fromId(TimeRangePicker.kt:1160)
        at nl.joery.timerangepicker.TimeRangePicker.initAttributes(TimeRangePicker.kt:147)
        at nl.joery.timerangepicker.TimeRangePicker.<init>(TimeRangePicker.kt:114)
        at nl.joery.timerangepicker.TimeRangePicker.<init>(TimeRangePicker.kt:39)
        at nl.joery.timerangepicker.TimeRangePicker.<init>(TimeRangePicker.kt)

Library tries to handle such cases but unsuccessfully: https://github.com/Droppers/TimeRangePicker/blob/a5c73dbbcb87dcc6b5d1c1f1f5b57e5c330bccd9/timerangepicker/src/main/java/nl/joery/timerangepicker/TimeRangePicker.kt#L135-L140 https://github.com/Droppers/TimeRangePicker/blob/a5c73dbbcb87dcc6b5d1c1f1f5b57e5c330bccd9/timerangepicker/src/main/java/nl/joery/timerangepicker/TimeRangePicker.kt#L1081-L1086

Method fromId never returns null, but throws exception with empty message on invalid value, but initAttributes expects that fromId returns null and assignes default value (HourFormat.FORMAT_12) if returned enum value is null.

So, what's expected behavior? To leave default value, or to throw exception. If the last one, it's better to throw exception with some message like 'Invalid attribute value(trp_hourFormat=value)'

When a user drags thumbs, obviously, the entire view is re-drawn. When a user interacts with the picker, clock settings are not changed. So we can cache clock in a bitmap. With bitmap cache, much fewer computations happen. But re-sizing becomes much more expensive. If caching bitmap is not preferred, it can be disabled.

For example expression 2.px tells nothing about from what to what unit we convert. It's better to use dpToPx name. This name tells us that we convert from dp to pixels. Everything is clear. Int.dp -> pxToDp(Float): Float Int.sp -> spToPx(Float): Float

And argument and return type are changed to Float, because more often we use Float, not Int

There are few cases in code where exprensive functions are called twice for the same angle. Newer runtimes are able to optimize such cases and speed of my version and current one will be the same. But older runtimes cannot do that.

Benchmarks:

In drawTicks (Benchmark):

• Fly FS504 (API 21): current - 1 655 ns new - 677 ns
• ZTE Blade V9 (API 27) current - 426 ns new - 198 ns

In differenceBetweenAngles (Benchmark):

• Fly FS504 (API 21): current - 2 982 ns new - 1 830 ns
• ZTE Blade V9 (API 27): current - 436 ns new - 425 ns

As you can see, newer runtime optimized differenceBetweenAngles and speed is almost the same

This PR changes the implementation of parseTimeString (parsing time is not something complex like parsing e-mail and it can be replaced to simpler implementation). For testing and architectural reasons, it can be exposed and moved to companion object of TimeRangePicker.Time. To ensure that new method works in corrent way, tests was added.

I have noticed that ClockRenderer allocates memory during drawing the clock, which is not good. This PR fixes it. Besides, I have optimized it a little bit.

While using the library, I have encountered an issue with setting end time from Kotlin code. When updating endTime, the start angle is updated instead of the end angle. This PR fixes the issue.

Great library. How can I pass a calendar to set StartTime and EndTime for Picker? **picker.setStartTime(calendar);**

I tried to use setStartTimeMinutes but seem it is not correct.

picker.setStartTimeMinutes((int) TimeUnit.MILLISECONDS.toMinutes(Calendar.getInstance().getTimeInMillis()));

i'll try set StartTime And EndTime.

binding.timerangepicker.startTime = TimeRangePicker.Time(6, 0)
binding.timerangepicker.endTime =TimeRangePicker.Time(8, 0)

but only StartTime set yet

i want all set at the same time on code

someone can you help me?

Type Int? in Kotlin JVM maps to reference type Integer. It causes memory allocations. In our case, nullability isn't necessary and can be avoided.

To save compatibility with the last version of the library, some variables types are explicitly marked.

Maybe we should break compatibility and then, boxed types won't be used at all.