Any updates on this?

from provenance.

from provenance.

Did Joe just describe Plex for ROMs? Badass.

from provenance.

Syncing saves states specifically would be a no-no in my opinion, for the reasons @JoeMatt described about version mismatching and the fact that save states are generally volatile between core versions.

But I can see a use case for syncing a battery saves (saves made by the native, in-game save mechanism), as they are non-volatile, even between emulator implementations. Syncing these would be convenient for playing on one device and then picking up that save on another.

However, I’m not placing this as a very high priority at all, there are much bigger fish to fry around controller mappings, game importer bugs, library UI, core implementations, etc.

from provenance.

I think the ability to sync battery saves would be excellent. Perhaps not means enabled by default, but there if you choose to use. To stop playing on the ATV, then pick-up where you left off on an iPad (on the plane) would be slick. That way we're not having to preface the use of save state syncing with "must be using the same version across all devices, etc".

from provenance.

@GoldenChaos There's another ticket around here where I discussed the idea of a REST API to do just that. The meta-data is there, hell we already even have a web server built in, though there are dumb simple REST frameworks in Swift out there.

We could expose an basic URL structure like,

Example REST URL points

• cores/
  {core_id, rom_types, version}

• cores/roms OR roms/core/core_id
  {list of ROM ids for that core in the database}

• roms/
  {list of all ROM IDs}

• roms/romid
  {OpenPVDB name, custom name, file_size, md5, artwork_id, is_favorite}

• roms/romid?get
  {download rom for id}

• artwork/artwork_id
  {width, height, size}

• artwork/artwork_id?get
  download the artwork

• battery/rom/rom_id
  {list of battery id saves for from id}

• battery/battery_id
  {size, save_date, associated rom_id}

• /battery/batter_id?get
  download the battery

-/search/?md5=,name=,isFavorite=1,core=
{return ROM id, or the whole ROM entry json, that matches the specified query}
Doesn't even have to support compound queries, expect maybe for isFavorite & which should be a simple SQL query to the Realm database

I think that's about all you'd need to fully expose the ROM database that you could find everything you'd want to make a remote ROM browser by system with Artwork and downloads.

Though as @jasarien said, there would need to be some additional stuff store in the Provenance database. Right now there's no way to associated a battery with a ROM except with matching the file name, and vice-verse is worse. A battery file can only be associated with a ROM by searching all the core rom storage folder for a ROM that matches file name, would be tediously slow to match all batteries to their ROM in one shot.

Call to action for anyone looking to get involved

Here's how

Keep reading

That being said, I think it wouldn't be all that difficult to start storing that linking data. One nice thing is that right now, if you delete a ROM and re-add it, the battery will still be there. If you depend on a database, and the database gets out off sync with what's really on the filesystem, you're stick with filename matching again.

ROMs to Cores and Artwork are already basically all in the REALM db already though. You could start with just that for remote ROM streaming / downloading. If get this far I'll gladly finish the Battery save changes.

If you make it somewhat well structured to not be tightly linked to our REALM database, that is put in some abstraction layer between REST requests and SQL queries, I could probably port it over to OpenEMU so OpenEMU could become a desktop host of ROMs, Batteries and ArtWork since we we basically 95% of the same meta data and cores.

Network discovery is incredibly easy with Bonjour. There are plenty of easy examples of making and finding services by service name that you get to make up yourself. It's a small bit of code to publish and search for network services with Bonjour.

Any one with moderate Swift skills could plug in an OpenSource REST client/server framework, make some changes to how Batteries are saved to add them to the Realm database tied to the ROM that made it, and then export that data in the Realm database with each end point.
The Swift based REST servers usually just have you supply and endpoint path and a function to handle calls that come into that path. A prototype could should be written in a weekend to at least get two Provenance apps talking to each other.

I encourage anyone who would like to take a crack at to just start looking at the Realm database we have now and see how it's structured do what you can from there. Link in an open source REST server, attach some calls backs to some end points to return some JSON data, hell make it up at first, and then load the URLs in a web browser and see the results. Once you see you can get that far pretty easily the rest won't be so bad.

The only difficult part is that we haven't actually used Swift in the project (yet) so Xcode will go about making changes to project to include bridging headers and such. If You want I can make a branch that has a dummy swift class that prints hello world at start, and has all the bridging stuff already tested and working.

from provenance.

As an added bounty, if someone does write something that I posted above, I'll make a raspberry PI disk image that has everything setup that you need to to access Bonjour services via VPN from an iOS device.

Meaning you could buy a cheap, ultra low power, older model raspberry pi and small SD card ($25 or so), copy an image I make onto the SD card, edit a text file with a username and password you want to use, plug it into your network and then be able to stream games, batteries etc from all over the world via your own VPN, assuming you have an Apple TV with Provenance, or I add it into OpenEMU, or I could write a tiny headless app using our existing code that could be a small local rom host on any Mac in your home.

Macs and Bonjour also support WakeOnLan, so the services are continuously published by the local DNS server that would run on the raspberry pi and would be set as the DNS server when connected via VPN. Then if your MacBook for example is sleeping, it can wake up and serve the files and go back to sleep. I think this works over WiFi but the power cable might have to be plugged in is all. This is actaully way easier than it sounds. I have a lot of experience setting up Bonjour AFP / SAMBA file hosts and VPN on linux servers like Raspberry Pi. The Avahi open source project for Bonjour (also called Zero-Conf in Linux world) has been around forever.

I'd much rather do this than deal with supporting various 3rd party cloud services. And then even still you'd have to generate some kind of XML file or similar that would sit on the cloud server too that would have to be downloaded and parsed to get meta data about the files on the remote host. Might as well just build that into what we have already as a web service in the app itself (or light app that sits on a mac in the menu bar and re-use the web importing code or Finder file copying to do imports)

from provenance.

I can do Dropbox integration, we used it in nds4ios and it works well. At the moment saving ROMs would be okay, since they're fairly small, but once more emulators are added the space needed for ROMs on Dropbox might increase drastically.

from provenance.

That'd be cool.

from provenance.

Would this sync with OpenEmu?

from provenance.

No, it would simply be dropbox integration. Unless OpenEmu also integrated Dropbox and you used the same folder they wouldn't sync together.

from provenance.

Save synching should be fairly easy to do with iCloud document synch, I'll take a look at it when I'm done with the PSX Core.

from provenance.

For my 2 cents, I'd prefer Dropbox over iCloud sync since my saves are already saved there (using symbolic links, so it works with OpenEmu) and because my iPad is under a different iCloud ID. (Maybe there's a way to share files between iCloud storage users, but I never use it so I wouldn't know.)

I'm fine if only the saved games are synced. Syncing the ROMs too would take up too much cloud space and I'd feel a bit paranoid having ROMs in the cloud...

from provenance.

Maybe it could have an option to let you choose what you want to sync? e.g. roms, saved games, configuration, etc.

from provenance.

I agree with Dropbox syncing. While ROM syncing would be nice, I don't think that's as necessary as save states. Like Cralex, I have symbolic links for my saves with OpenEmu setup, and being able to access my saves across devices would be amazing. It would also be nice to be able to choose which service to use. I would say Dropbox, Box, or iCloud Drive. Maybe Google Drive as well.

from provenance.

I setup an integrated web server that allows for bulk copying of ROMs as well as uploading/downloading game saves. Please see pull request here: https://github.com/jasarien/Provenance/pull/81

from provenance.

This has been discussed, but I think will be more of an issue as people want to use this app on their devices and on the new AppleTV, but we need to accommodate a way to sync game ROM's and game save files so we can just play on any device. I know there has been some discussion about Dropbox, but I wonder if there is any way we can incorporate this? A web server connection is a good stop gap, but I think a full blown sync solution is going to be necessary.

Is there any way we can dissect how GBA4IOS was utilizing Dropbox framework to make it work with ATV and iOS?

from provenance.

Dropbox would be fine if it was only iOS we were dealing with. As it stands there is no WebKit, or UIWebView on tvOS, which is a vital component in the completion of OAuth which Dropbox requires in order to be used in 3rd party apps. So we can't use Dropbox with tvOS until there is a usable web component.

from provenance.

I guess for now the only option is to use the iPad version of Provenance,
and then Airplay mirror the screen to the Apple TV, which I guess you can
do now....

On Tue, Sep 22, 2015 at 1:07 PM, James Addyman [email protected]
wrote:

Dropbox would be fine if it was only iOS we were dealing with. As it
stands there is no WebKit, or UIWebView on tvOS, which is a vital component
in the completion of OAuth which Dropbox requires in order to be used in
3rd party apps. So we can't use Dropbox with tvOS until there is a usable
web component.

—
Reply to this email directly or view it on GitHub
https://github.com/jasarien/Provenance/issues/1#issuecomment-142367635.

Josh Petersen
[email protected]
515-450-7311

from provenance.

I tried airplay previously, the latency was too high to be playable.

from provenance.

Welp that sucks. I guess for now I'll have a set of games I want to play
when I'm portable and a set of games that I want play around the house.
Does the web server work on TvOS? I guess you could transfer game files and
saves around back and forth if needed.

On Tue, Sep 22, 2015 at 1:23 PM, James Addyman [email protected]
wrote:

I tried airplay previously, the latency was too high to be playable.

—
Reply to this email directly or view it on GitHub
https://github.com/jasarien/Provenance/issues/1#issuecomment-142371605.

Josh Petersen
[email protected]
515-450-7311

from provenance.

Maybe something like this could help? https://github.com/gilbertchen/acrosync-library

from provenance.

Possibly. I'll have to take some time to have a proper look.

from provenance.

josejulio's idea look viable. All you need to do is make sure you have a local machine that can be the connection point to sync between ATV and iOS devices.

from provenance.

What about iCloud drive?

from provenance.

We don't know if the AppleTV will have an iCloud Drive app yet. It probably will but not until release.

Provenance can't access iCloud directly because it's not an App Store app.

from provenance.

We may be able to use CloudKit in development mode though, if not natively, via the REST api.

from provenance.

Maybe, wouldn't work if provenance is distributed by iEmulators again, or something.

from provenance.

Hopefully being able to build and run apps without a developer ID now should help there. Though it does still require you to have a mac.

from provenance.

That's what I mean. Building for yourself may allow access to iCloud in dev mode. But if it's distributed via iEmulators (which has been the widest distribution Provenance has had) it won't work because it'll be signed with an Enterprise cert and they don't allow access to iCloud.

Does the non-paid dev account even allow you to create a profile with iCloud entitlements anyway? I don't know if it does or not.

from provenance.

With the REST API, you shouldn't need developer credentials, you just need to set the app ID up once with valid credentials, and then other apps can access the web API for that App ID. https://developer.apple.com/library/prerelease/ios/documentation/DataManagement/Conceptual/CloutKitWebServicesReference/SettingUpWebServices/SettingUpWebServices.html#//apple_ref/doc/uid/TP40015240-CH24-SW1

from provenance.

Yeah I don't think that's going to work :D

Upload URLs are valid for a limited time (15 minutes) and the maximum file size is 15MB.

Unless I'm missing something?

from provenance.

Might work for cloud saves, and you can always chunk rooms into multiple parts. But yeah, overall we're very limited by not being a store app.

from provenance.

I think josejulio's suggestion might be the best to investigate.

from provenance.

Google drive example - https://github.com/googledrive/ios-quickeditor

Doesn't require oAuth, but does require some config both on the google drive console and setting 2 known secrets

from provenance.

We need a solution that's as simple as pressing a button in the app or else no-one but us techies is gonna use it.

from provenance.

Another option that comes to my mind, would be to start a web server, and request the user to move to a browser (on this phone, pc, mac, w/e) and go to http://local.ip.of.apple.tv, from there, do the dropbox login, receive the keys and send to the apple tv (using the same web server). Though is somewhat cumbersome.

from provenance.

So something similar to the way you activate HBO or ESPN on the current AppleTV, letting you browse to a page on the AppleTV, and use that external browser to authenticate with dropbox. Makes sense, not sure if it's doable but it sounds like something to look into.

from provenance.

Regarding AirPlay, according to the guy that runs Afterpad.com, the iOS 9.1 beta has impossibly low latency with AirPlay - basically as good as the Lightning-HDMI adapter.

from provenance.

Sounds like something we can revisit then.

from provenance.

Hey James,
Just a little suggestion,meanwhile you guys are dealing with the best solution to have sync ROMS and saves between iOS and tvOS, it will be great to include in a new official release a simple dropbox sync only for saves like GBA4iOs can actually do.
So we can finally sync saves between iPhone and iPad....Pleaseeeee! :)

from provenance.

I have dropbox syncing code for iOS. Reach out and I can provide, it would likely take me too long to integrate since I don't understand your current code, but certainly has a fair amount of the big stuff already solved with detecting dropbox status / sync issues. Not sure how best to pass that off

from provenance.

We can't use Dropbox on tvOS and I don't want two separate implementations to manage. I still think it would be best to explore an option that works for both iOS and tvOS.

from provenance.

Ok, I understand, but...is Web Server feature actually working? I tried version 1.2.1 and 1.1.6 but I can't connect to the IP. I can see only a blank page.

from provenance.

Last I checked it was working. Are you on the same wifi network as the iOS device you're trying to connect to from your computer?

from provenance.

Yes! I'm also trying with other Apps web server (VLC, Documents)... and It works. Same IP address.

from provenance.

you're using the very latest code from the master branch? (not the releases)

from provenance.

No, I'm using the releases. Am I wrong?

from provenance.

The releases aren't always the latest. They're just points in time where the version was incremented for version tracking.

I just testing the Webserver right now and it works for me: http://d.pr/i/10tYY

from provenance.

And what's about the idea to modify the actual web server interface adding a "download as zip" function for files and folders?
Just to make possible an excange of roms/saves between devices without a computer.At the end of the download it will activate the classic "open in" Safari dialogue screen.
It will be a kind of manual sync... But compatible with all the devices!!

from provenance.

Hey James, is this last an imbossible request? What's you think about it?

from provenance.

You could use HTTP requests to mimic oauth integration @jasarien if you wanted to attempt to do a implementation of DropBox before their official SDK catches up. EX: http://stackoverflow.com/questions/25423924/oauth-2-0-in-php-using-curl

As for the web server @illando it is derived from another GitHub project. However, it could be modified to allow for zip functionality. We would need to add a button the to the internal web page, an AJAX request back up to the internal web server, and some zlib or some other zip library to do the compression. Have you attempted to add this feature? What problem are you running into?

from provenance.

@dantheman213 Unfortunately I'm not a developer. I was just trying to be useful providing some ideas to improve the user experience, just because James asked for some suggestions in the post title.

from provenance.

Regarding Dropbox not working on tvOS since you could not authenticate without a web browser (9/22 comment): There was a recent discovery using private API's that show a UIWebView. Since you would never submit this app to the app store, being a private API is ok. See more here: https://github.com/steventroughtonsmith/tvOSBrowser

from provenance.

Just because an app isn't in the App Store doesn't mean it's fine to use private API. Private API is usually private for a reason. It may be that the API is unsuitable for reasons other than Apple just wanting to control things - perhaps its crashy, perhaps it changes a lot between SDK releases which could break source compatibility between versions.

Also, the age-old adage: "Just because you can, doesn't mean you should."

UIWebView clearly wasn't intended to be run on tvOS, regardless of whether it can or not. The Focus Engine is not designed to work with web content, and the hacks to implement a 'cursor' in order to interact with the web view, while clever, aren't a great user experience in any way.

Finally, in order to even build the tvOSBrowser sample app, one needs to redefine the macros used to tell the compiler what is available to tvOS in a file that ships with the SDK. I'm not doing that - I use my development setup for more than just Provenance, and modifying SDK files is not something I'm going to do. Plus, for users who aren't developers just following instructions to build Provenance for their AppleTV, it complicates things further for them - all of a sudden they have to modify a file that ships with Xcode? And they get this scary warning when they try?

There are other solutions that don't involve using private API.

from provenance.

Maybe this can work as to enable login on the apple tv (requiring a iphone/ipod/ipad)
https://github.com/rsattar/Voucher

from provenance.

Try to see if you can integrate google drive or mega since the amount of free space given on drop box is very limited unless you pay for more storage. It would also be nice if game saves/save states could sync with a cloud service.

from provenance.

found this on droopbox forums
" Gregory
September 15, 2015 20:58

Thanks for all of the information and screenshots guys, that's very helpful. I'll bring this up with the team internally.

One thing that may work with the existing infrastructure though would be how Apple TV apps of the current generation work for connecting external accounts. That is, the Apple TV app gives the user a short URL for the app's web site to browse to on an Internet connected device with a browser, and that web site processes a standard OAuth 2 app authorization flow. Upon redirected back to the app's web site, it can send down the necessary token to the TV app. That would offer a better user experience, especially if the user is already signed in to Dropbox on their phone, for example, as they'd only have to type in the short URL on their device, as opposed to typing in their full Dropbox credentials on the Apple TV (possibly including a second factor, etc.)."

https://www.dropboxforum.com/hc/en-us/community/posts/204784269-Authentication-to-dropbox-on-tvOS

from provenance.

turns out Facebook released an sdk for tv os log ins . https://developers.facebook.com/blog/post/2015/11/25/tvOS-SDK-beta/ maybe this can point to some way of getting drop box to start working or somehow signing into a Facebook thats connected to some dropbox account.

from provenance.

Why don't we just add a sharing sheet to save games, so you can copy your saves to and from your iCloud Drive app. It's not perfect, but should be a pretty solid workaround for not being a store app.

from provenance.

While likely not ideal, as it requires a server-side component, OAuth logins are possible on TVos without (I believe!) using private APIs, as demonstrated at https://github.com/aaronpk/TVAuth-TvOS.

from provenance.

I think this is worth taking a look at: https://blog.agilebits.com/2016/01/12/agilecloudkit-icloud-sync-gets-its-wings/

from provenance.

Cloud kit isn't suitable for storing/syncing large files like ROMs (and before you say "ROMs are tiny!" - SegaCD ROMs are upwards of 650MB).

from provenance.

I agree about ROMs for sure but I was more thinking about saves/savestates in fact. 😊

from provenance.

To solve the AppleTV problem, do you think we could put the Dropbox (or Google Drive, or whatever) login on the Provenance Import Roms locally-hosted page? You use a standard client side JS OAuth flow to get a token, and then send that token over to the Objective C app for storage / re-use. I'm not experienced in ObjC, so I don't know if there's a library that can consume that token easily (specifically for Dropbox), but if there is such a library then this would at least fix AppleTV's lack of web views.

from provenance.

http://9to5mac.com/2016/02/05/apple-adds-server-api-to-cloudkit-unlocking-new-developer-possibilities-for-the-icloud-service/

something new

from provenance.

FYI - I've created a branch with limited (but working) battery save (not state save) support using CloudKit. It allows you to copy saves to and from CloudKit manually - there's no automatic syncing. See https://github.com/jdelman/Provenance/tree/cloudkit-saves.

There is now a "folder" button on the game library view controller that takes you to the screen. It will show a list of your local and cloud saves. You can copy a save from local -> cloud by tapping on the local save, and vice versa for cloud saves.

If you're interested in building this into your own fork, you'll have to:

• add the iCloud entitlement to Provenance (and ProvenanceTV, if you're building for tvOS) and enable CloudKit
• configure a container using CloudKit Dashboard and set the proper container bundle ID on line 21 of PVCloudBatterySaves.m and in your entitlements
• create a schema called BatterySaves with the following fields:

Please let me know if you try it out, and of course, pull requests / improvements are welcome!

from provenance.

@jdelman This is working great. Thank you! 😊

from provenance.

@jdelman This is fantastic. Thank you. Got it working last night, and now I'm sharing save files between my iPhone, iPad, and AppleTV.

Question - is the manual saving (not automatic syncing) a deliberate design choice, or one made for the sake of releasing it sooner? Thanks!

from provenance.

@holincart Thanks for the feedback. I suppose the answer to your question is - it was a deliberate design choice made for the sake of releasing it sooner. ;)

Also, I didn't want to deal with conflicts / sync issues. Based on what I've observed with modification dates, it seems as though Provenance touches the Battery Save file as soon as it starts emulating the ROM - meaning that if, for some reason, you have Provenance open and run the same ROM in two different spots at once, you might get undesired behavior.

But please - if you have any suggestions as to when to do the sync, or how to handle conflicts, let me know! (@jasarien, have you checked this out yet? :D)

from provenance.

@jdelman Good call - definitely appreciate you taking the simpler path to get it out sooner!

I haven't given it much thought - and it's not pretty - but one option would be to prompt (via another action sheet) to upload the battery save after a user saves a state save. Clunky, but it's a relatively logical time to do it, and the user would be consenting to it. Could even add a toggle in settings to automatically upload the battery save after saving to a "local" state save.

Far from an ideal implementation from a UX standpoint, but may bring the functionality itself closer to the ideal scenario for those toying with the branch. On that note - and pretty much just for my own curiousity - why'd you go with battery saves over state saves?

from provenance.

https://twitter.com/bobard/status/742457078229307392

.@tapbot_paul “Developer ID-signed apps can now take advantage of CloudKit, iCloud Keychain, iCloud Drive & push” https://developer.apple.com/library/prerelease/content/releasenotes/MacOSX/WhatsNewInOSX/Articles/OSXv10.html#//apple_ref/doc/uid/TP40017145-SW1

Looks like it'll be possible to use CloudKit for syncing the game library and saves later this year even without being in the AppStores.

from provenance.

For the Mac... not for iOS or tvOS.

from provenance.

Ah, damn. Maybe they'll allow it for tvOS and iOS as well before the betas finish. It at least gives hope that something might change in that regard.

from provenance.

I don't think so.

DeveloperID has always been for distributing signed, secure apps outside of the Mac App Store (because Apple understands that disallowing non-MAS apps would be disastrous for the Mac), and allowing CloudKit to be used with DeveloperID signed apps is a no-brainer and it's a wonder as to why they haven't allowed it until now.

iOS never had DeveloperID and never will, because it's totally restricted to running apps from the App Store - there is no reason for Apple to allow CloudKit for non App Store apps on iOS because as far as Apple care there are no non App Store apps for iOS.

from provenance.

So, are we still in limbo with this then? Nothing official going forward (Dropbox, Google Drive, etc) due to Apple TV incompatibilities?

from provenance.

@JoelStickney IIRC it's not Apple TV incompatibilities. the problem is that this application is not allowed on the App Store. that means you don't get access to Apple's developer services like iCloud / CloudKit. any solution would require propping up a custom server to support syncing -- whether that server is for full blown syncing or just to relay oauth info to dropbox -- which costs money & requires volunteer effort.

from provenance.

Any other device (aside from the Apple TV) can connect to Dropbox directly, right? So, the intermediary server for OAuth is just for that?

from provenance.

@JoelStickney Yes.

from provenance.

Any updates about cloud sync? It would be awesome.

Cheers!

from provenance.

I would also prefer Dropbox. Makes definitely more sense than using CloudKit.

I also think that it makes the most sense to sync game saves only for now (or at least make it into an option). A huge game library could fill up the entire Dropbox.

from provenance.

Using Firebase 3.x with this would be possible. Firebase has added storage capabilities, works great with offline/online, and is compatible across several platforms (including tvOS and iOS)

from provenance.

syncing with dropbox can be awesome! I'm not sure it's necessary to sync games, only save state really matter.
Game can be imported in function of devices easily with the web UI, and all player already have it own game library somewhere. Moreover most ROMs are available on Internet easily. But save state with auto sync can be great to never loose their.

from provenance.

+1 for syncing of saved games across wherever you want (from inside the Files app). Could be Dropbox, iCloud Drive, whatever. Anything would be appreciated!

from provenance.

I wouldn't hold your breath on this feature as far as saved states for a few reason,

1. Various cores might have version mismatching and save states won't work across devices that aren't on the exact same version. I could see a scenario where a sync overwrites a save file on you have a version mismatch, now your save is Fubar'd until you update your other device to the same version of Provenance. And you can't exactly just download an update through the app store.
2. Authneticating with a cloud service would require using OAuth most likely. A lot of 3rd party SDKs are lazy and use a website to create a token and send back to the requesting client app. This is a problem for Apple TV sine there is no webview. We have to write totally custom UI to allow passing login information. Even SDKs for cloud services that have nave iOS components to do this without a webview don't have the same on Apple TV.
3. Has to be a way to choose which save state gets overwritenn. Currently Provenence users 5 slots plus an autosave slot. How would we know which save state to overwrite when syncing across devices? We'd have to come up with a whole new way of handling multiple save states.

I could keep going but I think you get the point.

ROM sharing on the other hand I think is doable. I had an idea while ago of something like a Plex server for ROMs. We could even build this as an extension into OpenEMU since they use the same exact ROM metadata format.

This would be more like devices on the same network could announce a bonjour service with a basic REST API that describes some endpoints like /systems /roms/systemid and provide a URL for another client to download that ROM. We could make it so the ROM is copied and imported into the local library, or is saved to a temporary cache and played from there.

This would actually be helpful for Apple TV since all ROMS already live in a volatile cache directory, by design of tvOS, and they could be deleted at any point as the device runs out of space.

For iOS devices that are away from a home network, this probably wouldn't be as helpful unless you have a VPN back to your home (which I do on my iPhone but I assume most people don't)

from provenance.

I think that for having saves on the cloud, we could have them manually, e.g. User selects "Save in cloud" (optionally a number of slots) or "Load from cloud"
As @JoeMatt comments, an automatic process is more complicated because of multiple devices being used at the same time.

from provenance.

@josejulio exactly, this way would be amazing 👍

from provenance.

I guess I'm having a hard time finding a compelling use case.

Is this to,

1. Save a state and continue it on another device at a later time or,
2. Back up save states and restore in case of loss of data.

If it's just #2, in the current PR for #677 I expanded the build in Web Server to support WebDav. Meaning now you can copy and overwrite entire directories in OS X finder or WebDev client which should allow for easy backup and restore.

I'm going to add an option to have it always running too so you can leave the client connected and not worry about it disconnecting every time you back out of the Upload screen.

from provenance.

If you just want a 'fetch all' 'save all' for battery states we could probably use something like this,

https://github.com/amosavian/FileProvider

We would just need to make the UI for entering the service type, URL, user, pass.

The issue with the Battery saves that I see is that they're all just in a a folder called 'Battery Saves' by the filename of the ROM. They're not split into cores or renamed to the proper ROM titles in the database. Meaning even if two devices had the same ROM, identical MD5s, but the filename was different when it was imported, it will be difficult to match up the right folder.

We'd have to change the way Battery saves are saved into a more reproducible file structure, which would break existing Battery saves on upgrade (but hey it's free software things will break compatibility)

from provenance.

My two cents - from a UX perspective, syncing features like this need to be invisible and work flawlessly or they get annoying quick. Nobody wants to have to dismiss a “save state incompatible with this version of provenance” alert every time they start a game.

I also think syncing battery saves only is not what people would expect. Speaking personally, I would expect all game metadata to be synced - custom artwork, battery saves, favorite status, custom names, and save states. Plus I’d expect the UI to be updated with syncing indicators and graceful error handling so it didn’t get in the way of playing games.

I don’t think syncing is worth having unless it really can sync your entire library’s metadata and fulfill the dream of hopping from one device to another seamlessly. It’s going to be an tremendous undertaking either way so if you’re gonna sync one thing may as well figure out how to sync them all and do it right.

from provenance.

Yeah, the whole import, database, saves and library UI needs a complete overhaul. It grew organically from when Provenance was just a Genesis front end. Now it’s a multi-emulator front end and is in dire need of refactoring.

from provenance.

from provenance.

from provenance.

I added UIDocumentPickerViewController to the N64+Swift branch. This allow you to select documents from iCloud and other cloud services like Google Drive (though this didn't work for me for some reason, iCloud did).

I've tested it with roms, zips and bios files. Everything copies and imports smoothly. Still could use some tweaks but seems pretty good.

If this works well, might be able to add export and importing of save states

from provenance.

As iCloud Drive not available on Apple TV. I've made some search and Cloudkit could be an easy solution for battery saves, but not Roms du to size of some roms (PSX). The integration is relatively simple, it's free (more or less), everybody with an iCloud account could use it and it's easy to setup when you build the app yourself (no need to add custom api-key in the app, just "enable" the function in the project settings).
I can make some test for battery saves, but any suggestion, recommandation, opposition ?

from provenance.

@leolelego: aucun progrès? beaucoup sont curieux de savoir ce qu'il y a dans votre cuisine.

from provenance.

yeah i have an idea for roms anyway, i already expanded the database to have a concept of 'Library' and can have multiple, online and offline, and games have the same
so in the browser we can show roms that are offline in storage, and then if you import them it'll update
the rest of the meta data can sync though.

Another option is using Realm's cloud sync. They have a way to self host it, I started playing around with that a little. Not sure how user accounts are handled though.

And then a way to host the files. Maybe we could host that too, since the files are small. Maybe a paid feature...

from provenance.

@JoeMatt How would in-app purchases be handled when Apple doesn't allow emulators?

from provenance.

Wouldn't use IAP. Accounts would need to be created in a web app. I haven't looked much further into how cloud based realm works, their docs for self hosting are, maybe purposefully, thin.

from provenance.

@JoeMatt If you guys need someone to develop a web application for managing accounts & payments, etc I'd be willing to help with that.

from provenance.