Allow ZwiftLauncher to allow auto-updating and on a schedule

ZwiftLauncher loads and sits in the system tray on Windows, making it convenient to load Zwift when you want to ride, except when there’s a big update coming. 

Nothing saps the energy to ride when you kit up and are standing over the bike, and then realize you have to wait 15 minutes for the client to download and install a new update. 

If ZwiftLauncher had the ability to do the following, it would GREATLY enhance the experience:

  1. Download + install updates
  2. Download + install updates at {user-specified time}
  3. Download but do not install updates
  4. Do not download or install any updates (let user decide)

This way, as long as ZwiftLauncher is loaded and active, it can download or download and install updates prior to actually wanting to ride. This models very much how many other apps, including Microsoft Windows itself handles updates. 

 

Agree with the frustration when I have a small window to train in and I’m confronted with an “Updating” message.

As an alternative to this suggestion (because behind the scenes updates can also be frustrating, how about an option “Update when I’m done riding”

At the end of the ride the user gets the message “Zwift needs to update. Don’t switch of your computer until we are finished”

I think 1,3 and 4 would be a grand idea - 2 maybe, never sure how often that feature is used by people with other applications. 4 is supposed to be there now, but appears to be a tad broken.

One thing would be getting rid of the login screen, so launching Zwift is just a double click, then you get on setting your bike up. Rather than having to go through the login process.

@Mark: I’ve solved this for Mac, my solution on Windows is coming next… 

http://blog.gnu-designs.com/howto-fully-automated-zwift-login-on-mac-os-x/

David, I’ve tried your mac script but although the Zwift app is being activated the script isn’t populating the fields. The script is retrieving the values from the keychain but the Zwift app doesn’t seem to have the focus.

@Stuart: I’ll put some work into forcing focus to the Zwift windows for each command. Someone else reported something similar and he had to close some other resident app he had running and the code started working, un modified. But I’ll see if I can just force it regardless of what’s running.

@David: Thanks. I’ve just found another snippet of code that uses:

 

Tell application “Zwift”

    launch

    activate

 

If that doesn’t work then any help you can provide would be great.

@Stuart
Cracking, hacked this

activate application “Zwift”

tell application “Zwift”

    launch

    activate

end tell

…and that seems to do it here (I had same focus issue). Cheers for that (and David for the original script).

Excellent, I’ll amend mine when I get home tonight. \0/

Just a heads-up, my code already does activate the Zwift window, but the focus gets stolen after the activation, which I believe is because OS X Notifications are stealing the focus back. I’m going to force it at each event, to be sure they’re being fired into the right process, not just the one that was activated previously.

I found a slightly safer method, I’m going to test this morning and update my blog post to include that new code. I’ll re-post the newly updated link + code on Zwift Riders later for others to consume.

Thanks for pushing me to get this updated!

David - have you tried Stuarts change ? Seems to work here, wondering if the ‘activate application’ is not having the effect we might expect, whereas the explicit ‘activate’ command does… or somesuch. 

Well it’s sort of working for me.

It works if I run it from Automator but if I run it directly from the file I get “The action “Run AppleScript” encountered an error.”

I’ve updated the HOWTO with a bit of extra code that ensures that Zwift is the modal application before stuffing in the keystrokes. Feel free to use this new version:

http://blog.gnu-designs.com/howto-fully-automated-zwift-login-on-mac-os-x/

The code in the blog post and the external linked file have both been updated to reflec this change.

I also made a quick vid showing how to change the default icon of the Automator script to something a bit nicer-looking:

https://www.youtube.com/watch?v=RkE5ljS6zX8

That’s not working for me, nothing getting entered in the Username/Password fields.

Also, had you intended not to click the “Start Ride” button anymore?

I made another update late last night after working with another Zwift’er on Facebook and we discovered two important things:

1.) El Capitan steals focus IMMEDIATELY from every app that is launched. This doesn’t happen on my Yosemite machines and I don’t have an El Capitan machine to test it on, but it’s consistent. I’ve added code to accommodate that and now it should work on El Capitan, and

2.) There are different login dialogs for non-trial vs. trial users. I wrote the original code based on my own login, which was in trial mode for the last 60 days, so it would always fail for users who already exceeded their trial and tried to run it, because my code was expecting that second dialog to show up with the two buttons: “Join Now” and “Start Ride”. For non-trial users, that second dialog never shows up.

What I need to do is include code to detect the second dialog (if possible) and handle both cases independently.

  1. Trial users: Fill in Username/Password, hit Enter, delay 3-5 seconds until second dialog paints, then click “Start Ride” on that second dialog.

  2. Non-trial users: Fill in Username/Password, hit Enter. Nothing more is required.

It’ll take me a day or two to work out the kinks in that bit.

I can create a second script that works for trial users, and you can use that in the meantime, but that’s just a temporary workaround until I can automate this in a single script.

Hopefully that makes sense.