I think you will still be able to use the DropBox app on your iPad, and then "share" the file to HeroLab; but then HeroLab will make a local copy of the file and any changes won't be synced back to DropBox.
-
Please note: In an effort to ensure that all of our users feel welcome on our forums, we’ve updated our forum rules. You can review the updated rules here: http://forums.wolflair.com/showthread.php?t=5528.
If a fellow Community member is not following the forum rules, please report the post by clicking the Report button (the red yield sign on the left) located on every post. This will notify the moderators directly. If you have any questions about these new rules, please contact support@wolflair.com.
- The Lone Wolf Development Team
Dropbox support
- Thread starter NeoEvaX
- Start date
I think you will still be able to use the DropBox app on your iPad, and then "share" the file to HeroLab; but then HeroLab will make a local copy of the file and any changes won't be synced back to DropBox.
nightpanda2810
Well-known member
Might be worth looking into how Resilio Sync works on the iPad. I use it between my desktop and laptop (I use HL on both) to sync everything, including packages and custom modifications. Works well.
Think DropBox, but no cloud portion. Only syncs between devices you configure.
If on the iPad Resilio Sync can sync any user-accessible folder on the device, then you could potentially sync the folder HL uses to store files locally.
Think DropBox, but no cloud portion. Only syncs between devices you configure.
If on the iPad Resilio Sync can sync any user-accessible folder on the device, then you could potentially sync the folder HL uses to store files locally.
To put it bluntly they probably have had to prioritize things, and this complex coding task has been something that they wanted to do but have not had the man hours to divert to it.
Yeah, that's a shame.
I'm curious what changed in the API that made it so much of a hassle to convert existing code...? I mean, it's a file sharing service, right? So it has open/read/write/close, and then probably optional parts to allow for versioning, sharing, and so forth, all of which HL doesn't use (most applications don't need those features).
Some day I'll go look at the API changes and see how much of a difference there is. I gotta believe that an emulation layer that converts the old API calls into the new ones wouldn't be that tough, but some of these third party APIs can get tricky... All the more reason for either iCloud (tough to use on Windows, though) or WebDAV (cross-platform standard) to be chosen.
I'm curious what changed in the API that made it so much of a hassle to convert existing code...? I mean, it's a file sharing service, right? So it has open/read/write/close, and then probably optional parts to allow for versioning, sharing, and so forth, all of which HL doesn't use (most applications don't need those features).
Some day I'll go look at the API changes and see how much of a difference there is. I gotta believe that an emulation layer that converts the old API calls into the new ones wouldn't be that tough, but some of these third party APIs can get tricky... All the more reason for either iCloud (tough to use on Windows, though) or WebDAV (cross-platform standard) to be chosen.
I use two iPads, a Pro and a Mini 2. Today one of my players edited his character on the Pro while I used the Mini. Turned out that the Mini was slowing me down, so we switched iPads. No problem using Dropbox.
Then I had issues creating a Spellbook for his char. I thought that maybe this was a bug of the app and checked via PC version. For that I remote connected to my PC via iPad, opened Hero Lab and opened his char, again directly from Dropbox. Then I printed his char as a PDF file to a shared Onedrive folder for him to download, all while sitting in another town via mobile internet.
One Dropbox gets dropped characters are jailed to a single iPad until you get an opportunity to move the data around. An "Open in" function would at least help by allowing to directly move character files out of HL to the Dropbox app (or whatever cloud app is used). I never connects my iPads to the PC via USB cable, using Itunes to move files is very incovenient.
Then I had issues creating a Spellbook for his char. I thought that maybe this was a bug of the app and checked via PC version. For that I remote connected to my PC via iPad, opened Hero Lab and opened his char, again directly from Dropbox. Then I printed his char as a PDF file to a shared Onedrive folder for him to download, all while sitting in another town via mobile internet.
One Dropbox gets dropped characters are jailed to a single iPad until you get an opportunity to move the data around. An "Open in" function would at least help by allowing to directly move character files out of HL to the Dropbox app (or whatever cloud app is used). I never connects my iPads to the PC via USB cable, using Itunes to move files is very incovenient.
Last edited:
Thanks for the link, Weissrolf.
With just a casual glance, I don't see anything that's really a road block. I presume that LW is using the Obj-C SDK and not making http calls directly (!) so some front-end functions to map return values would work for much of the changes. For example, the metadata returned when scanning a directory for filenames (which the iPad has to do in order to present a list of portfolios) is different between v1 and v2. The differences appear to be in the data's structure, not a fundamental change. So mapping the values back into the older format would probably still work.
However, there's a big change in how errors are handled. This would likely cause a ripple effect through higher level functions than the ones doing the actual IO, since many functions that detect an error probably just return that same error to their parent. Mapping the error messages doesn't look feasible, so that portion of the code would need to be completely revamped.
Another thing I noticed is that some of the functionality was demonstrated using Swift and LW wrote the iPad app in Obj-C. There is an SDK for Obj-C on the iPad, but when the examples are in Swift, that might make it more work to translate code examples...
Overall, it doesn't look like it would be impossible. However, it will be a fair amount of work (the error handling definitely; it may be possible to auto-generate the front-end stubs, or at a minimum, teach your favorite editor a macro or two to help automate it).
Regardless, whatever approach they use in the future (Box, SugarSync, WebDAV, whatever) will likely need stubs similar to the ones I'm thinking of, since whatever system they migrate to could also change in the future. Having a separate interface layer that can mitigate the ripple effects will be important. The Facade and Strategy/Template patterns will be applicable, and depending on how they use DropBox, the Builder pattern.
It'll be a fair amount of work.
With just a casual glance, I don't see anything that's really a road block. I presume that LW is using the Obj-C SDK and not making http calls directly (!) so some front-end functions to map return values would work for much of the changes. For example, the metadata returned when scanning a directory for filenames (which the iPad has to do in order to present a list of portfolios) is different between v1 and v2. The differences appear to be in the data's structure, not a fundamental change. So mapping the values back into the older format would probably still work.
However, there's a big change in how errors are handled. This would likely cause a ripple effect through higher level functions than the ones doing the actual IO, since many functions that detect an error probably just return that same error to their parent. Mapping the error messages doesn't look feasible, so that portion of the code would need to be completely revamped.
Another thing I noticed is that some of the functionality was demonstrated using Swift and LW wrote the iPad app in Obj-C. There is an SDK for Obj-C on the iPad, but when the examples are in Swift, that might make it more work to translate code examples...
Overall, it doesn't look like it would be impossible. However, it will be a fair amount of work (the error handling definitely; it may be possible to auto-generate the front-end stubs, or at a minimum, teach your favorite editor a macro or two to help automate it).
Regardless, whatever approach they use in the future (Box, SugarSync, WebDAV, whatever) will likely need stubs similar to the ones I'm thinking of, since whatever system they migrate to could also change in the future. Having a separate interface layer that can mitigate the ripple effects will be important. The Facade and Strategy/Template patterns will be applicable, and depending on how they use DropBox, the Builder pattern.
It'll be a fair amount of work.
TL;DR version: HL might be able to (somewhat easily) support Dropbox and other file sharing apps by supporting iOS 11’s new drag/drop facility.
Now the TL version:
For those who missed the Apple WWDC announcement today, it appears that iOS 11 will support drag and drop of files between applications.
Perhaps LW knew this (as registered developers they may have had advance information) and that may be one reason why they decided not to try to update to the newer Dropbox API -- if they support the drag/drop API instead, then HL zone the iPad will work with any other app that supports drag/drop of files. Which I have to assume will include Dropbox, Box, GoogleDrive, and so on.
I'm not a registered Apple developer so I don't know what the new API will look like, so no telling how tough it might be for LW to implement compared to the existing DropBox API, but it might be that it sits on top of the typical "Open In..." technique that the iPad uses to communicate between apps. If so, it might not be too tough (although I don't know if HL supports the OpenIn approach -- I've never tried it).
Now the TL version:
For those who missed the Apple WWDC announcement today, it appears that iOS 11 will support drag and drop of files between applications.
Perhaps LW knew this (as registered developers they may have had advance information) and that may be one reason why they decided not to try to update to the newer Dropbox API -- if they support the drag/drop API instead, then HL zone the iPad will work with any other app that supports drag/drop of files. Which I have to assume will include Dropbox, Box, GoogleDrive, and so on.
I'm not a registered Apple developer so I don't know what the new API will look like, so no telling how tough it might be for LW to implement compared to the existing DropBox API, but it might be that it sits on top of the typical "Open In..." technique that the iPad uses to communicate between apps. If so, it might not be too tough (although I don't know if HL supports the OpenIn approach -- I've never tried it).
ICloud is presumably a non-starter for it's relative unpopularity and expensive price for the capacity you get. It doesn't have that much of an appeal to Windows users.
ShadowChemosh
Well-known member
Really? I use iCloud on Windows without issues. Seems to be smoother than Dropbox actually.
I really don't pay much attention to cost so that could be a thing. I think I am pay $1 per month for 50 gigs. Which includes a backup of my iPad and iPhone. Plus I store every Paizo PDF (30+ gigs) on the iCloud. This makes getting to Pathfinder really easy on any device (Windows, or an i device).
Shrug works for me...
It's pretty much acknowledged though that ICloud does give you the less bang for the buck of all the cloud services there. Given that Herolab is operating on IOS devices and Macs (are they still relevant if you're not working in a creative studio?), ICloud support is sort of mandatory. Dropbox, however, has a far better cross-platform implementation. on a 50 gig data budget you're either running pretty full or not storing that many photos. I have the same allocation and I don't have 30 gigs free to store PDFS on it.
ShadowChemosh
Well-known member
True I am not a music or photo person so 50gigs easily works for me. I have more word documents than photos. LOL half my pictures I do have are of whiteboards.
I do have a full dropbox pro account also which gives me a 1tb which is nice for some of my "bigger" files I have to store. Looking at those prices seems your right that you get more space out of Dropbox for the cost.
Just was pointing out that you can get access to iCloud files from windows without issue. Cost is subjective to each person.....
<rant>
I use a MBP because I can get commercial apps for it (Adobe Acrobat Pro, TurboTax) that I can't get for Linux, otherwise my entire office would be Linux. Long live KDE!
What you probably meant is that they are more prevalent because they provide implementations for a wide range of operating systems. I remember SugarSync from way back when, and thinking that they were going to be great for me because they had a Linux implementation. Hah, what a joke that turned out to be!
Box.com has become popular within some enterprise environments as they are business-friendly with their server side encryption tools in which the customer keeps the key and Box can't see your data. (Think legal or financial firms. When a lawyer crosses the U.S. border, their laptop is subject to being confiscated by Customs just like yours. Now consider what kinds of information could be on that lawyer's laptop! So most of those companies recommend that employees store stuff in the cloud and clear local laptop caches before passing through Customs. But where can you store it that it's actually safe?)
I use DB primarily for things that I will want to share with others.
I could use Google Drive but I don't like Google's data invasion policies so I use them for very little nowadays. Their slogan used to be "do no evil", but I think now they're more in the "do no evil -- that you can't get away with!" camp. Unfortunately, I really like Waze. I wish there was another crowd-sourced GPS-based navigation app available now that Google owns Waze.
My own web hosting provider supports WebDAV (as I mentioned early in this thread) and I really should be taking advantage of that!
Anyway, I wanted to clarify my take on some of your assertions. Your mileage may vary. Standard disclaimers apply. A rolling stone gathers no moss. And so on...
</rant>
You've not been in a modern corporate America data center in awhile, have you? Many of the companies that I provide training for (I can't name them, but let's just say "Fortune 100 firms") are no longer distributing Windows-based machines to employees but are instead providing MacBook Pros. Primarily, I think it's because of the Unix-based operating system, more than anything else, but I guess you'd have to ask their CIOs to be certain.
I use a MBP because I can get commercial apps for it (Adobe Acrobat Pro, TurboTax) that I can't get for Linux, otherwise my entire office would be Linux. Long live KDE!
They have a better implementation? And how do you know that? Have you seen their code?
What you probably meant is that they are more prevalent because they provide implementations for a wide range of operating systems. I remember SugarSync from way back when, and thinking that they were going to be great for me because they had a Linux implementation. Hah, what a joke that turned out to be!
Box.com has become popular within some enterprise environments as they are business-friendly with their server side encryption tools in which the customer keeps the key and Box can't see your data. (Think legal or financial firms. When a lawyer crosses the U.S. border, their laptop is subject to being confiscated by Customs just like yours. Now consider what kinds of information could be on that lawyer's laptop! So most of those companies recommend that employees store stuff in the cloud and clear local laptop caches before passing through Customs. But where can you store it that it's actually safe?)
I don't store photos in the cloud. Photos are best viewed when there's some kind of management tool that organizes access to them. Whether that's Flickr or some other tool doesn't really matter, but dumping them in a directory in DropBox is kinda insane. My wife likes iCloud's "photo stream", but for me? Meh.
I use DB primarily for things that I will want to share with others.
I could use Google Drive but I don't like Google's data invasion policies so I use them for very little nowadays. Their slogan used to be "do no evil", but I think now they're more in the "do no evil -- that you can't get away with!" camp. Unfortunately, I really like Waze. I wish there was another crowd-sourced GPS-based navigation app available now that Google owns Waze.
My own web hosting provider supports WebDAV (as I mentioned early in this thread) and I really should be taking advantage of that!
Anyway, I wanted to clarify my take on some of your assertions. Your mileage may vary. Standard disclaimers apply. A rolling stone gathers no moss. And so on...
</rant>
I don't store drop photos in a Icloud directory, It's just that I take a lot of photos with my iPhone which will as a consequence archive them on ICloud. It not surprisingly is still the cloud service that works best with my IPhone. It's also the most expensive per gig by far.
Edit:
I just checked. Apple charges $10/month for 2TB of storage (in the US). Dropbox charges $10/month for 1TB of storage (and $15/month for 2TB using their "Dropbox for Business" plan). Dropbox has discounts for yearly payments ($8.25/month and $12.50/month, respectively).
Apple has clearly revised their pricing downward recently. Dropbox includes a few features that iCloud does not (like versioned files going back 30 days, or 120 days for their Business tier).
My previous post said:+1
Amen to that!!
(Although IIRC, they've come to realize that and there's supposed to be a price drop coming. Or not.
Last edited:
The Dropbox desktop application is somewhat more advanced than the other popular cloud storage solutions. It offer:
- Block level (delta) synchronization methods, while the likes of iCloud, Onedrive and Google Drive transfer full files even when only a single byte has changed.
- Local synchronization over LAN, which is useful if you are using the same cloud files on multiple local computers, especially many small ones.
- Multiple upload threads, which can make more use of your full upload bandwidth and thus gets data quicker to the cloud server.
- File hashes that identify files that are already on Dropbox servers and thus do not need to be re-uploaded. I mean to remember that this even works for identical files that other users already uploaded from different locations.
- Somewhat better optimized CPU usage for indexing files, also likely to index (and upload) many small files quicker than the other options when I last tested them against each other.
All that being said, Hero Lab only needs a few MB of storage, roughly 100 kb per Hero Lab profile. So it will fit into any free cloud storage plan anyway.
- Block level (delta) synchronization methods, while the likes of iCloud, Onedrive and Google Drive transfer full files even when only a single byte has changed.
- Local synchronization over LAN, which is useful if you are using the same cloud files on multiple local computers, especially many small ones.
- Multiple upload threads, which can make more use of your full upload bandwidth and thus gets data quicker to the cloud server.
- File hashes that identify files that are already on Dropbox servers and thus do not need to be re-uploaded. I mean to remember that this even works for identical files that other users already uploaded from different locations.
- Somewhat better optimized CPU usage for indexing files, also likely to index (and upload) many small files quicker than the other options when I last tested them against each other.
All that being said, Hero Lab only needs a few MB of storage, roughly 100 kb per Hero Lab profile. So it will fit into any free cloud storage plan anyway.
Last edited:
I've been using the 1TB Dropbox option.
I have all of my Hero Lab files and everything D&D related in their respective folders. Being able to open something on the laptop (which I take with me to our host's house) for the playing of the games, while working on the adventure at home on the desktop, and having everything stay in sync is great.
Exclusively for HL purposes, 1 TB is overkill, but the price is decent for the storage and my total data use is about 75% of the TB. My D&D folder is only 52.9 GB of that TB though.
I have all of my Hero Lab files and everything D&D related in their respective folders. Being able to open something on the laptop (which I take with me to our host's house) for the playing of the games, while working on the adventure at home on the desktop, and having everything stay in sync is great.
Exclusively for HL purposes, 1 TB is overkill, but the price is decent for the storage and my total data use is about 75% of the TB. My D&D folder is only 52.9 GB of that TB though.
I don't know any details of why this is a case of "square peg, round hole", but since I highly value the Dropbox functionality in Hero Lab, I would like to try to assist where I can.
If (one of the) problem(s) is the change from Objective-C to Swift, maybe this might help: Tim Johnsen wrote an Objective-C library for Dropbox api v2 interaction, that he has made open-source. (Licence is BSD 3-clause "New" or "Revised" License, so commercial use is allowed.)
Here are links to a blog covering the issue, and to the library download page.
Should other technical issues exist that make migration from v1 to v2 difficult for you, I'd be interested in the more technical details of what the issues are. Provided that's information you can publish publicly.
The problem is that the old Dropbox SDK was too good. You asked it "Give me file X" and it would check to see if it had the newest version of file X already downloaded - if not, it would download and cache it, unless you had no internet connection, in which case it would just give you the version it had cached previously. If two files were edited in different places at the same time, it would do conflict resolution to the best of its ability; if you made changes to a file, it would upload those changes to the right place as soon as it could. It's essentially a "black box" that you can put files into and take files out of, and everything Just Works, whether you're online or offline.
The new Dropbox API, on the other hand, has much simpler methods like:
* Upload file
* Download file
* Get list of files
And that's it. All of the "smarts" that made the old SDK so easy to use are gone. To migrate to the new API, we'd need to re-implement all the clever things the old SDK did. We'd need to add our own caching, for example, because the new API doesn't do any of that - it just lets you upload and download files, and you're responsible for any caching yourself.
The old and new versions operate at very different levels of granularity - I'm sure the new version is much more powerful and can do X, Y and Z specific things the old version couldn't, but it doesn't implement the critical stuff that most dropbox users need - that is, seamless sync and file use, whether you're online or offline. If they don't implement that, then we have to, and that's code that is writable, but time-consuming and tricky to get correct.
Now, obviously it would be possible for us to re-implement what the old SDK does, or work on an alternate solution - for example, iOS now has various other ways of accessing files stored by cloud providers that didn't exist when we added the dropbox sync capabilities (the "document picker", for example, and I believe there's something new being added in iOS 11 as well).
However, we have various major projects (*cough* Hero Lab Online *cough*) that are taking up 100% of my coding time, and so we just don't have the time we need to spend adding a new sync solution at the moment - that time is 100% booked on other projects which mustn't fall behind.
Hope this helps explain things!
The new Dropbox API, on the other hand, has much simpler methods like:
* Upload file
* Download file
* Get list of files
And that's it. All of the "smarts" that made the old SDK so easy to use are gone. To migrate to the new API, we'd need to re-implement all the clever things the old SDK did. We'd need to add our own caching, for example, because the new API doesn't do any of that - it just lets you upload and download files, and you're responsible for any caching yourself.
The old and new versions operate at very different levels of granularity - I'm sure the new version is much more powerful and can do X, Y and Z specific things the old version couldn't, but it doesn't implement the critical stuff that most dropbox users need - that is, seamless sync and file use, whether you're online or offline. If they don't implement that, then we have to, and that's code that is writable, but time-consuming and tricky to get correct.
Now, obviously it would be possible for us to re-implement what the old SDK does, or work on an alternate solution - for example, iOS now has various other ways of accessing files stored by cloud providers that didn't exist when we added the dropbox sync capabilities (the "document picker", for example, and I believe there's something new being added in iOS 11 as well).
However, we have various major projects (*cough* Hero Lab Online *cough*) that are taking up 100% of my coding time, and so we just don't have the time we need to spend adding a new sync solution at the moment - that time is 100% booked on other projects which mustn't fall behind.
Hope this helps explain things!