vedderb/vesc_tool

Package Store non-functional on iOS

NicoAleman opened this issue · 9 comments

As of the currently released iOS app version, the Package Store is still completely non-functional on iOS VESC Tool, with the Packages tab showing no available packages, and the Update Archive button having no effect. Currently, these users are forced to connect through a different platform (Android, PC, Mac, Linux) in order to install packages from the vesc_pkg repo.

It's been brought up in Discord and in many other discussions, but I noticed there was not yet an Issue posted for this, despite it being fairly crucial (notably for the rapidly growing VESC-based Onewheel scene, which rely on this feature), so I made sure to post here just so it doesn't slip by unnoticed.

I forget, what was the consensus on the vesc discord? Was this an apple issue blocking some feature or just some sort of api thing that needed to be worked around? @Jfriesen222 might have input as the ios app maintainer?

I wasn't able to find any more detailed discussion on it myself when searching the discord, but Ben mentioned he brought it up to Jeff again a few days ago and that he said he'd look into it 👍

I’m pretty sure it’s just some Apple permissions thing or some such but still need to investigate. Been planning to do it for months now and it keeps getting bumped down the list. Hopefully nothing too complicated.

OK cool I did some quick digging and found the issue I think. Apples file saving and permissions stuff are a bit wonky so I am seeing that when it trys to call CodeLoader::reloadPackageArchive() the check for file.exists() is returning false. Probably just defining a different path for iOS or some such will fix it I will keep tinkering

5C33CE40-2434-4164-81B6-31C77F0A49CB

Ok, got it working now but need to decide how to proceed with Vedder before merging changes. There were two changes I had to make. iOS doesn’t allow writing to local app data so I had to change the write location to documents instead of appdata and then I had to add a check to create the file since when first launched it won’t exist.

The question is if I change the location only for iOS by performing a platform check or if we just store the archive in default documents location on all platforms. My guess is just iOS using the documents variant is probably the right move since having a weird .rcc file pop up in my documents file on desktop seems a bit wonky.

Nice that you found the problem! I think the firmware archive (that now is available on mobile too) will have the same problem, so it would be good to make the same fix there.

I think it is best to make the fix specific to ios as you don't have permissions on android to write there until you have asked to user to give you permanent permission on the first write. Also, as you said, it is best to not have a weird rcc-file show up there and confuse users.

Good point I am almost finished with the changes now but I will add in the firmware archive as you suggest.

Found a better way to keep using app data instead and keep those files hidden on iOS. I guess a mkpath call is needed. Thanks stackoverflow.

https://stackoverflow.com/questions/45153658/application-private-directory-on-ios-with-access-to-creation-of-files-from-qt-ap

Think we can close this one now.