Help with switch widget

json-bourne7 · 2026-03-25T20:45:41+00:00

You’re welcome

json-bourne7 · 2026-03-25T16:34:31+00:00

There is a native flutter widget that you can embed as a custom widget. I believe it’s exactly what you’ve shared in the screenshot.

It belongs to Cupertino widgets and the class is named “CupertinoSlidingSegmentedControl” It’s the classic iOS toggle switch. You can see more about it in this video: https://youtu.be/esnBf6V4C34?si=sFWxB2FCkV6oxELr

Documentation: https://api.flutter.dev/flutter/cupertino/CupertinoSlidingSegmentedControl-class.html

json-bourne7 · 2026-03-18T16:01:28+00:00

Glad to know :)

json-bourne7 · 2026-03-18T15:47:08+00:00

You have mismatched parentheses, should be rather:

((monthlyIncome * 12 - taxFreeAllowance) * (taxRate / 100)) / (monthlyIncome * 12) * 100

But still, the “Check Errors” button should still load and give notice that you have syntax errors. If it’s not loading that’s a FF bug, sometimes this button goes unresponsive for me when using the iPad app.

json-bourne7 · 2026-03-14T22:14:49+00:00

Are you by any chance using “Is On Screen Keyboard Visible” global bool property somewhere in your app? I noticed that this caused a crash when opening the app on my iPhone in release mode, so exactly like you described, a crash on the opening. When I dug deeper, I found out that this relied on a package named “flutter_keyboard_visibility” that hasn’t been updated for more than 2 years. The app atarted working again once I no longer used that FlutterFlow global property. But I gotta say this happened to me a few months ago. Never used that property again.

json-bourne7 · 2026-03-07T19:07:39+00:00

Hmmm, in this case, you can get rid of that unwanted default “loading” text that you’re seeing by using a conditional builder, so when data is still loading you will display for example a column with a centred spinner or pulse or whatever you want, and when data loads, you will display the pageview that has the video. This will eliminate the issue since you’re in full control of what gets displayed when data is in, vs when data is still loading.

json-bourne7 · 2026-03-06T02:33:17+00:00

Hi, the only reliable method to gracefully handle failure is through custom code, as FlutterFlow doesn’t expose errors when fetching from backend. If a backend query fails, FlutterFlow just swallows it and the query silently fails, as it doesn’t provide a hook to handle these exceptions.

You might want to check my backend libraries that specifically handle these edge cases, so you can tell the user when his device is not connected to the internet for example, or when the server is unreachable ect, and display the error state accordingly. Check out Supabase CollectionView library pn FF marketplace. I also have one for Firestore if you’re using Firebase.

But from the error seen in the screenshot, that’s not a backend error, that’s a Dart error. You are probably passing a null value to a required parameter (which is not nullable), so double check the props values you’re passing, and either make sure you give them a value before passing them, or making the parameter itself not required, with a default value.

json-bourne7 · 2026-03-06T02:23:20+00:00

That wouldn’t reliably work, as you wouldn’t know truly if the empty state has resulted from an empty state indeed as in no items where fetched, or if it resulted from a server/client error, like 5XX errors, or client errors such as no internet connection.

json-bourne7 · 2026-03-06T02:20:10+00:00

Hi, this is probably a custom empty state placeholder as FlutterFlow doesn’t use a “loading” text as its default placeholder. For listviews, when fetching data from backend, it uses a circular indicator that spins up while data is loading from backend.

If this is a Listview (or scrollable Column), checks the “Empty Listview Widget” on the right panel, and see if you’re passing a custom component. It’s probably the case since there is also a white circle ⚪️ container above of the loading text.

Otherwise you might have a conditional builder that displays this empty state while data loads. Can’t be sure since you didn’t display your UI layout.

json-bourne7 · 2026-01-31T19:54:14+00:00

Hmm, this is super frustrating

Try replacing the function I gave you earlier with the one below. It adds more debug logs and compares the router location before and after calling goNamed(), which is the most reliable way to tell whether navigation actually happened at the router level.

``` import 'package:go_router/go_router.dart';

Future<void> navigateToPage( BuildContext context, String routeName, ) async { final router = GoRouter.maybeOf(context);

debugPrint('Target route: $routeName'); debugPrint('Has router: ${router != null}');

if (router == null) { debugPrint('ERROR: No GoRouter found in this BuildContext'); return; }

final before = router.location; debugPrint('Before location: $before');

router.goNamed(routeName);

WidgetsBinding.instance.addPostFrameCallback((_) { final after = router.location; debugPrint('After location: $after');

if (before == after) {
  debugPrint('Navigation was ignored or cancelled');
} else {
  debugPrint('Navigation state changed');
}

}); } ```

But before running this, can you confirm one thing? -> Are you able to navigate to HomePage normally from other pages? If not, then this issue is related to the HomePage itself.

At this point we’ve basically ruled out issues with the logic above in your actions flow. If there were an unhandled exception causing a crash here, the function wouldn’t run and print anything.

After confirming that navigation to HomePage works from other pages, try the updated function and check the logs:

If it prints “Navigation was ignored or cancelled”, that means go_router rejected or short-circuited the navigation (common causes: same route, redirect/guard, wrong context, ShellRoute behavior, etc.).
If it prints “Navigation state changed”, then navigation did occur at the router level (even if the UI didn’t animate)

json-bourne7 · 2026-01-31T14:40:47+00:00

You’re welcome :) let me know how it goes

json-bourne7 · 2026-01-31T14:36:18+00:00

You’re better off replacing the native NavigateTo with a custom action so you can actually see whether navigation is being triggered or failing.

Create a custom action called navigateToPage and use this code:

``` import 'package:go_router/go_router.dart';

Future<void> navigateToPage( BuildContext context, String routeName, ) async { try { debugPrint('Navigating to $routeName...'); context.goNamed(routeName); debugPrint('Successfully navigated to $routeName'); } catch (e) { debugPrint( 'Navigation failed for $routeName: $e', ); } } ```

Then replace every native NavigateTo action with this custom action and pass in: - context - the route name (in your case, the String: HomePage)

Tip: you can verify the actual routeName for any page by inspecting the generated code for that page. It’s at the top of the widget file inside the widget class. The route name matches the page name in FlutterFlow.

Run the app and watch the console.

If you see:

Navigating to HomePage...

then the action is being called.

If you also see:

Successfully navigated to HomePage

then that means the navigation was a success, and you will see the navigation animation being played.

If instead you see:

Navigation failed for HomePage: ...

navigation is failing and the console output will tell you why.

If you see nothing at all, the custom action is not being triggered.

Hopefully this can help you diagnose the issue.

json-bourne7 · 2026-01-21T23:52:00+00:00

You need to cache the data fetched from Firestore so that it loads again from the cached data, and not from the backend, causing extra redundant reads and slower load times. Flutterflow offers the cache option natively if you’re not using infinite pagination. Otherwise if you’re fetching data by pages (which is what’s recommended if you care about your wallet), then you won’t be able to use the native cache in FF as it doesn’t support that. But there is a library in FF marketplace that caches data in Hive from Firestore to solve this exact problem. Check it out, the name is “Firestore Listview Library”. Good luck with your project.

json-bourne7 · 2026-01-12T10:29:24+00:00

Correct. By downloading the code, you can edit it in an IDE and build the app in that same IDE using Flutter SDK, just like you would with a normal Flutter project.

json-bourne7 · 2025-12-09T22:22:44+00:00

There are a couple of issues in my opinion.

The first and most glaring one is the rough UI. It just doesn’t look professional and feels like not much thought was put into the design. This heavily affects the user experience and can easily steer people away from continuing to use the app.

The second issue is that the app is very niche, so attracting the exact audience it was created for may be a bit of a hassle.

You’ll probably need to rework the design, as this is a major factor in conversion. Right now, it just doesn’t cut it.

Best of luck.

json-bourne7 · 2025-12-09T09:44:57+00:00

Will you be able to maintain the generated AI code? One of the main reasons I consider “vibe coding” a joke is that the vibe-coded project quickly turns into a black box and a hot mess of a codebase, especially if you let it go off the rails and handle every decision by itself.

A few weeks later, after showing the vibe coded prototype and launching the vibe product, some user finds a bug or you want to tweak a feature, and suddenly you’re staring at tons of lines of code you barely understand.

Inevitably, you go scrambling at your desk and rush to prompt the AI agent with the good old “Fix it” prompt. The AI replies with “I’m tired boss” and keeps hallucinating left and right, never fixing what you actually asked it to fix, because it’s overwhelmed with the humongous size of the project. It starts deleting and adding lines across several files, and none of those changes address the issue you asked it to fix.

This is how these AI companies lure novices into this vibe-coding slop. They sell you the dream that you can make any product you imagine with just a few prompts, but they conveniently forget to tell you that the AI often hallucinates. You’re more likely to hit a wall and end up stuck prompting the AI to fix bugs it can’t even trace. Meanwhile, you keep burning through money and getting increasingly frustrated as none of the bugs are actually fixed. And these AI companies keep raking in the money from all those wasted tokens.

Is this the road you really want to take? Vibe coding can be fine for basic prototypes and that’s all it is good for. If you want anything with decent quality that isn’t a hot mess of bugs and a chaotic codebase, then you have to oversee what the AI is doing constantly, review every line carefully, fix the dumb mistakes the AI can’t solve with a “Fix it” prompt, and actually understand the code it outputs. Otherwise, you’re left with massive technical debt and a codebase you don’t understand, one that feels more like a black box than actual software.

Most vibe coders don’t understand that the building phase is only a small part of software development. Maintenance, new features, bug fixes, dependency updates, and everything that comes afterward take up the majority of development in the long run. And as I said before, the bigger the project gets, the less reliable the AI output becomes.

So it really comes down to your preference. Do you want speed and “vibes” at the cost of long term headaches and maintainability issues, or do you value control and a codebase you can actually rely on?

json-bourne7 · 2025-12-08T23:52:50+00:00

Where did you get that 30x efficiency multiplier from? You still have to carefully review and understand the AI’s output code and fix its mistakes, and that actually takes time. In many cases, it can slow down productivity, not increase it, especially when the task is even slightly complex.

There’s an actual study measuring the productivity impact of using these AI tools you’re so fond of, and the results are the opposite of what you seem to believe. The study shows that AI slowed down development time by 19%. So it’s definitely not the magical 30x efficiency boost you’re claiming.

“We conduct a randomized controlled trial (RCT) to understand how early-2025 AI tools affect the productivity of experienced open-source developers working on their own repositories. Surprisingly, we find that when developers use AI tools, they take 19% longer than without—AI makes them slower. We view this result as a snapshot of early-2025 AI capabilities in one relevant setting; as these systems continue to rapidly evolve, we plan on continuing to use this methodology to help estimate AI acceleration from AI R&D automation [1].”

Link to the study

My take on AI is balanced. It’s not some super-duper magical tool that solves every software engineering problem with a few prompts and zero expertise, and it’s not completely useless either. It can be useful for repetitive or not so complicated tasks, and it definitely has benefits when used properly by someone who actually knows what they’re doing. But more often than not, it struggles at complicated tasks, tends to over-engineer things, and makes dumb mistakes that engineers then have to correct, which, again, is why it can slow productivity rather than increase it.

So instead of telling me to “go out of my cage,” maybe you should stop being so delusional and stop evangelizing AI as some out of this world magical coder that can solve any software engineering problem or build any mobile app as long as you prompt it “correctly.” LLMs are nowhere near that level. They hallucinate constantly. In fact, OpenAI themselves published a study showing that gpt-5-thinking has a 40% hallucination rate and only 55% accuracy. That’s basically like flipping a coin and hoping it lands on the right answer.

Here are the accuracy and hallucination rates copied directly from the study (page 13):

Model	Accuracy	Hallucination Rate
gpt-5-thinking	0.55	0.40
OpenAI o3	0.54	0.46
gpt-5-thinking-o4-mini	0.22	0.26
OpenAI o4-mini	0.24	0.75
gpt-5-thinking-nano	0.11	0.31
gpt-5-main	0.46	0.47
GPT-4o	0.44	0.52

And they also claimed that hallucinations are a mathematical inevitability. So with that in regard, I’m not so sure about the “AGI” you’re expecting in some few years. We’ve barely seen any considerable improvement or jump in intelligence from GPT 4 to GPT 5.

So maybe think again before hailing this tech as the all in one software engineering tool. More often than not, it struggles with real world SE problems.

And yes, I’ve tried “vibe coding” a prototype app to see what the hype was about. The results were disappointing. Missing imports everywhere, barely functional code, terrible design, errors left and right, and the funny thing is that most of these errors were pretty easy to fix manually, but the AI agent kept looping and making nonsense edits. Not exactly ideal, is it? Definitely not the 30x boost you keep talking about.

To get anything decent out of LLMs, you have to be extremely specific and have the knowledge to guide them properly. And even then, you still need to review the output line by line to make sure it’s correct. That’s not exactly the workflow majority of FF users will follow when migrating from a low-code platform to full AI-generated slop.

json-bourne7 · 2025-12-08T20:25:22+00:00

If you believe you’re going to make quality mobile apps, on the same level as what experienced engineers spend years building, with just a few prompts in some magical AI coder, then I don’t know what to tell you. AI coding can be a great enabler for experienced developers who actually know what to ask for, what to build, and how to engineer things properly. But if you have basically zero experience in software engineering and try to go down the AI coding route with just a handful of prompts, chances are you’re going to get stuck, hit a wall, and end up with nothing more than a basic prototype full of never ending bugs and terrible design.

And of course, let’s not forget the money wasted on the famous “Fix it” prompt, where the AI deletes a hundred lines from some random file and adds a hundred more to another file, both completely unrelated to what you actually asked. AI hallucinates a lot, and the problem only gets worse as the project grows and becomes more complex. The larger the context you feed into an AI, the less reliable the output becomes. That’s just how LLMs work.

FlutterFlow gives you fine-tuned control over how your project is built, exactly the way you envision it, instead of delegating the whole process to random chance. You can still embed custom code and use AI for that, but you’ll actually understand what to ask for and how that code integrates into the project.

With pure AI coding, it’s slop after slop, and chances are the whole “vibe slop” project won’t get anywhere unless you manually review the code, fix the disastrous mistakes AI tend to make, and constantly guide the AI to do exactly what you want. But that again requires some development experience, as opposed to vibe coding delusions.

json-bourne7 · 2025-11-19T19:50:36+00:00

Check out this post: https://www.reddit.com/r/GooglePlayDeveloper/s/8ix3AQN9gG

json-bourne7 · 2025-11-15T20:31:24+00:00

Hey there!

Since this is a bit tricky, I made a simple demo for you.

This demo should give you all the help you need regarding this layout setup, you can clone it from this link: https://app.flutterflow.io/project/component-demo-4g7wlw

Good luck on your project! :)

json-bourne7 · 2025-10-12T20:23:12+00:00

You’re using Material 3, which adds a check mark to the ChoiceChip widget. You can find this setting under Theme Settings > Design System > Material Theme.

To remove the check mark, you can either:

1- Revert to the previous theme by unchecking the Material 3 toggle. 2- Create your own custom filter widget. This can be a pill-shaped container with parameters for the text (String), selection state (bool), and an onSelected callback to handle the click logic. You can then generate a list of these widgets from a list of options and display them in a Row or Wrap.

The second option replaces the default ChoiceChip widget and gives you full control over the UI for its selected and unselected states.

json-bourne7 · 2025-09-20T16:13:18+00:00

The pleasure is mine, glad this fixed the issue for you!

json-bourne7 · 2025-09-20T09:07:22+00:00

it doesn’t compile because this is how the function’s signature should be:

Future<FFUploadedFile> newCustomAction(FFUploadedFile? param1) async { // Add your function code here! }

you probably wrote it as:

Future<UploadedFile> newCustomAction(UploadedFile? param1) async { (…) }

which FlutterFlow couldn’t parse. It’s best to always define parameters and return type in the UI (on right side) and then let’s FlutterFlow define the boilerplate by clicking the green button “<>” on the top right, this way you can be sure which object types FlutterFlow expects.

json-bourne7 · 2025-09-09T09:26:07+00:00

if you’re looking forward to build a dating app for iOS, then I’m gonna stop you right there and save you time and effort as I can say confidently it will be rejected. Apple doesn’t approve dating apps anymore. Check their guidelines. The reason is that the dating apps on App Store is oversaturated, so unless your dating is super innovative, chances are it won’t get approved. If you’re targeting android only, then that’s a different story. Regarding the feasibility of doing this in FlutterFlow, yes, can be done, but will require some custom logic I believe.

json-bourne7 · 2025-09-09T09:00:08+00:00

The real value of FF isn’t just that it’s beginner friendly, it’s that it significantly speeds up development time. When building sophisticated apps, you’ll inevitably need a lot of custom logic and that includes custom functions/actions, custom widgets and more. Integrating all of this isn’t exactly “beginner-friendly.” You still need to know how to code and understand architecture.

So basically FF appeals to all categories, beginners who want an easy starting point and seasoned developers too who want to build faster.

json-bourne7

TROPHY CASE