A front-end programmer's one-month native Android development experience

A front-end programmer's one-month native Android development experience. Since I wrote Android applications, I have been spending more time on Zhihu.

Since I wrote the Android app, I have been spending more time on Zhihu. Oh, no, you misunderstood. What I meant is that it takes time to compile the code, package the APK, and run it on the device. It is not like the front-end, which automatically refreshes the page as soon as the code is saved.

Yes, starting from last Monday, due to the lack of manpower in the project, as a big front-end developer with Java development experience, I once again entered the world of native Android development.

After this month, I have gained some experience in writing XML code - no, I have gained some experience in writing Java code and reading Kotlin code. In general, the difference between Android and front-end is not very big. In some aspects, they are quite similar. No wonder programmers like me also classify Android development as a big front-end.

If you are a front-end programmer who wants to learn mobile development, or a mobile developer who wants to get involved in front-end development, then this article may be suitable for you to understand the difference between the two.

This article contains the following content:

• Coding efficiency vs maintainability
• MVP vs MV: The Day After Tomorrow MV
• Static Languages ​​vs Dynamic Languages
• View and DOM
• Code debugging
• compatibility

(PS: Due to my limited experience, some of the words I use may not be accurate.)

Note: The front-end application here refers specifically to a single-page application.

Coding efficiency vs maintainability

Because in terms of running efficiency, native applications must be much greater than WebView - after all, WebView is still a native application behind it, which is equivalent to adding an extra layer in the middle. Therefore, we will directly discuss the coding efficiency here.

In terms of coding efficiency, the front end is still faster, much faster.

• Faster preview speed.
• Mature ecosystem.
• A large number of UI frameworks and components available.
• Refer to other companies' implementations. The Web front end is an open world. Today, the effects you want to achieve have basically been achieved, so we can directly refer to
• Good rich text support

Considering that Android and iOS are implemented separately, the development efficiency of a hybrid application may be much greater than 2 times, and the development efficiency of cross-platform applications (such as React Native, Weex, NativeScript) will be close to 2 times (the reason is: when integrating certain functions, native code is required to implement them, which is equivalent to doubling the workload).

In terms of the current maintenance level, Java code is relatively well maintained. This is mainly because the front-end field changes too quickly, and software engineering practices are not as required as Java, so it is easy to have a lot of legacy code. However, considering the bloated Java code, it is better to use Kotlin instead.

Just press: Command + Alt + Shift + K to become a father easily.

MVP vs MV: The Day After Tomorrow MV

MVP, namely Model-View-Presenter, corresponds to view layer-data layer-presentation layer.

From the perspective of MVP, front-end applications and Android are not born with MVP architecture. However, there is not much difference between the two in the processing of business logic. The only difference that can be experienced may be the difference brought about by JavaScript asynchrony and Java synchronization.

V*

Front-end applications that use frameworks will have the added bonus of MV*. Once you choose a framework, you can only follow its unique model. For example, the core provided by Vue is the VM in MVVM, React is just the View layer in MVC, and Angular may be MVW (Model-View-Whatever). In this case, if you want to change based on the framework, the flexibility may not be that great.

Android uses the MVP architecture, which mainly relies on conventions. One of the reference specifications is Google's official android-architecture, or the Clean Architecture recommended by the community. Both Clean Architecture and MVP rely on conventions. Once we talk about references, it means flexibility - you can follow them or not.

At this time, Android's MVP requires us to create MVPView and Presenter ourselves.

 public class MainActivity extends AppCompatActivity implements MainView {
 ...
 }

The entire MainActivity is just a View layer, and the real business logic is handled by the Presenter. In simple terms, you need to manually create four or five classes to complete an Activity's Hello, world.

Model

At the same time, Android needs to validate and convert the Model by default. Because to extract a value from JSON, you need to convert JSON to an object - you can directly use the Retrofit library to convert the data, or use GJSON to convert it into an object. This is a big difference from the front-end world. In the front-end world, this kind of thing is easy, with the famous JSON.parse.

When writing in JavaScript, you don't need to validate the Model. However, in React there are proptypes, and in Angular you can use TypeScript to do something similar.

Compared with the front-end without object validation, once an error occurs, it is not easy to detect. This may also be an advantage - when you launch a new version of the API, the old application will not have NullPointerException. At the same time, during development, when the back-end API changes, it will also lead to a series of subsequent bugs.

Static Languages ​​vs Dynamic Languages

Since I wrote the Android app, I have been spending more time on Zhihu.

Compilation and dynamic execution

When we write web applications, as long as we save the code, the web page can be automatically refreshed by tools such as LiveReload. Therefore, in cross-platform frameworks such as React Native, there are also features such as Live Reload.

When I was developing Android applications, every time I wanted to try to view the effect on a mobile phone, I had to build, compile the code, install it, and wait for about two or three hours before it could run on a virtual machine or a real machine.

But things don't always go so smoothly. You may encounter a NullPointerException and the application will crash. At this time, you need to fix the problem in the code, add blabla!=null, compile, and continue to crash.

No wonder Android programmers love Kotlin. Just one view can tell whether something is valuable:

 override fun onCreateView(inflater: LayoutInflater?, container: ViewGroup?, savedInstanceState: Bundle?): View ? {
    val view = inflater?.inflate(R.layout.fragment_home, container, false )
    val button: Button = view !!.findViewById(R.id.open_rn_button)
    button.setOnClickListener(this)
 return   view  
 }

But due to my lack of experience, I often write val as var. This is just like those iOS programmers who are used to writing alloc init and suddenly like writing ES6 overnight:

 let className = NSStringFromClass(MyClass)
 let classType = NSClassFromString(className) as ? MyClass.Type
 if let type = classType {
 let my = type.init()
 }

Oh no, they wrote it in Swift.

And as an object-oriented language, Java inherently means a lot of bloated code.

 public   int getId() {
 return id;
 }
 public void setId( int id) {
 this.id = id;
 }
 public String getName() {
 return   name ;
 }
 public void setName(String name ) {
 this.name = name ;
 }

A large amount of code means a large number of bugs, and a certain amount of repeated code means we are back to the world of design patterns.

IDE support

Fortunately, Android Studio has strong and good Intellij support. The language support on the IDE is much friendlier than the third-party library support for JavaScript:

You should know that WebStorm or Intellj IDEA Professional Edition have a lot of problems in supporting JavaScript third-party classes.

View and DOM

In the past, the front-end had a natural problem in DOM operations, that is, when we used $("*"), it was global. Of course, today's frameworks have fewer problems with this problem, but it is still possible to be misused or injected. Android, on the other hand, is local to the page.

Style Reuse

The front-end uses HTML + CSS to write the style, while the installation only uses XML to cut the picture, which is not an easy task. Unlike CSS, which can achieve style reuse through "inheritance" and "override". Android also has a way similar to JavaScript to generate HTML, custom templates.

When we use React to write components, we can pass corresponding attributes to the components. This attribute can be a function, value, component, and so on.

 MyComponent.propTypes = {
  optionalArray: PropTypes.array,
  optionalBool: PropTypes.bool,
  optionalFunc: PropTypes.func,
  optionalElement: PropTypes.element
 }

In Android layout, this is not so easy. In order to reuse styles, they need to be extracted into UI components, and they can only be components on the UI. Reuse can only be achieved on HTML + CSS.

HTML + CSS has various tricks when writing UI, such as style priority or importance.

Two-way binding

From a native perspective, there is not much difference between document.getElementById() on the front end and findViewById on Android. But when the front end has a front end framework, things are different. Fortunately, Android has a View injection framework like ButterKnife.

At the same time, Android also comes with two-way DataBinding, which the native front end does not have.

It’s just that there is a front-end framework on the front end, so there is no problem at all.

Layout debugging

Fortunately, I already had some experience in writing React Native layouts, so writing Android layouts was not that difficult.

When it comes to layout debugging, it is more convenient to use the browser for front-end debugging - you can also modify the DOM structure in real time in the browser. Android also has such a tool, called Layout Inspector:

In addition, you can also use Facebook's stetho to do Web-related debugging work:

In general, it is pretty good. How come this structure looks so similar to React Native?

Code debugging

In terms of code debugging, Java has a solid foundation and is generally better than JavaScript.

In addition, remember that we can set breakpoints in the Chrome browser and then do some calculations in the Console. Thanks to JetBrain's Evaluating Expressions behind Android Studio, the value of expressions can be calculated in real time, and code debugging on Android is also very easy.

And with my limited Objective-C programming experience, XCode can also do it.

Network debugging

In Chrome browser, the built-in NetWorks is almost perfect. Android can also use Stetho:

But it has a lot of dependencies, needs to be injected on the page, and cannot debug plug-in applications. If you want to debug the network, Charles is better.

However, what if the development environment is HTTPS? That would be even more troublesome.

compatibility

The front-end faces debugging different browsers or compatibility with IE. Generally speaking, the problem is not big - there will be no crash. Even if there is a small problem, the user can try another browser first. When your Android app crashes on the user's phone, the user can only change the APP.

In addition, Android faces a fragmented system, different versions, and different screen sizes. Overall, it is much more complicated for the front end.

in conclusion

Android has done a great job in software engineering, while the front-end has an advantage in development efficiency.

Web development is great.