Hello, everyone. I am So In-seong from 29cm, and I have been tasked with presenting how to quickly implement web services into apps using WebView. Please give me your support. 

Before I begin my presentation, let me briefly introduce myself. I have been a professional soldier for nearly six years, and now I work as a developer at 29cm. However, my introduction is not the main focus; I’m just glad to see all of you. 

This presentation is not a technical dive into WebView, nor is it about making apps more elegant and flashy. I will not be sharing a grand narrative about transforming web services into apps. If you were expecting that, I hope you can set those expectations aside. 

What I hope you will take away from this presentation is an understanding of what WebView is, what tools to use, and how to seek help through certain keywords.

We can apply this directly to the BaroBaro app. So, I will continue with the presentation. My presentation will include a QR code, so if anyone wants to see the code directly on their phone, it would be good to have the QR code scanner open. Now, what are the criteria we consider when thinking about an app? Usually, when we decide to develop an app, it is when the planner or the company's service needs to grow significantly, or when we want to better understand user needs and enhance the business's performance. The reason we need to start with an app is very clear: mobile device usage overwhelmingly dominates. So, what is the difference between a web app and a mobile app? If we simply develop this web service and access it through a browser on a mobile device, everything...

You could say that responsive design is better. So, if I were to make a very rough analogy between web apps and mobile apps, I think there would be a difference like this: a mobile screen that is implemented as a responsive web design versus a mobile app that is designed specifically for mobile screens. What are the differences? There are several, of course. I have removed the disadvantages and only noted the advantages. Just knowing these points can be very helpful for interview questions. But what determines whether we choose an app or a web service? It's not just important when we are doing personal or toy projects. When a company is starting to develop a service, what is the key point that marks the starting line? First of all, the best thing about the web is that it can encompass various platforms.

So, productivity is very high. On the other hand, mobile devices may have slightly lower productivity because we need to develop for both iOS and Android platforms. However, the fact that mobile devices can be used to expand functionalities more meticulously is a significant advantage. Now, let's talk a bit about the presentation topic, which is WebView. WebView exists on both Android and iOS. This means that it is not a unique feature of cross-platform frameworks like React Native or Flutter, but rather one of the abstracted interfaces supported by native languages themselves. So, what is WebView? I think you might ask this question. WebView can be summarized as an embedded browser that allows us to incorporate web content into our app.

If you have ever experienced or used an iframe, you might feel that this iframe web view is quite similar. We often use Google Home, and if you take a closer look at Google, it is structured in this way: there is a status bar, and the web screen is displayed, which is also an app. In fact, it is difficult to say that Google Chrome is just a browser; it is a form of a browser opened within an app. The web works the same way. It is layered on top of a native app, allowing the web view to render web content. If we look at this in a more detailed diagram, it is displayed like this: on the right is the web app, and on the left is the mobile app. The differences are quite pronounced, and suddenly the term bridge appears, which may seem unfamiliar. Both are native platforms.

There is an interface that can operate on an OS and communicate with any web app or web content. This interface serves as a kind of tool that allows communication with native platforms, OS, or web content. These are things we don't need to worry about. Through this bridge, we can directly call the basic system API. In fact, the term plotter refers to a framework that uses different languages. Despite the differences in language, it can call native code, as well as React Native, Swift, or Kotlin. This is possible because, similar to what is created in a web view, certain system APIs can be called. The biggest advantage of a web view is that it can integrate native functions through the JavaScript language. Let me reiterate.

This function is called a bridge. A bridge is, to put it simply, an abstracted interface. You don't need to focus too much on the term bridge. We can just use it as needed. Since you can control it using all the code from the API, if you think you need to create a bridge yourself, your app or service you are developing is likely already evolving to the next level. Now, we need to find a representative example of this bridge, and you may have seen it often: it's the PostMessage provided by the Windows object. This PostMessage doesn't exactly perform a specific action, but by binding events to the Windows object through PostMessage, you can receive specific messages delivered by PostMessage in the Windows object. If you just remember this one thing, we can move on to the next topic.

While working with web views, many additional features can be applied. So, what is good about web views? Web views allow for simultaneous bidirectional development, which is very beneficial. Once you develop it, you can cover the app, and you don't have to worry about multiple platforms. However, that's not the most important aspect for us. The reason why web views are a good technology is that, as I mentioned earlier, web views operate in a completely isolated environment from the domain and web app. Later, I will show you the code for GIF Pro. If a runtime error occurs within the web view and the website crashes, we often say that the error in the code propagates. In actual services, if this propagation occurs, the server would crash. Conversely, even if the server crashes, the app does not shut down. This creates the most significant independent and separate sandbox.

The biggest advantage is that our developers can directly handle the web view. This means that even web content opened in a web browser can function more independently within the web view. Ultimately, choosing a web view can make it feel like you are utilizing all the features of a native app. The reason for this is that the code running on the web service communicates through the web view, allowing it to interact with the native app. Therefore, you can implement these features in a more scalable way. Now that we've covered this, we need to prepare for how to create the app. Before that, we have a decision to make. It's a really tough question: React Native or Flutter? They have been in fierce competition. In fact, I...

While preparing, I continued to search for information, and I think I can make a comparison. If you look at React Native on the left, you can see that one hour in the planet's time equals seven years. So, by the time I return, React Native will have been released. However, the major version has not been updated yet; it is still at 0.777 and continues to rise. Meanwhile, update patches are still being released. Google is leading Flutter, and two weeks ago, they officially announced that the code push feature, which React Native had, will be applied to all platforms in Flutter. So, in effect, React Native might be at a disadvantage. But this announcement is about React Native. Initially, React Native was overwhelming. Why was it overwhelming? Because React was very strong at that time.

Facebook was too strong. It was before the beta phase. Gradually, it started to rise. In 2023, Meta abandoned React Native. So now, React Native is returning to the community team, while Flutter is steadily gaining traction. We need to compare these. I'm already exhausted. I make these decisions and talk to the leaders, and those leaders in the head office are finding it very difficult. What are they even saying? Seriously, what on earth are they talking about? So let me summarize it clearly for you. It's a bit extreme, but if you are creating an app without web services, you simply don't have the resources. If you don't have iOS developers or Android developers, you need to use Flutter. If you have web services or have tried React, then you should go with React Native. This is not about technical proficiency or community completeness; it is a realistically feasible option.

Here is the presentation. Many of you participating in this venue have used React, right? So, I have prepared React Native. This way, you all can have more opportunities to create an app at least once. Now, I apologize to others, but I have thought about this. We should take a look at what React Native offers. Earlier, I mentioned that a web view acts as a kind of bridge, allowing communication between the web and the app. If you look at this phrase, when sending from React Native to the web and from the web to the app, we call it through respective properties and methods. It may seem a bit difficult at first glance. The properties above are predefined, while the methods are actions we can freely perform dynamically. Let's look at the code; on the left is React Native.

This is an app. If you look at the area marked with a red line, it is implemented with injected JavaScript. This code can send the template string above when the web view opens the web page. In other words, this executes first, which is why you can see Hello displayed on the screen on the right. Okay, I apologize. Next, we will discuss sending data from the web to the app. I have prepared a template like this because I need to show you the HTML file. Please refer to the box with the red line. I have defined a method called postMessage, and on the left side, I have defined the onMessage property. If you look at the screen on the right, you can see Hello appearing. This means that we can handle the web view arbitrarily without modifying any code on the web. Up to this point, we have discussed what tools we might use and the web view.

If you think you can handle it, then it's time to set it up. React Native integrates like this; it's JavaScript code. This JavaScript code communicates organically with these bridges and continues to interact bidirectionally with native modules. That's why I say it integrates this way. However, this slide itself is not very important. But the flow ultimately needs to be compiled from React Native to JavaScript. So we need to start, but since I don't know how to start, what I have prepared is what we see very often: React Native. This React Native has no custom settings like Java Native, so we have to do everything ourselves. It's inconvenient and cumbersome, but on the other hand, because there are no attachments, it feels a bit more...

It's easy to get native. This chapter is a spoiler, but React Native is a more framework-oriented and convenient tool. It's not all that important, but just remember that it has a simpler workflow. So, this presentation is prepared based on that. Before setting up the project, we might say that we don't have it, but let's not use what has already been created. We chose React Native based on our resources, so we need to find a more efficient path. If you use X4, you can easily finish everything with the CLI. Just by setting it up like this, the project will be created. I intentionally didn't include more detailed information, so it would be good for you to actually run the tool or check the guide on the Dev server or Dev page, as it provides excellent guidance. Let's start with the initial setup.

Let's add a web view to the project. We will install the React Native WebView library. The file in the top left is the initial app that appeared when we set up the project. The code has changed on the right side, but the number of code lines hasn't changed significantly. Now, here comes the Q. I have written the code to display a link. The right side shows the execution screen. You don't actually need to see it. On the right, the app has become an app. So, is that the end? Has it finished? Looking back, I received some feedback. The screen is covered by the notch, the scrolling is strange, and swiping doesn't work. If the internet disconnects, a white screen appears, making it seem like the app has crashed. Yes, we need to develop it further. Before we develop the app, we need to think about the ideas we had on the web, how to handle routing, and domain design.

When discussing how to design a URL, planners, data scientists, and developers will often talk about what events will occur with that URL. You need to discard all of that because, in an app, there is no browser, and therefore no routing. Instead, we have implemented a navigation system that provides routing functionality. This navigation can be broadly categorized into protected and nested routes. Remember that we need to use native modules to utilize the app; otherwise, there is no point in using the app. If you keep this in mind, you can check the contents. 

On the web, we use anchor tags to facilitate communication between documents, allowing for page navigation and presenting information in a more efficient manner for users. However, since the web is not the same as an app, the code does not function in the same way. This is not important. We will stack screens in the app, unlike the web.

If the browser manages history, the app manages screens in memory as a stack. Now, how do we configure navigation? This is all well documented in the React Native documentation, but it's important, so I will elaborate a bit more. Navigation operates under a top-level component called the Navigation Container. If you don't wrap this, you won't know where to store the data in memory. Therefore, you must input this and then define the components that will be included underneath. This is what we can understand as the screen component. So, how do we define the Navigation Container? You can define it like this: just import it from the library and write the definition, and that's it. There's no more to worry about. Now, we need to see how navigation works. Here...

There is code that applies a stack. This is a form that you often see in apps. You can modify this animation yourself. The library called React Native Stack is available, and there is also React Stack. The difference between Native Stack and Stack is whether it can be customized or not. Next, when we swipe, an interaction occurs where the hamburger menu appears and disappears, and this is also navigation. The usage is the same; you create an instance of the navigation and then define the navigator. Lastly, we often see the bottom tab in apps. It organizes the screens by tab. You can declare it in the same way. Earlier, I mentioned the screen component; all navigations are components of this screen, which are passed as props to the navigation and routes.

We can inject this. With this navigation and route code, we can handle the code coming from the web view more efficiently. Of course, if you don't want to use such features, but you want to pass between different stacks, such as from stack navigation to drawer navigation, you can use these functionalities. The screen component has various properties; I made the color a bit gray to indicate that it is not important. You can see what role it plays by looking at this. For example, if I need to move to another screen or if an event occurs on this screen and I need to reset or go back, we have defined these functionalities. Now, we just need to examine them and apply them according to the relevant cases. The reason we need to look at this in detail is...

The reason I say there isn't one is that we need to create the app quickly since we already have a web service. However, there are times when we cannot receive the navigate route sent from the screen component in the web view component, especially if it is not a full-screen web view. For example, if we want to wrap a component in the web view to make it look nicer, or if we have not only the web view but also buttons, inputs, and a keyboard, what should we do in such situations? We also provide a solution for this. We offer it as a hook, so by using the useNavigation and useRoute hooks, we can handle it in the same way within that instance object. Now, if you hear all this, it might sound quite complicated. I have prepared an app for you; it might be a very unfamiliar app for you. Until now, we have only focused on to-do lists.

I think to-do lists are very cliché. There is an app called Real World. Later, if you go to the link provided, the official documentation will open, but that's not important. I have prepared a demo. The demo shows how it works, but you don't necessarily have to watch it. However, since it's on mobile, you just need to understand the basic features. On the left, all the functionalities are provided. It's a great app for creating projects. For this presentation, I created an app, and you will hear how the app in this code repository changes. The conditions are as follows: we need minimal development and a quick release. So, the structure remains the same. This technology is something you use very frequently, so I included it. Now, let's discuss how to implement and design the app.

Should we take this? We need to start from here, but let me highlight some important points. In web services, we often fix the header in place. However, when we explained the drawer earlier, you might have felt that it resembles a hamburger menu, right? So, we should use the hamburger menu, which means we need to use the drawer. Should we use a header controlled by the web in the app? Typically, when you access the header through a master GMB account, the header changes, and clicking on different headers often alters the routing. Should we use this? We probably shouldn't. In general decision-making, it is usually decided not to use it. So, there should be criteria for which components should be visible on the web and which should be visible in the app.

Therefore, you need to be able to distinguish between the web and the app. When page routing occurs, you must decide how to design the routing, which routes to hide, and which screens to display. Additionally, when a user logs in, where should that information be stored, and how can we handle authenticated users? Also, how can we utilize native features? I believe this is how we can proceed. I will explain in this order: when a routing occurs in a web view, we catch it and overlay a screen, using a library to manage the storage more impactfully. 

So, how do we make these judgments? In the web, the view provides elements to determine whether it is an app or not through the window object. The first is the user agent, which shows whether the user is accessing from Android or a PC. This is one aspect.

The first point is that when accessing through a web view, there are properties that the web view provides through React Native. We need to determine whether this property exists in the React Native web view. The second point is about the screen. We create mobile apps, right? Because of the responsive screen, the size of the screen is fluid. If we check the maximum size, we can clearly identify that it is mobile. However, when it comes to mobile web, even though it is responsive, we need to check the web view, which can be combined with the previous conditional statements. So, how do we provide router events? We will use the bridge that has the window object we mentioned earlier. By using window.postMessage, we can send messages to the web view, and the web view will handle and control the corresponding data. By sending a post message like this,

The parameters that are important are the ones that are included in the middle. This code is written for the web, specifically for handling values before processing them. The React Native WebView checks if there are any properties available. If they exist, that would be nice. Then, we wrap the router provided by Next.js once more. When it comes to the WebView, we send a message, and when it is not a WebView, we push the router. Of course, after logging in or signing up, instead of pushing, we need to replace or remove any processes that will occur next. It would be great if you all could make these decisions. Then, an object comes in. This object appears because, in the React Native WebView code, when we insert the message handler's event, the variable for the native event corresponds to that string.

I have all the text. Of course, Jason has the object. With this, we can control the properties related to navigation, such as stack actions, pushing, navigating, or dispatching. We can utilize the properties we talked about earlier regarding navigation. Now, how do we control log navigation? There are two cases for log navigation: nested navigation and using storage. 

Nested navigation does not require you to scan a QR code. The code is the same, but the actual implementation is different. If you look at the navigation, when you click on settings, the drawer disappears, and it pushes. In an environment with nothing, the bottom tab also disappears. This means we can configure the screen according to the case. This is nested navigation. 

So, how do we store information? We need to use a library for information storage. We must not do anything else. When developing an app, this is essential.

You need to use a lot of libraries or port them yourself. This is local storage, and even if the app is closed, the data remains intact. You can use it like this. It seems like you're handling state management, and if someone has recorded this before, they would know that this actual code works even when the app is closed. Oh, they say they need push notifications, but everyone seems to need everything. This really doesn't make sense. We will only look at the important things. We will check if the features are necessary. Of course, it would be nice to have them, but the question is whether they are needed right now. It seems like only push notifications are necessary since that's why we started the app. There are two types of notifications: local and push. Local notifications are when we directly send notifications to the app. This is how notifications actually work, but local notifications are not included in this picture. The app itself...

Because it is being thrown, the to-do reminder alarm app sends push notifications. So, what does this diagram represent? It illustrates the explanation for push notifications. The development app either sends a notification to the notification server or calls the backend, which then sends it to the notification server. In other words, it handles notifications based on user events. However, Google and Apple have restricted this; you have to pay. It's a monopoly. Here, the platforms are involved, but third-party tools do not just sit idly by. They set up an external push notification server and communicate with it. How do they communicate? They make HTTP method requests. Just by making a request, the notification is sent. Now, how do we implement this? We mentioned that we use the X4 framework. By using the library provided by it and configuring it on the right side, you are done. The rest is an explanation of the methods.

We're going to do a little bit, but even if you're a bit distracted, you can still follow along. The methods are available for you to search and find as much as you need; just focus on what roles they play. First, this is the screen for local notifications. You don't need to scan the QR code. If you look to the right, that's what you would see in a real mobile app, and on the left is the simulator. You can confirm that a push notification is coming in. There are various functions here. First, you set how to send the notification and how to handle it. Then, there are event branches for when a notification arrives or when a received notification is tapped. There are methods to decide when to trigger local notifications. However, we don't need local notifications for push notifications; we need push notifications. Sending push notifications is really simple. First, we need to have permission before sending push notifications.

All the features of the native app require permissions. Access to the camera, file uploads, downloads, and the recorder all need to be authorized. However, before requesting permissions, we need to check if they are already granted. If the status indicates that permission is granted, we can handle a unique value from the user. To send something to a user, we need the instance ID of that user. This instance ID will be stored in the database, and when we retrieve it, we can control it with the push token data. In fact, when sending a push notification, we use this token data. The code we developed is shown on the right side of the screen. When we run it in the simulator, it will work on mobile. The reason for this is that the mobile app does not support push notifications on the X4 simulator. Therefore, we used a mobile device. You can see that we are sending a push notification to the server.

You receive notifications on your mobile device, and you can also confirm your reactions. Now, one thing to keep in mind is that React Native components do not operate like HTML. It is not the web. Therefore, everything is compiled into native code that is bundled by JavaScript. We will need to customize this later. Since it is not the web, there is no CSS; there is no CSS object model. As a result, some CSS styling does not work. iOS and Android may behave differently as well. Naturally, since it is not the web, there are no events. Those events are handled by native events through the JavaScript bundle. Finally, let's assume that the app has gone through various gateways to be created. We need to build it, and with this one command, it’s done. After creating any app, the term eas build is used.

By doing this, the Android bundle has been completed in the middle here. However, if you look at the bottom, there is a red line, which indicates the iOS bundle. The iOS bundle requires payment. Therefore, we can first upload only the Android app to the Play Store. Usually, Android development is always faster for this reason. At this point, you might think, Oh, I can't do this, but we still have to proceed. Let’s summarize: for minimal development, we only included two pieces of code: checking the web view in the web code and intercepting and handling routing events. This way, we have a clear idea of how to design the app's screens when routing events occur. Based on user information, we will determine which screens to show and which components to hide. We included push notifications.

Since we have entered, at least the minimum native development has been completed. This means that the app meets the requirements. Now, this is the code I have completed, and you can see how the code has changed on the left. As for the app, you can just take a look at the code. The next screen is the layout I envisioned. I have simplified the screens that were previously used in the Real World app. It’s simplified; it checks whether the user is authenticated or not and shows different screens accordingly. This is the layout. There is a splash image, and when the event is triggered, the bottom tab appears. Even with pagination, the stack builds up. Now, you need to log in. Once you log in, you will see the drawer on the right. You can go to your profile and write posts. I hope that when you hit like, a push notification will come. First, let’s set the theme.

I have added a settings tab that can be changed, and a deep link that opens a specific website. I haven't implemented anything directly myself. When you click like on the left, a push notification comes in. With just this, we can say that we have completed the app, as the web service has quickly turned into an app. Now, what we are curious about is how to launch the app. Currently, there is a built app version file. First, we need to prepare the accounts. Of course, we need to prepare the accounts, but these accounts come with a cost. Google is very quick with feedback, but Apple is quite slow, so always prioritize Apple first, and I hope you can handle both Google and Apple together. When you set up your store, always remember to prepare static resources. Designers should always take care of this first.

They take care of it. When you study or read books, you often talk about these topics. Right now, when we launch the app, there are things that come up just by searching. But there will be questions about whether we can launch an app with just the surface features. In fact, we receive feedback from Apple like this: Why does it have to be an app? What is the reason for making this an app? The thing you have created is just like an app, but is there a reason it needs to be an app? No, there isn't. So, at the very least, we need to develop local native notifications. That's why we are adding notifications. If you look at it, on the left is Apple and on the right is Google. Sometimes we receive feedback that certain features are lacking. This feedback is very detailed, so after reviewing it, we make revisions and then distribute it.

If you provide it, the review process can proceed smoothly. This is the last part, and we have developed this much. We have thought a lot about it, and now we need to expand the app. It will really show a lot. Earlier, in the completed app, there was a brief pink screen when the app was loading, which is called a splash image. When the app is opened, it shows the user what the app is about, such as what icons to include and how to manage so that it doesn't get blocked by the notch. It also involves changing the colors of things like the Wi-Fi connection and clock displayed on the notch. All of these can be done with React Native itself, and if we additionally incorporate native development, everything can be completed. If you have the time, these are really good things to do. Of course, other considerations include expanding the bridge interface, managing files, and adding a camera.

By providing voice recordings, you can enrich the services you create. For instance, in the user environment I showed earlier, you can make decisions about how to handle screens differently based on whether a user is logged in or not. Once deployed, if this app does not manage version control, rolling back will not be possible. Therefore, it is essential to conduct thorough testing before app deployment. 

Next, since users will be using the app, we need to collect events to verify our findings. This involves significant work with data scientists, as it requires expansion. Naturally, service logs must also be in place. Additionally, since webview-based apps can crash if the network is unstable, we need to gradually bring these issues into the native area. This is what expansion entails. Ultimately, if you want to expand the app, you need native developers.

This is an unchanging truth. There are many frontend developers among us, and there are also many backend developers. Without native development, we cannot proceed because it is necessary to understand the language and the device. I believe that the representatives need to fight for this. Of course, a completed app may function, but it might be a bit lacking for users. However, since it works, we should use it for now. But what can we do? We have done our best. Now, the presentation is almost finished. Of course, if it ends here, it will be difficult for you to say that you have developed an app. As I mentioned earlier, the app needs to be gradually expanded; only then will it truly benefit the company's services. Until now.

The information we discussed can be verified through the reference materials. I will conclude the presentation now. Thank you.

웹뷰를 이용해 웹 서비스를 앱으로 빠르게 구현하기 | 인프콘2023

IT분야, 프로그래밍, 디자인, 업무스킬, 3D 모델링, 온라인 마케팅 등
전문 지식 분야를 무료 혹은 경제적으로 학습할 수 있는 인프런 입니다.

더 많은 학습을 원하시면 인프런으로 놀러오세요!

미래의 동료들과 함께 성장하는 곳, 인프런
🌱 인프런 바로가기 : https://www.inflearn.com​ 
