Proposal for Sponsored Open Source Android Support

[thesunny]

I am considering a sponsored version of an Open Source Android Plugin for Slate for USD $25,000.

1. This is an alternative to the proposal for a Paid Android Plugin (also proposed by me) for USD $500 per license as described here Proposal for Paid Android Plugin #3573

2. The Android Plugin will be released as open source under the same license as Slate and will support at least the latest version of Android with similar features and limitations as the 0.47x Android Support

3. Building Android support is a lot of work. We would love to be able to contribute for free (like Ian!), but the cost is high to burden alone. We contributed Android Support for Slate 0.47 which was working although not perfect and that cost about USD $40,000. That doesn’t include research we did prior to starting or the devices we had to purchase to test on.

4. It's uncertain how much it will cost to complete the 0.50x version of Slate Android. It may cost more or it may cost less. Either way, we are committing to completing it if we raise the funds. If it costs less, we will not be returning unused funds; if it costs more, we will cover the difference. Note that the 0.50x port is not trivial as another user worked for 3 months on it and it was never completed.

5. For clarity, we already spent USD $40,000, so even if the port costs $0, there will be no profit from this.

The port will be completed in partnership with Wayne Leroux with assistance from me. Wayne has built an impressive collaborative editor based on Slate (https://github.com/wleroux/slate-collaborative) so I have confidence in his ability to complete this project. He has also contributed other open source projects (https://github.com/wleroux?tab=repositories). I expect him to be able to complete the project; however, if for any reason he cannot, I will either complete it myself or will return the funds. Wayne and I intend to work together on a different Slate related project which would benefit from Android support.

If we are unable to raise the funds through sponsorship, we will revert to the paid model at USD $500 per license. For clarity, if we don't raise the funds through sponsorship and use a paid model but later receive the equivalent revenue in licensing fees from the paid model (USD $25,000 or 50 licenses), we will not then open source the code.

I recognize that this is a non-trivial amount to raise. I expect that companies that can afford to do so, will need to contribute more in order to meet this fundraising goal. To put the amount into perspective, this is the equivalent of contracting a senior developer for about 6 weeks. 3 organizations, contributing the equivalent of a contract valued at 2 weeks worth of work will reach the sponsorship goal (about USD $8000 each) or 50 smaller contributors paying what would be the licensing fee of USD $500.

Update: Now Live!

Add Android Support to Slate - KickStarter Campaign Now Live

[thesunny]

Hi everyone, just a quick update:

I've put together a KickStarter campaign and have submitted it. We are awaiting its approval. The campaign is in Canadian Dollars (we are a Canadian company) but we are raising the Canadian equivalent of the US dollars noted above.

We've started work on the Android Plugin part-time at the moment.

If we are able to raise the funds, our plan is to start work on the plugin full-time in August and upon completion release the plugin as an open source project.

As a reminder, if we are unable to raise, we plan to release the plugin under a paid license.

[signalwerk]

@thesunny I hope you also have thought of small tiers in the kickstarter campaign. I don't need Slate in a commercial product or client but would also like to contribute, since I have some private projects with slate. Plus I like what you did for 0.47!

[thesunny]

@signalwerk I have a pledge level at $50. Do you think that works?

[signalwerk]

@thesunny awesome! 🥳 can't wait to see that happening!

[thesunny]

Hi Everyone,

The KickStarter campaign is now live.

We will be grateful to all contributions towards the goal no matter how small.

That being said, in order to make this campaign a success, in my opinion, we will need both of the following:

1. Companies that use Slate for their business to contribute at a corporate level. It will be difficult to meet the pledge goal without this support.

2. Members of the community (people like you) to promote the campaign to your organization or to other organizations that would benefit from Android support in Slate.

Many have asked for this fundraising towards open source Android support. The work has been done to create the fundraising campaign but we need your help in order to make this a reality.

Support this fundraising campaign:

Add Android Support to Slate KickStarter Campaign Now Live

Note: If we raise above the fundraising goal, we will spend time to support earlier versions of Android.

[thesunny]

An update,

The KickStarter campaign

We have raised $2,351 out of $30,000 with 10 contributors. This means that 40% of the people that showed support for the Android plugin, have backed the campaign.

If you intend to back the campaign, please do so now and help build momentum.

Several of you asked me to seek sponsorship in GitHub issues, on the Slack Mobile channel and privately. To make this happen, it requires help from everybody to get it to the right people. For clarity, this is not a profit making venture for me or my company (we will lose money), but it is a way for the community to get a much needed feature into Slate.

[clauderic]

I've created a 12 page design document which includes all of the issues I encountered building Android support the first time along with the solutions I used to overcome those issues.

Hey @thesunny, the Kickstarter campaign mentions a 12 page design document. Is this something that can be reviewed by the community?

The Kickstarter campaign is scarce on technical details on what the proposed approach would be, and I think it would help build confidence in the project if more technical details were shared.

The previous solution revolved around composition start / end events and MutationObserver.
Is this still the planned solution moving forward?

I've spent the better part of the last month reviewing the Android plugin that was shipped in slate-react@0.4X.X, and am really appreciative of the work that you put into it. It has a number of issues that I've since been trying to fix.

While trying to fix bugs in the original Android plugin, I noticed that there are a number of things that I think were overlooked with the original solution:

• Composition events do not fire consistently the way you might expect them to in Android. For example, the compositionend event often only fires when the keyboard is dismissed, or sometimes fires out of sequence at the beginning of a composition, and therefore should not be relied on to determine the end of a composition

• The Slate value needs to be updated on every single text insertion / deletion / line break to allow for other plugins to interact on the value. The previous Android plugin only attempted to reconcile the mutations that had occurred on compositionend, which only happens when the keyboard is dismissed or the input is blurred as outlined above.

• Many plugins rely on keydown events to override the default browser behaviour (for example, on backspace or on enter). On Android, keydown events have unidentified keycodes, and therefore cannot be used reliably by plugins to augment the default browser behavior.

  In an ideal world, plugin authors should not have to write plugins with a separate code path for Android, Slate should expose a universal way for listening for specific events such as backspace and enter

• Plugins can also affect the DOM and trigger changes that are then detected by the MutationObserver. There needs to be a strategy in place to distinguish between mutations that originated from a composition and mutations that originated from plugins. As outlined above, the compositionstart event is unreliable on Android, in my experience, the beforeinput and input events are a more reliable way to detect the start of a composition

• Some actions are extremely difficult to reconcile using MutationObserver alone. The main example that comes to mind is handling backspace properly, which can result in dozens of mutations that are difficult to decrypt. In my opinion, some actions such as backspace would be better handled using beforeinput rather than MutationObserver alone

• The original solution uses the ReactDOM.unstable_flushControlled method, which is no longer exported from the stable builds for ReactDOM as of react-dom^16.11.0

I am sharing these issues not to criticize any of the work that was done, but rather in the hopes that we can discuss them along with potential solutions so that these aren't overlooked in the next Android plugin.

[thesunny]

Here is the Design Document although I suppose it's more of a "How I got 0.47x Android to work".

https://airshelf.com/thesunny/slate-android

I read all of your comments but I don't have the time to address them individually. They all make sense and I think I considered most or all of them at one point. One of the problems is Android is just not simple. I tried many more direct approaches and spent, I think, 2-3 months going in circles on the "without mutations" version for example. Some of this is documented in the link.

Also, keep in mind that if you are using it with the latest version of Android, it was never tested on it because it didn't exist. If it works at all, it's kind of lucky. The new version will be tested on the latest version of Android.

One thing that may never work is being able to intercept certain keypresses. The reason why is that Android may not provide that feature (haven't checked latest version of Android). You can't preventDefault some events that can be done in every other browser and that is by design by the Chrome Android team. This is also the reason why I have to revert the DOM a lot.

[thesunny]

Hello everyone!

Some great news is that we have one Silver Corporate Sponsor. We now have CAD $9,501 of the $30,000 goal or about 1/3rd of the goal to complete an Android plugin.

In order to get Android support added, we need 3 more corporate sponsors at the silver level (CAD $6500) or one at the gold (CAD $13,000) with a silver.

There are only 17 days to go.

If you believe Android is important to your project, please reach out to corporations and/or contribute yourself. With over 18,000 stars on the Slate repo, I find it hard to believe that it's not possible to raise funding to add Android support to this project which effectively adds the reach of Slate to almost 40% of the OS market.

I know there are some big corporations that use Slate so please reach out to them.

Add Android Support to Slate - KickStarter Campaign Now Live

[thesunny]

The good news is we are now at CAD $17,161 out of CAD $30,000.

The bad news is we have 6 days to go before the Kickstarter campaign is closed.

It's all or nothing so the funding has to complete.

The community asked to propose an offer to fund this project as open source and now it's up to you to get it funded. I've reached out to as many people as I can. We only need a little more to get this done! If you care about getting Android support in, please reach out to companies that could benefit from Android support. There are 18,400 stars but it means nothing if we can't reach the people that would benefit from this.

https://www.kickstarter.com/projects/sunnyhirai/add-android-support-for-the-slate-wysiwyg-editor?ref=user_menu

[thesunny]

Well everyone, this is the last chance. There is about 24 hours left.

We've raised CAD $18,461 out of CAD $30,000.

There is $11,539 left to go.

If you've been waiting to see if this gets funded without you, it's not! Now is the time to make the commitment. We need two silver sponsors to make this happen.

Last Chance at Android Support Kickstarter Campaign

[thesunny]

We made the fundraising goal on the Kickstarter!

A very generous sponsor added CAD $11,000 (over one third) of the goal and pushed us just over.

For privacy reasons, I don't want to name individual contributors, but thank you to everyone that contributed. We are slated to start in the second week of September.

[Nantris]

Holy cow! I was bracing myself for disappointment this morning. This news blew me away. Very excited!

[ghost]

This is very good news.

[thesunny]

Hi everyone,

We have an alpha version of a Slate Android Plugin available here:

https://github.com/wleroux/slate-android-plugin

It's not a final release by any means, but if you want to get started with it and report any issues not listed before, it could help us isolate bugs. It's posted under Wayne Leroux's GitHub account at the moment but may be moved in the future.

Notes about the alpha release:

• Requires the 0.59 version of Slate released a few days ago
• Only works on Android 10 (may work on Android 11)
• Continuous backspace has bugs
• Auto-Complete has bugs

Please post here if you have any issues

[ghost]

Can someone maybe explain why an editor like ProseMirror doesn't have these problems on Android? Is it due to the architecture used or does ProseMirror have all kinds of hacks for Android?

[jljorgenson18]

Prosemirror still has Android problems and there are plenty of hacks inside of Prosemirror. You also lose consistent support for backspace and other keys because Android doesn't send keyCode information consistently. Prosemirror has some interesting ways of guessing that you did a backspace and then resetting the content based on the mutation.

Prosemirror does have a really awesome mutation registration system that is really nuanced and has many workarounds in place, but there are still many, many issues across device, OS version, webview version, and keyboard combinations. They are primarily just issues baked into contenteditable/Android though.

Prosemirror is still very, very good at Android compared to almost any other option and we still had to do insane workarounds to resolve issues.

[jljorgenson18]

Also, Prosemirror has really intelligent composition support where it tracks compositions and but then protects the composition text node until the composition is complete. The problem with compositions is that if you interact with composition text nodes at all, it can derail the whole composition (especially on Android). Prosemirror also works around various selection bugs that plague Chrome/Android Chrome with their state syncing system.

[coniel]

@thesunny Thanks a lot for this plugin!

I've run into an issue with soft line-breaks. Here's a simple reproduction (it simply prevents the default Enter key behavior and inserts \n as text instead). This somehow results in an infinite \n insertion loop when hitting Enter:

[thesunny]

Hi @coniel thanks for letting us know. These bug reports are really helpful for us.

I've mentioned this post to @wleroux who is the developer that's working on this version of the plugin.

[wleroux]

Thanks @coniel! I've published a new version of android-slate-plugin (version 0.0.3) to support soft line-breaks. :)

[swashata]

Hello,

When I select multiple words and try to delete, sometimes only the last letter is being deleted. Maybe it is happening because I am listening to selection and showing a popup toolbar. Please see this video. If needed, I can provide access to source code and a staging site to reproduce the issue.

https://youtu.be/OQQmAna6gWI

Using android-slate-plugin version 0.0.3

[coniel]

@wleroux Seems I forgot to thank you for the fix. So thanks! Can confirm that it works. I've been using the plugin since then and I've been seeing an error reported in my error logger, though I'm unable to reproduce it myself:

[markgrancapal]

Just want to report that I encountered the same issue @swashata posted here.

Application version: Chrome 87.0.4280.66
OS: Android 10

This may be an issue that cannot be fixed and appears to be due to the fact that Android editing happens outside the JavaScript process. In other words, we can't seem to ever guarantee a state. If we read a document state (for example), it may have been modified by the time we reacted to it.

@thesunny is there no solution for this continues backspace bug?

[wleroux]

@markgrancapal I've recently acquired an Android 11 device to investigate @swashata's issue, haven't tried to reproduce it there yet. My test environment is very similar to yours (Chrome 87.0.4280.101, Android 10). Are you using the default keyboard or any other customizations?

RE: backspace issue... The issue with the backspace has to do with how Android handles contenteditable and Slate's cursor synchronization code. Android modifies the cursor out-of-band from javascript, which makes it impossible intercept the changes before Slate's synchronization code. The approach we took was to avoid modifications to the Slate codebase entirely.

My current hypothesis on the issue is that in attempting to override Slate's default handling of composition events, we introduce these other issues. There is no way to override Slate's default handling of composition events without either preventing default or stopping propagation of these events, however without overriding the composition events, it doesn't work properly at all. I am working on validating that hypothesis.

[markgrancapal]

@wleroux Yes I'm using the default Keyboard GBoard.

That is quite complicated, handling the backspace issue. I hope you guys will find a solution on this. I'll test it again and send some feedback when you release a new version

[thesunny]

Hi Everyone,

It's the end of the year and, sadly, it looks like we aren't able release a complete version of the Slate Android plugin in time for the December 2020 goal. Wayne is continuing to work on the plugin and we will be focusing all of his available time on the Slate Android plugin until it is complete.

I was hoping to not have to get involved but if we aren't able to complete in a reasonable time, I'll consider my jumping back in as described in the Kickstarter.

Thank you for your patience. Android support will get done. As mentioned, it is something we need in our projects as well so we are strongly motivated to complete.

[cngeru]

Hello,
Will one have to use a plugin or will it be integrated into the library already ?

[thesunny]

@cngeru It will likely be integrated into the library eventually though I can't say that with 100% certainty.

The issue we are contemplating is that if the Android parts are difficult to maintain as Slate master is changed, we may want to lock an Android plugin to specific versions of Slate; however, as Wayne is working through the Android plugin, it appears that there are changes to Slate core that are required and for that reason, we may initially not release it as a plugin after all.

The short answer is, we're still not 100% sure about the initial release but the goal is that eventually it will be part of core. Even if it's not initially though, it should be a yarn add and hardly any code to get it working.

[clauderic]

Hey @thesunny / @wleroux, are you able to provide any updates on progress?

I'm wondering if there's a work in progress branch I should be looking at seeing as there have been very few commits in the past few months on the master branch.

If not, is there a way to contribute to help move things faster? The alternative would be for people like myself who'd like to help things move forward to fork the android plugin and work on it separately, but perhaps there's a way to combine our efforts here. Are you open to adding collaborators to the repository?

Currently the Android plugin has a number of issues that would need to be addressed before being considered "production" ready:

MutationObserver vs beforeinput

The main architectural concern I have with the current implementation is that it relies solely on MutationObserver to reconcile the DOM with the Slate value, which assumes that the Android browser correctly modifies the DOM when events happen, which isn't always the case. In my experience, some actions are difficult / impossible to reconcile with the DOM using MutationObserver alone.

Further, even if the intent was indeed to ignore beforeinput events and rely solely on MutationObserver, the plugin isn't overriding the handling of beforeinput events that Slate is listening for, which is causing issues such as improperly handling the text replacements that are suggested in the keyboard toolbar, since Slate is responding to these events before they result in DOM mutations. Here are three demos to illustrate:

Slate + Android plugin:

Kapture.2021-01-18.at.16.10.11.mp4

Slate only:

Kapture.2021-01-18.at.16.36.22.mp4

Native contenteditable div without Slate or Android plugin:

Kapture.2021-01-18.at.16.56.26.mp4

User interaction vs Other mutations

The other main concern I have with the current implementation is that currently, the Android plugin makes no distinction between mutations that may originate from a user interaction versus mutations that might originate from an action triggered by a transformation (for example, a mutation triggered by a plugin). Since commands / transformations can also affect the DOM, these will trigger changes that are then detected by the MutationObserver.

There needs to be a strategy in place to distinguish between mutations that originated from a composition vs other mutations.

User-agent detection

Finally, and this is less of a major concern, but currently, the android composition manager is being connected regardless of user agent, which feels like an oversight, and one that cannot be addressed by consumers since the Android plugin is built as a hook rather than a decorator. Hooks cannot be invoked conditionally, so this means that the responsibility of checking whether the code should run falls onto the Android plugin hook rather than the consumer.

[wleroux]

Hello @clauderic,

Here's a little bit of a technical update on this effort.

The original approach is non-viable and the repository has been abandonned. The original approach attempted to create a standalone plugin that would interface with the existing Slate code as-is. This approach worked relatively well for the devices I was testing on, however I ended up spinning my wheels trying to close gaps in edge cases. Furthermore, when additional users attempted to use it with their devices, it became apparant that differences could not be resolved with that approach. The plugin hooks exposed by the latest version of Slate do not provide us with the necessary trigger points. We've kept it around as it might be better than nothing, but we've been working on the next iteration.

The new approach is currently using a forked version of Slate. This allows me to modify Slate to provide the hooks required as needed. We're porting the 0.47 plugin (which worked pretty decently) to the latest version of Slate. However, both React and Slate has changed significantly since then. The port of the plugin code is completed and I'm currently working on the necessary hooks into the slate code. Once we're confident in our solution, we will be seeking to add these new hook points to Slate proper and release the plugin (with user-agent-detection) either as an independent plugin or as part of Slate proper.

The nature of this work doesn't lead to frequent commits: A significant portion of the work is basically solving mystery after mystery. A lot of debugging, manually testing multiple different devices, manually combing through mutation logs and corresponding reconciliation, mapping statements to equivalent statements in the newer version (e.g.: ReactDOM#unstable_flushControlled isn't accessible anymore, despite obviously being exported here: https://github.com/facebook/react/blob/9a2150719b971adf078eca5cecbb18c146545cbd/packages/react-dom/src/client/ReactDOM.js#L205). These are all very time-consuming activities that aren't very commit-rich. Furthermore, I try to commit when there's a tangible improvement to the solution, rather than the more frequent but ultimately useless WIP commits.

At this point, I don't think collaborative efforts would be benefitial. However once we get decent initial version with the new approach, there will be more opportunities for community involvement. Stay tuned!

[clauderic]

Hey @wleroux, thanks for the update. It might be worth putting a disclaimer on the plugin's README that development was abandoned in favour of a different approach to set expectations for people that might stumble on the repo.

As for the new approach you mention, is there a work in progress repo we can follow?

I spent a significant amount of time working on the old Android plugin for Slate 0.47 to get it in somewhat of a production ready state. The code is a bit scrappy, but perhaps it can be helpful to you. Some of the notable changes I made is distinguishing between user interaction vs other DOM mutations, and batching beforeinput and input events to use them to identify and resolve edge-cases. https://github.com/clauderic/slate/tree/master/packages/slate-react/src/plugins/android

As for ReactDOM.unstable_flushControlled, it is no longer exported from ReactDOM stable builds as of ^16.11.0
https://twitter.com/clauderic_d/status/1285300144909553664?s=20. Since that version, it is only exported from experimental builds of react-dom; It needs to be invoked conditionally and is only useful when React is used in async mode (see https://github.com/facebook/draft-js/blob/master/src/component/base/DraftEditor.react.js#L265-L276 for how it is used in DraftJS)

[thesunny]

Just a quick update that @wleroux  got a version of Android support that appears to be mostly working which is the port of the 0.47x version but modified to work with the new design of Slate.

Wayne is continuing to clean that up. We also got an okay from Ian to use a swappable editable.tsx component that will allow us to more easily swap the entire input engine for Slate Android. This should keep the input engine separate while still being easy to reason about.

[clauderic]

Swapping out the editable.tsx component is an interesting idea, but one that I would tend to advise against, at least based on my understanding of what you're proposing.

In the long term, it sounds like the kind of approach that will lead to a lot of duplication of code, such as all of the handlers for drag and drop and copy paste, and also mean that bug fixes and new features need to be done in multiple places, which could easily lead to inconsistencies due to human error if one does not remember to update both places.

Instead, I'd like to propose a more encapsulated strategy that would have a much smaller scope. The idea would be to conditionally switch between input handling strategies depending on the environment rather than switching out the entire editable.tsx component. This strategy minimizes duplication and allows to encapsulate the input reconciliation strategies.

I wrote a small work-in-progess proof of concept branch to illustrate the strategy using hooks as input strategies that adhere to a standardized interface in terms of the arguments they accept and their return values (hook polymorphism). They can both add DOM listeners on the editor's root DOM node or return React synthetic event listeners that should be added on the <Editor> div.

[clauderic]

I've opened a draft pull request based on the strategy outlined above in the hopes of sparking more discussion around the overall approach and bringing more transparency to the development of the Android reconciliation layer so that the community can help

It also introduces more changes to add better support for Android through this Mutation Observer strategy. Some parts of the PR are directly based off of the work of @wleroux and @thesunny (specifically around text diffing) ❤️

Slate.MutationObserver.reconciliation.strategy.mp4

Things that are currently working:

• Distinguish between mutations that originate from user-input vs other mutations
• Update text (with some issues)
• Replace selection (with some issues)
• Delete selection
• Insert line break
• Delete backwards

List of known issues (non-exhaustive):

• Issues updating cursor position when inserting identical text (for example, inserting the letter e multiple times in the word text when the cursor is after t: te|eext)
• Copy/paste should not be tracked as user input by the MutationObserver layer, but currently is
• Need to ignore mutations that happen within void nodes (contenteditable="false")
• Handle readOnly prop of editor
• Issues initially updating selection position on some Android devices

Feedback is welcome, and please report all issues on the PR so we can discuss them and find solutions. This PR is a rough first draft and there are likely many issues with it.

[thesunny]

Hi @clauderic,

First of all, I wanted to thank you for your thoughts, feedback and code contributions on adding Android support to Slate. I can see you really care about this project and are putting a lot of effort into its success.

I don't know if the project will get the most traction by having two Android forks building simultaneously and separately. The reason why is that due to the complexity of Android, it could be challenging to take bits and pieces from each of the two forks and combine them together without coordination. If you want to take a coordinated approach, what do you think of reaching out to Wayne on Slate's Slack, either on the mobile channel or as a direct message. His username is Wayne.

One thing to keep in mind if you decide to move forward on your own is that I'd recommend testing on at least the latest 2-3 versions of Android as per the statistics below. They do need to be tested separately (each Android version has different quirks), and ideally, you'd want real devices as the emulator isn't always accurate in my experience.

StatCounter Worldwide Android

StatCounter United States Android

[clauderic]

Hey @thesunny, the intent is by no means to have two separate Android projects simultaneously working in opposite directions, quite the opposite really. Rather, the intent of opening a PR was simply to bring new ideas to the table, bring more transparency to the development of the Android compatibility layer and spark discussion on some of the technical challenges of bringing Android support to Slate.

I offered to collaborate with @wleroux a while ago, but at the time he did not think collaborative efforts would be benefitial. Would gladly collaborate with him if his views on the matter have changed, will reach out to him on Slack.

[thesunny]

@clauderic

Thanks for the clarification and again thanks for the work you are putting.

If Wayne pushed back on input at this time, It may be true that it's not the right time.

There is a point when I was working on Android where I didn't find it was optimal to solicit input. For me that was before it was stable because there were just so many things I had to be thinking about that I couldn't manage another train of thought at the same time.

I think Wayne is coming closer to that point where Android is closer to stable though. We have a meeting once a week, and he seems to be feeling confident that he is getting close.

Sunny

[signalwerk]

@clauderic Thank you for your input and your branch. I think it's always good to have someone to bounce off ideas and challenge some architectural decisions. I'm sure @clauderic and @thesunny appreciate your input and I hope your effort pays off in a better and more durable implementation in the end. As an outsider (user of slate, kickstarter, but not dev of slate) I highly appreciate all of your work and I think the idea you bring to the table sounds like you deeply care and have a good understanding how to keep a long maintainable android version alive. Please keep your inputs and engagement up!

Thank you all.

[robbywh]

Hello @thesunny @wleroux ,

Is there any updates about the android plugin? Do you have a deadline to finishing this plugin?

thank you for your effort to make android plugin come true.

[thesunny]

Hi @robbywh, Wayne is continuing to work on it.

I was planning on making the following announcement about two weeks ago but I've been, unfortunately, dealing with something urgent at work which also came in the middle of trying to help complete the advanced TypeScript integration for Slate.

I discussed this with Wayne already and if he is unable to finish a version of the plugin by end of March, and he is not confident in finishing it, I will start personally working on completing the plugin.

[thesunny]

Wayne is now in the process of doing platform testing. If you want to experiment with Android support against your Android device (call it a preview), you can take a look here:

https://github.com/wleroux/slate/tree/bugfix/android-keyboard

For clarity though, Wayne is doing the platform testing so the expectation is that this is not yet ready for production.

The goal is that this will be merged back into master when it's ready.

Also for clarity, the goal is to put this into a state where Android is usable. Even at the end of this process, there won't be a direct 1:1 correlation with Slate on other platforms. There are, amongst other things, hard limitations on what can be achieved with mutations versus the input handler, especially with respect to plugins. Over time, the hope is that the community can get Android even closer to being on par with other platforms.

[thesunny]

Wayne has completed a Draft PR for Android in Slate.

Please test and provide feedback.

#4200

[thesunny]

Update: Merged Android support. Please report any Android bugs as separate issues. #4200

[toddka]

Should this page be updated? I'm just browsing the docs as a first time user and found this discrepancy: "Chrome on Android is supported on Slate 0.47 but is not currently supported in Slate 0.50+ though there is currently work being done on one"

[thesunny]

@toddka Yes, this should be updated! I'll fix the docs to reflect this.

[thesunny]

@toddka FYI, docs have been updated. Thanks for bringing this to our attention.