Coinverse | Coinverse Open App is the first audiocast app | Android library

I am not sure if having "nested LiveData" is okay. When we work with any event-driven design implementation (LiveData, RxJava, Flow) we usually required to assume that the discrete data events are immutable and operations on these events are purely functional. Being immutable is NOT synonymous with being read-only(val). Immutable means immutable. It should be time-invariant and should work exactly the same way under any circumstances. That is one reason why I feel strange to have LiveData or ArrayList members in the data class, regardless of whether they are defined read-only or not.

Another, technical reason why one should avoid nested streams: it is almost impossible to observe them correctly. Every time there is a new data event emitted through the outer stream, the developers must make sure to remove inner subscriptions before observing the new inner stream, otherwise it can cause all sorts of problems. What's the point of having life-cycle aware observers, when the developers need to manually unsubscribe them?

In almost all scenarios, nested streams can be converted to one layer of stream. In your case:

There is no use case to mark a Dao method as suspend that produces a DataSource.Factory. The return type is simply used by the annotation processor to know what kind of code to generate (just like the suspend modifier is). A DataSource when used together with a LiveData will always execute queries on off the main thread so you can safely call non-suspendable database and blocking network calls. Also, there makes no sense to mark any Dao method that returns LiveData to be suspendable since the ArchTaskExecutor makes sure that queries are run off the UI thread but results are delivered on the UI thread.

To construct LiveData that calls suspendable methods, you can use the liveData {} builder extension from lifecycle-livedata-ktx extensions artifact.

There is also a LiveData-builder that constructs a LiveData directly from your DataSource.Factory, check out the paging-runtime-ktx artifact.

Also, I would not recommend returning MutableLiveData like that. Mutable livedata is usually mutated in private, and returned as a non-mutable LiveData object.

Use MockK's Extension & top-level functions implementation strategy to mock Firebase's FirebaseAuth.kt class. This will result in the FirebaseAuth class being essentially ignored when called in the unit test code, thus not crashing the test due to external Firebase dependencies.

The source of the mocking issue is either due to the static method getInstance, how the currentUser variable is auto-generated, or both.

Test - SomeLocalJUnitTest.kt

Find the latest version of MoPub in the documentation here.

build.gradle (project)

Thanks @Doug_Stevenson and @AndersonMendes for the guidance!

I was including both the bucket id to my Google Cloud Storage and the file path in the same string which was the source of the error.

var bucket = storage.bucket('gs://[projectName].appspot.com');

Refactor AndroidViewModel implementation to ViewModel as outlined in Jose Alcérreca's post Locale changes and the AndroidViewModel antipattern

This refactor will remove the need to create Application Context.

In addition to the ViewModel refactor, pass components into the ViewModel as an argument to separate dependencies. A Dependency Injection library may be used in the new ViewModel in order to create required components (ie — Repository, Database, Analytics, and etc.) and de-couple them from the ViewModel as well.

Each package may only be associated with one SHA-1 key. When removing the additional Firebase project and reverting the shared Firebase project to it's original state with the SHA-1 key the console provided the following error which revealed an issue.

An OAuth2 client already exists for this package name and SHA-1 in another project

This error message did not show originally, and would be useful to see the first time the same SHA-1 key is detected in a Firebase project with the same Android package name.

Remove the SHA-1 key from any other Firebase projects with the same package name. When using two Firebase projects in an Android application, they cannot use the same SHA-1 key.

The default Firebase project was not being generated from the google-services.json in the second newly created project.

Rebuild the project in Android Studio under Build > Rebuild Project

Strategy - Create both an open source shared Firebase instance to provide access to shared data and Cloud Functions, and have developers who download the GitHub project create their own private Firebase instance for authentication used as the default instance via the google-services.json file.

Pro-tip - Be sure to identify a unique SHA-1 key with each Firebase project that requires it, otherwise there'll be an authentication error outlined here.

• Initialize the shared open source Firebase project with the Use multiple projects in your application programmatic implementation (separate project from the non-shared staging and production projects used for releases). - FirebaseApp.getInstance("openSourceProject") Note: setProjectId(...) also needs to be set for the FirebaseOptions although not mentioned in the link above and any other setters for services used such as Storage.
• Populate app with public content and price data from shared Firestore project - FirebaseFirestore.getInstance(FirebaseApp.getInstance("openSourceProject"))
• Use shared Cloud Functions and Firebase Storage to create .mp3 files from Storage .txt files and access .mp3s from Storage. - FirebaseStorage.getInstance(FirebaseApp.getInstance("openSourceProject")) and FirebaseFunctions.getInstance(FirebaseApp.getInstance("openSourceProject"))

• Initialized as default Firebase project instance via the google-services.json file.
• Use for authentication with their SHA-1 key
• Save logged in user data to their Firestore instance - FirebaseFirestore.getInstance()
• Create a Firebase token for delete user functionality