Kotlin Coroutines 1.4 is here, as is another chance to stave off boredom.
Imagine we have a fragment that is interested in a todo task from the classic JsonPlaceHolder API.
Since we are working with flow, we need to launch a coroutine to collect it.
A small button will tell the viewmodel to fetch a todo, update the flow and let us collect updates so it can be displayed on the screen.
The viewmodel itself will be owned by the activity, not the fragment, in order to run an experiment later down the line.
value = null. That is the initial update that will be given to anyone who first collects this flow. …
Flow is fun to play around with.
In short, it represents a cold stream of values. Kind of like my typical afternoon at the pub drinking a stream of too many cold ones.
Aside from looking at memes all day we might as well write some code.
FlowGuy seems like someone trustworthy that gets the job done. He holds this stream that will emit a new list containing humans every 1 second.
All this work will happen on the IO thread/scheduler/whatever, just to be safe and keep the UI thread as free as possible.
Since this is a cold stream, nothing is actually happening when we run our app until someone starts collecting this
someFlow variable. …
The android framework has a curious case of killing any app that’s in the background for more than a few minutes.
Take this for example:
The RedditViewModel is responsible for fetching a post from Reddit while the calling activity/fragment is responsible for observing the redditPostData variable.
Once the post is fetched the activity’s observer is notified and we show it to the user.
A ViewModel “sits” quite close to the activity/fragment. Something that a user would be looking at generally, even if they are unaware.
You would think that a professional keyboard user walking into your ViewModel test file would probably be able to read the test methods and make some sense of what’s going on at the screen level without even running your app, right? 🤡
Our little ViewModel looks like…
This is part of a series head-scratching my way into coroutines. It can be read as a standalone although you are missing out on some stale memes on the other one:
The little repository class fetching a Reddit post works fine (?!) and your pull request is ready.
Hol’ up ❗
🐱👤 The gods of code review will not be satisfied until some semblance of code coverage is there. They can then go home and sleep soundly, knowing that this piece of art is perfectly safe to go on production 🐱👤
We need some kind of test rule class that will do all the work for us on every test so you don’t have to copy-paste the same code everywhere. …
Concurrency on Android has been weird to say the least.
By default, Android handles UI work on the main thread. Any operation that does not “touch” the UI should preferably be off-loaded to someone else.
A lot of effort has gone in fixing that issue in the past: Executors, Handlers, Loaders, RxJava, AsyncTask (R.I.P) and a bunch of others I’m missing.
This post focuses on how to implement coroutines in your project while the next one will be on testing them. (perfect code does not need testing but let’s pretend 🙈)
Most apps out there are based on the same premise. …
This is the second mem- ehhh part in the “👏👏 Retrofit review 👏👏” series.
You can find part 1 here:
After copy pasting everything like any self respecting Stack Overflow user, we reached a point where everything works.. but looks kind of.. meh.
Everything is thrown in the activity 😱!
This is the part where I should explain why this is a horrible way to write but there’s enough internet warriors out there defending good coding practices.
Let’s fix that by introducing a ViewModel.
The point of a ViewModel is that he can be paired with an activity and you can throw everything that’s not UI related to him. Tell your activity to observe whatever is interesting that the ViewModel has in it and then do your thing. …
This is a spin-off to the “Retrofit review” article I wrote a while back.
You can find it here:
Glide is an image loading library developed by people smarter than me.(granted, I’m not very bright)
You can check out the official docs (https://github.com/bumptech/glide) if you are an inquisitive soul but we both know why you are here.
This is a spin-off of the “Android RxJava in 5 minutes” article I wrote a while back and has stuff that you might find useful for this one.
You can find it here:
It seems like everyone and their mother is running an API on the internets. If you are not too sure what an API is, or how to consume (????) it no less, fear not. This tutorial will teach you how you too can copy-paste your way to a lead dev position in Silicon Valley.
Doing something of value is paramount to finding happiness aside from browsing stale memes on r/programmerhumor. …
This is a kind-of a sequel of the “Android RxJava in 5 minutes” article I wrote a while back and has stuff that you might find useful for this one.
You can find it here:
Research says that 50% of what you need to know as an android dev is displaying a list of something on the screen. In the olden days populating that list and updating it was just meh.
In comes ViewModel + DiffUtil, Google’s kind of successful effort trying to fix the mess that Android is.
So that’s what we gonna do I guess.
Source code in 3 simple files can be found…