I have similar problem as in this thread MobileFirst 8.0 Direct Update failing after downloading the updates
The app is working fine if there is no direct update available. I have also performed the suggested items from the above thread. But the problem persist.
Once I accept the update, the application will reload, internally it will call WLAuthorizationManager.obtainAccessToken again, however this time it will return error with the error code "CHALLENGE_HANDLING_CANCELED"
Does anybody has any suggestions what could go wrong?
This is an expected behaviour during direct update as the contents of the app gets changed after the direct update and this invokes failure callback in WLAuthorizationManager.ObtainAccessTokenAPI.
Soon after direct update, the application reloads. WLAuthorizationManager.ObtainAccessTokenAPI makes a call and returns success if the connectivity between server and client is proper.
Related
I'm using worklight application management features from an Android native App.
I want that when in the console the application status is changed to "Access Disabled" the only option for the user will be to quit.
In the Knowledge Center and in Developer works there is documentation about how to do it:
http://www-01.ibm.com/support/knowledgecenter/SSZH4A_6.2.0/com.ibm.worklight.appadmin.doc/admin/t_denying_access_to_older_app_versions.html?lang=en
https://www.ibm.com/developerworks/community/blogs/worklight/entry/how_to_create_a_customized_remote_disable_behavior?lang=en
It is explained that you must set a specific value for the initOptions object used in the WL.Client.init() method.
But in the Android native API I have not found the way to set the initOptions. The init method is deprecated and it does not accept initOptions.
Also, in case of Remote Disable the ResponseListener used in the WLClient.connect(aResponseListener) is not invoked, success or failure, no method is executed. Is this working as designed? I would expect a failure or success but not nothing.
Is it possible in a native app to force the application to close in case of Remote Disable?
How could I handle this situation manually in the app?
Unfortunately I do not have an example for you, but this is the general idea.
See if you can work with it (if someone can produce an example - please do...):
You need to create your own Remote Disable challenge handler that will extend the default Worklight Remote Disable challenge handler (RemoteDisableChallengeHandler.java).
class MyRemoteDisableChallengeHandler extends WLRemoteDisableChallengeHandler
Then you need to implement your custom logic in MyRemoteDisableChallengeHandler
WLClient.registerChallengeHander(new MyRemoteDisableChallengeHandler())
This will override the original.
You'll need to create your own dialog with a Quit button.
Some additional documentation.
For handling MaM configurations, this is, when you configure the app as Lost, Stolen, etc, in the Worklight Console -> Devices tab you must install the Fix IF201408281937 (Worklight 6.2) or later.
This events are also handled with the ChallengeHandler registered for the realm "wl_remoteDisableRealm"
I'm using singalr library to develop a real time notification web site using MVC 4.
My web app will run on several web servers so I need to manage connections using a db.
Every thing goes Ok exept that the OnDisconnected method is not fireing in all web browser.
It seems to work fine with firefox but using IE9 and all mobile browsers it nevers fires.
So here's my question, I don't won't to rely on this method and end up with lots of unused connections in my db. Besides, even if the Ondisconnected method will work find there is a chance that the server will go down and these unused connection will remain in the db.
I was thinking of a background method that will run every 1 minute let's say and compare the db's connections against the current connections.
The problem is that I don't know how to implement that or is it the best way to do so.
Is there a way to get all valid connection so I can compare with the db?
Thanks in advance
The OnDisconnected method should ALWAYS fire for every browser. However, when the OnDisconnected method fires may vary.
Here is the process that SignalR goes through when triggering the OnDisconnected method:
SignalR binds to the unload event of the browser and attempts to send an AJAX request to the server to notify it that the client is going away (disconnecting). IF that AJAX request successfully reaches the server the OnDisconnected method will be triggered immediately. IF that AJAX request fails to reach the server due to network conditions or other unseen conditions then the OnDisconnected will not fire UNTIL the ConnectionTimeout (configuration) has elapsed.
Soooo long story short, OnDisconnected should always eventually fire for every client and every browser. If it does not you should absolutely file an issue on GitHub.
Hope this helps!
Using the Worklight v5.0.6 code sample/tutorial "Integrating server-generated pages in hybrid applications" (http://public.dhe.ibm.com/software/mobile-solutions/worklight/docs/v506/WebViewOverlay.zip) allows for the web content to be integrated. The code sample works fine and web content integrated correctly.
However, when I set connectOnStartup to true in the apps//common/js/initOptions.js file, the tabs and web content from the WebViewOverlay fail to load.
I see in the wlclient.js (apps//android/native/assets/www/default/wlclient/js/wlclient.js) that there is a check that if doConnectionOnStartup is true, then call WL.Utils.wlCheckReachability(), else call finalizeInit()
It appears that the WebViewOverlay and the tabs are created by the finalizeInit() being called, but if connectOnStartup is set true, then finalizeInit is not called.
How can I get both the WebViewOverlay to work and the connectOnStartup to work together?
This is, most probably, caused by connection failure. wlCommonInit function will be invoked only after successful connection, in case connection fails it will never be invoked. First of all - check your connectivity from a mobile handset to WL server. Second, you can either manually use WL.Client.connect() after tabbar was initialized (like Carlos suggested) or specify onConnectionFailure callback in your initOptions.
I provided what I did above in the comments - but it turned out that the dialog box to indicate an update was available was not showing up, and instead the error message "WL.SimpleDialog.show() error in invoking callback." was seen in the log messages of logcat. This log message is coming from worklight.js (apps//android/native/assets/www/default/wlclient/js/worklight.js) on line 820. Just FYI, I did change the worklight.js code to print out err, and it said "No class found". I didn't take the troubleshooting any further at that point
So the app was contacting the WL Server correctly, but the dialog to indicate an update was available was not appearing.
To fix, I simply created a new hybrid app and brought over the necessary code to get the WebViewOverlay to work
My SL application is commercial and working just fine on hundreds of machines.
SL is using a WCF service and it works as expected, but today I observed behavior on client machine, where literally no call is made to server.
After you click button that sends a call, some error occures, and no record about WCF call is created in Fiddler.
Error is:
[HttpWebRequest_WebException_RemoteServer]
Arguments: NotFound
Debugging resource strings are unavailable...
I read about this error that people recommend to use Fiddler, but as I say there is no call displayed in Fiddler
So problem is worse than I thought initially.
It comes and goes. Currently we have found a working solution that fixes the problem after it appears although it doesn't make any sense to me.
For example if I get this error in chrome & mozilla & OOB version,
launching a program in IE works, and after that chrome,mozilla & OOB
start to work too.
Thing is that same people who had this problem solved with this workaround experience it again in some days, like a week, with no apparent reason, and then combination of launches from various locations helps (usually IE helps the most).
Any help appreciated, I start a bounty as its pretty sick bug and I need to fix it somehow.
Update
Weird IE fix scenario:
At some point OOB version gets into state where it doesn't send any WCF request to server.
(fiddler doesn't see it, server doesn't gets it).
After launching web version in IE, and hitting the same button, that sends WCF request we get desired result in IE web version.
Without changing anything else, just relaunching OOB version which was in this buggest state before, makes OOB version work correctly. Its not reinstalled, not changed - nothing.
This is what I call "IE cure" of this problem.
So the question is what can IE launch potentiall change for OOB version?
According to this thread the message Debugging resources are unavailable appears when de client is not using the the Silverlight Developer Runtime.
This means that the actual exception is hidden from you (and us) so the next step is to reproduce the error on a system that has the Silverlight Developer Runtime.
I found this article. It might be worth it to check the certificate you are using (are you using a certificate) It is one of those things that is different with OOB apps and browsers.
I've deployed an application inside a corporate network and I want the update process to require less attention from users, similar to how Google Chrome install updates - in the background. I don't need to give the user a choice to update.
I've used the System.Deployment library to detect when new ClickOnce updates are available and install them automatically. I'm wondering if its necessary to restart the app after the update is complete. Currently I invoke Application.Restart() at the end of my update script.
But what if (to make the update process more transparent for the user) I performed a 'silent' async update and then displayed an icon prompting the user to restart the app to apply the changes? Would this make the app unstable in any way?
Furthermore, if I ran my custom InstallUpdate() process on a timer, say every 30 minutes, would ClickOnce be stable to continue to update for every new version that was released even thought the user has not restarted (nb: I'm expecting the updates to only apply once the user restarts the app)?
I would think it depends on what your application does at startup, and what it's doing when the update is installed and the application is restarted, and what the update contains. You could try running it and then attaching a debugger to it and see what it's doing and what impact it has.
For example, our application loads a lot of information into memory when it starts up. If the update included a change to one of the data structures, and the app didn't reload the data for some reason, it would cause a problem.
After a few years of doing it like this, we have found that it is possible to silently install updates this way. However there are a few issues to be aware of:
If the thread terminates prematurely during the Update() (eg: the user exits out of the app while the updating is in progress), the install will become corrupt and the next time the user loads the app, the ClickOnce normal deployment will fire off and re-install the app.
The user's desktop icons always redraw (flicker) after an update is installed.
Calling ApplicationDeployment.CurrentDeployment.CheckForUpdate() more than 65536 times causes a System.NullReferenceException Source.
An alternative is not to actually check for an update, I have found that this locks one of my dlls and prevented a form from loading, so use with care:
If ApplicationDeployment.CurrentDeployment.Update Then ' update app
console.writeline("update installed")
' code to inform user update was sucessfull and they need to restart
End If
If your ClickOnce project is 32bit, and you run it on an x64 platform, any file associations your app has will break after performing a manual ClickOnce update. See this MS support case for more details.