Again, it depends on what you mean by reasonably secure.
Are you worried about someone with access to your unlocked device? If so, there are few secure options (without implementing your own password, or keychain set_master_password), because anything that your app can access can also be accessed by others.
If that's not your concern, then many options are equally secure:
File local to your device
Something stored in your Keychain
(Since files are encrypted on all newer devices)
File stored in iCloud also seem reasonably secure, assuming your iCloud account is secure. If you are someone who is likely to succumb to a phishing attack, then maybe that's not a good idea.
Though you could also encrypt the file with a password for storage in iCloud, if you are really paranoid.
Ssh keys shouldn't change frequently, so using ftp or samba or a temporary web page or temporary git server would all work to get files into the device one time. Also, google api keys can usually be downloaded directly from the developer dashboard or whatever it is called these days, directly to each device.
@ccc I will post something in a few days when I clean some things up. I created an endless loop calling a function that wrote a large amount of data to a BytesIO. No crash. I downloaded objgraph, and this never showed any increase in BytesIO objects.
My attempt at writing an image viewer that uses pil2ui failed after 4 photos (with or without del bIO) because of apparently a bad image in my
photos(at least one that PIL choked on). I will say that, in the case of displaying
photosassets, one should be using
.get_image. That avoids any round trip through PIL, which is probably where any leaks or bugs occur. A simple image viewer using
get_ui_imageran for longer than I cared to wait without a crash.
Creating ui.Images also requires some care, because these might not get gc'd automatically. I believe the best practice is to include a
with objc_util.autoreleasepool():when many UIImages are created -- though I haven't had time to explore whether setting the imageview image causes the old image to get leaked (in which case it would be necessary to manually handle the deallocation of the UIImage object)
Due to some bugs in how views get closed in pythonista, you cannot easily re-present a view that was already presented. (There might be some caveats, I forget)
So I'm guessing that you can display view B, but when trying to show view A again, you get the failure.
One approach is to use a NavigationView, which will give you the sliding animation. Another approach is to have both views as subviews to a root view, and either add/remove from the root, or hide/unhide, or send_to_front, etc.
Hmm, not sure I agree.
bIO is defined within the scope of the function def. When the function returns, bIO falls out of scope. As we have created no other references to bIO, it's reference count should then be 0 and it should then be immediately deallocated.
Does defining bIO in a context manager create a reference cycle? I don't think so.
The context manager probably has a reference to bIO, but bIO doesn't have a reference to the context manager. As long as we don't create a reference cycle, the periodic gc is not needed to resolve . It might be different if you had this within a for loop, instead of a function (though I don't think so).
I suppose it would be easy to use something like the objgraph module to check either way.
@alexsunnyx123 pythonista 1.4??? I don't think anyone here runs 1.4 anymore. Pythonista 2.0 was a free update, assuming you have iOS 8 at least, though I guess if you have an iPad 2.0 or something you might be stuck (also, since 2.0 is no longer offered, Apple's stupid policies if not letting you install the last supported version of an app might also mean you are out of luck).
I forget what the interface was like on 1.4 honestly -- the problem you describe doesn't ring a bell.
You might try importing the script in the console to see if you can get the syntax error displayed. Or use the runpy module.