Floating search view assumes that view is always called from activity

[manjunathc23]

Hey Airmorty,

Your lib looks great! I want to use it in my upcoming project work. However I am not able to use your lib as of now as It crashes on me when I try to inflate the view. When I looked into your source code its accessing activity. I feel custom view should be activity / fragment agnostic! In my opinion if the custom view is doing more than a view should do then that responsibility should be given back to caller of this custom view. Let me know your thoughts!

Caused by: java.lang.ClassCastException: android.view.ContextThemeWrapper cannot be cast to android.app.Activity at
com.arlib.floatingsearchview.FloatingSearchView.setupQueryBar(FloatingSearchView.java:454)

Thanks! Manju

[arimorty]

Hi Manju,

You are absolutely correct, and that is exactly the kind of issues I would like to address before adding any new features, so thanks for that.

The issue was fixed in d303a2cb94a51c9c4db38acef731fa0743eeac42. I will close this issue once I confirm that the Maven repository is up to date.

[manjunathc23]

Hey @arimorty ,

Thanks for consideration.I think it would be still better to give callback to the caller after voice button clicked and expect the result back to view from setter methods.

We have also implemented some of our custom views like this and later we ran into multiple problems decided that custom views should not do anything extra which related to calling fragments or expecting any other result. So we keep all our custom view dumb / agnostic of external factors like calling voice recognition etc.

Let me know your thoughts!

Thanks! Manju

[arimorty]

@manjunathc23 Ok, since I have other things I want to improve first, I'll have a look at your suggestions about letting clients handle voice rec it in the future, probably release 1.0.3. For now, I have added a silent exception to avoid crashing the client.

I can confirm that release 1.0.2 now is live. It contains fixes you suggested (mainly the casting problem) as well as a very important fix relating to dynamic suggestion item height measuring (if you don't know already, suggestion items can have different heights, try it out with long texts).

I hope it will inflate without any problems. Thanks for suggestions and, if possible, I would love to see your project when ready (if you end up using this lib)

[manjunathc23]

Perfect! Thanks for considering.

Thanks a lot. I'll add credits to your work too. I would also love contribute your repo.

Thanks! Manju

[arimorty]

Thanks for the pic. If you are going to use Hindi in the search, you should know that RTL support is not complete yet, but I hope it will be for next release (1.0.3).

[manjunathc23]

Hey Ari,

We are not gonna use localization as of now. Our app will be in english language. Anyways Hindi is not RTL its same use LTR as English. I'll let you know when we go live with search bar.

Thanks a lot!

[manjunathc23]

Hey @arimorty ,

Take a look at the PR https://github.com/mikepenz/AboutLibraries/pull/175

I have created a PR to get your lib included in the About Libraries, let me know if you want to add more details about your lib.

Thanks! Manju

[arimorty]

That's great, Thanks.

[ghost]

Please support RTL in next release . thanks