• 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

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 just don't have the time we need to spend adding a new sync solution at the moment
//
Hope this helps explain things!

Yes it does, thank you :)

If the main bottleneck would be the time required for coding a Dropbox abstraction layer, would you be up for community support? I'm thinking in the lines of: if the community (myself or whoever) could code an initial version of such an abstraction layer, given any constraints defined by you, would that possibly help to speed up the process and increase the odds of this item being doable sooner rather than later?

In understand that even if you think this'd be a idea worth trying, it will still take time for you folks, reviewing, embedding, testing, et cetera. But still, I'm putting the option out there :)
 
Question is if all of this becomes obsolete once an online/web based version of Hero Lab hits?!

I'm not sure that question's as simple as it sounds. First, what do you mean exactly? :) The Dropbox sync could become obsolete because the ipad app could become obsolete? Or the Dropbox sync could become obsolete because the online version would provide alternate syncing? (Or something else?)

If we're talking about obsoleting the offline platforms, then: Even if, functionally, Hero Lab Online would be able to do everything the app and desktop versions could do, non-functionally there will be differences. I'm thinking about aspects like: offline support, stability and uptime, performance and responsiveness, user experience. All of these can either be a measurable con (e.g. perhaps uptime could not be guaranteed, or online performance could be measurably less), or a reason for users to have preferences. Deciding when to go obsolete would require making decisions on which non-functional requirements you want to meet and how much investment its worth.

When we're talking about obsoleting the Dropbox syncing method, in favour of alternatives. I'd guess that's exactly what this discussion is about :) There's the impression that currently, there is no alternative in place that offers the same benefits as Dropbox sync. So when deciding how to update, considering alternatives (and their pros and cons) would be at the core of the discussion I think. I would guess that to support the development team in making that decision, it's valuable to know how we, the users, use the sync mechanism, and which aspects we value. What follows is the question what that means for measuring if the syncing mechanism is "fit to purpose".

For example, for me: I like the Dropbox sync because it's clean and simple, while delivering the functionally that I need.

Functionally:
  • My portfolios are available in Hero Lab regardless of platform.
  • I can access my data even when offline. (Caveat: when cached.)

Non-functionally:

  • The method is easy. One-time linking Dropbox and the rest is general use.
  • The method is transparent. I know where my data is and how the process works.
  • I can manually reach my portfolio's to enable "advanced" use without those functions being in Hero Lab. (Things like version control, backup, gathering several portfolio's for a game).
  • I understand what's happening, meaning I'm not afraid of unexpected behaviour in the app.
  • The trust in the Syncing mechanism is equal to the trust I have in Dropbox, which is sufficient. (Uptime/backup/restore/management/security are on the level I require for files for my hobby).

Anyway, in a nutshell: I would not terminate this discussion just yet because things might become obsolete later ^_^
 
The problem is that the old Dropbox SDK was too good. [...] 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.
Hm, that is pretty good!

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).
Yes, iOS 11 will have the drag/drop functionality from the new Files app. My guess is that there will be an API similar to the "Open In..." API so that dropping a file onto an app will result in the same sequence of operations as "Open In..." (or if not the same, then very similar).

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. :(
Ah, so it's a project management issue! (LOL :D)

It's unfortunate how existing products sometimes languish while all attention is given to the New Product, but it's understandable that people want to work on the new stuff (all that glitzy and sparkle, y'know!). Heck, I'm like that! I suppose that as long as the New Product supports being able to use and update my character while I'm offline, then I'm good with it. But if the offline version is going to sync with the server whenever it's got a network connection, you could end up implementing that synchronization solution you alluded to when discussing replacing the Dropbox API...

@Yerdiss: My understanding is that the iPad app is completely Obj-C -- there is no use of Swift in it currently...
 
Last edited:
I cannot even remember the last time I had to connect a cable to the Ipad or Iphone to transfer files onto them. Please don't force me to do it ever again. Especially not with four computers/tablets sharing the same HL profiles. ;)
 
One temporal solution/workaround I would like to see: Hero Lab could implement the "Open in" dialog, which in turn would allow to save profiles to the Dropbox (or other) app to save it to the cloud.

Will the new file explorer in iOS 11 allow to access HL files and move them to a cloud folder?
 
One temporal solution/workaround I would like to see: Hero Lab could implement the "Open in" dialog, which in turn would allow to save profiles to the Dropbox (or other) app to save it to the cloud.
It's a bit cumbersome, but it is doable using HL as-is.

I opened the DB app and selected the portfolio file. DB told me it couldn't display that file type (and the Help link pointed to an outdated article; oh well).

I tapped on the three dots in the upper right and selected Export. HL did NOT show up in the list of apps, nor was it in the extended list that simply needed to be "turned on" so it would display. I'm guessing that HL doesnt register itself as being able to handle files with the .por extension and/or doesn't register a MIME type with iOS and then declare itself able to handle that MIME type. :(

On the second row, however, towards the end of the list, was "Open In..." I selected that and then picked HL from the list and the portfolio was imported into HL as a "local" portfolio (meaning it appeared at the top of the screen).

So Open In does appear to work using existing techniques, it's just very cumbersome to use. Note that getting the file out of HL and back to DB will involve mailing it to yourself, then opening the email and tapping on the attachment, choosing to store it in DB. And you'll need to navigate to the DB folder where you want it stored. (I may look into creating a top-level folder in DB for HL stuff so that the navigation part is a little more streamlined, but there doesn't seem to be any other solution.)

Until LW corrects this problem, I may configure a new email address with an auto responder that just extracts attachments and moves them into a particular folder on DB. Then I could email them to "hl@some.addr" and they would just magically appear in the correct DB folder with no work on my part. I might be able to use Automator on my MBP to do this, but most likely I'll end up writing a Perl script to do it and then run the Perl script as a rule in my mail client. (That's not perfect, because if my laptop is sleeping the file won't get processed, but at least it's automated.)

Will the new file explorer in iOS 11 allow to access HL files and move them to a cloud folder?
I don't have a beta of iOS 11 to test with, but I'm thinking that dropping a file should produce the equivalent of Open In. That would be easy to implement, both for Apple and the app developer, so it's the path of least resistance. If true, then the iOS 11 Files app should be able to get portfolios into HL even easier than I described above, but getting the data back out of HL is still going to be a PITA. :(
 
Last edited:
Good news, everyone - Dropbox has changed their plans at the last minute:

https://blogs.dropbox.com/developers/2017/06/updated-api-v1-deprecation-timeline/

Our new plan is to maintain our current Dropbox support as long as we can, until the new September deadline (or whenever they actually turn off the API). In addition, we'll be making it easier to import and export from other cloud services in our next iPad release, which should be sometime next week.

Great news!
Thank you for looking into a long term solution. But I am happy to see Dropbox will be good for a bit longer.
 
<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! ;)

Not to mention the fact that a Mac can cross boot into Windows, and Apple has been pretty consistantly winning "Best Windows Laptop" from PC Magazine for years... :D

Seriously though, with a Mac I get OS X, Windows, and a 'nix... two of those things are not as easily true with a Windows OEM laptop.
 
Back
Top