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

  1. ‹ Older
  2. 3 years ago

    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.

  3. 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.

  4. Tim P

    7 Dec 2017 Testers, Xojo Pro Rochester, NY

    With a 301 or 302?

  5. 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.

  6. Phillip Z

    7 Dec 2017 Testers, Xojo Pro Florence, SC
    Edited 3 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.
  7. Kem T

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

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

  8. 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 ;)

  9. Michel B

    27 Dec 2017 Testers, Xojo Pro
    Edited 3 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" :(

  10. 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.

  11. Michel B

    27 Dec 2017 Testers, Xojo Pro

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

  12. Kem T

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

    Are you using the latest version of the project?

  13. Michel B

    27 Dec 2017 Testers, Xojo Pro

    I got it from the git.

  14. 2 years ago

    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?

  15. 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.

  16. scott b

    6 May 2018 Testers, Xojo Pro local coffee shop

    @Kem T 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.

    simplest and most straight forward path is the best way to go.

  17. Beatrix W

    17 May 2018 Testers, Third Party Store Europe (Germany)

    So I've finally gotten an SSL certificate for my main websites. Now Kaju (I think the current version still uses 1.x) complains about an incorrect packet marker on this code here:

    dim sig as string = firstLine.Left( Kaju.kUpdatePacketMarker.Len )
      if StrComp( sig, Kaju.kUpdatePacketMarker, 0 ) <> 0 then
        if HandleError( KajuLocale.kErrorIncorrectPacketMarker ) then
          continue do
        else
          exit do
        end if
      end if

    When checking the result there is a 301 redirect. The problem is that all old versions now will have the same hissy fit. Is there something I can do on my website to fix this?

  18. Kem T

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

    Just so I understand the situation...

    Your app points to http://path/to/update which returned the update information. Now it wants to redirect to https://path/to/update but AllowRedirect is set to false in the app so it's not following it. Is that it?

    The only thing you can do is make sure the current url returns the update information and put a new url into the new version that uses the certificate. Also turn on AllowRedirect to prevent this in the future.

  19. Beatrix W

    17 May 2018 Testers, Third Party Store Europe (Germany)

    Yes, you understood correctly. AllowRedirect is set to false. Most likely I never thought I would have to use this property.

    The support from my hosting company told me to remove the automatic redirect from http to https and then muck around with the htaccess file myself and then exclude the update file. Perhaps I'll try this tomorrow.

  20. Kem T

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

    I'm curious because I'm thinking of changing that default to True instead...

    Did you intentionally set it to false, or did you just let it use the default? If the latter, was that intentional, or did you just ignore it?

    My original thinking was about security, but now I see that this situation can become common if users didn't know or think about that property.

    BTW, the develop branch contains new code around the new framework HTTPSocket, and that does not give you the option, it will always follow redirects.

  21. Beatrix W

    17 May 2018 Testers, Third Party Store Europe (Germany)

    I just never noticed this property.

  22. Newer ›

or Sign Up to reply!