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.
Feathers.js is the most impressive back-end framework that I’ve seen in the node.js world. Like
Django rest framework in the python world. Similar API to
express.js. And very productive as you can generate rest CRUD API in seconds while still highly customizable. And has a unique concept called
hook which distinguish it from the others.
Next.js is a library that you could use to do the
react server-side rendering easily along with all the toolings. Previously I set up a project which uses these 2 to do SSR, I thought it should be very easy. But to my surprise, it took me a while. I think it worths to write a blog here to share what I learned. We will use
feathers-cli to generate a fresh new codebase and start from there.
We have an eye on Kotlin Native (KN) from day 1. I highly like its portability. You can generate universal package for both Android and iOS, or even Windows, OS X, Linux. Just share some of my thoughts here from my current experiences.