Cloud Messaging (push notifications) in Android Kotlin - Build, Publish & Deploy

Build & Publish - Cloud Messaging (push notifications)

Performance Impact

Using cloud messaging for push notifications has minimal impact on app frame rate and UI smoothness because notifications are handled by the system outside your app's main thread. However, frequent or heavy payloads can increase battery use and network data consumption. Keep notification payloads small and avoid waking the app unnecessarily to preserve battery life.

Optimization Tips

To keep your app running smoothly at 60fps, avoid processing heavy tasks directly in the notification handler. Use WorkManager or background threads for any data syncing triggered by notifications. Limit the frequency of notifications and batch updates when possible. Also, use data-only messages sparingly to reduce wake-ups and conserve battery.

App Size and Startup Time

Integrating Firebase Cloud Messaging (FCM) adds a small increase to your app size, typically a few megabytes due to Firebase libraries. This is considered medium impact. The startup time impact is minimal since FCM runs as a background service managed by Google Play Services, not your app process. Keep dependencies minimal to avoid unnecessary size growth.

iOS vs Android Differences

On Android, Firebase Cloud Messaging uses Google Play Services to receive and display notifications. On iOS, Apple Push Notification service (APNs) is used, and Firebase acts as a wrapper. iOS requires explicit user permission to show notifications, while Android grants permission by default (starting from Android 13, explicit permission is required). Also, iOS limits background processing time after receiving notifications more strictly than Android.

Store Review Guidelines

• Ensure your app requests notification permissions clearly and respectfully, explaining why notifications are needed.
• Do not send spammy or irrelevant notifications; follow Apple App Store and Google Play policies on user experience.
• Handle user opt-out gracefully and do not bypass system notification settings.
• Comply with privacy policies regarding user data used in notifications.

Self-Check Question

Your app takes 5 seconds to load this screen after receiving a push notification. What's likely wrong?

Answer: The notification handler is doing heavy work on the main thread, blocking UI rendering. Move processing to background threads or schedule work asynchronously to fix this.

Key Result

Cloud Messaging minimally affects UI performance but can impact battery and data if misused. Optimize by offloading work from notification handlers and respecting user permissions. Firebase adds moderate app size but negligible startup delay. Follow store guidelines to ensure smooth approval.

Practice

1. What is the main purpose of Firebase Cloud Messaging (FCM) in Android apps?

easy

A. To manage app permissions and settings

B. To store user data locally on the device

C. To send push notifications to users even when the app is closed

D. To create user interfaces with buttons and text

Solution

1. Step 1: Understand FCM's role

   Firebase Cloud Messaging is designed to send messages or notifications to users' devices.

2. Step 2: Identify the correct purpose

   It works even if the app is closed, keeping users updated with push notifications.

3. Final Answer:

   To send push notifications to users even when the app is closed -> Option C

4. Quick Check:

   FCM purpose = push notifications [OK]

Hint: Remember: FCM = push notifications, not UI or storage [OK]

Common Mistakes:

• Confusing FCM with local data storage
• Thinking FCM manages UI elements
• Assuming FCM controls app permissions

2. Which Kotlin class should you extend to handle incoming Firebase push messages in your Android app?

easy

A. FirebaseMessagingService

B. FirebaseDatabase

C. FirebaseAuth

D. FirebaseStorage

Solution

1. Step 1: Identify the service for message handling

   FirebaseMessagingService is the class designed to receive and handle push notifications.

2. Step 2: Exclude unrelated Firebase classes

   FirebaseDatabase, FirebaseAuth, and FirebaseStorage serve different purposes like data storage, authentication, and file storage.

3. Final Answer:

   FirebaseMessagingService -> Option A

4. Quick Check:

   Message handler class = FirebaseMessagingService [OK]

Hint: Use FirebaseMessagingService to receive messages [OK]

Common Mistakes:

• Choosing FirebaseDatabase for message handling
• Confusing FirebaseAuth with messaging
• Using FirebaseStorage instead of messaging service

3. Given the following Kotlin code snippet inside a FirebaseMessagingService subclass, what will be logged when a message is received?

override fun onMessageReceived(remoteMessage: RemoteMessage) {
    val title = remoteMessage.notification?.title ?: "No Title"
    val body = remoteMessage.notification?.body ?: "No Body"
    Log.d("FCM", "Title: $title, Body: $body")
}

medium

A. Title: No Title, Body: No Body if notification is null

B. App crashes if notification is null

C. Title and Body are always empty strings

D. Logs only the body, not the title

Solution

1. Step 1: Analyze null safety with Elvis operator

   The code uses ?: to provide default strings if notification or its fields are null.

2. Step 2: Understand logging behavior

   If notification is null, title and body become "No Title" and "No Body" respectively, so the log shows these defaults.

3. Final Answer:

   Title: No Title, Body: No Body if notification is null -> Option A

4. Quick Check:

   Elvis operator handles nulls = default text logged [OK]

Hint: Elvis operator ?: gives default when null [OK]

Common Mistakes:

• Assuming app crashes on null notification
• Thinking title/body become empty strings
• Believing only body is logged

4. You wrote this code to get the device token for FCM but it never logs the token. What is the error?

FirebaseMessaging.getInstance().token.addOnCompleteListener {
    if (!it.isSuccessful) return@addOnCompleteListener
    val token = it.result
    Log.d("FCM", "Token: $token")
}

medium

A. You need to call addOnSuccessListener instead of addOnCompleteListener

B. You forgot to add internet permission in AndroidManifest.xml

C. You must call getInstance() with context parameter

D. You should use getToken() instead of token property

Solution

1. Step 1: Check the API for token retrieval

   FirebaseMessaging.getInstance().getToken() is the correct method; there is no .token property.

2. Step 2: Verify other options

   Internet permission is needed to run, but the code won't compile due to undefined token property. getInstance() without context works, and addOnCompleteListener is correct.

3. Final Answer:

   You should use getToken() instead of token property -> Option D

4. Quick Check:

   No token property = use getToken() [OK]

Hint: Use getToken() method to fetch FCM token [OK]

Common Mistakes:

• Forgetting internet permission
• Thinking context is required for getInstance()
• Using wrong listener type for token retrieval

5. You want to send a push notification only to devices that have a specific user preference enabled. Which step is essential to implement this targeting correctly?

hard

A. Use FirebaseDatabase to store notifications and query them on the device

B. Send the device token to your server and filter tokens based on user preferences

C. Send notifications to all devices and let the app ignore unwanted ones

D. Use FirebaseAuth to authenticate users before sending notifications

Solution

1. Step 1: Understand device token role

   Device tokens uniquely identify devices to receive push notifications.

2. Step 2: Implement server-side filtering

   Send tokens to your server and filter them by user preferences before sending notifications.

3. Final Answer:

   Send the device token to your server and filter tokens based on user preferences -> Option B

4. Quick Check:

   Token + server filtering = targeted notifications [OK]

Hint: Always send tokens to server for targeted notifications [OK]

Common Mistakes:

• Sending notifications to all devices without filtering
• Using FirebaseDatabase instead of server filtering
• Confusing authentication with notification targeting