[Paywalls V2] Adds template previews#2184
Conversation
📸 Snapshot Test4 modified, 18 added, 238 unchanged
🛸 Powered by Emerge Tools |
Generated by 🚫 Danger |
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #2184 +/- ##
==========================================
- Coverage 81.03% 80.53% -0.50%
==========================================
Files 276 277 +1
Lines 9397 9455 +58
Branches 1333 1334 +1
==========================================
Hits 7615 7615
- Misses 1222 1280 +58
Partials 560 560 ☔ View full report in Codecov by Sentry. |
…x Emerge. (Needs a ton of cleanup.)
…even works on Emerge.
| emergeGradlePlugin = "4.0.9" | ||
| emergeSnapshots = "1.3.2" |
There was a problem hiding this comment.
This was done on advice from Emerge, but didn't end up fixing the issues.
tonidero
left a comment
There was a problem hiding this comment.
Many thanks for doing this! It's great to have these 💪
| } | ||
|
|
||
| buildFeatures { | ||
| buildConfig true |
There was a problem hiding this comment.
I guess this might increase build time so very slightly in release without need, but then again, it shouldn't be noticeable at all, I'm totally ok with it
There was a problem hiding this comment.
Hmm yea, I researched a bit but I don't think it's possible to only enable this in debug builds. I think it's negligible indeed, especially since there are no buildCofigFields defined for release builds.
| dateProvider = { Date() }, | ||
| ) | ||
|
|
||
| LoadedPaywallComponents( |
There was a problem hiding this comment.
Should we wrap this into a full width/height box with a white background or something like that? To better visualize how it would look like on a device.
There was a problem hiding this comment.
Emerge doesn't really support this 🙁 I tried it in 2 ways now:
- Setting a device spec in the
@Previewannotation. - Adding a
requiredSizemodifier to the root.
The device spec is ignored, and the requiredSize results in things being cut off at the top and bottom:
Regarding the use of a parent composable, I'm not sure which alignment to pick then, and I'm afraid whichever alignment we pick might influence our results.
There was a problem hiding this comment.
2 more developments on this front:
- I added a
WindowAndDisplayMetricspreview to thedebugsource set to get some insights into the Emerge Snapshots rendering environment. Turns out it renders at 411 x 683 dp, while Android Studio's default rendering is at 392 x 850 dp, which is quite a bit taller. - I tried to use
DeviceConfigurationOverrideto force the dimensions, but somehow Android Studio fails to render in that case. I think this could be a nice future improvement though.
This is part 1 of 3:
offerings_paywalls_v2_templates.jsonfile, and the previews themselves.offerings_paywalls_v2_templates.jsonfile.Description
This adds previews of all templates, based on the Official Paywalls V2 Templates repo. It includes the offerings network response as JSON, and parses that in a
PreviewParameterProvider. It then renders each Paywall as an individual Preview. This way all we have to do is update the JSON file, and we would automatically get updated previews for each paywall. No need to manually add a preview if we add a paywall, for instance.It doesn't load images and icons yet, but it's already useful to catch various issues such as layouts and gradients.
Design decisions
This section explains why we do things a certain way.
The Composable to preview
I picked
LoadedPaywallComponentsas the Composable to use for these previews. Other candidates werePaywallandInternalPaywall, but both of these won't work as they use a ViewModel. Android Studio simply refuses to render these.The source set
The previews, including the giant JSON file, are part of the
debugsource set, as I didn't want to include this (particularly the JSON) in the published SDK. We might wanna think about doing this for more of our previews. If we want to, we could move the previews to a dedicatedpreviewssource set in the future, but for now I thoughtdebugwould work fine.Deserializing JSON into Offerings inside revenuecatui
Our
revenuecatuilibrary doesn't handle the deserialization of JSON intoOfferings, but that is what we need here. I chose to construct a specificOfferingParservia reflection. This way we don't need to make anything public inpurchasesjust for these previews.I considered, but ultimately discarded, using the full
PurchasesSDK. We wouldconfigure()and then fetch theOfferings. Doesn't work becauseconfigure()uses things likePackageManagerwhich is not available in a preview environment.Reading the giant JSON file
We are reading the giant JSON file in a very specific way, and the reason for this is the Emerge Snapshots environment. I navigated 2 constraints, that I found out about through trial and error:
InputStreamopen for the entire lifecycle of aPreviewParameterProvider.valuesSequence, and yielding items for each item in that Sequence, is not supported. The stream will be closed prematurely in the Emerge environment.Given these 2 constraints, the only working solution is to reopen the stream every time the
valuesSequence is asked for a newvalue. We then parse the file, and only read the the Offering we care about into memory. This is then only kept in memory for as long as the currentvalueis needed. After that, we reopen the stream again and read the next Offering into memory.How this looks in Android Studio