Trying to upload an API level 29 and play store console throws an error?
Tags: kotlin, androidappdevelopmen, googleplaystore, androi
Published: 2023-01-06 17:41:03

---
title: Trying to upload an API level 29 and play store console throws an error?
published: true
date: 2021-11-27 07:26:10 UTC
tags: kotlin,androidappdevelopmen,googleplaystore,androi
canonical_url: 
---

### Trying to upload an API level 29 and play store console throws an error? Uff, same here… but indeed I fixed it!

![](https://cdn-images-1.medium.com/proxy/1*sB7eh-Ky_PF8pW6Zj4FVtg.png)

It’s all in the world of Nullability..

> “Kotlin’s type system is aimed at eliminating the danger of null references, also known as [The Billion Dollar Mistake](https://en.wikipedia.org/wiki/Tony_Hoare#Apologies_and_retractions).”

Source: [https://kotlinlang.org/docs/null-safety.html](https://kotlinlang.org/docs/null-safety.html)

[Kotlin](https://kotlinlang.org/docs/null-safety.html) comes with a powerful weapon **Safe calls, Safe Type Cast, !! operator, Elvis operator** , etc..

### **Safe calls:**

```
val name = object?.anotherObject?.name ?: ""
```

or

```
val name = object?.anotherObject?.name.orEmpty()
```

**Explanation:**

**Case 1** : When **object** is null, then **name = “”**  
**Case 2** : When **object** is valid **, anotherObject** is null, then also **name = “”  
Case 3 **: When** object **and** anotherObject **are valid** , **but** name **is null, then** name = “”** (Typical API problem 😝)  
**Case 4** : obviously a positive case 🙂

> **Note** : Ideally the above cases should be part of your unit tests..   
> for a blog sake, I have explained it as a case.. 😆

### **Safe Type Cast:**

Let’s talk about Android bundle, extras, etc..

Sender Class (i.e **ListActivity** )

```
intent.putExtra(_EXTRA\_KEY\_AObject, a_Object)
```

Destination Class (i.e **ListDetailActivity** )

```
intent.getParcelableExtra(_EXTRA\_KEY\_AObject_) as BObject
```

Damn it! I am an **AObject** , and how can you assume myself as **BObject ?** If I am a Java, I would brutally throw **“ClassCastException”**

**Safe Type Cast** comes into the rescue here!

```
intent.getParcelableExtra(_EXTRA\_KEY\_AObject_) as? BObject
```

Ohoo.. Still cool, incase of wrong casting, my app wouldn’t crash and still the value will be assigned as  **`null`**

Enough of the story, we all know  **!! operator** (Forced unwrap) and **Elvis operator** (Optionals) as it is self explanatory 😜

**Now, what is the actual problem in the recent update?**

Legacy code aside, **Kotlin** actually behaves in a way it wanted to..

Reference: [https://android-developers.googleblog.com/2020/03/handling-nullability-in-android-11-and.html](https://android-developers.googleblog.com/2020/03/handling-nullability-in-android-11-and.html)

If Android target version is 29, the code below makes sense..

```
intent.getParcelableExtra(_EXTRA\_KEY\_AObject_) as AObject
```

Post API level 29, the same code starts giving compilation errors. (believe me, we had 500 conflicts as such in our project 😧)

You know why **getParcelableExtra** returns **null**? Android native classes are full of Java man!

![](https://cdn-images-1.medium.com/max/958/1*5Q4uUD0hmZLgEeSH332oqg.png)

### How to solve?

**Option 1:**

Use Safe Type Cast as below

```
intent.getParcelableExtra(_EXTRA\_KEY\_AObject_) as? AObject
```

But there is a drawback with this approach..

The AObject even though is not null, we will have to really deal with the optionals as below..

```
aObject?.anotherObject?.name.orEmpty()
```

Imagine handling with defaults at tons of places?  
(i.e) **Activity** to **ViewModel** to **Repository** to **DataSources**

Uff! In all those levels, nullable just flows like a river or need to handle a null check at **ViewModel.**

### Option 2: **(My Favourite approach)**

Why to handle nullable at tons of places and risking your app in the production? Crash in the QA or testing phase is still better than spoiling the data to the user in the production.. (By showing null, or EMPTY in the UI)

Just force cast it to  **AObject**

```
intent.getParcelableExtra<AObject>(_EXTRA\_KEY\_AObject_) as AObject
```

> **Note:** Going with the above approach,  
> 1. Please make sure that objects are non nullable from the API (At least for the mandatory fields).   
>  — Yes, get the API contracts fixed first.. Mobile developers doesn’t have a luxury to update the app instantly, whereas APIs can be instantly changed. You know what I mean 😉)  
> 2. If you’re in the middle of the release and immediately has to fix things out?., then handling the **null** checks or passing defaults value before starting an activity is the solution. — The best part is that you get a warning message and you tend to pass some optional value 😄 (Ideally we should write a test in **ViewModel** for this case and move to the next screen only when the value is not  **null** )

* * *