Kaju self-updater talk (v.2.x)

  1. ‹ Older
  2. 2 years ago

    Bob K

    6 Dec 2017 Testers, Xojo Pro Kansas City

    Any known issues with 2017 R3?

  3. Kem T

    6 Dec 2017 Testers, Xojo Pro, XDC Speakers, MVP Connecticut

    I haven't tried yet, but wouldn't expect so.

  4. Bob K

    7 Dec 2017 Testers, Xojo Pro Kansas City

    hm...okay. getting some odd results back from the HTTPSocket but I'll dig into it more today if I have the chance.

  5. Bob K

    7 Dec 2017 Testers, Xojo Pro Kansas City

    Even though I've set Redirect to true it's not finding the correct address. A quick test in the Xojo framework shows that it brings it back the file contents as expected. So it appears that the redirect code isn't working as expected. Very odd.

    Man, I love this stuff </s>

  6. Bob K

    7 Dec 2017 Testers, Xojo Pro Kansas City

    Looks like Kaju.HTTPSSocket.GetHeaders isn't working the way it's implemented. Always returns Nil (at least in R3).

  7. Kem T

    7 Dec 2017 Testers, Xojo Pro, XDC Speakers, MVP Connecticut

    That's going to make things painful. Were you able to verify that outside of Kaju?

  8. Bob K

    7 Dec 2017 Testers, Xojo Pro Kansas City

    Yeah. If I put an HTTPSocket on a Window and call the URL it has the HeadersReceived event fires with the new Location.

  9. Kem T

    7 Dec 2017 Testers, Xojo Pro, XDC Speakers, MVP Connecticut

    I just tried the Kaju test app (Mac 64-bit) without issue, fwiw.

  10. Tim P

    7 Dec 2017 Testers, Xojo Pro Rochester, NY

    With a 301 or 302?

  11. Bob K

    7 Dec 2017 Testers, Xojo Pro Kansas City

    I suspect there's an issue with the SSL certificate on the website we're using.

  12. Phillip Z

    7 Dec 2017 Testers, Xojo Pro Florence, SC
    Edited 2 years ago

    Just to add to this conversation I am working on some minor tweaks to Kaju which I will submit a pull request for. I am switching the HTTPSocket's to the new Xojo.Net.HTTPSocket for two reasons:

    1. I want the app to check for updates asynchronously so as not to lock up the app while checking.
    2. I need the update checker to follow SSL redirects so that updates and the JSON can be used behind SSL.
  13. Kem T

    7 Dec 2017 Testers, Xojo Pro, XDC Speakers, MVP Connecticut

    Sounds good, I'm happy to take a look.

  14. Michel B

    27 Dec 2017 Testers, Xojo Pro

    Alright. I sell a significant number of packages on Amazon on CD. The big issue some of the users are utterly unable to download themselves. So I am going to try and implement Kaju for on CD software.

    I am sure I will have questions very soon ;)

  15. Michel B

    27 Dec 2017 Testers, Xojo Pro
    Edited 2 years ago

    I just tried the test app on Windows 10 with 2016R3.

    When I check I get the update page, but then all I get is a beep when I click anywhere.

    After quitting, I get

    An error has occured. Would you like to try again now or later ?
    The update data cannot be read - Webkit HTMLViewer is not currently supported for 64-bit

    Note that I cannot build in 64 bit anyway.

    After clicking Try Again, I get the update page, and again the same error. After another Try again, I was able to download the update.

    Now I get "The downloaded file appears to be corrupted" :(

  16. Kem T

    27 Dec 2017 Testers, Xojo Pro, XDC Speakers, MVP Connecticut

    I don't recall when WebKit was made 64-bit compatible, but there was a point when it wasn't. I've no idea why you'd see that message if you're not compiling in 64-bit though.

    To be sure, compile the test app in 32-bit and try it that way. Running through the ide doesn't work right.

  17. Michel B

    27 Dec 2017 Testers, Xojo Pro

    I did compile 32 bits. That's why I was wondering.

  18. Kem T

    27 Dec 2017 Testers, Xojo Pro, XDC Speakers, MVP Connecticut

    Are you using the latest version of the project?

  19. Michel B

    27 Dec 2017 Testers, Xojo Pro

    I got it from the git.

  20. Kem T

    2 May 2018 Testers, Xojo Pro, XDC Speakers, MVP Connecticut

    I could use some advice for the next version...

    Right now, you can create a background image in one of two ways: you can specify it within the app, or you can specify a URL to download the image for a version, but this was done in the days before hi-res was common.

    Modifying the former is easy. Instead of giving Kaju an image, you can give it an image set and Xojo will do the right thing. I'm updating the test app accordingly.

    The latter is trickier because you don't know if the user is using hi-res or not, so here are the choices:

    1. Allow you to specify an ImageURL (same as now) and Image2xURL, which will be optional. If only ImageURL is specified, the behavior won't change. If only Image2xURL is specified, it will be scaled. If both are specified, the ImageURL dimensions will be used and an image set created.
    2. Keep just ImageURL and specify a Scale key, assumed to be 1 for backwards compatibility. You can specify any number and the image dimensions will be calculated within Kaju.

    The advantage of (1) is that you might get better looking images on each type of screen, but the software will have to download each image whether it needs it or not.

    The advantage of (2) is simplicity but you are relying on Xojo to scale the image where needed.

    Thoughts? Preferences?

  21. Kem T

    2 May 2018 Testers, Xojo Pro, XDC Speakers, MVP Connecticut

    I was given the advice "do the simplest thing", and I think that's sound. The simplest is to introduce the "Scale" key. Eventually most people will be on hi-res and we won't have to worry about it anyway.

  22. Newer ›

or Sign Up to reply!