[endofreach]

Spending compute to encode a string just to decode it with more compute, because the whole purpose was to print the decoded string seems... a bit wasteful at best. I don't understand.

Sure, the excuse here might be that the generated QR code can be used to connect other devices as well, but if that was the reason, it would have been mentioned i guess. It seems like the QR code is only generated & displayed to be read from screen... It seems to me– a judgmental moron– almost as if chatgpt came up with this...

Sorry if this sounds harsh, most likely i am wrong and don't get something here. And usually i wouldn't have commented because my comment doesn't bring something positive to the table... But i really so much don't get it here, i had to comment in the hope of being enlightened why this is smart and not the opposite...

But either way: if it solves an issue for you the way you want it to: perfect. Congratulations on finishing an app as you imagined it. That is really great, regardless of opinions like mine.

[ylj]

I understand your point and initially wanted to avoid the overhead of generating and scanning a QR code just to connect to WiFi. The reason for this approach is that the Android API doesn’t allow non-system or non-rooted apps to directly manage WiFi connections. In other words, it’s not possible to create a simple app that directly connects to WiFi with known network name and password.

Generating and scanning a QR code is a workaround to minimize steps—avoiding the need to manually select the network from a long list and type the password.

Android does provide a WiFi suggestion API [1], but it has several limitations and doesn’t behave quite as expected. I initially tried using that, but eventually settled on the QR code solution.

Hope this clarifies things!

[1] https://developer.android.com/develop/connectivity/wifi/wifi...

[jjayj]

> Android does provide a WiFi suggestion API [1], but it has several limitations and doesn’t behave quite as expected.

Can you expand on this? I read the linked doc, and it looked like a separate API should be used to used to "persist a network connection" (my words), but as someone with no Android dev experience there don't seem to be any obvious limitations.

You did mention in another reply that only certain root apps can do [what we expect]. Is there a link where I can learn more about that?

[jjayj]

> You did mention in another reply that only certain root apps can do [what we expect]. Is there a link where I can learn more about that?

Actually in the same comment I replied to, but there doesn't seem to be a way to edit posts in my mobile client.

[endofreach]

Thanks, it does clarify. I thought one might at least be able to pretend to have a QR code parsed result string (eg wifi:T:WPA;S:MySSID;P:mypassword;;), to trigger the systems API. I didn't know that android now has these limitations.

I was sure, a third party QR code scanner should be able to read wifi qr codes and trigger a connection prompt as well. But apparently the it can't. This is dumb, but then you're app is not.

Hope i didn't bring too much negativity.

[ylj]

Not at all. These are great questions I asked myself too!

[wolrah]

I think the intended purpose are cases like hotels where they really should be offering QR codes but instead just display text on the TV. If you control the display device then definitely just use the QR code but the problem this solves is when someone else has made bad choices.

[jjayj]

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

> You can instantly connect using Google Circle to Search or Google Lens.

Is there something special about the Google integrations that other apps can't achieve (I'm not an Android developer)?

[endofreach]

> 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.

[ylj]

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

[ylj]

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

[ylj]

Yes, exactly. If WiFi QR codes were provided in the first place, we could just use the built-in QR code reader to instantly connect. This app targets situations where WiFi credentials are displayed only as printed text.