Added the Decimal Support while entering target for any Habit.

[sumanabhi]

Added the Decimal Support while entering the target for any Habit.

This PR will resolve this issue #900

Changes I made:-

Change the input type for Target EditText

You can check attached Screenshots here ->

[hiqua]

My issue was about when you entered a new checkmark, while you seem to have looked at new habits, correct? Are these related?

In any case I think the (well "my") idea was more to keep the current interface, but just allow the user to switch to the fractional part by using . from the numpad.

Another thing is that currently, the measure can only be specified by increments of 0.05, while your changes seem to allow any float as input. I'm not sure what the reasoning was to have this restriction, but it could have been to avoid weird rounding issues with floats.

My idea initially when opening the issue was that once you've entered the digit, it would be nice to finish entering the full measure by just pressing . then the fractional part.

On the screenshot below, the user has entered 1 and could now enter .05 instead of scrolling to enter the fractional part.

If my intuition above regarding floats is correct (I haven't checked), I think the fractional part should then be rounded to the closest possibility (e.g. 1.04 to 1.05).

[iSoron]

Thank you for the PR, @sumanabhi. Issue #900 is about something else, but I think we should allow fractional target values. The integer restriction in this form was just by accident. I'm planning to merge this PR in the branch hotfix/2.0.2.

Another thing is that currently, the measure can only be specified by increments of 0.05, while your changes seem to allow any float as input. I'm not sure what the reasoning was to have this restriction, but it could have been to avoid weird rounding issues with floats.

You're right; we store entries as integer numbers to avoid rounding issues with floating point numbers. The 0.05 increment restriction, however, was implemented just to make it easier to scroll to the desired fractional value. If we have a faster way to enter the fractional part of the value, that restriction can be removed.

[hiqua]

You're right; we store entries as integer numbers to avoid rounding issues with floating point numbers. The 0.05 increment restriction, however, was implemented just to make it easier to scroll to the desired fractional value. If we have a faster way to enter the fractional part of the value, that restriction can be removed.

So we can just use the same kind of field as in this PR for new checkmark entries then, if I understood you correctly?

[sumanabhi]

Hey @iSoron @hiqua ,

Thanks for the approval of PR.

I think I was misunderstood the scenario due to not having detailed knowledge of application. But now after seeing the screenshot attached by @hiqua I can check and try to understand the issue and then will let you know if I'm able to solve it or not.

[iSoron]

Merged in branch hotfix/2.0.2 (b1c53bd)

[iSoron]

So we can just use the same kind of field as in this PR for new checkmark entries then, if I understood you correctly?

@hiqua Sorry, your suggestion is not clear to me. Are you proposing applying the solution from this PR to number_picker_dialog.xml? Note that we currently use two NumberPickers in that XML layout, so that users can either type or scroll, whichever is the most convenient. If we switch to EditText with numberDecimal as input type, users would lose the ability to scroll.