Android Kotlin: Forecast App 10 – Getting Device Location – MVVM Tutorial Course

We’ve already written code which is responsible for storing the WeatherLocation inside the local database. Our user interface is also prepared to use location. What we haven’t implemented yet properly is the LocationProvider. At the moment it has only dummy functions which return some constant values.

In this tutorial, you’re going to learn how to work with the location of the device and also, how to fall back to user-defined “custom” location if the user doesn’t grant us the location permission.

👉Get the code from this tutorial👈


Matej Rešetár

Matej is an app developer with a knack for teaching others. If he's not programming, making tutorials or doing other business, he's mostly working out, listening to audiobooks and taking cold showers.

  • Al W says:

    On your app crash, if you get it again, look at your logcat. I did get an app crash (sorry, can’t remember when). The error was an unhandled 500 http response code in Jake Whartons retrofit coroutines adapter.

    Also, when navigating back after changing unit settings, the display doesn’t change unless i navigate to 7 days and back home. That’s probably something I missed along the way. I’ll dig further.

  • Alin says:

    Yet, another interesting tutorial. I liked the way Location was implemented with the lifecycle aware component in a separate class.
    TDD talk was interesting as well, maybe you can decide to have a simple basic app that shows tdd with the tools that the jetpack provides now. Maybe the quotes app would be a good candidate as it was used in previous tutorials.
    I am not convinced if TDD should be done at small level, for each function or at larger scale for a complete behavior, because later if you decide to refactor, then some of these small functions will be removed leaving a bunch of failing tests behind.

    Keep up the good work.

    • I will make a TDD tutorial for sure! I like to test whole classes in a unit test, with each test for a different use-case (initialized, not initialized, tricky cases, throws an exception…) This encourages to write your classes as “modules” with no direct dependencies on other classes – otherwise, you wouldn’t be able to test them at all!

  • >