Content card UI for iOS #715
Conversation
src/pages/edge/adobe-journey-optimizer/content-card-ui/iOS/api-usage.md
Outdated
Show resolved
Hide resolved
src/pages/edge/adobe-journey-optimizer/content-card-ui/iOS/index.md
Outdated
Show resolved
Hide resolved
src/pages/edge/adobe-journey-optimizer/content-card-ui/iOS/index.md
Outdated
Show resolved
Hide resolved
...s/edge/adobe-journey-optimizer/content-card-ui/iOS/public-classes/contentcardtemplatetype.md
Outdated
Show resolved
Hide resolved
|
|
||
| ## Overview | ||
|
|
||
| The Messaging extension provides a way to listen to events from content cards displayed in your application. The following functions can be implemented in conformance with the [ContentCardUIEventListening](../public-classes/contentcarduieventlistening.md) protocol: |
There was a problem hiding this comment.
I would just simplify and make this "... can be implemented with the..."
There was a problem hiding this comment.
When defining protocol methods the word "conformance" makes sense.
...s/edge/adobe-journey-optimizer/content-card-ui/iOS/tutorial/listening-content-card-events.md
Outdated
Show resolved
Hide resolved
| - Return `true` if your application has successfully handled the URL. This indicates to the SDK that no further action is needed. | ||
|
|
||
| - Return `false` to allow the SDK to process the URL. |
There was a problem hiding this comment.
Same comment as above, instructions are directed at the developer implementing the method.
Hence Return makes sense
There was a problem hiding this comment.
"Returns" would still be the correct usage here, even with its developer-focused and imperative tone since we're explaining that it will be returned and not directly providing a return statement. Here's a link to other documentation in the SDK where we use "returns" for the same usage case:
...s/edge/adobe-journey-optimizer/content-card-ui/iOS/tutorial/listening-content-card-events.md
Outdated
Show resolved
Hide resolved
| # AEPHStack | ||
|
|
||
| The AEPHStack class extends AEPStack and arranges its child views horizontally. It provides additional customization for aligning child views vertically. | ||
|
|
||
| ## Public Properties | ||
|
|
||
| | Property | Type | Description | Default Value | | ||
| | --- | --- | --- | --- | | ||
| | alignment | [VerticalAlignment](https://developer.apple.com/documentation/swiftui/verticalalignment) | The vertical alignment of child views in the stack. | [center](https://developer.apple.com/documentation/swiftui/verticalalignment/center) | | ||
|
|
||
| # AEPVStack | ||
|
|
||
| The AEPVStack class extends AEPStack and arranges its child views vertically. It provides additional customization for aligning child views horizontally. |
There was a problem hiding this comment.
Wait... HStack provides customization for aligning child views vertically and VStack for arranging child views horizontally?
There was a problem hiding this comment.
Haha yeah seems confusing but this is correct. Here is Apple documentation https://developer.apple.com/documentation/swiftui/hstack/init(alignment:spacing:content:)
|
|
||
| The `onInteract` method provides an optional `actionURL` parameter associated with the interaction event. The return value of this method determines how the URL is handled. | ||
|
|
||
| * Return `true` if your application has successfully handled the URL. This indicates to the SDK that no further action is needed. |
There was a problem hiding this comment.
Again, these would be better as "Returns", as mentioned in other comments.
Description
Related Issue
Motivation and Context
How Has This Been Tested?
Screenshots (if appropriate):
Types of changes
Checklist: