For starters you might break all of the code starting with the if statements into a new method. Then, store your object in a variable.

  # after start method:
       def update_menu(self):
            #if....

    m=RecycleMenu()
    
    
Then in your actions, call m.update_menus()

@cvp, sorry, I did not actually try it -- per the release notes there is supposed to be appex.get_ui.image().

didn't actually look -- but

Your start Navview function is called only once -- before your button actions have been called. So of course, the booleans are false.

If you want your button actions to do something, they will need to call out to the function that does something.

Doesn't appex provide a get_ui_image function? That will be much lighter weight than going through PIL and back.

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 photos assets, one should be using .get_ui_image instead of .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_image ran 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)

If you are talking about a main view and a pop up menu, you can present the second view as a sheet (instead of fullscreen).

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.