You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jan 24, 2019. It is now read-only.
There are multiple levels of difficult we can make this, so let's start simple:
Create a public static class API {} that does the same things, with the same signatures, that api.js does right now.
Bind that class to the window.Android object so our webviews can work with it
refactor api.js so that instead of running its own code, it forwards all calls to window.Android.API.sameFunctionCall(same, function, arguments)
And make that work properly. With that, we have a good basis to start adding better controls for network error detection, callback handling across webviews, and many other things that are really quite hard right now, but much easier if they happen outside of the JS thread.
In order to make sure we stay sane, we probably want to tackle that last step in stages too:
1. mirror the api.js interface in API.java but make all the functions public boolean ....() { return true; }, with api.js simply adding a call to window.Android.API.whateverfn(...), just to see if we can even hook them up.
2. keep the code we run in api.js but refactor each function body to be a callback, and route the callback trigger through Java. api.js: function abcd(x,y,z) { var callback = function() { /* all the code we had before, wrapped! */ }; window.Android.API.abcd(x,y,z, callback); }, then see if that still works
3. once both of those work, we have a solid basis to start lifting the actual workhorse code from api.js to java, and we can start lifting one function at a time without disrupting anything. Small PRs for big wins!
The text was updated successfully, but these errors were encountered:
Woot! Just to provide a bit more context for this and #2354: I spent a while trying to debug the app because it kept reporting "Looks like there might be a problem with your username or password." It took me quite a while to figure out that this was happening because my phone's airplane mode was activated--which is a silly mistake for a developer to make, but I'm sure it happens to less technical users too. Being able to report a separate "Check your internet connection" error would have made the problem a lot easier to figure out, and apparently we can easily do this if we uplift api.js so it runs through Java.
There are multiple levels of difficult we can make this, so let's start simple:
public static class API {}
that does the same things, with the same signatures, thatapi.js
does right now.window.Android
object so our webviews can work with itapi.js
so that instead of running its own code, it forwards all calls towindow.Android.API.sameFunctionCall(same, function, arguments)
And make that work properly. With that, we have a good basis to start adding better controls for network error detection, callback handling across webviews, and many other things that are really quite hard right now, but much easier if they happen outside of the JS thread.
In order to make sure we stay sane, we probably want to tackle that last step in stages too:
api.js
interface inAPI.java
but make all the functionspublic boolean ....() { return true; }
, with api.js simply adding a call towindow.Android.API.whateverfn(...)
, just to see if we can even hook them up.api.js
but refactor each function body to be a callback, and route the callback trigger through Java. api.js:function abcd(x,y,z) { var callback = function() { /* all the code we had before, wrapped! */ }; window.Android.API.abcd(x,y,z, callback); }
, then see if that still worksThe text was updated successfully, but these errors were encountered: