Does not support text input number

Hi! (first of all great work on flutter search bar)

ISSUE

KeyboardType only supports text though what about the cases when we have to deal with numbers? in my case I need to search by number

and I see in code
keyboardType: TextInputType.text,

should be

keyboardType: TextInputType.number,

though this would be have to be an optional settings

TECHNICAL APPROACH

@todo

NOTES

@todo

Hi @ArcticZeroo ,

I can work on that issue. My approach is adding a parameter like numberType which default value is false and check on

flutter-search-bar/lib/src/flutter_search_bar_base.dart

Line 152 in 499bbe6

keyboardType: TextInputType.text,

line and if developer passes true for that parameter, it shows up number. numberType name can be changed by good name, of course. What do you think about my approach?

Hi @ArcticZeroo ,

I can work on that issue. My approach is adding a parameter like numberType which default value is false and check on

flutter-search-bar/lib/src/flutter_search_bar_base.dart

Line 152 in 499bbe6

keyboardType: TextInputType.text,

line and if developer passes true for that parameter, it shows up number. numberType name can be changed by good name, of course. What do you think about my approach?

Hey @gozeloglu, I think it makes the most sense here to add a parameter which allows the developer to pass any text input type rather than 'hardcoding' it to be only number or not. This way we don't need a boolean option for every single future text input type that may be desired in the future.

Hi @ArcticZeroo ,
I can work on that issue. My approach is adding a parameter like numberType which default value is false and check on

flutter-search-bar/lib/src/flutter_search_bar_base.dart

Line 152 in 499bbe6

keyboardType: TextInputType.text,

line and if developer passes true for that parameter, it shows up number. numberType name can be changed by good name, of course. What do you think about my approach?

Hey @gozeloglu, I think it makes the most sense here to add a parameter which allows the developer to pass any text input type rather than 'hardcoding' it to be only number or not. This way we don't need a boolean option for every single future text input type that may be desired in the future.

Hmm, you mean that I should add a parameter in TextInputType type. So, the developer can call the function like SearchBar(TextInputType.text, ...) if he wants to create a text keyboard and calls the function like SearchBar(TextInputType.number,...) if he wants to create a number keyboard. If I understood correctly, what should be the default value of that parameter? I think text is appropriate for this.

Hmm, you mean that I should add a parameter in TextInputType type. So, the developer can call the function like SearchBar(TextInputType.text, ...) if he wants to create a text keyboard and calls the function like SearchBar(TextInputType.number,...) if he wants to create a number keyboard. If I understood correctly, what should be the default value of that parameter? I think text is appropriate for this.

Yeah, that is pretty much what I am suggesting. Though it should not be a positional parameter, it should be named like everything else (e.g. SearchBar(keyboardType: TextInputType.text)). The default value also must be text so that we don't break backwards compatibility

Hmm, you mean that I should add a parameter in TextInputType type. So, the developer can call the function like SearchBar(TextInputType.text, ...) if he wants to create a text keyboard and calls the function like SearchBar(TextInputType.number,...) if he wants to create a number keyboard. If I understood correctly, what should be the default value of that parameter? I think text is appropriate for this.

Yeah, that is pretty much what I am suggesting. Though it should not be a positional parameter, it should be named like everything else (e.g. SearchBar(keyboardType: TextInputType.text)). The default value also must be text so that we don't break backwards compatibility

I made changes in ab81ae7

I think this issue can be closed. It is fixed in #41 @ArcticZeroo @edutrul