Refactor Android Plugin

Do you want to request a feature or report a bug?

Refactor the Android plugin in order to improve readability and make the code easier to understand.

What’s the current behavior?

The Android plugin merges all Android versions into one plugin and uses if/else and switch/case statements to execute the correct code for the correct version. It also uses if/else statements to split execution based on native/non-native onBeforeInput handlers.

It is difficult to follow the code and easy to break code in another version of Android without realizing it. For example, some code in Android 8 may not be branched and fixing this may break code in Android 9. Furthermore, we might edit code in the wrong branch inadvertently.

What’s the expected behavior?

First, split the code into plugins for each version making it impossible for changes in one version of Android to break changes in another.

Second, internally refactor the code so that onBeforeInput calls out to onBeforeInputNative and onTextInput in the Android plugin.

[thesunny]

As an update, I’ve separated Android plugins by major version number and in combination with an ActionManager object that I added this has made understanding the code easier and the iterations faster. It is less common for a fix in one area to break things elsewhere.

Some insights:

• There are some methods that overlap between Android versions; however, we must be careful because sometimes they are similar but not the same and the difference matters. I’m on the fence about how and when to share methods between Android versions.
• There is almost no overlap between Android’s special handling and all other browsers. These issues are mostly unique to Android.
• Special classes like ActionManager and DomSnapshot are not useful for other browsers
• Reconciler might be useful in other browsers

[thesunny]

@Slapbox Thanks for asking for the clarification and @ianstormtaylor for the response.

I’d be happy to have this merged in with the other code at some point in the future. At this point, however, I think it’s premature.

Right now even I (the author!) have to read my own notes and source code to understand what I did. And the way it’s written is spaghetti and hard to understand because the concerns are all over the place in one file. The goal for splitting this is to make it easier to understand what the code does on re-reading and of course for new readings as well. This was the immediate impression I got when coming back to the code after a hiatus.

In the future, however, I can see that we might extract some common modules that could be used in a more general manner and integrated hopefully. I don’t think I have the right building blocks yet though and IMO that needs to come first before trying to integrate.