Mobile hybrid application Hybrid App development practice

[Introduction] In recent years, with the increase in the types of mobile devices, the increase in operating systems, and the increase in user needs, before starting each project, everyone will consider a lot of factors such as cost, team members, technical maturity, time, project requirements, etc. Therefore, there are more and more solutions for developing apps. There was a small wave of HTML5, and countless people participated in or saw a discussion: native development or hybrid development, or Web development? What is the best practice? I think only those who have practiced it will know. Especially in this mobile Internet era full of various variables.

[Abstract] The author will start from the current development status of Hybrid App, explain the advantages and disadvantages of Hybrid App, compare the respective characteristics of Hybrid App and Native App, and finally explore the new ideological direction of Hybrid App.

Analysis of the Current Status of Hybrid App

Web App

There is no doubt that Web App is the most cost-effective and fastest solution. Especially in the past two years, the responsive design has been very popular, and the Web App market provides a very good practice venue. The most recent typical Web App best case is the Sun weather application, which is praised for its detail processing.

Generally speaking, a Web App has the following characteristics: it runs in a browser; it is a pure Web front-end architecture, and many important mobile features cannot be accessed, such as contacts and push notifications; it is a Single Page App; and its sales channels are mostly limited to browsers.

Hybrid App

The so-called Hybrid App actually has different branches and overlaps with Native Apps. Here are three different solutions.

Solution 1: Use middleware such as PhoneGap and AppCan, use WebView as the user interface layer, use Javascript as the basic logic, and communicate with the middleware, and then use the middleware to access the underlying API to develop applications. This architecture is generally very dependent on the performance of the WebView layer.

Solution 2: Use unofficial language tools such as Adobe Air, RubyMotion, Appcelerator or Xamarin to package and develop as native applications. The reason why I define them as Hybrid Apps is that they are not simply developed using the native language, but by providing developers with friendly development tools and converting the development language into the native language, and finally packaging the entire application, so they also belong to the category of hybrid applications.

Solution 3: Based on the development of native applications, WebView is embedded, but the overall architecture is provided by native applications. Generally, such development is composed of native developers and web front-end developers. Native developers will write the basic architecture and APIs for web developers to develop the interface and most of the rendering. This ensures that both the interaction design and development have a relatively compromised effect, and good optimization will also have a great effect. (Facebook Three20 used this solution that year)

Therefore, Hybrid App has the following characteristics:

1. The native language may not be used or may not be used mostly during development, but it has all the features of native applications;
2. The architecture solution may differ from the original one, which is basically determined by the tool;
3. It has cross-platform features;
4. Generally speaking, development is simpler than native development.

Native App

Native App is undoubtedly the most reliable solution. However, the learning cost, talent cost, development efficiency and consideration of the characteristics of different platforms have become a hurdle in the minds of developers. As for whether this hurdle is insurmountable or a hurdle that allows you to improve, I think it depends entirely on you. Based on various factors, it is estimated that many people will choose a compromise solution and develop Hybrid Apps, including myself.

More content below will be discussed around Hybrid App development.

Advantages and disadvantages of hybrid app development

In the process of developing Hybrid App, I have experienced several different solutions. Of course, I have also experienced the development stage of Native App. In such a complicated process, I have gained a lot of experience. Now I will share the advantages and disadvantages of these solutions with you based on my own experience. For those who are new to the industry, I started from the Web front-end. After all, the threshold is low, and I can quickly cultivate my confidence and sense of code. After going deeper, I started to get involved in mobile development. So I will start with the first solution of Hybrid App.

Solution 1 (Web architecture is the most important)

advantage:

1. Full Web development helps Web front-end technicians to quickly build page styles to a certain extent;
2. It is helpful to display the same interaction layer on different platforms;
3. Easy to debug, you can debug through the browser during development, with rich tools.

shortcoming:

1. Although you can focus on interface and interaction development, this page will become a disadvantage. For example, to imitate the default settings interface of iOS, a lot of HTML and CSS codes are needed, and the effect may not be as good as the interface on iPhone.
2. Because this is cross-platform development, it is still the same sentence: compatibility is the pain of the front end. If you have learned about web development on Android machines, you will know this pain. For example, a few years ago, when writing rounded corners on Android devices, border-radius: 10px, rough edges would appear on Android devices.
3. The convenience of debugging is actually at the Web interface layer. But when actually developing a Hybrid App, you will encounter the need to access the underlying request of the mobile phone and do some processing. For example, if the app has a Push Notification service, you need to go to the bottom layer to obtain the data when the Push Notification occurs, and do the corresponding interactive processing. Of course, frameworks like PhoneGap already have a good plug-in mechanism to help you solve similar problems. Of course, there are also plug-ins such as Game Center. For details, you can go to Github to follow the official PhoneGap account, which has very rich resources.

Solution 2 (Compilation and Conversion Method)

advantage:

1. Use a language you are familiar with to develop applications. For example, RubyMotion uses the Ruby language to develop iOS. The amount of code is reduced by orders of magnitude.
2. Some development tools provide cross-platform functions, allowing your application to be quickly published on different platforms. For example, Xamarin from the Mono community is a typical example. Using the C# language, you can publish your application to the iOS, Android, and WinPhone markets;
3. The developed programs run efficiently. Most applications of this architecture are still very dependent on the underlying things, and the interface things all use native APIs, so the efficiency is of course better than architectures like PhoneGap.

shortcoming:

They rely heavily on the toolkits provided by tool vendors, and a full set of tools is required for debugging. Of course, generally speaking, these vendors will release their tools for a fee, and there are also customer service to provide technical support. If you encounter system upgrades, third-party SDK upgrades, development tool bugs, etc., you have to wait for the tool vendor to resolve them. This is equivalent to putting the risk on the other party, but you have to bear the responsibility.

Solution 3 (Native architecture is the priority)

advantage:

1. This is undoubtedly the most stable way to develop Hybrid Apps. The efficiency of the interaction layer is solved by Native things, and the architecture is basically to write web pages in the App. Even the App Store adopts this solution.
2. The division of labor during development is very clear, with the bottom layer handled by iOS developers and the upper layer handled by Web front-end developers;
3. Effective online parameter configuration method to facilitate timely online replacement interface;

shortcoming:

1. The team needs at least two engineers, one for Web and one for iOS. Of course, if the developer knows both technologies, they can take on the responsibility independently.
2. Or running efficiency, you need to weigh how much of the interface should be rendered by the Web. After all, the efficiency of WebView will be relatively low. In the past, Facebook changed the entire application to a native solution because of the low efficiency of Web rendering. Of course, this can be solved through optimization. But optimization is also limited. As Matz, the founder of Ruby, said, optimization must be appropriate (including time spent, skills, etc.), and sometimes the return rate achieved by optimization may not meet your expectations.

Comparison between Hybrid App and Native App Development

Because the idea in solution 3 is basically the idea of ​​native application development. The comparison here should not be too big, so I will not elaborate too much on the difference between the two. However, if you focus on Web architecture, or develop with special tools like solution 2, it will be compared with native development. This time, I will temporarily discuss solution 1. The discussion will mainly focus on architecture and code management, and of course some details will be mentioned.

Architecture Discussion:

Because this is an application that focuses on web development, it requires developers to have a strong understanding of large-scale web front-end architecture. When it comes to this, the words that may immediately come to your mind are: angular.js, require.js, sea.js, backbone.js, etc. That's right, these tools can help you quickly sort out your ideas and manage your web applications. PhoneGap is the most developer-friendly and has the greatest room for development. So the author will start the discussion with PhoneGap applications. (Because similar Sencha also provides solutions, but Sencha itself is a heavyweight framework, and has its own ideas in it, plus it also provides development tools, so it is not suitable to discuss here. For developers, they can choose the right tools according to their needs)

From the tool point of view:

Angular.js

Used for two-way binding, network requests, view management, etc.

Require.js

JavaScript modularization tools, when using more interactive objects and PhoneGap plug-ins, you will find that a powerful modularization tool will provide great help during development. It can help you manage the overall code in an orderly manner.

Jade Template Engine

Template engine. I personally recommend using Jade, and I have written many articles on Jade's techniques for using it in different scenarios in my blog. Jade's syntax is very concise and it is very friendly to JS developers. If you haven't started using a template engine yet, hurry up and join the queue, you are already behind.

Jquery Mobile

If you don't have a designer yet, but are eager to build an app, jQuery Mobile provides multiple sets of templates with different styles for you to use, and also contains different interactive animations, etc. It is also cross-platform. Of course, in actual scenarios, I think you will spend a lot of time writing CSS, because the design is always imaginative. Of course, you also have many tools, such as Sass, and less.js.

PhoneGap.js or Cordova.js

A must-have code library for PhoneGap development, used to communicate with the PhoneGap framework. This library has now been renamed Cordova. You'll have to ask Adobe why the name was changed.

PhoneGap Plugins

PhoneGap plugins can help you quickly access other APIs on the phone and use Javascript to manipulate these underlying APIs, such as calling the corresponding events of Push Notification.

Looking at the web layer in the hybrid application from the code directory:

 /js
 mainView.js
 settingView.js
 networkObject.js
 renderObject.js 
 
 /lib
 /PhoneGapPlugins
               push-notification-plugin.js
 pickerView.js
 PhoneGap.js
 zepto.js
 jquerymobile.js
 iscroll.js
 angular.js
 jade.js 
 
 /css
 /mainView
               listItemTemplate.css
               questionListTemplate.css
 /settingView
 /personView
 /layout
               navigationBar.css
 tabButton.css
 app.css 
 
 /template
 /mainView
               listItemTemplate.txt
               questionListTemplate.txt
 /settingView
 /personView
 /layout
               navigationBarTemplate.txt
               tabButtonTemplate.txt 
 
 index.html
 app.js
 require.js

From the code directory, it is a classic static web page file directory, which is very simple. Let's use one sentence to describe the operation process of the entire application:

Open PhoneGap application -> enter index.html -> run require.js -> load application resources -> app.js controls the entire application -> angular.js performs event binding and view rendering -> when rendering the view, the data and the loaded view template (code in the template directory) are processed -> through the jade template engine -> rendered to the corresponding position

It's that simple.

After reading the simple PhoneGap application, let's take a look at the code directory of a simple iOS application. The ideas are very similar. Here, I will not go into the code part to discuss the specific implementation and details.

 demoApp
 /Resource
               navigationBar.png
               [email protected]
 /demoApp
 AppDelegate.h
 AppDelegate.m
               /SettingViewController
                    settingViewController.h
                    settingViewController.m
               /MainViewController
                    mainViewController.h
                    mainViewController.m
               /Supporting Files
                    demoApp-Info.plist
                    InfoPlist.strings
 ...
 /plugin
 /AFNetworking
                    AFHTTPClient.h
                    AFHTTPClient.m
                    AFHTTPRequestOperation.h
                    AFHTTPRequestOperation.m
 ...
 /Frameworks
               CoreData.framework
               UIKit.framework
 /Products
 demoApp.app

Objective-C is a general-purpose, high-level, object-oriented programming language. Objective-C is based on the message passing model of Smalltalk. In Objective-C, it is more accurate to say that objects pass messages to each other rather than calling each other's methods. Objective-C emphasizes object-oriented programming, and Objective-C requires that the class (interface) and implementation (implementation) be divided into two parts. The class definition file follows the convention of C language with a .h suffix, and the implementation file has a .m suffix. So you will see a large number of class files in it, and the entire project is made up of different classes. (Of course, this description may not be accurate, but it is easy for everyone to understand)

This is very different from the rich Web front-end development. In Web front-end development, there are three musketeers: HTML, CSS, and JS. You must use these three things well to build the entire application. But in Native applications, it is very simple. You only need to master Objective-C. Therefore, for native applications, as long as you follow the specifications during development, even a novice can quickly get started and understand the code. Because the model has been determined, everyone uses the same set of APIs. Just follow the process. Of course, learning Objective-C requires a process, but for developers with experience in C and Java, it is a very simple thing.

Of course, the disadvantages of native development are also obvious, that is, it cannot meet your cross-platform needs.

From the code directory, we can see why I use multiple JS libraries and frameworks. The main purpose is to build a maintainable and standardized Web application. Because the Javascript language itself is very flexible, 100 people can have 100 styles, and there are no courses specifically for Javascript, so it is easy to have misunderstandings about this language in the past. For various reasons, it is necessary to constrain the code style and architecture of an application. In addition, Javascript itself does not have the concept of class, so in Javascript's object-oriented programming: Javascript's data and member encapsulation are very simple. There is no class, it is completely object operation. This is very different from Objective-C. At this time, you must have a mentality to handle the entire Web application: that is, abstract it into objects as much as possible, and your job is to have communication between objects.

There are also some points that developers should pay attention to. For native applications, whether it is iOS or Android, a set of native interface libraries will be provided. Take Objective-C as an example. If the author needs to call Alert, the author only needs to write: UIAlertView * alertView = [[UIAlertViewalloc]init];, and the view is declared. Then execute the corresponding method, and it will be fine. But for Web applications, you need to write <div id='alertView'><button>OK</button></div><script& gt;$('#alertView').show();</script>

, a bunch of CSS and HTML codes to implement. Of course, you will ask the author, can't you just write alert()? If it is really that simple, I suggest you write an alert in iOS WebView, and implement: title is a prompt, content is: alert view, and the text of the confirm button is: OK. Then you will know where the limitation of WebView is.

Therefore, to complete the best practice of JS in Web App development, you must learn excellent ideas and implementation methods. In this article, the authors will not do such an in-depth discussion for the time being. Instead, they will throw examples to everyone first, and perhaps in the next discussion, they will go into detail about the following two projects.

The first one is an example from Stanford's iOS development open class, using objective-c to implement a simple card game. This is a classic MVC development. The project address is as follows: https://github.com/lbj96347/Stanford-W2013-CardGame. If you are using a Mac, then congratulations, you can compile this game immediately for testing and code browsing.

The second one is an example written in JavaScript, which achieves the same requirement and makes a simple card game. However, it is developed using HTML+CSS+JS. It also learns the idea of ​​inheritance and MVC. The project address is: https://github.com/lbj96347/JSMatchismo. Congratulations again, no matter what computer you use, you can browse the code and run the game at any time.

New ideas of Hybrid App

Over the past two years, different markets and different demands have led to new developments in various technologies. For Hybrid Apps, there are actually some new solutions. In order to solve the problem, the final thinking will be reduced to the following points:

1. Choose the tool according to your needs;
2. Use appropriate tools to do appropriate things and solve problems in a targeted manner;
3. The world is balanced. For developers, the more useful work they do, the better the user experience will be, and vice versa.
4. Cross-platform is a "pretense". Being able to do everything does not mean doing everything well.

These are also the points that I have the deepest experience with. And you will find that Hybrid technology also basically follows these points.

Choose tools according to your needs

If you have used Jquery Mobile, you have done transition animation (that is, going from one view to another). Transition animation is very common in iOS navigationController, and it is very simple, with good and smooth effects. In Jquery Mobile, ajax and css are used to implement it, and the core code may be only a few dozen lines. It may be similar to that in iOS (if animation is included), but the actual effect is not satisfactory. Similar problems will occur: page jitter, incoherent feeling, and slow operation on some devices. If the experience required by your application is not very high, such as some news display applications, which emphasize typesetting more. The small experience gap here can be ignored. (Because this is what the British BBC does), but if your application emphasizes experience details very much, the solution here may not be suitable. Maybe you need to optimize, but the time for optimization may be enough for you to learn more. In this case, do you continue to choose an immature tool or choose to learn a new language? So it depends on the needs.

Another example. Someone once mentioned to me that it is really fun to use HTML and CSS to write application interfaces, but the efficiency is not very good. So why not try to move the application content directly into Canvas? Construct a set of powerful enough tools, a set of powerful enough UI components, and run the entire application in Canvas. This idea is very good, but in fact, the short board page appears inside. Although the performance of Canvas is high, can you guarantee high effects with too many elements and components inside? Everything will rely on JavaScript. It is not a simple matter for Javascript to construct powerful enough object-oriented components. Abandoning CSS and HTML means that the internal design components can be highly customized, and the loose coupling is done very well. It is a completely new set of xcode and ui libraries. This is not just solving one or two problems. Since there is such a tool, why don’t I choose a better one, such as Xamarin.

Use the right tools for the right job

Friends who make games probably have a deep understanding of this. In order to solve the problem of Canvas performance, more and more people and application manufacturers (especially browser manufacturers) have provided a solution that is to connect the Canvas API with the underlying system API. This means that you only need to write Canvas code, and the actual rendering is done using the underlying system stuff, which improves the overall performance. For example, Ejecta http://impactjs.com/ejecta .

For developers, it is very comfortable to use Javascript to write game logic and do various controls. Moreover, because the API is the same, it can also run on PC (regardless of performance issues). This really achieves cross-platform, but it is not lacking in efficiency. What impressed me the most was @大城小胖's approach when making hybrid applications (making games), Xiaopang's game architecture. JS is responsible for logic and engine. JS Binding binds native OpenGL, allowing the native to do complex rendering processing. HTML CSS can handle UI (such as some buttons). This is typical: let the tool do what it is good at.

Cross-platform is a "cover"

Why do you say that? Haven't I always hoped that everyone could go cross-platform? Yes. But we must really recognize this hurdle. From IE compatibility, to the current chaos among multiple browsers, to the compatibility of iOS and Android devices on the Web, isn't this a historical example? Cross-platform is not bad, but it is really difficult to estimate what effect you can achieve in a certain era. It's like when you travel abroad. If the relationship between the two countries is very good and many conventions and laws are consistent, it won't cause too much burden to you. But if the language is different, the living habits are different, it will be difficult for you to adapt. As a human being, it is difficult for you to survive in different environments. True cross-platform means that everyone seeks common ground. This is definitely not a matter of one or two days, nor is it a simple matter.

Why do we need cross-platform? Business needs. Here we must follow the principle of choosing tools according to needs, using appropriate tools for appropriate things, and developing according to actual conditions. If possible, I think it is necessary to understand them all, so that various development ideas will affect you, and you will be able to distinguish what is good and what is bad, and make better choices. For example, the example of the cutscene I just mentioned. In fact, you can use the hybrid application I mentioned, solution three, to solve this problem. You just want to use navigationController to make a beautiful cutscene, which can be achieved in iOS with just a few lines of code.

Let me give you another example. If you are making a to-do list application, it is nothing more than simply storing data and rendering some related interfaces. If you use native controls, you have to write a lot of code and deal with memory issues. But if you use the Web method, such as backbone.js, the total code may be around 100 lines. The entire application is implemented, including local storage. All you have to do is make the entire interface more beautiful. It may only take an hour of work. But if you use native development, it is difficult to guarantee that it will be completed within an hour, because debugging and compiling take time, right? Besides, there is also the interface.

Therefore, we must recognize the "pretense" of cross-platform. Not all problems can be solved with the same method. We need to integrate them!

Summary and the author’s feelings

There are actually quite a lot of pitfalls in making Web Apps. I cannot list them all here. But I believe that after practicing, you will know how to better bypass these pitfalls (such as the example of the cutscenes I mentioned). So for developers, you must have strong perseverance, work hard to practice, and satisfy your curiosity that can never be satisfied, because the final experience will bring you a different feeling, stay hungry. At the same time, we must maintain a learning heart, constantly absorb nutritious ideas, learn new knowledge, and don’t be too easily satisfied, stay foolish. Every language has its own ideas, and every tool has its own methodology for solving problems. Trying more can bring you better architecture, better applications, and provide users with a better experience. Of course, there will be better rewards.