igocas.blogg.se - Internal kotlin android

#2 is where things really get complicated - in Android, Activities are only active when visible to the user, so we’d need a Service or BroadcastReceiver to receive and process updates. #1 is fairly straightforward if you have a single Activity in your application that hosts multiple Fragments, but it gets more complicated if you have multiple Activities (as most Android apps do).

Be able to listen for location updates when the app isn’t visible to the user (e.g., to show updates in a notification and/or log to files while the user is looking at a different app).

Be able to listen for location updates in one place in the app (“single source of truth”) and reflect the results in multiple activities and fragments.

I recently ran into a situation that I couldn’t find a readily-available answer for in the Android Jetpack documentation or code samples - I was looking to re-architect several apps that make heavy use of location updates. Android can get pretty complicated when you stitch a lot of components together, and having recommendations on architecture design from the experts is certainly welcome.

The official guidance from Google on best practices for app architectures is perhaps the most valuable part of this toolkit. A relatively recent addition to the Android ecosystem is Jetpack, a set of libraries, tools, and best practices to help developers write less code and develop solid, production-worthy apps. Thankfully, things have gotten a lot better for Android users and developers since then.