docs: expand Customer Profiles push notifications to Android, Flutter, and Swift - #8616
docs: expand Customer Profiles push notifications to Android, Flutter, and Swift#8616ekjotmultani wants to merge 3 commits into
Conversation
…, and Swift The standalone Connect clients are released in amplify-android (aws-connect), amplify-flutter (amplify_connect_client), and amplify-swift (AmplifyConnectClient). Expand the five client pages that apply to them from platforms: ['react-native'] to the four-platform set, with per-platform install, client creation, and identifyUser / registerDevice / removeDevice snippets and error handling. The four React Native push-handling pages (permissions, device token, notification interaction, badge count) stay React Native only: the standalone clients register tokens with the backend but do not handle notification display. Verified with jest (305 passing), cspell (clean), and a full production build: all four platforms prerender the customer-profiles routes, and every internal link target builds on the three new platforms.
…tter setup amplify_core's NotificationsOutputs parser still requires the legacy Pinpoint fields (aws_region, amazon_pinpoint_app_id), so passing the full outputs file containing notifications.amazon_connect to Amplify.configure throws a parse error. Remove the key before configuring, matching the released example app; the Connect client reads it from the decoded map instead.
| // Amplify.configure parses only its own sections, so remove the | ||
| // notifications key before configuring. The Connect client reads it | ||
| // from the decoded map instead. | ||
| final authOutputs = Map<String, dynamic>.from(outputs)..remove('notifications'); |
There was a problem hiding this comment.
[suggestion] Is this stripping-the-notifications-key step actually required? The published amplify_connect_client README just calls AmplifyConnectClientFlutter.createFromAmplifyOutputs(amplifyOutputs: amplifyOutputs) on the full decoded outputs, no mention of removing the notifications key before Amplify.configure(). If Amplify.configure genuinely chokes on that key on the current release, keep this, but if it doesn't we should drop the workaround since it adds unnecessary complexity and could send readers down the wrong path.
There was a problem hiding this comment.
It is, unfortunately. NotificationsOutputs in amplify_core still has the pinpoint fields as required, so Amplify.configure throws on an outputs file where notifications only has amazon_connect. The README doesn't hit it because its snippet never calls Amplify.configure, but the example app in the repo does the same strip for the same reason. We have a parser fix in flight on amplify-flutter to accept the new shape, once that releases I'll simplify this snippet to a plain configure.
There was a problem hiding this comment.
Why not make the pinpoint fields optional?
|
|
||
| ```kotlin | ||
| dependencies { | ||
| implementation("com.amplifyframework:aws-connect:LATEST_VERSION") |
There was a problem hiding this comment.
[nitpick] Couldn't confirm com.amplifyframework:aws-connect on Maven Central when I checked (0 results), though that could just be an indexing lag since the Flutter package was released only a couple days ago too. Worth a quick sanity check of the exact group/artifact coordinate before merge so nobody copies a build.gradle line that 404s.
There was a problem hiding this comment.
It's there, the search index just hasn't caught up. Direct path resolves: https://repo1.maven.org/maven2/com/amplifyframework/aws-connect/2.39.0/ (went out with the 2.39.0 release on Jul 30).
| | `phone` | `string` | The user's phone number. | | ||
| | `location` | `object` | The user's location. Accepts `city`, `country`, `postalCode`, and `region`, each a `string`. | | ||
| | `customAttributes` | `Record<string, string>` | Additional key-value pairs to store on the profile. | | ||
| | `customAttributes` | `map` | Additional string key-value pairs to store on the profile. | |
There was a problem hiding this comment.
[nitpick] The old copy explicitly said "customAttributes values must be strings", this drops that constraint when the type became map instead of Record<string, string>. If all four SDKs still require string values here, worth restoring that note so it doesn't read like arbitrary values are now allowed.
|
|
||
| <Callout info> | ||
|
|
||
| Device registration requires a push channel, so `registerDevice` throws `ConnectUnsupportedOperationException` on web and desktop platforms. `identifyUser` works on every platform. |
There was a problem hiding this comment.
[nitpick] Flagging for awareness rather than asking for a change: this callout implies the flutter platform tag here covers non-mobile targets too (web/desktop), which matches the package's platform support matrix on pub.dev, but nothing else on this page discusses non-mobile Flutter usage. Fine to leave as is if that's intentional.
There was a problem hiding this comment.
Yeah that's intentional. identifyUser works everywhere Flutter runs, only device registration needs a push channel, so the callout scopes exactly that.
| See [Identify a user](/[platform]/frontend/push-notifications/customer-profiles/identify-user/). | ||
| </InlineFilter> | ||
|
|
||
| After sign-out completes, subsequent calls are signed as a new guest identity. See [Remove a device](/[platform]/frontend/push-notifications/customer-profiles/remove-device/). |
There was a problem hiding this comment.
Good restructuring here, moving the ordering callout to wrap all four platform variants instead of duplicating it per platform, and generalizing "after signOut completes" to "after sign-out completes" so the prose doesn't leak a specific API name into shared copy.
| | `deviceId` | A stable identifier the library generates and persists per installation, shared with other Amplify libraries. | | ||
| | `platform` | The `platform` string passed when creating the client. | | ||
| | `appVersion` | The `appVersion` string passed when creating the client. | | ||
| | `channelType` | The `channelType` passed when creating the client. Defaults to `ChannelType.GCM`. | |
There was a problem hiding this comment.
The ChannelType.GCM default here lines up with what the overview page's client-creation snippet documents, and the Flutter/Swift derivation logic in the rows below is consistent with their respective overview sections too. Nice to see that stayed in sync across pages.
| <InlineFilter filters={['swift']}> | ||
|
|
||
| ```swift | ||
| try await client.removeDevice() |
There was a problem hiding this comment.
should be something like
func handleSignOut() async {
do {
try await client.removeDevice()
} catch {
print("Failed to remove device before sign out: \(error)")
}
_ = await Amplify.Auth.signOut()
}
There was a problem hiding this comment.
Done, switched it to that shape. It also matches what the remove-device page shows, so the two pages agree now.
- identify-user: restore the note that customAttributes values must be strings, which was dropped when the field table generalized the type for the mobile platforms. - guest-and-authenticated-users: guard removeDevice in the Swift sign-out snippet so a failed removal cannot skip signOut, matching the pattern the remove-device page documents.
|
Tick the box to add this pull request to the merge queue (same as
|
3 participants
Description
The standalone Amazon Connect Customer Profiles clients are now released on all three mobile platforms:
aws-connect(AmplifyConnectClient) in amplify-androidamplify_connect_clientin amplify-flutterAmplifyConnectClientin amplify-swiftThis expands the five Customer Profiles client pages under frontend > Push Notifications from
platforms: ['react-native']to includeandroid,flutter, andswift, following up on the platform scoping deliberately deferred in #8613.Pages expanded
UserProfilesnippets and error handlingregisterDeviceafter sign-in (React Native handles this automatically)Deliberately unchanged
All snippets were written against the released public API surfaces in each repo.
Testing
yarn test:unit: 305 tests, 62 suites, all passingyarn spellcheck: clean (3,023 files)By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.