Building Notifications with FCM and C# in Australia

The C# Corner Annual Conference 2020 is a three-day event for software professionals and developers, with dozens of speakers covering C#, Microsoft Azure, cloud computing, data, web development, DevOps, AI and robotic process automation. Its multi-track agenda spans several days, and attendees can create an account or log in to the event platform to shape a personal schedule. It is a practical setting for examining how applications communicate with users beyond their own screens.

Building a notification system with Firebase Cloud Messaging and C# brings that focus to a common product requirement. Firebase Cloud Messaging, or FCM, manages delivery to Android, iOS and web clients, while a C# service decides who receives an alert and what it contains. The key question is not whether a message can be sent, but whether the right person receives the right alert once, at a suitable moment, with enough context to act.

Reliable push notifications cross several layers: device permissions, application tokens, identity records, business rules, cloud transport and user preferences. A weakness in any layer can produce duplicates, stale messages or silence. Australian teams also operate in a large, mobile-first market where customers move between metropolitan and regional areas, businesses serve the whole country and communication preferences rarely follow one pattern.

Sessions on Azure, cloud architecture and DevOps can shape the supporting platform, but implementation still needs clear boundaries. A C# backend should own decisions and delivery, while each client manages registration and local presentation. Applied to banking, retail, logistics or public-service products, this separation creates a notification capability that scales without coupling business rules to one transport.

Designing the end-to-end notification flow

Begin with an event-driven flow. A business action creates an event with an identifier, audience rule, content reference and delivery policy. An ASP.NET Core service or Azure Function consumes it, loads the recipient or segment, checks consent and quiet hours, then calls the Firebase Admin SDK. Firebase returns a provider message ID, which the service stores against the event and device token, creating a traceable path from decision to attempt.

Treat device registration as identity data rather than a disposable string. After sign-in, the client requests permission, creates or refreshes its FCM token and sends it through an authenticated API call. The API associates that token with an internal user and device record. Events can then target a user, topic or registration. Tokens rotate, get revoked or survive an app uninstall, so invalid registrations should be removed when Firebase reports them.

Separate content from transport. A display message contains a title and body, while a data message lets the app interpret fields, open a deep link or localise text. Payload limits and background handling differ across platforms. Keep templates in a configuration store, include a stable correlation ID and reject oversized payloads before sending. A compact C# minimax example shows a useful architectural habit: keep domain rules independent from the interface presenting them.

Connecting Firebase Cloud Messaging to C#

Create a Firebase project, register Android, Apple and web applications, and obtain each platform's required configuration. Use server-side Firebase Admin credentials; never ship a service-account key in a mobile or browser package. In the backend, add the Firebase Admin .NET package, initialise it from a protected credential source and register the messaging client through dependency injection. On Azure, Key Vault is a practical home for secrets.

The sending service can build a Message, MulticastMessage or TopicMessage and pass it to the asynchronous Firebase API. Hide that transport behind an INotificationSender interface so application services do not depend on Firebase classes. Set a TTL when freshness matters, use collapse keys for replaceable updates and reserve priority for genuinely urgent events. Queue lengthy work through Azure Service Bus or another durable broker rather than holding an HTTP request open.

Clients remain part of delivery. Android 13 requires runtime notification permission, and iOS asks users to allow notifications after installation. Request access in context, explain its value and provide an in-app preference centre. Register or refresh tokens after sign-in, react to rotation and clear local notification state at sign-out. These details often determine whether a correct backend produces an alert that customers receive and trust.

Planning for Australia's mobile landscape

Australia's geography makes network behaviour part of application design. Sydney and Melbourne cover large population centres, but Perth and Adelaide are much farther away; a cloud region in eastern Australia can still improve response times for many users. For a national app, measure FCM send latency and callback handling instead of assuming one region serves every participant equally. Small payloads and sensible caching often matter more than raw processing power.

Many Australian developers call a push notification a “ping,” and “ping me when it's done” is a familiar workplace request. The informal language reflects an expectation that alerts arrive without another visit to the website. Yet people in regional and remote areas, older customers and staff on basic handsets may rely more on SMS or email. A channel strategy can use FCM for the app experience and SMS for an urgent event when the recipient has explicitly opted in.

Scheduling crosses several clocks. Perth uses Western Australian time, Brisbane does not observe daylight saving, and Sydney and Melbourne shift their clocks. Store timestamps in UTC, display them in the recipient's zone, and calculate quiet hours from a stated preference rather than the server default. Australian banks, supermarkets, couriers and field-service operators serve customers across these regions, so one national campaign may reach people at very different local times.

Securing delivery and comparing channels

Keep the server path authenticated and least-privileged. Use a dedicated FCM service account, rotate credentials and avoid hard-coded JSON keys. Validate requests at the API boundary, derive recipients from the signed-in account where possible, and prevent clients from choosing arbitrary audiences. Log correlation IDs rather than sensitive content. On Azure, Key Vault-backed secrets reduce the amount of long-lived credential material stored in application code.

Marketing and service messages need an Australian compliance review. The Privacy Act 1988 and Australian Privacy Principles govern personal information, while the Spam Act 2003 regulates commercial electronic messages and raises consent, identification and unsubscribe requirements. The treatment of a particular FCM campaign can depend on its content and audience, so teams should document the sending basis and provide clear controls. Transactional alerts and promotional campaigns should not share default preferences or frequency rules.

Operations need more than a successful HTTP response. Track send attempts, accepted messages, available delivery callbacks, invalid tokens, latency, opt-outs and deep-link conversions. Retry only transient failures, use exponential backoff and cap attempts. A dead-letter path should preserve events for inspection rather than dropping them silently. These measures distinguish a Firebase problem from a targeting error, an app crash or a device with stale registrations.

Recommended rollout for Australian teams

Begin with one measurable journey, such as a delivery-status update or account-security alert, rather than enabling every notification type at once. Define events, audiences, templates, permissions and suppression rules before connecting clients. Use separate Firebase projects for development and production. A staged release through staff, selected customer cohorts and a wider audience gives clear checkpoints for permission rates, delivery health and support feedback.

Test the whole chain under realistic conditions. Simulate expired tokens, permission denial, offline devices, duplicate events, time-zone changes, quiet hours and FCM throttling. Confirm that Android, iOS and web clients open the correct destination and that a repeated event does not create another alert. Test the sender abstraction automatically, then run a small production pilot and compare direct FCM, topic messaging, email and SMS against accessibility, localisation and consent needs.

• Define a stable event schema with recipient, content, correlation and expiry fields before adding channel-specific code.
• Store FCM tokens against internal users and devices, refresh them on sign-in and remove registrations that Firebase rejects.
• Ask for notification permission only when a useful alert is available, then expose granular preferences inside the app.
• Define channel rules for push, email and SMS, including consent, urgency, quiet hours, fallback limits and frequency caps.
• Store and display times in UTC while applying quiet hours and scheduled delivery in each recipient's local zone.
• Monitor delivery acceptance, invalid tokens, latency, opt-outs and downstream conversions before expanding an audience.
• Exercise token expiry, permission denial, duplicate events, provider throttling and notification loss in regular release tests.

A successful implementation gives the business a durable communication channel while retaining control over who hears what and when. The C# backend owns audience and policy decisions, Firebase manages transport, and clients provide the native experience. That separation supports Australian scale, where national reach must coexist with regional connectivity, different time zones and firm privacy expectations.