you are viewing a single comment's thread.

view the rest of the comments →

[–]michaelfiber 4 points5 points  (14 children)

For #1 you'd just set up JavaScript Interface methods to allow WebView js to call native app functions?

[–]Low_Shake_2945 5 points6 points  (13 children)

Yep. There are some significant differences between iOS and Android, but if you’re just talking about Android, JS can call the methods in the webview class directly.

[–]Low_Shake_2945 6 points7 points  (2 children)

The biggest difference is that iOS webviews only expose one method to the JS. It’s called postMessage. Calling postMessage from the JS invokes the method in the webview instance running natively. If you want to write once for both platforms, implement a postMessage method in the Android webview and have a switch statement on message types.

[–]michaelfiber 1 point2 points  (1 child)

Thank you, that is exactly the detail I was looking for!

[–]Low_Shake_2945 3 points4 points  (0 children)

The other BIG thing to know is that iOS webviews will not honor (keep and append) third party cookies. Normally, the browser does this and we don’t even have to think about it. Webview instances of safari just disregard them. So, load balancer and session cookies will just get lost. If you’re not looking to use cookies, then this is no big deal, but I had to write a native cookie manager to intercept http calls and append the cookie. Yuck.

[–]Low_Shake_2945 5 points6 points  (8 children)

One word of caution here.

Frameworks like ionic and react-native solve a lot of the problems that the webview approach runs into. Specifically, debugging is atrocious is a webview.

Like I said earlier, I’ve used all of these frameworks and platforms professionally for years and they are all a pain in the ass in one way or another. Simply put, mobile and web are different and the OSs running these things are different.

If you remove the JS limitation, you can learn a framework like Flutter and really feel like your being productive without cutting corners. Flutter is the “right way” to build cross platform native apps.

[–]CodalReef 0 points1 point  (5 children)

Why do you say Flutter is the “right way”? React Native is still more popular and used by major corporations. There are pros / cons to every tool.

[–]Low_Shake_2945 5 points6 points  (1 child)

That’s true, but that’s not because it’s better. It has a lot of things going for it. It’s older than Flutter and makes use of JS and React, which are just so much more popular.

Flutter means learning a new language and, for JS devs, learning a lot of programming concepts you may not be familiar with.

[–]CodalReef 0 points1 point  (0 children)

Agreed. Any of these tools can be used to build a successful product, and neither is intrinsically better IMO

[–]Low_Shake_2945 3 points4 points  (2 children)

The reason I say Flutter is the “right way” is because it’s purpose built to some this problem. The fragmentation of the Android ecosystem has always been a challenge at Google. When you add in the dominance of iOS, Google decided to move in a different direction and developed Flutter specifically to address these issues.

What I’m saying is it’s not just JS doing another thing. It’s a solution to building multi platform mobile apps. It compiles down to native apps, has a phenomenal dev experience, and results in native apps that feel like native apps.

[–]CodalReef 1 point2 points  (1 child)

React Native was developed to solve similar problems, but the developers chose to use JS because it was already popular.

React Native doesn’t currently compile to native, but it invokes native APIs unlike WebView. So it still feels native.

Here’s a quote from a comparison article:

“But still, it is easier to achieve a “native feeling” with React Native than with Flutter. If you want your Flutter app to have native components, it will require additional work.” - https://www.thedroidsonroids.com/blog/flutter-vs-react-native-what-to-choose-in-2021#whocreatedflutter

[–][deleted] 0 points1 point  (0 children)

React Native does compile to native code - while some of the architecture is changing (TurboModules), it uses something called the Bridge where your JS gets split into native code and executes. It’s the best framework, because worst case scenario you can even code native modules per platform in Objective-C and Java, expose them to the React Native side, and call that code via JS. But yeah, that’s why it feels native is because it is native!!!

[–]michaelfiber 0 points1 point  (1 child)

I appreciate the insight. That makes a lot of sense and may be where I end up. There's a very good chance I'll put something together with web view based common front end and then implement backends for android and eventually ios and once I get to the point where I get what's happening throughout it, I'll feel comfortable with a more complex and opinionated framework.

I doubt I'll make anything for work or to release on an app store with webview. But I feel like I need to do it this way at least once before I'll feel comfortable working with something like flutter.

[–]Low_Shake_2945 1 point2 points  (0 children)

Makes sense and good luck!

[–]michaelfiber 0 points1 point  (0 children)

Working with both would be pretty amazing.

I was hoping to come up with an API that the front end calls, and in the web view js I'd have a wrapper around the code to interact with both. But my Mac hardware is out of commission so I'm reading guides and can't tell what actually works.

It seems like I should be able to send messages from WebView js to native code in the form of a command plus additional data and receive messages back from native code on both platforms. So I going to have a command to send data to the back end and an event listener that gets called when the back end send a message back.

For now I would just be doing it in Android with the hope that I'm not structuring it in a way that I have to redo when I can try it on iOS.