TheProduct Hunt communityis buzzing about these incredible apps, and we’re here to tell you why!
Dive into the world of digital innovation with us as we showcase the elite selections from May’s latest findings.
Fromadvanced SaaSandproductivity boosterstogroundbreaking AI tools,essential remote work resources, and premium solutions fordevelopers,marketers,fintechaficionados, and even those in thedating scene— this list has it all.
If you’ve ever wished for a magic wand to bring your web dreams to life without all the technical fuss, then let’s talk aboutWegic.
Powered by the latest GPT-4o model, this web designer and developer is ready to turn your ideas into reality through simple conversations. Just share your vision, even if it’s rough around the edges, and Wegic will understand and bring it to life.
The app can create and modify websites in multiple languages, with custom domains, ensuring that your ideas are translated into a functional and beautiful page without hassle.
AI copilot for every marketing task Tags:Productivity, Marketing, Artificial Intelligence PH Launch: 02.05.2024 Upvotes: 1658 ▲
Shape the future of your marketing with adaptive strategies and role-based KPI alignment throughWaxwing
Every marketer needs to streamline efforts, save time, and cut costs. And maybe you’ve got the creativity and drive on the field, but need that extra push to become an AI-savvy marketer.Waxwingis that helping hand.
With just two minutes of onboarding, you can dive into detailed step-by-step plans complete with KPIs, impact assessments, effort estimates, and cost evaluations, backed up by a database of 500+ personalized marketing strategies.
Waxwing integrates with third-party tools like Similarweb and Semrush, as well as your internal tools, creating a central hub for all your business intelligence. Its context-aware AI acts as a copilot, always knowing what task you’re working on and providing the necessary guidelines to execute it effectively.
Turn any process into a step-by-step guide Tags:Productivity, Artificial Intelligence, Remote Work PH Launch: 15.05.2024 Upvotes: 1477 ▲
Onboard new employees, provide instructions to customers, or simply share knowledge with your team withGlitter AI
We’ve all been there: drowning in endless Zoom calls and struggling to explain processes to our co-workers or customers. Creating clear documentation takes too much time and we’re not always able to delegate that task.
But there’s an app that can completely change your workflow:Glitter AIturns your mouse clicks and voice into beautifully written guides complete with screenshots and text — pretty straightforward and incredibly effective!
The perk of the platform lies in its simplicity and efficiency. Just go through your process as you normally would and explain what you’re doing out loud. Glitter AI listens, takes screenshots, and turns everything into a polished guide you can easily edit and share.
No more starting over five times or dealing with the hassle of video tutorials — just speak, click, and share.
🪙 Pricing
Basic plan:Free(up to 10 guides, desktop + web capture, magic article: AI speech to text)
Pro plan:$16/month per member(unlimited guides, blur sensitive information, remove Glitter branding, export guides anywhere)
Team plan:$60/month(5 team members included, $12 / additional team member)
Speak toVoicenoteson your phone or computer or record from audiobooks and YouTube videos
Imagine this: You’re in the middle of a brainstorming session and ideas are flowing fast. Instead of scrambling to jot everything down or losing half your thoughts, you simply speak intoVoicenotesand see the magic happen.
The app captures every word you say and transcribes it accurately, even if there’s background noise or if you speak softly.
Later, when you need to revisit those notes, everything is neatly organized and searchable. This way, what could have been a chaotic mess of lost thoughts becomes a treasure trove of organized ideas, ready for you whenever you need them.
Over time, as you accumulate more notes, the AI helps you connect the dots, revealing insights you might have missed otherwise.
For those using the latest iPhone, setting Voicenotes as your action button is a game-changer, and for desktop users, keyboard shortcuts make recording a breeze.
🪙 Pricing
Note:Voicenotesis available on the web, iOS, Android,and soon on smartwatches — there’s no need to sign up to try it out for free.
Believer:$50/lifetime deal(limited launch offer, with limitless recording and the smartest AI models, GPT-4o and Claude Opus)
With an overwhelming number of platforms and influencers out there, there’s a simpler way to identify and engage with key influencers who can boost your brand’s visibility and credibility:Ivee.
This AI-powered B2B influencer marketing platform is designed to help you spot trendsetters, assess their audience quality, and engage with them at scale. You can easily identify the most relevant opinion leaders from LinkedIn, YouTube, Apple Podcasts, and Substack, with more platforms coming soon.
The app provides unique KPIs and data insights, such as engagement rates, performance trends, and sponsorship history, so you can accurately assess the quality of an influencer’s audience.
Plus, you can create custom influencer databases tailored to your specific needs — by topics, projects, channels, subscriber sizes, and more — so that using Ivee is straightforward and highly effective.
Instantly search through all your folders, apps, and accounts MeetCuriosity,the ultimate all-in-one search tool, command bar and AI Assistant 🔎
Curiosity: connect all your apps and inboxes for search, chat with your files, and autoreply any message
Curiosityis the one search bar for all your work. It connects with all your emails, calendars, local folders, cloud drives, and tools like Notion, Slack, pCloud, and HubSpot to give you one integrated search! That saves time and helps you stay in the flow.
Curiosityalso gives you a shortcut to instantly launch programs, join meetings, open folders, and search your clipboard history.
And it gets even better: With theAI Assistant,Curiosityputs the power of ChatGPT at your fingertips. You can use it to summarize or translate documents, auto-reply to emails, and ask questions about your files.
No need to waste time jumping from one app to another when you can have everything you need in one place, right?
🪙 Pricing
Starter plan:Free(connect up to 5 apps, search across apps and folders, launch apps and meetings, AI assistant)
Pro plan:€8/month(connect unlimited apps, advanced AI assistant, deep file search, unlimited clipboard history)
Workspaces plan:€10/month per user(5+ users, shared search across sources, user management and central billing, 50GB+ cloud storage)
Save valuable time withFynk, a powerful contract management software
Fynkis an all-in-one solution that makes contract management a breeze. Built with powerful AI, this app seamlessly imports, creates, automates, manages, collaborates on, and signs contracts — all in one platform!
Whether you’re bulk importing existing contracts or creating new ones from templates, Fynk’s smart AI analyzes and summarizes your contracts, extracting key information like renewal dates and parties involved.
The app includes a custom contract editor with dynamic fields, digital signatures (SES, AES & QES), and automation workflows.
Plus, Fynk supports approval workflows, negotiation and collaboration features, along with reminders and notifications to keep you on track.
And if you’re starting from scratch, the app’s public templates and in-editor AI will guide you through drafting a contract in no time.
🪙 Pricing
Essential plan:$69/month(50 tracked documents, 2 users, SES signatures, AES signatures, QES signatures, AI contract analysis, AI contract summary)
The first copilot for technical design Tags:Software Engineering, Developer Tools, Artificial Intelligence PH Launch: 15.05.2024 Upvotes: 1137 ▲
Write natural language prompts to output diagram code and share them withEraser AI
Launched to help you create and edit diagrams and documents with ease,Eraser AIis the tool that will take the tedious parts of technical design off your plate, so you can focus on the more important aspects of your projects.
Simply type out your ideas in natural language, and the app generates a beautiful, colorful, icon-studded diagram in seconds. You can easily tweak it to perfection and quickly generate an outline for your design doc. Choose from four different diagram types and even include images in your prompts if you’d like, with full control over editing.
You can quickly create outlines for planning documents (like RFCs and design docs) or documentation (such as READMEs), and use additional AI prompts for open-ended or tedious tasks.
🪙 Pricing
Free Plan:Free(5 files, 20 AI diagrams, 7-day version history, unlimited guests, diagram-as-code, Github integration, Notion integration)
Professional Plan:$10/month per member(unlimited files, AI diagrams, and guests, 90-day version history, PDF exports, private files, publicly editable files)
All AIs in one platform for team collaboration Tags:Productivity, Artificial Intelligence, Bots PH Launch: 13.05.2024 Upvotes: 1122 ▲
Streamline your workflow, improve decision-making, and cut costs withBoodleBox
Have you ever found your team under pressure to deliver a comprehensive market analysis report, but the data was scattered across different sources and tools? Instead of wasting time jumping between platforms and struggling to integrate various AI tools, you can now turn toBoodleBox.
This all-in-one AI collaboration platform is designed to make teamwork with GenAI simpler, faster, and more efficient.
BoodleBox brings together the top AI models — ChatGPT, Claude, Gemini, Llama, Perplexity, DALLE, SDXL — and over 1,000 custom GPT bots, so that you can enhance your workflow by allowing multi-bot chats and personalizing responses with custom knowledge.
🪙 Pricing
Basic plan:Free(2,500 words/month, over 1,000 AI bots, up to 2 boxes)
The investment platform for couples Tags:Fintech, Dating, Investing PH Launch: 16.05.2024 Upvotes: 1036 ▲
Prepare for a brighter future next to your loved one withPlenty
Are you and your partner trying to figure out how to invest and plan for your future in the best way possible?Plentyaims to transform your financial journey with tools and resources that promote teamwork, shared responsibility, and smarter investment decisions — so you can grow your wealth together.
Unlike traditional financial services that often cater to individuals or require hefty fees and minimums, this platform offers accessible and advanced investment strategies and financial products to everyday households.
With a high-yield savings account offering 5.08% APY for your cash, a low 0.20% annual investing fee, and advanced direct indexing portfolios, you get access to financial tools that were once reserved for the wealthy.
The platform is built on the concept of managing money in a “Yours/Mine/Ours” approach, making it easy to balance shared and individual financial goals.
🪙 Pricing
Membership plan:$8.33/month per person(5.08% current APY for savings, $500k SIPC insurance per account, 2–4% higher after-tax returns)
Build a product that resonates with your audience withInsighto
If you’ve ever wished for a simple, cost-effective way to truly understand what your users want, say hello toInsighto: a platform designed to help you collect valuable feedback, prioritize features, and build a product that your users will love!
Unlike Canny and similar tools, Insighto is pretty straightforward and focused on what truly matters. You can easily collect feedback from your customers, prioritize these insights, and make informed decisions about which features to develop next — without being overwhelmed by unnecessary features.
Best of all, it’s completely free, making it accessible for startups and small teams who need to manage their budgets carefully.
Welcome back for another exciting Flutter stable release! This time, we’re thrilled to present Flutter 3.22. We’re bringing WebAssembly to the stable channel, a fully featured Vulkan backend for Impeller on Android, promising smoother graphics and a major performance boost. We’re also introducing streamlined workflows with new widget state properties, dynamic view sizing, and improved form validation. But that’s not all — you’ll find flavor-conditional asset bundling, a preview of Vertex AI for Firebase in Dart, and updated DevTools to make your life easier.
In just a few months since our last update, we’ve merged an impressive 1595 pull requests from the Flutter community, with 37 new community members contributing to Flutter for the first time!
So, dive in and discover all the new features and enhancements that the Flutter community has brought to this latest release!
WebAssembly With the release of Flutter 3.22, Wasm is now available on the stable channel, offering significant performance improvements. In our internal benchmarks using Chrome on an M1 MacBook, the Wonderous app’s frame rendering time improved by 2x on average and 3x in worst-case scenarios.
These enhancements are vital for apps with animations and rich transitions, where maintaining a smooth frame rate is essential. Wasm helps achieve this by reducing performance bottlenecks, resulting in smoother animations and transitions. To start using Wasm with your Flutter web apps, check out our Dart Wasm documentation and Flutter Wasm documentation. For the full announcement, visit the Flutter at Google I/O blog post.
Engine Flutter 3.22 introduces significant updates to Impeller, the rendering engine that powers your Flutter applications. Key highlights include the completion of the Vulkan backend on Android for smoother graphics and improved performance, ongoing optimizations for blur effects and complex path rendering, and a new experimental API for testing with Impeller. In line with our roadmap, we’re committed to enhancing Impeller’s quality and performance, including completing the iOS migration to Impeller and expanding Android support.
Impeller Vulkan backend feature complete on Android In this release, Impeller’s Vulkan backend for Android is feature complete. In particular, in the past few months, the team has been hard at work completing the implementation of fast advanced blends, support for custom fragment shaders with the FragmentProgram API, PlatformView support (though it requires a small API migration), and fully implementing all blur styles.
Android preview In the 3.19 stable release, after releasing improvements in Impeller’s OpenGL backend, we invited users to try out Impeller on Android devices both with and without Vulkan support. Over the past few months, after evaluating the performance of the OpenGL backend and estimating the remaining work on the Vulkan backend, we have decided to focus our efforts on making the Vulkan backend production ready first.
Impeller solves the issue of shader compilation jank. Additionally, in our benchmarks it outperforms the legacy renderer on average, 90th, and 99th percentile frame times. We therefore believe that the performance of the Vulkan backend on Android is acceptable. In this release (3.22), an app that opts-in to Impeller will use the Vulkan backend where available. In a future release, this will become the default. When an app that opts-in to Impeller runs on a device that doesn’t support Vulkan, Flutter will gracefully fall back automatically to using OpenGL ES with Skia. No action is necessary on your part. In the future, when we believe the OpenGL ES Impeller backend is production ready, this fallback will also use Impeller.
As the Impeller preview on Android continues through the 3.22 stable cycle, we request that Flutter developers upgrade to the latest stable version, and file issues about any shortcomings noticed when Impeller is enabled. Feedback at this stage is invaluable to ensuring that Impeller is successful on Android and that we will be able to confidently make it the default renderer in a release later this year. The Android hardware ecosystem is very diverse. For that reason, the most helpful feedback about Impeller should include detailed information about the specific device and Android version where issues occurred.
Blur performance improvements Blur has been reimplemented in Impeller for both iOS and Android. In particular, the new approach, which is similar to Skia’s, reduces the CPU and GPU time of blurs by nearly half in benchmarks.
The chart below shows worst-case, 99%-ile, 90%-ile, and average frame rasterization times and GPU frame times in ms on an iPhone 11 device in a pathological benchmark intended to highlight blur performance. After rewriting Impeller’s blur, both the CPU and GPU cost of backdrop filter blurs has been nearly halved. This scale of this improvement translates to non-pathological cases as well, as would appear in typical apps.
99%-ile, 90%-ile and average frame rasterization times and GPU frame times in ms on an iPhone 11 device in a pathological benchmark intended to highlight blur performance Stencil-then-Cover Impeller on both iOS and Android has moved to a new rendering strategy based on the Stencil-then-Cover approach described in the chapter “Drawing Filled, Concave Polygons Using the Stencil Buffer” in the OpenGL Redbook. Team members discussed more on this technique as it applies to Flutter in GitHub issue #123671.
This approach solves the issue where the raster thread was spending too much time calculating tessellations for complex paths on the CPU for example, SVGs and Lottie animations. After the change, the total frame time (UI thread on the CPU + raster thread on the CPU + GPU work) is much lower for frames that contain complex paths. Users will notice that Lottie animations and other complex paths render more smoothly, with lower CPU utilization, and slightly higher GPU utilization.
(Left) A Lottie animation. Previously, Impeller on a recent iPhone took 64ms / frame of raster thread CPU time to render it. (Right) The same animation on the same device after we landed the Stencil-then-Cover optimization. Raster times are nearly 10x faster. While pleased with these improvements, there is still more work to do. Among other opportunities, we are aware that polyline generation remains prominent in CPU profiles, and we intend to investigate shifting this work to the GPU, as well.
New API While still experimental, flutter test now accepts the --enable-impeller flag, which exercises Impeller using the Vulkan backend.
Framework Widget state properties MaterialState has been moved outside of the Material library and renamed WidgetState, in order to make it available to Cupertino, the base Flutter framework, and package authors. For more information on migrating to the new WidgetState, see the migration guide.
Dynamic view sizing Enhancements to dynamic view sizing benefits developers building responsive layouts, ensuring better UI adaptability across various device screens.
Improved form validation Thanks to the contributions of Flutter community member SharbelOkzan, Flutter 3.22 comes with more flexible form validation methods allowing developers to create more robust user input handling, enhancing both usability and security.
Covariants in 2D APIs Reducing the need for type casts in 2D graphics APIs simplifies development workflows and enhances performance, important for games and complex animations.
Flavor-conditional asset bundling Developers using the flavors feature can now configure individual assets to be bundled only when building for a specific flavor. For more information, check out Conditionally bundling assets based on flavor.
Transformation of assets using Dart packages Users can now configure Dart packages to transform their app’s assets as they are bundled. For more information, check out Transforming assets at built time.
Android Deep linking Deep links can significantly improve the user experience in your Flutter app, acting as shortcuts that seamlessly guide users to specific content within your app, boosting engagement, and driving sales. While Universal Links for iOS and App Links for Android are highly recommended for their security and user-friendly nature, setting them up can be a bit tricky.
In the last Flutter stable release, we introduced a deep link validator tool within DevTools that supports checking web configuration for Android apps. In this version, we added a new set of features to help verify setups within your Android manifest files.
For more information on using this tool, check out Validate deep links.
Predictive back gesture Flutter now adds more support for Android’s upcoming predictive back feature, where users can peek at the previous route or even the previous app during a back gesture. This is still behind a feature flag on Android devices, but you can find details on how to try it out yourself on GitHub.
Flutter tool enforces version requirements on Gradle, AGP, Java, and Kotlin In this release, the Flutter tool enforces a policy regarding the versions that it supports for Gradle, the Android Gradle Plugin (AGP), Java, and Kotlin. Initially, the tool only provides warnings.
Currently, the supported version ranges are as follows:
Gradle — Fully supported 7.0.2 to current, warn otherwise AGP — Fully supported 7.0.0 to current, warn otherwise Java — Fully supported Java 11 to current, warn otherwise Kotlin — Fully supported 1.5.0 to current, warn otherwise In the next major release these warnings will become errors, which can be overridden with the flag --android-skip-build-dependency-validation. More generally speaking, the tool provides a warning for at least one release before fully dropping support (generating an error) for a given version of these dependencies.
This policy was discussed in an associated design spec. Comments and feedback are always welcome.
Support for using Gradle Kotlin DSL in Gradle build scripts on Android Gradle Kotlin DSL is now supported in Flutter, providing an alternative to the traditional Gradle Groovy DSL. This support allows for a better code editing experience, featuring auto-completion, quick access to documentation, source navigation, and context-aware refactoring.
This initial support was contributed by GitHub user bartekpacia. Developers can now choose to rewrite their Gradle build scripts in Kotlin to take advantage of these benefits, although the Flutter tool doesn’t yet allow for selecting Kotlin over Groovy when using flutter create.
For more details, check out the PR 140744 by bartekpacia.
Platform views improvements Heads up for all Flutter app developers! If you’re using Flutter to build apps that rely on native Android components (like maps, web views, or certain UI elements), we have some important news.
Due to a bug in Android 14, apps built with older versions of Flutter might not work properly on devices running this new Android version.
Flutter 3.22 fixes this issue and improves the overall performance of these native components in your Android apps. So, to ensure your app runs smoothly on all Android devices, make sure to rebuild and release your app with Flutter 3.22.
This update also includes behind-the-scenes improvements to make platform views on Android more reliable and performant overall.
End of support for KitKat Flutter’s minimum supported Android version is now Lollipop (API 21). Beginning with Flutter’s 3.22 stable release, Flutter will no longer work on devices running Android KitKat (API 19). For more details, see our deprecation guide.
iOS Platform view performance We understand that platform view performance on iOS has been a pain point for many Flutter developers. This has been especially noticeable within scroll views when using platform views.
Recent updates directly address these concerns, with significant improvements in scenarios like embedding multiple inline ads within an article. Here are some key improvements in our benchmark:
Reduced GPU usage: GPU usage has been reduced by 50%, leading to less power consumption and a potentially smoother user experience. Improved frame rendering: Average frame render times have decreased by 1.66ms (33%). Minimized jank: Worst-case frame render times have been reduced by 3.8ms (21%). If you’ve previously experienced performance challenges when using multiple platform views (like ads, maps, etc) within scrolling views, these optimizations offer the potential for a more fluid and responsive scrolling experience. Please give it a try and let us know what you think.
Ecosystem Vertex AI for Firebase Dart SDK preview release The Vertex AI for Firebase product has been released to public preview and includes the Dart SDK. This enables you to use the Gemini API to build generative AI features for your Dart or Flutter app, with production, performance and enterprise scale in mind. The SDK is integrated with Firebase App Check, which protects your API calls, and safeguards your backend infrastructure from serious threats like billing fraud, phishing, and app impersonation. Jump into the Getting Started for Dart and start using it with no cost with a promo code
The Google AI Dart SDK remains available, and is recommended for prototyping only. Google AI has free-of-charge access (within limits and where available) and pay-as-you-go pricing. If you have been prototyping with the Google AI Dart SDK, and are ready to migrate to Vertex AI for Firebase, check out the migration guide.
DevTools updates We continue to improve DevTools, the suite of performance and debugging tools for Dart and Flutter. This release includes performance improvements, general polish, and new features like including CPU samples in the timeline, advanced filtering, and support for importing and exporting memory snapshots.
Other notable improvements were shipped with the devtools_extensions and devtools_app_shared packages that support DevTools extension authors. We added support for connecting an extension to the new Dart Tooling Daemon (DTD), which allows DevTools extensions to access public methods registered by other DTD clients, such as an IDE, as well as allowing access to a minimal file system API for interacting with the development project.
To learn more about all the updates included in Flutter 3.22 check out the release notes for DevTools 2.32.0, 2.33.0, and 2.34.1.
Google Mobile Ads SDK for Flutter For those of you monetizing your Flutter apps with Ads, we’ve got some exciting news: Google Mobile Ads for Flutter has just released a major update to version 5.0.1!
Enhanced support for User Messaging Platform (UMP) SDK: The update adds support for the latest APIs from the Android UMP SDK version 2.2.0 and iOS UMP SDK version 2.4.0. The UMP SDK is crucial for complying with privacy regulations, making it easier for you to obtain user consent for personalized ads. This new version introduces several new APIs to simplify the consent gathering process.
Expanded mediation partners: We’ve broadened your ad monetization horizons by offering integrations with popular ad partners, including Unity, Meta, AppLovin, Iron Source, Mintegral, Pangle, DT Exchange, InMobi, and Liftoff. You can now maximize your app revenue with expanded mediation options and simplified implementation.
We encourage you to try out these new features in your Flutter apps and let us know which other mediation partners you’d like to see us support. Your feedback is invaluable as we continue to enhance the Google Mobile Ads SDK for Flutter.
Breaking Changes and Deprecations Removal of v1 Android embedding Deletion of version one of the Android embedding is under way. This will likely have no effect on most apps, as
Version two has been the default for many years The Flutter tool would already block building version one apps, unless specifically overridden with the flag -- ignore-deprecation. This release breaks Flutter tool support for v1 apps completely. It is no longer possible to override.
Plugin authors, please note: when the v1 android embedding was initially deprecated a migration doc was written for plugin authors at https://docs.flutter.dev/release/breaking-changes/plugin-api-migration. As part of this migration, it was recommended that plugin authors keep support for apps using the v1 embedding, by including in their *Plugin.java a method with the signature
public static void registerWith(@NonNull io.flutter.plugin.common.PluginRegistry.Registrar registrar)
We plan to fully delete the v1 Android embedding in the next release, at which point plugins that include a method with this signature will no longer compile (as it makes reference to a type from the v1 android embedding).
It currently serves no purpose, as this release has broken apps using the v1 embedding. We recommend that plugin authors release updated versions of their plugins with the v1 code removed as soon as possible, to avoid breakage in future versions of Flutter. For an example, check out PR 6494, which removed the plugins maintained by the Flutter team.
Deprecations removed in 3.22 Breaking changes in this release include deprecated APIs that expired after the release of v3.19. To see all affected APIs, along with additional context and migration guidance, see the deprecation guide for this release. Many of these are supported by Flutter fix, including quick fixes in the IDE. Bulk fixes can be evaluated and applied with the dart fix command-line tool.
As always, many thanks to the community for contributing tests — these help us identify these breaking changes. To learn more, check out Flutter’s breaking change policy.
Conclusion At the heart of Flutter’s success is you — our amazing community. This release wouldn’t be possible without your countless contributions and unwavering passion. From the bottom of our hearts, thank you.
Ready to explore Flutter 3.22? Dive into the full release notes and changelog, fire up your terminal, and run flutter upgrade. We can’t wait to see what you build!
Since our previous posts regarding Content Engineering’s role in enabling search functionality within Netflix’s federated graph (the first post, where we identify the issue and elaborate on the indexing architecture, and the second post, where we detail how we facilitate querying) there have been significant developments. We’ve opened up Studio Search beyond Content Engineering to the entirety of the Engineering organization at Netflix and renamed it Graph Search. There are over 100 applications integrated with Graph Search and nearly 50 indices we support. We continue to add functionality to the service. As promised in the previous post, we’ll share how we partnered with one of our Studio Engineering teams to build reverse search. Reverse search inverts the standard querying pattern: rather than finding documents that match a query, it finds queries that match a document.
Intro Tiffany is a Netflix Post Production Coordinator who oversees a slate of nearly a dozen movies in various states of pre-production, production, and post-production. Tiffany and her team work with various cross-functional partners, including Legal, Creative, and Title Launch Management, tracking the progression and health of her movies.
So Tiffany subscribes to notifications and calendar updates specific to certain areas of concern, like “movies shooting in Mexico City which don’t have a key role assigned”, or “movies that are at risk of not being ready by their launch date”.
Tiffany is not subscribing to updates of particular movies, but subscribing to queries that return a dynamic subset of movies. This poses an issue for those of us responsible for sending her those notifications. When a movie changes, we don’t know who to notify, since there’s no association between employees and the movies they’re interested in.
We could save these searches, and then repeatedly query for the results of every search, but because we’re part of a large federated graph, this would have heavy traffic implications for every service we’re connected to. We’d have to decide if we wanted timely notifications or less load on our graph.
If we could answer the question “would this movie be returned by this query”, we could re-query based on change events with laser precision and not impact the broader ecosystem.
The Solution Graph Search is built on top of Elasticsearch, which has the exact capabilities we require:
percolator fields that can be used to index Elasticsearch queries percolate queries that can be used to determine which indexed queries match an input document.
Instead of taking a search (like “spanish-language movies shot in Mexico City”) and returning the documents that match (One for Roma, one for Familia), a percolate query takes a document (one for Roma) and returns the searches that match that document, like “spanish-language movies” and “scripted dramas”.
We’ve communicated this functionality as the ability to save a search, called SavedSearches, which is a persisted filter on an existing index.
type SavedSearch { id: ID! filter: String index: SearchIndex! } That filter, written in Graph Search DSL, is converted to an Elasticsearch query and indexed in a percolator field. To learn more about Graph Search DSL and why we created it rather than using Elasticsearch query language directly, see the Query Language section of “How Netflix Content Engineering makes a federated graph searchable (Part 2)”.
We’ve called the process of finding matching saved searches ReverseSearch. This is the most straightforward part of this offering. We added a new resolver to the Domain Graph Service (DGS) for Graph Search. It takes the index of interest and a document, and returns all the saved searches that match the document by issuing a percolate query.
""" Query for retrieving all the registered saved searches, in a given index, based on a provided document. The document in this case is an ElasticSearch document that is generated based on the configuration of the index. """ reverseSearch( after: String, document: JSON!, first: Int!, index: SearchIndex!): SavedSearchConnection Persisting a SavedSearch is implemented as a new mutation on the Graph Search DGS. This ultimately triggers the indexing of an Elasticsearch query in a percolator field.
""" Mutation for registering and updating a saved search. They need to be updated any time a user adjusts their search criteria. """ upsertSavedSearch(input: UpsertSavedSearchInput!): UpsertSavedSearchPayload Supporting percolator fields fundamentally changed how we provision the indexing pipelines for Graph Search (see Architecture section of How Netflix Content Engineering makes a federated graph searchable). Rather than having a single indexing pipeline per Graph Search index we now have two: one to index documents and one to index saved searches to a percolate index. We chose to add percolator fields to a separate index in order to tune performance for the two types of queries separately.
Elasticsearch requires the percolate index to have a mapping that matches the structure of the queries it stores and therefore must match the mapping of the document index. Index templates define mappings that are applied when creating new indices. By using the index_patterns functionality of index templates, we’re able to share the mapping for the document index between the two. index_patterns also gives us an easy way to add a percolator field to every percolate index we create.
Example of document index mapping
Index pattern — application_*
{ "order": 1, "index_patterns": ["application_*"], "mappings": { "properties": { "movieTitle": { "type": "keyword" }, "isArchived": { "type": "boolean" } } } Example of percolate index mappings
{ "application_v1_percolate": { "mappings": { "_doc": { "properties": { "movieTitle": { "type": "keyword" }, "isArchived": { "type": "boolean" }, "percolate_query": { "type": "percolator" } } } } } } Percolate Indexing Pipeline The percolate index isn’t as simple as taking the input from the GraphQL mutation, translating it to an Elasticsearch query, and indexing it. Versioning, which we’ll talk more about shortly, reared its ugly head and made things a bit more complicated. Here is the way the percolate indexing pipeline is set up.
See Data Mesh — A Data Movement and Processing Platform @ Netflix to learn more about Data Mesh. When SavedSearches are modified, we store them in our CockroachDB, and the source connector for the Cockroach database emits CDC events. A single table is shared for the storage of all SavedSearches, so the next step is filtering down to just those that are for *this* index using a filter processor. As previously mentioned, what is stored in the database is our custom Graph Search filter DSL, which is not the same as the Elasticsearch DSL, so we cannot directly index the event to the percolate index. Instead, we issue a mutation to the Graph Search DGS. The Graph Search DGS translates the DSL to an Elasticsearch query. Then we index the Elasticsearch query as a percolate field in the appropriate percolate index. The success or failure of the indexing of the SavedSearch is returned. On failure, the SavedSearch events are sent to a Dead Letter Queue (DLQ) that can be used to address any failures, such as fields referenced in the search query being removed from the index. Now a bit on versioning to explain why the above is necessary. Imagine we’ve started tagging movies that have animals. If we want users to be able to create views of “movies with animals”, we need to add this new field to the existing search index to flag movies as such. However, the mapping in the current index doesn’t include it, so we can’t filter on it. To solve for this we have index versions.
Dalia & Forrest from the series Baby Animal Cam When a change is made to an index definition that necessitates a new mapping, like when we add the animal tag, Graph Search creates a new version of the Elasticsearch index and a new pipeline to populate it. This new pipeline reads from a log-compacted Kafka topic in Data Mesh — this is how we can reindex the entire corpus without asking the data sources to resend all the old events. The new pipeline and the old pipeline run side by side, until the new pipeline has processed the backlog, at which point Graph Search cuts over to the version using Elasticsearch index aliases.
Creating a new index for our documents means we also need to create a new percolate index for our queries so they can have consistent index mappings. This new percolate index also needs to be backfilled when we change versions. This is why the pipeline works the way it does — we can again utilize the log compacted topics in Data Mesh to reindex the corpus of SavedSearches when we spin up a new percolate indexing pipeline.
We persist the user provided filter DSL to the database rather than immediately translating it to Elasticsearch query language. This enables us to make changes or fixes when we translate the saved search DSL to an Elasticsearch query . We can deploy those changes by creating a new version of the index as the bootstrapping process will re-translate every saved search. Another Use Case We hoped reverse search functionality would eventually be useful for other engineering teams. We were approached almost immediately with a problem that reverse searching could solve.
The way you make a movie can be very different based on the type of movie it is. One movie might go through a set of phases that are not applicable to another, or might need to schedule certain events that another movie doesn’t require. Instead of manually configuring the workflow for a movie based on its classifications, we should be able to define the means of classifying movies and use that to automatically assign them to workflows. But determining the classification of a movie is challenging: you could define these movie classifications based on genre alone, like “Action” or “Comedy”, but you likely require more complex definitions. Maybe it’s defined by the genre, region, format, language, or some nuanced combination thereof. The Movie Matching service provides a way to classify a movie based on any combination of matching criteria. Under the hood, the matching criteria are stored as reverse searches, and to determine which criteria a movie matches against, the movie’s document is submitted to the reverse search endpoint.
In short, reverse search is powering an externalized criteria matcher. It’s being used for movie criteria now, but since every Graph Search index is now reverse-search capable, any index could use this pattern.
A Possible Future: Subscriptions Reverse searches also look like a promising foundation for creating more responsive UIs. Rather than fetching results once as a query, the search results could be provided via a GraphQL subscription. These subscriptions could be associated with a SavedSearch and, as index changes come in, reverse search can be used to determine when to update the set of keys returned by the subscription.
When working with UI in Flutter, there are often cases where you need to measure the size of widgets that have variable sizes depending on their child widgets. Let’s take the example of an OTT streaming app.
In the movie detail page, the plot section shows both text and images. If this area exceeds a certain height, a ‘More’ button appears, partially hiding the content. Pressing ‘More’ reveals the rest of the content.
This plot section does not have a fixed size. Rather, its height varies dynamically based on the amount of text data, device width, and image height. Therefore, to implement such a UI structure, it’s necessary to measure the rendered height of the widget and conditionally set up UI elements like the ‘more’ button and the hidden content based on whether it exceeds a certain height.
So, how can we measure the dynamic size of widgets? In this post, we’ll explore step-by-step how to measure the variable size of widgets through a simple example. Additionally, we’ll delve into the following concepts, addressing Flutter’s rendering process.
WidgetTree, ElementTree, RenderTree BuildContext RenderObject addPostFrameCallback NotificationListener Implementation Goals Let’s briefly examine the example we’ll cover in the post.
The above screenshot depicts a simple page displaying information about movie cast members. It consists of a Text widget for the title section and a ListView widget with ExpansionTile displaying information about the cast members, all wrapped inside a Column. The Text widget for the title section shows the current height of the Column.
class CastInfoPage extends StatelessWidget { const CastInfoPage({super.key});@override Widget build(BuildContext context) { return Scaffold( backgroundColor: const Color(0xFF000000), appBar: AppBar( leading: const Icon( Icons.arrow_back_ios, color: Colors.white, ), titleSpacing: 0, backgroundColor: Colors.black, centerTitle: false, title: Text( 'Dune: Part Two', style: AppTextStyle.headline1, ), ), body: SafeArea( child: SingleChildScrollView( padding: const EdgeInsets.symmetric(horizontal: 16) + const EdgeInsets.only(top: 20), child: Column( crossAxisAlignment: CrossAxisAlignment.start, children: [ Text( 'Height : ${0}', style: PretendardTextStyle.bold( size: 24, height: 37, letterSpacing: -0.2, ), ), const SizedBox(height: 10), ListView.separated( physics: const NeverScrollableScrollPhysics(), padding: EdgeInsets.zero, shrinkWrap: true, itemCount: CastModel.castList.length, separatorBuilder: (_, __) => const SizedBox(height: 8), itemBuilder: (context, index) { final item = CastModel.castList[index]; return ExpansionTile( tilePadding: EdgeInsets.zero, title: Row( children: [ ClipRRect( borderRadius: BorderRadius.circular(56 / 2), child: CachedNetworkImage( height: 56, width: 56, imageUrl: item.imgUrl, fit: BoxFit.cover, ), ), const SizedBox(width: 10), Column( crossAxisAlignment: CrossAxisAlignment.start, children: [ Text( item.name, style: AppTextStyle.title1, ), Text( item.role, style: AppTextStyle.body3.copyWith( color: AppColor.gray02, ), ) ], ), ], ), children: <Widget>[ Text( item.description, style: AppTextStyle.body3, ), ], ); }, ) ], ), ), ), ); } } When you click on the ExpansionTile, the widget expands to show detailed information about the cast members. Therefore, the size of the widget changes, requiring adjustment of the height value accordingly. We can summarize the following requirements.
- Must be able to obtain the precise size of the currently rendered widget. - Should be able to access the value in the measuring widget to handle UI conditionally. - Must detect changes in widget size dynamically and obtain the changed size (not expandable size). - Should be easy and convenient to use. You can check out the implemented example through the following site.
measure_size_implementation A new Flutter project. measure-size-builder-example.netlify.app
How are Widgets Drawn? First, let’s take a look at how widgets are drawn on the screen in Flutter.
You’ve probably heard about the concept that Flutter creates widgets based on a 3 Tree Architecture consisting of Widget, Element, and Render. You may not be very familiar with encountering objects of elements or render trees during Flutter development, as it's not very common. However, understanding the basic concepts of Flutter's widget tree structure can be very helpful when direct manipulation or access to element or render objects is required, as in this example. So, let's try to explain it in a way that's easier to understand.
Widget Tree — Blueprint of a Car class Lamborghini extends StatelessWidget { const Lamborigini({super.key}); @override Widget build(BuildContext context) { return Car( paint: RedPaint(), engine: 4LV8Engine(), wheel: RimsAltaneroShinyBlack(), carbon : UpperExteriorCarbon(), ... ); } } To help understand the three tree structures of widgets, let’s use the analogy of building a Lamborghini. To build a car, various components such as color, engine, etc., need to be determined. In the above code, we’re passing necessary options to the Car class within the build method.
This process is similar to creating a blueprint for the car, defining how the car’s components are structured and shaped. StatelessWidget or StatefulWidget always override the build method and return a widget inside. These codes are returned as a widget tree and internally create the necessary 'element' through createElement().
Key Point! The code inside the build method is returned as a 'widget tree' and creates an 'element tree'.
Element Tree — Car Parts and Engineers The element tree generated from the widget tree is comprised of elements that are part of widgets and are responsible for managing widget lifecycle and state changes. While the widget tree contains structural information about the code written by developers, the element tree consists of pieces of widgets created based on the widget tree.
If the widget tree is likened to a blueprint of a car, the element in the element tree can be compared to both the car parts and the engineer managing those parts. Just as a car engineer arranges and manages necessary parts according to the blueprint, the element tree creates elements that are parts of the UI needed for the final rendering of widgets and communicates any changes to the render tree as necessary. Now, let's take a closer look at the characteristics of elements.
Widgets are Immutable, Elements are Mutable All Flutter widgets are immutable, meaning their content cannot be modified during runtime. This is similar to a car not being able to suddenly transform into a motorcycle. However, elements are mutable, allowing widgets to be changed as needed. In other words, elements can be removed and replaced with new elements.
Role of BuildContext The BuildContext, which we always pass as an argument when executing the build method in StatelessWidget or StatefulWidget, is used when direct manipulation or access to the Element object is required. It also indicates where the Element created from the widget tree is positioned in the tree. It's like an engineer (BuildContext) examining the blueprint (Widget Tree) to determine where the necessary parts (Element) are and arranging them accordingly.
showDialog<void>( context: context, builder: (BuildContext context) { return AlertDialog(...); }, ); Similarly, when displaying a popup using methods like showDialog, we always need to pass the BuildContext because we need to know which widget (screen) in the composed tree the dialog should appear on.
Key Point! - The element tree manages the widget’s lifecycle and communicates changes to the render tree as needed. - BuildContext is used to determine the position of widgets currently displayed on the screen and plays an important role in manipulating or accessing elements. -BuildContext is also considered as an Element.
Rendering Tree — Car Manufacturing, Manufactured Car
Once the necessary elements are created, the widget finally creates a Render Tree. It's used to handle the actual rendering via the widget's createRenderObject method, which creates a RenderObject, an object that manages the widget's size and layout information. During this process, the RenderObjectElement, created from the Element Tree, becomes directly involved.
The rendering tree can be likened to the manufacturing of a car using car parts. It completes the car using the components manufactured from the Element Tree.
In the rendering tree, two main methods, layout and paint, are used to actually render the widgets we see. During the layout phase, parent nodes pass constraints to child nodes, and at the lowest level, the final size information is passed back up to determine where and how widgets should be drawn. Then, the paint operation is performed, passing the work to the GPU thread to finally complete the widgets.
Key Point!
What If it Wasn’t Composed of Three Widget Trees?
Now that you have some understanding of the architecture of the widget tree, you can clearly understand the reason why widgets are composed of three widget trees. If you were to replace a wheel on a car, you wouldn’t need to rebuild the entire car from scratch. You’d simply replace the existing wheel with a new one. Flutter operates on a similar principle. When parts of a rendered widget need to change based on state, the corresponding element detects this and communicates the changes to the render tree, allowing only the necessary parts to be re-rendered.
However, if Flutter’s widget tree were composed of only one tree, even widgets that didn’t need to change based on state would be redrawn, leading to inefficiencies. It would be like building a new car every time you change a wheel.
In summary, the fundamental reason Flutter’s widgets are composed of three tree structures is to efficiently re-render only the necessary parts of the screen when changes are needed based on state.
1. Separating Widget Trees and Accessing Render Objects via BuildContext Now, let’s go through step by step how to derive the size of widgets with variable sizes depending on their child widgets.
As mentioned earlier, the rendered size of a widget exists in the render tree within a RenderObject, and to access this object, we need a BuildContext. Therefore, the formula is established that with just a BuildContext, we can access the rendered size of a widget.
Size size = context.size!; With this code, we can check the rendered size of a widget accessible via the BuildContext.
However, there is one problem in the current example code’s widget tree.
We want to obtain the rendered size of the Column widget through its associated RenderObject. However, the BuildContext that can access the RenderObject is located higher up at the CaseInfoScreen level. This means that if we proceed like this, we’ll end up measuring not only the size of the Column but also the size of the AppBar, which is a child widget of the Scaffold.
To solve this issue, there are various methods, but the simplest approach is to separate the widget whose size you want to measure, like a StatelessWidget or StatefulWidget. By doing this, a new sub-widget tree is created where the BuildContext is directly accessible through the build(BuildContext context) method of the separated widget. This is commonly referred to as "separating the BuildContext."
class ContentView extends StatefulWidget { const ContentView({Key? key});
class _ContentViewState extends State<ContentView> { double renderedHeight; // <-- Rendered height of the [ContentView] widget
@override void initState() { super.initState(); /// Accessing the rendered size of the widget via [BuildContext] /// and assigning it to the renderedHeight variable renderedHeight = context.size?.height ?? 0; }
@override Widget build(BuildContext context) { return Column( crossAxisAlignment: CrossAxisAlignment.start, children: [ Text( 'Height : ${renderedHeight}', // <- Displaying the rendered height in a Text widget ), ... ], ); } } Now, as shown in the above code, by separating the widget we want to measure into a separate StatefulWidget, we can obtain the rendered height of the desired widget by accessing the size value through the BuildContext within the new build method.
NOTE If you don’t separate it into a separate widget, using GlobalKey to find the RenderObject can also be a good approach.
2. Obtaining Size When Widget Rendering is Complete However, running the above code will result in the following runtime error:
======== Exception caught by widgets library ======================================================= The following assertion was thrown building Builder(dirty): Cannot get size during build. Why does this error occur?
As explained earlier, in the render tree, the layout method is responsible for passing constraints from parent nodes to child nodes and determining the final size information from the bottom node to the top node to decide where and how the widget should be drawn. The problem arises because an attempt is made to access the size value before the layout method is executed.
To address this issue, Flutter provides the addPostFrameCallback method. This method is used to register a callback that is invoked after the widget has been painted on the screen. In other words, it's a callback method that is executed after the rendering tree operations are completed.
WidgetsBinding.instance!.addPostFrameCallback((_) { setState(() { renderedHeight = context.size!.height; }); }); Inside the addPostFrameCallback callback method, as shown in the code above, you can assign the rendering height of the widget accessed through the BuildContext to the renderedHeight variable. This way, by accessing the rendering size value through the context only after the widget has been rendered, you can assign a value to the renderedHeight variable without encountering any errors.
3. Detecting and Obtaining Size When Widget Size Dynamically Changes While most of the requirements have been met, there’s one remaining functionality: detecting when the widget’s size changes due to user interaction and displaying the updated size on the screen.
When the ExpansionListTile widget on the screen is clicked, the widget expands, changing its size. However, the current code does not detect the size change and update the value.
To address this, we can use a widget called NotificationListener, which is useful for detecting and handling notifications (such as size changes, scrolling, gestures, etc.) that occur within the widget tree.
NotificationListener( onNotification: (_) { if(renderedHeight != context.size!.height) { setState(() { renderedHeight = context.size!.height; log('height : $renderedHeight'); }); } return true; }, child: Column(...) ) Wrap the existing Column widget with a NotificationListener widget. Inside the onNotification callback, add logic to detect the size change of the widget and update its size accordingly. In the provided code, the setState method is used to update the changed size.
NOTE Since NotificationListener can receive events like scrolling or touch gestures, which could lead to unnecessary updates if the size remains the same, the update logic is placed within the condition if(renderedHeight != context.size!.height).
By adding this code, the widget’s height changes are detected, and the size is updated accordingly. However, a new issue arises: continuous execution of the onNotification callback whenever the widget's size changes.
[log] height : 367.0 [log] height : 367.0 [log] height : 369.3854225873947 [log] height : 375.8518112897873 [log] height : 385.81551444530487 [log] height : 435.25 [log] height : 413.13516367971897 [log] height : 430.28125 [log] height : 448.9247215986252 [log] height : 469.3435592651367 [log] height : 491.38857555389404 [log] height : 551.9744523763657 [log] height : 540.0271100997925 [log] height : 567.0 The onNotification callback is repeatedly executed whenever the widget's size changes, leading to multiple unnecessary calls to the setState method. This could potentially impact performance and needs to be addressed.
To solve this issue, we can implement a debouncer logic. A debouncer delays consecutive calls for a certain period and executes the action only after the last call.
/// Deboucner Module class Debouncer { final Duration delay; Timer? _timer;
Widget build(BuildContext context) { return NotificationListener( onNotification: (_) { debouncer.run(() { // <-- Apply Debouncer Callback if(renderedHeight != context.size!.height) { setState(() { renderedHeight = context.size!.height; log('height : $renderedHeight'); }); } }); return true; }, child: Column(...) ... } In the provided code, a Debouncer class is declared, and within the onNotification callback, the debouncer is used to delay consecutive calls to the setState method. This ensures that the setState method is only called after the widget's size has stopped changing, optimizing performance.
4. Modularizing for Ease of Use Since the functionality of obtaining the rendering size of a variable widget can be applied to different screens or multiple projects, modularizing it for easy use is a good idea.
Therefore, I created a custom widget called MeasureSizeBuilder. This widget encompasses all the logic discussed earlier, and it is designed to allow access to the rendering size of the specified widget through the builder property, which returns the widget whose size needs to be measured. The size can be accessed through the size property within the builder.
Now, let’s take a look at the completed example code.
Finally, we have fulfilled all the requirements we set out to achieve 🎉
I have published the measure_size_builder package used in the example. For those interested in this feature or modularized code, please refer to the following link.
measure_size_builder | Flutter package Simplest way to get dynamic size of widget pub.dev
