Welcome!
This is the community forum for my apps Pythonista and Editorial.
For individual support questions, you can also send an email. If you have a very short question or just want to say hello — I'm @olemoritz on Twitter.
Can Pythonista enable/disable WiFi?
-
Since Apple did a bad thing in iOS 11, the user now has to go to settings, WiFi, then turn WiFi on or off. In iOS 10 and earlier, you could swipe up then enable/disable WiFi. Much easier.
I’d like to make a script that can do the same, without me having to go to settings to enable/disable. ( the same goes for Bluetooth).
Can I do this in Pythonista?
-
That's not possible due to app sandboxing.
-
I haven't installed iOS 11 yet - did the Wi-Fi switch get removed from the control center or something?
-
@dgelessus WiFi switch in control center, read this
-
@dgelessus said:
I haven't installed iOS 11 yet - did the Wi-Fi switch get removed from the control center or something?
Yes, the button in control center does NOT turn off wifi and bluetooth, it only disconnects the current session.
If you want to turn either off completely, you need to go to settings. -
Oh right, now I remember, I think I read about that before. Out of curiosity, in what situation do you need to physically turn off Wi-Fi (instead of just disconnecting) and airplane mode is not a solution?
I can sort of understand the reason behind it - in many cases when I turn off Wi-Fi specifically, it's because I want to temporarily disconnect from my current Wi-Fi network, not because I need to turn off the antenna. I'm guessing that at least it results in faster reconnection once you turn Wi-Fi on again.
To be clear, I wouldn't consider the iOS 11 behavior better - ideally, both options should be easily available, maybe "disconnect" with a short tap and "antenna off" with a long tap. I'm just trying to think about what Apple's reasoning behind this might have been.
-
@dgelessus said:
Out of curiosity, in what situation do you need to physically turn off Wi-Fi (instead of just disconnecting) and airplane mode is not a solution?
Turn on Airplane Mode, Wifi & BT are Off.
Leave Airplane Mode on, turn on Wifi. Wifi comes on, Airplane mode is still on.
This doesn't make sense. You can't be in airplane mode if you're transmitting.
So, I never use Airplane Mode.I was hoping to put a script shortcut on my homescreen so that i can enable and disable Wifi, without having to go to settings. The Buttons in Control Center are useless.
I don't want wifi/BT on due to the battery drain (especially in ios 11), I want the radios off. -
Let me rephase this differently...
In Pythonista, can I write a script to move a slider in one of the GUIs in iOS, such as the Wifi Enable slider?
-
No, that is not possible. iOS apps are very strictly sandboxed, that sort of interaction is not allowed on iOS. (Which is great if you ask me, I prefer it if programs are not allowed to randomly mess with other things running on my device.) Interaction with other apps is quite limited, you can't do much automatically other than starting apps via URL schemes, and passing around files. And any interaction with iOS itself has to go through the APIs and frameworks provided by Apple, and there are none for controlling device functions like Wi-Fi and Bluetooth (which is also a good decision if you ask me).
-
I agree somewhat.
So how is it that Apple allowed Pythonista to slip through their cracks?
I'm actually amazed that it exists and doesn't get pulled -
That's what everyone was thinking a few years ago, especially since downloading and executing arbitrary code was forbidden by the App Store guidelines :) Thankfully last year Apple changed its stance towards coding apps on iOS, running user-provided code is now officially allowed, and Pythonista updates no longer have a 50% chance of being rejected for strange reasons. (I hope it stays that way - you never know with Apple...)
This is why Pythonista 3.2 added iCloud sync and re-added file importing. In Pythonista 1.4 (my first Pythonista version!) you could actually import files via "Open In" from other apps, but then Apple forced omz to remove that, since it allowed importing code. Later the share sheet was added (in 2.0 I believe), which had a built-in "Import" option for everything but .py files. Obviously there were lots of ways to work around that limitation, but apparently it was enough to make Apple happy.
-
@cappy and @dgelessus Hi, interesting question. I am also ok in not having applications or scripts that can modify the phone settings; maybe some not dangerous settings parameters could be enabled/disabled with simple scripts, foe example like wifi or bluetooth or cellular data. Obviously excluding settings like Touch ID, Privacy, iTunes Store and App Store, etc.. that are very personal. But only Apple can decide.
It would be enough for me if Pythonista could open the Setting page where I find the setting I want to change manually (and that I change frequently), because sometimes surfing into the iphone Setting menu and its many submenus is not so pleasant :-). As an example , if I want to access to Setting->General->VPN, I'd like to open the VPN Setting page (not changing or adding parameters that I want to perform only manually) istantly with Pythonista in order to change/add what I want in little time.
Does anyone know if ios setting submenu pages can be opened with Pythonista (not change the parameters) in the same way Pythonista can open installed applications or web pages?
Thank you
Regards -
-
@zrzka Hi, thank you, I will read something about it. But why do you say that it is not reliable to open programmatically setting pages if scripts can't modify setting parameters?
Regards -
@Matteo it has nothing to do with the fact that script can / can not modify settings. It's not reliable, because it should be treated as private API, can be modified during any iOS release (and it is, check the difference for VPN & iOS < 10, iOS > 10), tried some of these and they don't work as expected, ... Again, there are some ways how to open specific Settings.app page, but even if it works for you, you can't rely on it.
-
@zrzka Hi, thank you for explanation: I understand now that the problem could be to use some scripts that open some setting pages/submenus in a version x of ios and these scripts could not work in a version y of ios if api are changed from x to y. I am more relaxed now knowing that the problem is just this and not related to obscure changes of ios settings by scripts .
Regards