ActionBar is good for UE, but sometimes we do want to hide it. Here we will see the ways to do it.
With the new
android.arch.lifecycle.ViewModel, you can extend your own ViewModel which is life cycle aware. Or you can use
AndroidViewModel if you want to inject
context to your model. One problem with the default
ViewModel is the constructor takes zero parameters. If you want to make it takes parameters, you need to make a new
FactoryClass for each view model. But with Kotlin, it could be more simple. Let’s see how to do it.
Databinding for MVVM or any other pattern is a must have. Let’s see how to set it up. The reason for this blog is that it seems most of the examples out there online either deprecated or just try to solve another problem. Our goal is to setup a project with a brand new project generated from Android Studio.
I encountered a weird thing today. In Android Studio 3.1.1,
import android.arch.lifecycle.ViewModelProvider is totally fine while
import android.arch.lifecycle.ViewModelProviders is not fine. Because there is no
The solution is to add the packages by yourself. It doesn’t even get mentioned in the official doc and most of the tutorials online. And after working with some already setup project. It finally bites me.
Mock is the answer to this kind of case when you need to deal with the IO thing like network request. Such that, you can test your logic without worrying about the underneath implementation. But sometimes it’s not the case. Integration test is the answer.
Previously, we talked about how to share code across platforms in kotlin world. But as your code base grows, you will encounter a scenario where you might want decouple the code. Things like separating the platform specific implementation to another repo in order to reuse them in a future project. Well, lucky you, this is our topic today.
When you add a new activity in Android Studio. It will have a default back button at the upper left corner. How to remove it? I check many things online but they are not working. So, let’s remove it by ourselves!
When you try to deal with the across platform codes. You need to solve 2 things, one is the architecture of how to share the code, another one is how you share. Well, different languages might have different techniques. But in Kotlin, you can use multiplatform projects to share the code. And via kotlin native, you can even expand the support to iOS and Android, I mean, natively.
An example of supporting code sharing among iOS, Android, JVM and JS is added in this repo.
I love typescript. But after I gave flow a try, it really makes things easier in terms of
react related thing. It could handle the redux immutable check and easy to start. But one problem is that sometimes you just can’t find type definition for the 3rd party libs as oppose to typescript, which is already widely adopted nowadays. So, how to solve it?
next.js is really amazing to enable SSR with react. And
flow.js is great way to type check your code in an easy way. But after following the official example to setup the project. I get the
ESLint parsing error when it encounters the flow
type definition. Let’s see how to solve it.