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

  1. ‹ Older
  2. last year
  3. Jon O

    19 Mar 2019 Testers, Xojo Pro Chicago Area USA
    Edited last year

    @Kem T I just got your email and, sure enough, the security token is missing. You must be using an old version of admin as that was introduced in 2.1.

    OK. So if I generate a new file with the new admin app, will the old 2.0 versions I have in the field be able to read it?

    I'll try generating a new file tomorrow. Time to get some shut-eye.

  4. Kem T

    19 Mar 2019 Testers, Xojo Pro, XDC Speakers, MVP Connecticut

    @Jon O Wow. I'm not trying to be a smart a## but you wrote the program and code and you don't know how to help me??

    Yes Jon, I wrote and released an open source project so you can help yourself. I am not your tech support, and now I'm done. Good luck.

  5. Jon O

    19 Mar 2019 Testers, Xojo Pro Chicago Area USA

    Kem,

    If you notice, I felt my reply was inappropriate and deleted it. You are correct that you are not my tech support. I'm simply looking for help from someone that knows my about the code than I do. I appreciate you taking the time to help me and I am sorry that I offended you.

    I was able to get it working with the file from the new admin app and the old 2.0 code still seems to read it fine. I'm seeing everything I should now.

    Jon

  6. Kem T

    20 Mar 2019 Testers, Xojo Pro, XDC Speakers, MVP Connecticut

    Accepted, moving on.

    Kaju was designed to ignore keys it didn't recognize knowing that future versions might add stuff. Backwards compatibility for each update is a requirement.

  7. Jon O

    20 Mar 2019 Testers, Xojo Pro Chicago Area USA
    Edited last year

    That's excellent to know. I have it working now with my site using HTTPS. Since I'm using AsyncUpdate, I have to add some more event handlers in the one case where my check was depending on synchronous operation, but that is easy enough to do.

    If it doesn't work now, then I must be doing something else wrong, but all the handling of when to bring up the update window, etc. is all done inside the Kaju code which I've not touched. So I'm hoping this fixes it. I don't know if Windows 10 requires HTTPS like OS X now does (I'm still on Win 7), but it's all secure now.

    Thank you for your help.

  8. Jon O

    20 Mar 2019 Testers, Xojo Pro Chicago Area USA

    @scott b the new mantra from the "security" folks is anything that uses non-HTTPS is bad bad bad bad. in their minds everything has to be "secured" or else.

    I thought about this some more last night and took a little different perspective. Perhaps it's not so much that anything anyone is doing on a site needs to be encrypted or secured, but knowledge that the site you are going to is the site you want and not something hijacked. The signed security certificate ensures that if someone visits my site, that they can be confident that they are on my site and not some hacked redirect to it. Therefore the software they download from it is valid and not some form of malware.

    Looking at it that way, I can understand why HTTPS everyone can be a good or desired thing.

  9. Jon O

    8 Apr 2019 Testers, Xojo Pro Chicago Area USA
    Edited last year

    Hey all,

    I've come across a hiccup in Windows with Kaju and using an secure Async socket. It seems that the PageReceived event is being fired multiple times until there's a stack overflow and the program crashes. This seems possibly to be a Xojo.Net.HTTPSocket thing as opposed to a Kaju thing because the error is happening in the PageReceived event HTTPSocketAsync object which is a Xojo.Net.HTTPSocket object.

    Has anyone else seen this happen and know a workaround or cause?

    What's really odd is that, when I first fire up the program, I have Kaju check for an update in the background. It's if I initiate a manual update that this socket seems to go nuts. Again, in OS X, it's fine. I don't have a problem. Just Windows.

  10. Tim P

    8 Apr 2019 Testers, Xojo Pro Rochester, NY

    @Jon O This seems possibly to be a Xojo.Net.HTTPSocket thing as opposed to a Kaju thing because the error is happening in the PageReceived event HTTPSocketAsync object which is a Xojo.Net.HTTPSocket object.

    Has anyone else seen this happen and know a workaround or cause?

    I saw that behavior on a project, but I did not have time to stop and investigate whether it was the Kaju implementation or a Xojo framework issue. It did not happen in 2018r4 or earlier.

  11. Jon O

    8 Apr 2019 Testers, Xojo Pro Chicago Area USA

    Thanks, Tim. I've figured out how to "stop" the behavior from crashing my app, and I found a couple of spots where I don't think I was coding some things properly. When I was operating synchronously, I created my Kaju.Updater object locally in a method. Then I waited for and returned the result. When I moved to an Async connection, I added handlers to handle the async events, but I messed up by still using just a locally scoped Kaju.Updater object. So the object technically goes out of scope when the method completes, but it's held in memory because of the events still existing. I'm not sure if this was feeding the problem, but it certainly isn't good coding form!

    So I'm still going through and trying to figure if there's something I'm doing or the Xojo.Net.HTTPSocket is doing. Ideally, I'd like to update things to URLConnections and I know Kem wants to do that too, but right now, I don't know if I have time to do it myself.

  12. Kem T

    8 Apr 2019 Testers, Xojo Pro, XDC Speakers, MVP Connecticut

    There are known bugs in HTTP socket in 2018r4 on Windows, so that might be what you're seeing.

  13. Jon O

    8 Apr 2019 Testers, Xojo Pro Chicago Area USA

    @Kem T There are known bugs in HTTP socket in 2018r4 on Windows, so that might be what you're seeing.

    OK. I have a feeling it might be. While my "out of scope" object was not good coding form, there's nothing with anything that I am doing (that I can see) that would cause the PageReceived event to fire non-stop.

  14. @Jon O OK. I have a feeling it might be. While my "out of scope" object was not good coding form, there's nothing with anything that I am doing (that I can see) that would cause the PageReceived event to fire non-stop.

    Indeed I have same issue, I'm using the Xojo.net.HTTPSocket for a simple app that controls a device to open a door and I do have another socket that checks the status of it , like a heartbeat but the problem is that some times the socket goes nuts and it kills the app after max 30 min, on Mac so far it is stable .

  15. Jon O

    8 Apr 2019 Testers, Xojo Pro Chicago Area USA

    @Aurelian N Indeed I have same issue, I'm using the Xojo.net.HTTPSocket for a simple app that controls a device to open a door and I do have another socket that checks the status of it , like a heartbeat but the problem is that some times the socket goes nuts and it kills the app after max 30 min, on Mac so far it is stable .

    OK. Well, what I have ended up doing is make sure that I remove the event handler for the socket as soon as I am done with it. This is most easily done setting up delegate methods and having a set method that you can just use to set the delegate to NIL. AddHandler and RemoveHandler work fine as well, but you have to be a little more specific with how you use them and wrap them in try/catch blocks so that you don't throw an exception if you've already removed the handler, etc.

    I've tested removing the event handlers and then adding them right back in to see if the socket is still going crazy. It isn't. Seems like as soon as the event handler is removed, the socket starts behaving itself.

  16. @Jon O OK. Well, what I have ended up doing is make sure that I remove the event handler for the socket as soon as I am done with it. This is most easily done setting up delegate methods and having a set method that you can just use to set the delegate to NIL. AddHandler and RemoveHandler work fine as well, but you have to be a little more specific with how you use them and wrap them in try/catch blocks so that you don't throw an exception if you've already removed the handler, etc.

    I've tested removing the event handlers and then adding them right back in to see if the socket is still going crazy. It isn't. Seems like as soon as the event handler is removed, the socket starts behaving itself.

    Hi Jon,

    Can you please provide an example for that ?

    I will see tomorrow the project and maybe put it somewhere , so far works nice on Mac but windows it's a nightmare .

    Thanks .

  17. Jon O

    8 Apr 2019 Testers, Xojo Pro Chicago Area USA
    Edited last year

    1.) In whatever object you have that calls the updater code, create a Delegate with the same signature as the event you want to handle (just like add handler):

    Private Sub delAsyncUpdateComplete(sender as UpdateCheckClass, result as Kaju.UpdateChecker.ResultType)

    2.) Create a property in this object of that type of delegate:

    Private Property AsyncUpdateCompleteCallBack as delAsyncUpdateComplete

    3.) Create a Handler Method for your Delegate:

    Private Sub HandleAsyncUpdateComplete(sender as UpdateCheckClass, result as Kaju.UpdateChecker.ResultType)
      If AsyncUpdateCompleteCallBack <> Nil Then
        AsyncUpdateCompleteCallBack.Invoke(Self,result)
      End If
    End Sub

    4.) Create a Set Method to set the callback for the delegate:

    Sub SetAsyncUpdateCompleteHandler(theCallback as delAsyncUpdateComplete)
      mUpdateCheckInstance.AsyncUpdateCompleteCallBack = theCallback
    End Sub

    5.) Set an initial AddHandler for the event in the constructor of your object:

    AddHandler AsyncUpdateComplete, AddressOf  HandleAsyncUpdateComplete

    Be sure to set a remove handler in your close event for the object.

    Now, wherever you want to use this update object, you can easily create a method, and set that method to be the event handler. No need to worry if AddHandler or RemoveHandler has been called. You can call do this anywhere you want:

    UpdateCheckClass.SetAsyncUpdateCompleteHandler(AddressOf UpdateCheckCompleteEvent)

    So my object that does all the checking is called UpdateCheckClass and it's actually a Singleton so I can call it anywhere in the app and I don't have to worry about instantiating it (and in the case of a Singleton, the method in step 4 is actually a Shared Method.

    My UpdateCheckComplete event has the following singature/code:

    Public Sub UpdateCheckCompleteEvent(u as UpdateCheckClass, UpdateResult as Kaju.UpdateChecker.ResultType)
    
      UpdateCheckClass.SetAsyncUpdateCompleteHandler(Nil)  // HERE IS WHERE I REMOVE THE HANDLER
     
      Select Case UpdateResult  
      Case Kaju.UpdateChecker.ResultType.Error
        MsgBox "There was an updater error."
      Case Kaju.UpdateChecker.ResultType.IgnoredUpdateAvailable
        MsgBox "There is an update available but you have chosen to ignore it."
      Case Kaju.UpdateChecker.ResultType.NoUpdateAvailable
        MsgBox "No update is available at this time."+EndOfLine+EndOfLine+"You have the most current version."
      Case Kaju.UpdateChecker.ResultType.UpdateAlreadyInProgress
        MsgBox "There is an update already in progress."
      End Select
    End Sub

    So basically as soon as the event handler method is called, I then remove it.

    I've got one more layer of an event in here from the socket that uses a traditional Add/Remove Handler directive, but I'm going to skip that. This should be enough to get you going. If not, I can try to throw my code into a project for you.

    So this is specifically for the Kaju Updater object I am working with. Your case may be a different class, but the same principles still apply. The PageReceived event of the Xojo.Net.HTTPSocket is the offending event. So I would use what I do above for that event in your HTTPSocket. It's signature is:

    Event PageReceived(url As String, httpStatus As Integer, content As String)

    So create the Delegate and necessary handler methods and callbacks with this signature and then you can add/remove the event at will in code. It's pretty cool.

  18. Tim P

    10 Apr 2019 Testers, Xojo Pro Rochester, NY

    This looks like the problem I saw, so it doesn't look like it's a Kaju problem :)
    https://forum.xojo.com/53353-net-httpsocket-pagereceived-problem

  19. Jon O

    10 Apr 2019 Testers, Xojo Pro Chicago Area USA

    Yeah, I don't think it's a Kaju thing. I posted wondering if others had seen the same or if my implementation was causing an issue. Looks like others have seen the same thing. Dale is definitely correct.

  20. Thomas R

    8 May 2019 Testers, Xojo Pro Berlin, Germany

    Hi,

    I am trying to use Kaju in my first Xojo project, but ran into a problem, I can't solve...

    Environment:
    Xojo 2019R1 on macOS 10.14.4
    Kaju 2.1

    Implemention is done completly, version set to "0.5.0" under ""Build Settings > Shared > Version" (Major Version: 0, Minor Version: 5, Bug Version: 0, Stage Code: Development, Non Release Code: 1". plist in build app shows 0.5.0 as versionstring.

    Kaju Admin is set up with correct App Name, version "0.5.1", with releasenotes, a Mac binary and a windows 64-bit binary. HTML file and binaries are uploaded to website and path and RAS Key are put into app.

    Checking for updates works fine in debug mode - Kaju finds the update from 0.5.0 to 0.5.1 and displays its update window.
    But in the build app it does not find any update. Even testing with the "WndTst" Window and manually entering all neccessary infos (URL and RSA Key) it checks the html file and says: "no update available".

    Any tips, how to solve this?

    Regards,
    Thomas

  21. Kem T

    8 May 2019 Testers, Xojo Pro, XDC Speakers, MVP Connecticut

    Just for testing, try changing the Major Version to 1 instead of 0 and see if that makes a difference. I mean in both the compiled app and the update info.

  22. Newer ›

or Sign Up to reply!