Easy Tutorial
❮ Android Tutorial Webview All Vim Cheatsheat 3 ❯

12.5 DrySister View Girls App (Version 1) – 5. Code Review, Adjustments, and Logging Class Writing

Category Android Basic Introduction Tutorial

1. Some Chit-Chat


I must admit, it's been over a year since the last DrySister article, and many friends have privately messaged me saying it was great and asking when the next one would be. I mostly replied that it was discontinued... The reasons vary, but recently, with some free time, I decided to wrap up the first version. When I started writing, it was with AS 2.1.2, and now it's AS 3.0.1. The content for this section is as follows:

-Step 1: Review what was covered in the previous sections

-Step 2: Make adjustments to run the code on AS 3.0.1

-Step 3: Write a logging class

Next, we'll talk about signing, obfuscation, and publishing to the app market. No more nonsense, let's get started with this section!


2. Code Review


-Section 1: Project Setup and Simple Implementation

-Section 2: Parsing Backend Data

-Section 3: Image Loading Optimization (Writing a Small Image Caching Framework)

-Section 4: Adding Data Caching (Introducing SQLite)

These are the contents of the first four sections, which apply important knowledge points in Android basic introduction. If you have mastered them, you can be considered to have barely entered the door of Android, but the road ahead is still long!


3. Code Adjustments


After switching to AS 3.0, the code in the following files needs to be changed. As usual, switch branches with the command: git checkout -b fix, and then start modifying the code:

Project-level build.gradle:

APP-level build.gradle:

gradle-wrapper.properties:

There's also a small change to be made: SisterApi.java, change 福利 to: %e7%a6%8f%e5%88%a9. This involves Chinese encoding issues, and HttpUrlConnection cannot open links containing Chinese characters. You need to encode the Chinese part using URLEncoder.encode(Chinese part, "utf-8");, remember only the Chinese part, not the entire URL!! Encoding also requires catching exceptions. Since there's only one place to encode, I used an online encoding tool directly: https://c.tutorialpro.org/front-end/695

The converted result:

Additionally, there are some minor changes. For buildToolsVersion 26 and above, findViewById does not need to be strongly typed. Click into the method to see that it uses generics, so remove all findViewById:

Finally, I felt that the effect on my Meizu E2 was a bit off, so I adjusted the page layout slightly to make the image width full screen and the height adaptive. Here, the attribute android:adjustViewBounds = "true" is used, which scales width and height proportionally; also, move the text for the next step into the strings.xml file and adjust the margins slightly:

Finally, let's look at the project's running results: (Wow, beautiful girls are indeed pleasing to the eye):

Then merge this branch into the develop branch. Here, we don't use the previous merge routine but use rebase to merge. The specific process is as follows:

git add .
git commit -m "fix code in as3.0"
git checkout develop    # Switch to develop branch
git rebase fix_code_as3.0.1 # Merge branch
git push origin develop # Push develop to remote branch
git branch -d fix_code_as3.0.1  # Delete the merged local branch

If you don't understand Git, you can learn from another article. I won't explain it here: Pig's Summary of Git Usage


4. Writing Logging Utility Class and Crash Log Collection Class


Logging logs is something every developer is familiar with and is indispensable for debugging. When the application is packaged for testing, if the tester reports a crash, the first thing we think of is to ask for the logs. Speaking of logging, many developers like to随手一个Log.e(xxx,xxx), treating all logs as Error level, mostly because: red is more noticeable, haha! Then directly print the value of the variable, or add it in a method to verify if the method is executed, etc. Remember to delete it when officially releasing, or it's简直是作死. Anyway, I was scolded by a senior at my previous company, and it left a deep impression on me! Log management is very important. The two utility classes we need to write are as follows:

>

Okay, the requirements are the above two points. Next, we prepare to start writing the code. But before writing the code, let's talk about two points regarding Log, which most of you may already know:

1) Quickly Print Log

Open Settings, click through: Live Templates -> AndroidLog and check all the log printing options. You can also write your own templates in the Template text below~

Then type log... in any code and press enter, and the Log statement will appear, with the TAG being the current method name~


2. About Log Usage

1) Quickly Print Log Commands

Open Settings, click through: Live Templates -> AndroidLog and check all the log printing options. You can also write your own templates in the Template text below~

Then type log... in any code and press enter, and the Log statement will appear~

If you are outside a method, typing logt can directly generate a TAG with the class name:

2) Log Level Knowledge

My former team leader once mentioned our bad habit of directly using Log.e during a small meeting. Different Log levels should print different information:

>

The following three levels should not be used as ordinary debugging information. Using these levels indiscriminately can cause unnecessary trouble for developers when analyzing bugs.

3) Writing the Log Utility Class

As usual, create a branch: bug. This is very simple. Print during debug, do not print during release, using BuildConfig.Debug for judgment. The code is as follows:

4) Writing the Crash Log Collection Class

The crash log collection class relies on Application and Thread.UncaughtExceptionHandler to implement~ When the application is about to terminate due to an uncaught exception, it will use Thread.UncaughtExceptionHandler to query the thread of UncaughtExceptionHandler, call uncaughtException method, and pass the thread and exception as parameters. If the thread does not explicitly set an UncaughtExceptionHandler, it will use its ThreadGroup as its UncaughtExceptionHandler, and then throw it to the default uncaught exception handler. So we just need to implement the UncaughtExceptionHandler interface, override the uncaughtException method, to implement our custom handling. Let's go through the logic list first:

The general logic is as above, let's go through it step by step. First, steps 1 and 2:

Then the crash log, composed of several parts: first, the current time

Then the application version and device information, here we use a HashMap to store:

Then the exception information, this is simple, just pass the exception object, call printStackTrace directly. Finally, combine them together:

The writing to file is also solved, then the custom UncaughtExceptionHandler singleton and the default UncaughtExceptionHandler handler's acquisition, set to the custom UncaughtExceptionHandler, also need to override the UncaughtException method

Then we write our own exception handling routine into a method. When an exception occurs, pop up a Toast to inform the user that the application needs to restart, and call the method to write the log:

Then the overridden UncaughtException method makes a judgment, whether the exception was handled by us, and whether the default UncaughtExceptionHandler is null, i.e., was the exception handled? If not handled, throw it to the custom UncaughtExceptionHandler, if handled, restart the application.

Finally, add the relevant code for restarting the application, and it's done:

At this point, our crash log collection tool class is complete. To enable it, you need to add it in the onCreate() method of DrySisterApp.java:

If you want to test if it works, it's simple, just manually cause a crash. For example, I do a division by zero operation in the next step button:

After running the application and clicking the next step, it crashes directly. Open the root directory of the built-in storage to see if there is a Crash folder. If you open it and see our log file, it means success:

At this point, it's done, merge the branch to develop, and then push it to the remote repository:

git add .
git commit -m "add LogUtils and CrashHandler"
git checkout develop    # Switch to develop branch
git rebase bug_log_catch # Merge branch
git push origin develop # Push develop to remote branch
git branch -d bug_log_catch  # Delete the merged local branch

5. Summary

This section first reviewed the previously written code, then made minor adjustments due to the switch to AS 3.0, and finally wrote a logging utility class and a crash log collection utility class. Although it's just a small image display program, it covers most introductory knowledge. The next section will be the conclusion of the first version, including signing and packaging, obfuscation, and publishing to the CoolMarket! Stay tuned~

Code Download:

https://github.com/coder-pig/DrySister/tree/develop Feel free to follow, star, and if you have any suggestions, please submit issues!

WeChat Subscription

❮ Android Tutorial Webview All Vim Cheatsheat 3 ❯