The focus is to change the EmojiView to be high performance with less memory usage.
Major Changes
1. ViewPager is successfully migrated to ViewPager2.
ViewPager2 is the recommended way by Google to handle the View Page Transition. Even I asked GPT-4 the advantages of ViewPager over ViewPager2, I have to reiterate twice to get its answer. However, the answer is not really the merit it has.
From the first trial, I tried the suggestion from GPT-4 that to use RecycleView + GridLayoutManager + ViewPager2. I found that it is even slower. After trial and errors, the root cause is that RecycleView + GridLayoutManager cannot render the emoji as smooth as ArrayAdapter + GridView.
The latest decision is GridView + ViewPager2. I have already fixed the layout issue related to ViewPager2, now it is good to use as the same as ViewPager.
GridView itself does not like ViewPager to have all negative comments, and Google has not yet make it dead.
2. UI Improvement
The color and some visual effects are similar to Whatsapp which looks better.
color of tab button (both normal and pressed)
bottom border for selected tab
size of emoji
padding of emoji
removed gap between emoji which cannot be clicked.
ripple background (selectableItemBackgroundBorderless for API 21 or above btw. selectableItemBackgroundBorder can be served as fallback.) is now replaced by a custom effect which looks better for emoji key. ripple background suppose to be used in the large button. it is easy to implement but not customizable (e.g. unable to resize). now the effect looks similar to WhatsApp keyboard which is much make sense.
3. Recent Emoji Manager
I asked GPT-4 to rewrite as per my request. It did it and no error found in both complier and runtime.
The revised logic is to compare the clicking record count first, then clicking timestamp.
4. Builder
The builder concept was not a good approach, and there are many event listener callback to be passed across the views. This make the code become messy and easy for memory leakage. Now Just pass one object which is combined the controller and the builder settings. All object references are weak references such that it will not create memory leakage.
All sub components just need to store one reference copy to that controller object, and let the controller to decide how to make changes.
Therefore, it is now much feasible that the handling can be customized from the external.
5. Removed AsyncTask for image loading, and added some coding for background thread.
Loading Drawable in Background is definitely a wrong decision.
There are so many emojis, it will just consume the RAM and no much benefit.
Now there is already setOffScreenPageLimit(1) such that there is always one in left and one in right for the paging. This is already preloaded. It has been tested that it is as smooth as with preloading all images.
And if such loading action in setEmoji is delayed, the UX might not be good when the user try to swipe the pages.
6. Reorganized some nested function coding style.
In the past, there are many nested functions (e.g. Callable, Runner, etc.) which might lead to memory leakage. As now all these things are moved to the controller, such nested function are much reduced.
Remarks
I have compared the before and after and I found that the current version is significantly more responsive than before.
Although the original version has been "evolved" into Kotlin, but those issues I found have not been updated or followed. I become the current version is better than the original version.
The files are updated and can be used, but those class naming and builder etc shall have been finalized first.
There are many no use java class and to be deleted.
Therefore, this PR just serves as a historical record.
This PR is for file record purpose only.
The focus is to change the EmojiView to be high performance with less memory usage.
Major Changes
1.
ViewPageris successfully migrated toViewPager2.ViewPager2is the recommended way by Google to handle the View Page Transition. Even I asked GPT-4 the advantages ofViewPageroverViewPager2, I have to reiterate twice to get its answer. However, the answer is not really the merit it has. From the first trial, I tried the suggestion from GPT-4 that to use RecycleView + GridLayoutManager + ViewPager2. I found that it is even slower. After trial and errors, the root cause is that RecycleView + GridLayoutManager cannot render the emoji as smooth as ArrayAdapter + GridView. The latest decision is GridView + ViewPager2. I have already fixed the layout issue related to ViewPager2, now it is good to use as the same as ViewPager.2. UI Improvement
The color and some visual effects are similar to Whatsapp which looks better.
selectableItemBackgroundBorderlessfor API 21 or above btw.selectableItemBackgroundBordercan be served as fallback.) is now replaced by a custom effect which looks better for emoji key. ripple background suppose to be used in the large button. it is easy to implement but not customizable (e.g. unable to resize). now the effect looks similar to WhatsApp keyboard which is much make sense.3. Recent Emoji Manager
I asked GPT-4 to rewrite as per my request. It did it and no error found in both complier and runtime. The revised logic is to compare the clicking record count first, then clicking timestamp.
4. Builder
The builder concept was not a good approach, and there are many event listener callback to be passed across the views. This make the code become messy and easy for memory leakage. Now Just pass one object which is combined the controller and the builder settings. All object references are weak references such that it will not create memory leakage. All sub components just need to store one reference copy to that controller object, and let the controller to decide how to make changes. Therefore, it is now much feasible that the handling can be customized from the external.
5. Removed AsyncTask for image loading, and added some coding for background thread.
Loading Drawable in Background is definitely a wrong decision. There are so many emojis, it will just consume the RAM and no much benefit. Now there is already
setOffScreenPageLimit(1)such that there is always one in left and one in right for the paging. This is already preloaded. It has been tested that it is as smooth as with preloading all images. And if such loading action in setEmoji is delayed, the UX might not be good when the user try to swipe the pages.6. Reorganized some nested function coding style.
In the past, there are many nested functions (e.g.
Callable,Runner, etc.) which might lead to memory leakage. As now all these things are moved to the controller, such nested function are much reduced.Remarks
The files are updated and can be used, but those class naming and builder etc shall have been finalized first. There are many no use java class and to be deleted. Therefore, this PR just serves as a historical record.
The next update shall remove the old files.