Joke Collection Website - Public benefit messages - What is the difference between native development and mixed development of app?

What is the difference between native development and mixed development of app?

native app is a mobile app developed by using the local operating system of mobile phones. At present, mobile phone systems are mainly divided into Android and Apple iOS, both of which have their own programming languages and tools. The development of native app is to develop it separately by using official development tools.

app mixed development is the integration of NativeAPP and webapp, some core modules are developed by native mode, and non-core content is realized by web mode.

APP development mode is usually divided into WebAPP and NativeApp native mode, both of which have their own advantages. Whether to develop by native app or WebApp has always been the focus of debate in the industry. However, with the development of HTML5 and the popularity of cloud services, it is becoming a trend to adopt HTML5 for WebApp development. Users can choose according to the APPlication characteristics and requirements, or they can choose a mixed mode of the two:

NativeApp development

NativeApp development is what we call the traditional APP development mode (native app development mode). This development should adopt different languages and frameworks for different mobile phone operating systems such as IOS and Android. This model is usually composed of two parts: "cloud server data +APP application client", and all UI elements, data content and logical framework of APP application are installed on the mobile phone terminal.

WebApp development

WebApp development is a framework-based APP development model (HTML5APP framework development model), which has the advantage of cross-platform. this model usually consists of "HTML5 cloud website +APP APPlication client". the APP application client only needs to install the framework part of the application, and the application data is presented to the mobile phone user every time the app is opened.

the difference between native APP development and WebAPP development mode

WebAPP needs to develop "html5 cloud website" and "APP client". Kunming tiandu network company concluded that this type of APP has the following characteristics:

(1) every time you open the APP, you have to get UI and data from the cloud website through the APP framework;

(2) Mobile phone users can't access the data in the APP application if they can't surf the Internet.

(3) Frame-based APP can't call the hardware devices (voice, camera, SMS, GPS, Bluetooth, gravity sensing, etc.) of the mobile phone terminal.

(4) The access speed of the frame-based APP is limited by the Internet access of the mobile phone terminal, which will consume a certain amount of mobile phone Internet traffic every time it is used.

(5) The installation package of frame-based APP application is small and contains only frame files, while a large number of UI elements and data contents have just been stored in the cloud;

(6)APP users can access the latest real-time cloud data every time;

(7)APP users don't need to update the app frequently, but realize real-time data interaction with the cloud;

APPlicable enterprises: e-commerce, finance, news and information, and app applications that enterprise groups need to update frequently.

NativeApp needs to develop "cloud server data center" and "APP client". Kunming Tiandu Network Company summarized that this type of APP application has the following characteristics:

(1) Every time you get the latest APP function, you need to upgrade the APP application;

(2) The installation package of native APP application is relatively large, including UI elements, data content and logical framework;

(3) Mobile phone users can access the previously downloaded data in the APP application without surfing the Internet.

(4) The native APP can call the hardware devices of the mobile phone terminal (voice, camera, SMS, GPS, Bluetooth, gravity sensing, etc.)

(5) The APP application updates new functions, which involves submitting to various application stores for review every time.

APPlicable enterprises: games, e-magazines, management applications, internet of things and other app applications that do not need to update the program framework frequently.

how to choose WebApp and NativeApp development mode

mobile Web is ubiquitous, and it is the only platform that supports various devices to access at present. Like desktop Web, mobile Web supports various standard protocols. Mobile Web is also the only platform for developers to publish mobile applications, which effectively connects various mobile interactions with desktop tasks. The development of NativeApp can make full use of the characteristics of devices, which is often impossible for Web browsers, so for a product itself, NativeApp is the best choice. The following sections will discuss some major functions of NativeApp.

when should I choose a NativeApp

1. Charge for the application

There is no provision that developers cannot charge for the use of a mobile WebApp, but for some reasons, people often think that they cannot or should not charge for a WebApp. Due to historical reasons, there are two major obstacles to the payment service on mobile devices:

2. Payment methods

It is quite troublesome to enter the credit card number on mobile devices, and there is no security guarantee on many old-fashioned devices. A typical way is that if you need to charge for your application, you can reach an agreement with the operator to let the operator charge for your service on your behalf. This also means that you need to reach cooperation with multiple operators. This is usually the first choice, because many mobile phone users may not have credit cards at all, such as teenagers.

another method is to save the user's credit card information on a secure website. Users can purchase application services by logging in to this website. This process is not particularly ideal, because it means that users can't buy services directly through their mobile devices.

3. Forced sharing

Mobile operators will get a commission. Whether the App is released through operators or mobile devices, they all provide a charging mechanism for the app. These operators and mobile devices will extract part of the revenue and then hand over the rest to application developers, which means that developers must abide by their market rules. It is usually very difficult to adapt to the market rules of operators, which requires a lot of human resources. Comparatively speaking, the market rules of mobile devices are much simpler, but there are also many difficulties.

applications and services that hinder the interests of operators and mobile device developers will be blocked. In the past, websites that were not operated by operators and mobile device developers could not escape the fate of being closed if their income was too conspicuous, but recently, such things rarely happened.

if you want to charge for your NativeApp, then you must accept this reality-you must abide by other people's market rules and give up some revenue.

4. develop games

if you want to develop a mobile game (mobile games are the biggest piece in the mobile market), then you need to develop a NativeApp. Games take up a lot of resources and need to use many device APIs or platform APIs. Although there are several games that are completely developed by Web technology, they have a certain market share, but compared with the market share of NativeApp, they are still insignificant. Game users have high requirements for the visual and operational effects of the application. Although mobile Web provides some simulation experience, it is far from meeting the needs of users.

when developing mobile games, you need to carefully consider which platforms your application needs to support. Fortunately, there are many tools that can help you push your game to multiple platforms, but it still takes a lot of manpower and material resources to complete these tasks.

5. using the location function

the next function is the location function, which can determine the current location information of the user through GPS or signal detection. In the past, users' location information could only be viewed through the APIs of NativeApp, but now W3 Localization API is embedded in most mainstream mobile browsers. Devices with WebKit installed, such as iPhone or Android, or devices with Opera or Mozilla browsers, can get the user's location information.

I believe that location function will bring many new applications to Web technology. If the Web browser can be used reasonably, Web developers can use the user's location information and other content to develop more interesting applications. Although this is not technically difficult, it is limited by privacy protection regulations. We regard the Web browser as the entrance for users to enter the WorldWideWeb. Adding location function means introducing some sensitive information into the website, which may lead to serious consequences. However, the location information displayed in the location-aware application must be authorized by the user, and the user certainly has the right to prohibit the application from publishing its own location information.

6. Using a camera

A camera can provide rich possibilities for your application. In the past, mobile MMS(MultimediaMessagingService) was used to process mobile photos. In other words, after you take a photo, you need to use MMS to send it to a server, and the server will process the photo accordingly and inform you of the finished result. This process is very time-consuming, and quite complicated, and there is no guarantee of reliability.

by accessing the camera, NativeApp developers can simplify the process of taking photos. Users can do some simple processing on photos directly at the client, and upload photos to the server only when necessary, and it is transmitted through reliable HTTP. W3C is developing an API to access the camera, but it has not been formally integrated into the browser.

In many types of mobile Apps, the camera is very useful, such as snapshot application, short film shooting application, etc. The camera can be used to capture many important moments. In the near future, we can see that-as long as a logo is photographed by a camera, the application can automatically complete the language conversion on the logo-this technology has become popular in Japan.

7. Using sensors

Now more and more mobile devices have added the sensor function, which can sense the physical speed and gravity of the device and transmit the sensed data results to the device. This device is often used to sense whether the settings are turned over, and the application automatically adjusts the direction of the picture according to the received information.

sensors can be used to help users improve the sense of reality when interacting with devices; Most mobile devices are handheld, and applications can adjust the content screen according to the direction of the device, such as flipping the screen or detecting physical movement, and can guess the user's environment accordingly. For a simple example, if the user is walking, the sensor can detect a slow movement or speed, which can provide the user with a large font user interface, thus making it easier for the user to see the contents on the screen.

However, developers can't rely too much on sensors, because sensors can't tell which interactions are intentional and which are meaningless. Every mobile interaction needs to pass the "transmission test". When designing your interaction, you must consider the user's scene in a crowded car or train. Consider whether your application can correctly handle the user's shaking of the mobile device if the user is in a crowded subway or driving. Usually, most developers don't consider these factors. Make sure to design a backup plan for each task to deal with mobile interaction in special scenarios.

8. accessing the file system

if your application needs to save data locally, then you need to develop a NativeApp. For example, you should save the user's address book, telephone or E-mail information, or save the data obtained from other devices.

accessing a file system often involves issues of security and user privacy protection. Malicious applications may modify or delete data on your mobile device. An application with virus can spread the virus to many other mobile phones by using the network on mobile devices. This kind of thing often happened before the mobile application authentication mechanism was adopted.

on the other hand, mobile devices are becoming more and more private, and a large number of users' personal information, as well as users' friend information and business information are stored on mobile devices. It is a good idea to develop applications for these private information. However, there are some risks. Using data stored on mobile devices can provide users with more targeted services.

developers must keep in mind that users' private data can only be accessed after obtaining their authorization. We see that many applications use a lot of users' private data without users' authorization, and they are mistaken for spam or phishing applications, even though these applications are originally providing some very useful services. People's misunderstanding of your application will affect the promotion of your service. If the operator receives too many complaints about your application, your service may be terminated, and even other applications will be implicated.

when accessing the file system, it is very important not to access any user's private data without the user's authorization. This point is often ignored by most applications. W3C is developing relevant standard API for mobile developers, but the work has not been completed yet.

9. offline users

the last reason why they need to develop NativeApp is that users may be offline or unable to access mobile networks. This may rarely happen in cities, and even in rural areas, network coverage has gradually become popular. However, short-term network connection interruptions still occur from time to time, and your application should consider how to deal with this situation.

think about when and where users usually use your App. If it is a mobile game, then users are likely to use this App on the plane. Tracking map applications are often used in remote places with poor network coverage. Mobile travel guides often visit a foreign network and often need to pay roaming and international network fees. At this time, it is best for the application to provide offline services for users, so as to ensure that users can still enjoy the same services without accessing the network.

browsers that now support HTML5 can also realize offline access, but it may not be obvious to users. As more and more browsers begin to support offline access, applications need to clearly tell users that they can still access mobile WebApps when the network connection is interrupted.

NativeApps often assume that the network connection is reliable. App usually only considers the scenario that the network is in good condition and takes it for granted that the network is closed and the network speed is fast enough. It is not uncommon for mobile devices to suddenly enter a bad network environment from a good network environment. NativeApps should be tested under the worst network conditions. For example, the user may still have full signal coverage when starting the task, but there may be no network signal at the end of the task.

the user is in an.