Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Disable RecentEmoji #477

Closed
keyvanNorouzi opened this issue Oct 23, 2020 · 3 comments · Fixed by #510
Closed

Disable RecentEmoji #477

keyvanNorouzi opened this issue Oct 23, 2020 · 3 comments · Fixed by #510

Comments

@keyvanNorouzi
Copy link

Is there any way to disable the RecentEmoji tab? (version 0.7.0)
I want to dismiss the Recent Emojis

@lukesleeman
Copy link
Contributor

lukesleeman commented Oct 26, 2020

We have a similar need, and I would be happy to submit a PR.

Digging through the code the recent emoji come from the EmojiPopup.Builder, get passed into the EmojiPopup, and from there into the EmojiView where a EmojiPagerAdapter is build with the recent emoji as its first page.

I can think of two approaches to to represent the "No recent emoji please" case:

Option 1 - Represent it as null recentEmoji field in the builder and pass the null along to emoji view, etc
This is easy enough to do - unfortunately it introduces a null into the codebase, and we will need a whole bunch of null checks in various places. Its possible somebody will miss a null check at some stage and the library will crash. This also has the disadvantage of representing a "Business state" of "I don't want recent emoji" by an instance variable being null which could be a bit obscure.

Option 2 - Create some sort of marker implementation of RecentEmoji - perhaps an NoRecentEmoji
We could create a singleton object RecentEmoji which implements the RecentEmoji interface with empty operations. Inside the EmojiView and EmojiPagerAdapter we can check to see if the recentEmoji field is NoRecentEmoji and remove that page from the adapter.

@vanniktech which approach do you think would be best for this codebase? If it was kotlin I would probably go with option 2, but this is old school java, so perhaps some more nulls aren't that bad 🙂

@vanniktech
Copy link
Owner

Option 2 sounds good.

@vanniktech
Copy link
Owner

PR welcome.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants