When creating a native application on Android or iOS, I think that most of the time it communicates with some server via API. However, if you do not handle API data well, It crashes or is said to be an unstable app that works strangely. This time, we will summarize the crashes / malfunctions that we have encountered so far and introduce measures to prevent them from crashing.
--Be sure to write the processing in case of server error / parse error ――I don't believe that "the value of XX is always on the server" --Int = 0, boolean = false have no meaning
--Crash with returning 404 trying to get deleted resources in request parameters --Crash when returning 500 due to server failure when acquiring user data when starting the application --HTML of error page for browser is returned and cannot be parsed and crashes
The server does not always return 200 (normal). If you send a fraudulent request, it will return 404 or 422, If the server is over-accessed and down, it will return some error. It returns nothing and may time out.
At that time, if the consideration of "what to do if an error value is returned" is omitted, it will drop due to a parse error, or various values will start to move in the state of null or initial value, leading to abnormal operation.
Be sure to add error handling when a 400 series or 500 series error is returned. Also, if parsing fails, it will be treated as an error and the user will be notified that there is a communication error.
--Crash because the value of 〇〇 is not in the old user information ――The value of 〇〇 was always present at the time of implementation, but there was a time when it was not a repair on the server side and it crashed. --I was using the API of an external service, but suddenly the service ended and the API disappeared and crashed
When deciding the specifications with the developer on the server side You may be told, "This value doesn't exist when it's null, so you don't need to check for null." Don't believe these words. The person does not always have a complete grasp of the data specifications, ** It may not be the person who will repair the part later **
Since we don't know when null will be returned, all data classes that receive the response should be Nullable and String.
UserApiData.kt
data class UserApiData(
val id : String?,
val name : String?,
val age : String?,
val birthDay : String?
)
(Written in Kotlin)
However, if you do so, you will have to perform null check and type conversion each time you use it in the application, and the code will become very complicated. for that reason, ① Data class that receives the response ② Data class used in the app Create two and create a conversion method that creates ① to ②.
User.kt
data class User(
val id : String,
val name : String,
val age : Int,
val birthDay : Date
)
UserConverter.kt
class UserConverter(){
fun convert(data: UserApiData): User {
if (data.id == null) throw IllegalArgumentException("user_id is null")
return User(
data.id,
data.name ?: "",
data.age?.toIntOrNull() ?: 0,
parseData(data.birthDay)
)
}
}
In that conversion method, Null check is performed and the value is entered in the form of NonNull. If you get stuck in the Null check there
Depending on the case, we will use the correspondence such as. Then you can ** receive the response from the server properly and perform a null check in one place **
--The dialog that is displayed only when false is always displayed. --Processing to be executed only when user status is 0 is always performed
This leads to a bug when defining requirements. In Java, int and boolean are initially set to 0 and false, respectively, and are not null. It is implemented assuming that a value other than 0 comes from api, and if the value does not come, the process will be executed with 0 as it is.
There is a method to set it to String in the same way as ↑, and a method to receive it with the wrapper class Int, Boolean instead of the primitive type int, boolean.
If you do so, the initial value will be null, so if the initial value does not change unintentionally, a crash or error will occur instead of an illegal operation.
I also want to prevent crashes / errors, but this is still better because it is included in Crashlytics and is easier to detect during testing.
--Do not forget error handling at the time of server error and parsing error --API receives all nullable, assuming it returns null
Actually, there are some measures that cannot be taken by adjusting the implementation time and specifications, but I think it would be good if we could take measures as much as possible to create a stable app.
Recommended Posts