> I guess the question is "why generate a QR code rather than just connect?"

Exactly. Why not use the API directly? Why encode a string into an image for the sole purpose of displaying that image to then basically do a screenshot to then read from the screen, to run an algorithm on that to detect & decode to get the string you already had after doing the OCR on the wifi credentials.

Btw: i didn't even open the link. My comment was based solely on this post. Now i see that it's an expo / react project... so the amount of wasteful energy spent is even higher.

I have looked at the code. This here stands out to me:

>>> if (Platform.OS === "android") { // On Android, we use system built-in WiFi connection dialog via qr code return false; } else if (Platform.OS === "ios") { // On iOS, we need to use a different method await WiFiManager.connectToProtectedSSIDPrefix( ssid, password, !isWPA // iOS only ); <<<

Aside from the fact that the comments indeed look very llm-esque to me, the way they're phrased also implies that the ios way of directly connecting is the "different" method. Like that one is the workaround of both approaches– and the wasteful way is the desired one– for no apparent reason.

Thanks for looking into the code! Initially, I wanted the app to work consistently on both platforms, but I found that the WiFi connection APIs behave very differently. In the end, I focused mainly on Android to ensure it matched my intended use case.

You’re right about the LLM smell. I’ve been using cursor composer and find it very handy at times!

I added more explanation here https://news.ycombinator.com/item?id=43384670

I know. The simple answer is that Android doesn’t allow apps to directly manage WiFi connections. I’ve provided a more detailed explanation here https://news.ycombinator.com/item?id=43384670