vocascan / vocascan-mobile

Android and iOS client for Vocascan
6 stars 1 forks source link

New Web-View Based Approach #5

Closed Tracer1337 closed 2 years ago

Tracer1337 commented 2 years ago

tl;dr

Replace the flutter app with a web-view based react-native app and inject native modules into the web-view.

Problem

Building the entire vocascan-frontend repository from scratch in a new programming language is not the ideal solution, not only because we already have a responsive web-app in this branch, but it's also a boring and non-rewarding task (the last commit here is 8 months old).

Proposal

A better approach would be to take the existing web-app and loading it into a web-view based native app. From my experience the easiest method would be to use a TWA, but this only works for android and doesn't allow native modules. Another approach is using a managed app like Cordova, but the startup time of the final app will be horrible. I recommend building either truly native apps (Java, Swift) or using react-native, then load the web-app into a web-view and provide native modules through a web-view bridge.

The last method is how my project Meme Bros partially works. In the repository you will find the canvas directory, which contains a web-app which is rendered both on the web and in the mobile app. In the directory client-lib you will find the code used for communicating between the react-native app and the web-view. The bridge is then used to sync the state of a context and pass events from the app to the web-view and vice-versa.

A challenge with this approach will be to find matching packages for the web and the native app, for example with AI based approaches like the (planned?) vocabulary-scanning feature. We may use the Tesseract OCR Engine for this, which is available for android / iOS and the web, but the web version is really slow (it takes almost three seconds for the example on their website). We should therefore also consider to provide different feature-sets for both the web and the mobile app (No one will scan there vocabulary cards through a webcam, so forcing them to use the faster mobile version will benefit the UX).


Don't get me wrong here, I really think @Florian-Sabonchi did a great job at developing the foundation of a flutter app, but 130 commits for only having the authentication working is not worth it, considering we already have implemented the entire app for the web. So I would like to hear your opinions on this topic @Florian-Sabonchi @luwol03 @noctera, I may then volunteer to maintain the mobile app together with @Florian-Sabonchi.

luwol03 commented 2 years ago

The mobile client was a project of Florian. We decided to let the development of an app go without us involved because we focussed to that time only on the desktop app.

The native implementations can be done through the modules we already implemented for different API possibilities in the web/desktop version (take a look at the src/modules folder on the Frontend).

I like this direction, because then each interface looks the same and there is no difference between all those versions and the codebase is the same, so there are not that much maintainance tasks to keep those in sync if new features are implemented on the server.

The only thing which is not that easy with mobile apps in general (doesn't matter for which version we decide) is that we have to pay yearly to publish an IOS app.

florian-sabonchi commented 2 years ago

Hi thanks for your feedback, I would definitely be in favor of switching from Flutter to a web-view based react-native app. This would save us work, the problem is that I'm currently developing the app on my own which makes things difficult. If @Tracer1337 agrees to help me with the development I would be there. I suggest that we archive the repository of the app first and then delete it

luwol03 commented 2 years ago

Why deleting it? We can use it for the web view based app sources like we did it with the desktop app.

florian-sabonchi commented 2 years ago

Okay, but that would mean a complete rebuild anyway. But yes we can also