Currently I'm looking at attempting a web request and seeing if that fails to determine if I'm online or not, but ideally it'd be nice if there was some hook in the OS that would alert me when I'm offline and go online.
Does anyone know if this is possible today?
It looks like the com.palm.connectionmanager has what you need:
http://webos101.com/Connection_Manager
http://webos101.com/Code_Snippets
Enjoy!
The links above point to the webOS101 site providing information on how to do this in Mojo. It is still valid in Enyo, but seemingly a little more work to get it going. In a Kind you have to add a component like this:
{name: "getConnMgrStatus",
kind: "PalmService",
service: "palm://com.palm.connectionmanager/",
method: "getStatus",
onSuccess: "statusFinished",
onFaulure: "statusFail",
onResponse: "gotResponse",
subscribe: true}
Then when you want to get the status make a call like this:
getStatus: function() {
this.$.getConnMgrStatus.call();
}
This code also subscribes you to the status so the onSuccess, onFailure, and onResponse functions will get called everytime there's a change. You may or may not want this. Be sure to add in those functions.
I'm still leaving Scott's answer as the answer because it lead to this approach in Enyo. Please comment if you have any tips.
Related
I'm having trouble with CodeMirror. I'm trying to add in live number scrubbing, similar to Brett Victor's example, and Khan Academy's capability, but I am not having too much luck.
I can't post links, but I found this library which kind of gets the job done (made by user FWeinb on GitHub) which can kind of accomplish what I'm looking for, but I've noticed that although the numbers appear to have been changed, as soon as I do something like press enter in CodeMirror, then the value of the variable resets to what it was originally.
I'm using ReactJS, and I am not too sure how to fix this. I'm trying something a little ludicrous by calling this.replaceRange every time the contents are being changed, but there must be a better way. Here is a snippet of my code. It's not what I want it to be ideally, but just for testing purposes:
this.cm.on('dblclick', this.handleDblClick.bind(this))
...
handleDblClick() {
let matches = document.querySelectorAll(".cm-number");
let scrub = new Scrubbing (matches[0],
{ driver :
[
Scrubbing.driver.Mouse,
Scrubbing.driver.MouseWheel,
Scrubbing.driver.Touch
]
})
matches[0].addEventListener('DOMSubtreeModified', () => {
//console.log('change detected')
})
}
So I know that currently the scrubber edits this: <span class="cm-number"></span>, but that the actual underlying data isn't updating with the scrubber, nor is it persisting. Can anyone shed some light on what I should be doing here so that the value of the variable within the editor is updating live with the scrubber, and so that the value persists upon a new action?
I'm building a LuisDialog and have LUIS integration working well.
In the cases where LUIS doesnt fill in all the gaps I need, what is the best approach for disambiguation?
Right now, I use PromptDialog callbacks - So inside a Dialog method (decorated with the LuisIntent attribute), when I need to get more details/disambiguate i'd have:
PromptDialog.Choice<string>(context, EnsureTimeOfDayChosen, new[] { "Morning (AM)", "Afternoon (PM)", "Any" }, "What time of day would you like us to book the appointment? (AM/PM/Any)", "Please choose AM or PM. Alternatively, if you don't mind which, just say Any.");
And the delegate's body (EnsureTimeOfDayChosen):
string AmPmOrAny = await result;
context.PerUserInConversationData.SetValue<string>("TimeOfDay", AmPmOrAny);
BookAppointment(context);
The problem with this approach is the last line of the delegate - it doesn't feel right. I can't easily call back into the place I was in the initially called, LuisIntent decorated method and resume.
Instead, I have to deal with the LUIS info up front, and call the BookAppointment method after gathering more info, and storing it in PerUserInConversationData.
Am I doing it wrong?
Any help would be greatly appreciated - Kind Regards,
Matt.
Given current implementation of the Dialog model, I cannot think of a better way of implementing your logic. Currently anytime that you are waiting on an async response from the user, your code will be resumed on the callback you provided upon response. You can think of it as Begin/End model for async programing
I have created a set of views by using ui-router.Then I write a run() function to listen a route issue like this:
$rootScope.$on('$viewContentLoading',function(evt,config){
console.log("one is loading!");
})
So I say I want to create a movement or some kind of animate during the view content is loading,but the code above just consoled nothing.
Then I try another state called $viewContentLoaded and do the same thing,and it worked,it consoled something as expected.
But why would these two issues behave differently?
Are you positive you're setting up listeners on the correct scopes? $viewContentLoading is broadcast on $rootScope while $viewContentLoaded is emitted from the local $scope.
This StackOverflow question may help shed some light on why the 2 act different and may help you figure out what's wrong:
$rootScope.$broadcast vs. $scope.$emit
Maybe you can also add a Plunkr showing the issue? I am unable to replicate this issue.
Say I am trying to save a Foo record to the back-end. For whatever reason, the back-end never returns (neither success nor failure).
From what I can see, it looks like foo stays in the "in flight" state. The problem with this state is it completely locks the record - you can't do anything on it (can't rollback, can't unload). I understand why it is like that (to try and keep things consistent). But is there something you can do about an edge case like this?
I've not tried this but you might find a solution by looking at ember-data's source code, specifically states.js: https://github.com/emberjs/data/blob/master/packages/ember-data/lib/system/model/states.js#L306-L351
Not sure there is a solid best practice here, but my best guess is that you can recover by sending becameInvalid to the model's stateManager.
Building on Mike's suggestion, I ended up with the following:
record.send('becameInvalid');
record.unloadRecord();
Mark Dalgleish wrote a nice little article about how to use promises in AngularJS views.
Some people asked questions about this in the comments, but Mark didn't answer them (yet). Because I'm asking me the same question, I will ask on StackOverflow instead to get an answer:
If you use promises in views, how do I handle "loading"/"waiting" indication, because they are async? Does a promise have something like a "resolved" or "withinRequest" property?
How do I handle errors? Normally they would arise in the second callback, but if I use a promise directly in the view I don't handle this case. Is there another way?
Thank you.
EDIT: as of angular v1.2 the resolution of promise in views is not activated by default.
The automatic resolution of promises in a view looks like a handy tool at first but it has number of limitations that need to be understood and evaluated carefully. The biggest issue with this approach is that it is AngularJS who will add callbacks to a promise and we've got little control over it.
Answering your questions:
1) As indicated, it is ultimately AngularJS who will add a success / error callbacks so we don't have much control here. What you could do is to wrap the original promise into a custom one that would track resolution. But this kind of deft the whole purpose of saving few keystrokes. And no, there is no things like 'resolved'. In short - there is no universal mechanism for tracking progress that would work for all promises. If your promises are $http-based you might use interceptors or pendingRequests property to track request in progress.
2) You can't. Once again, it is AngularJS that adds a handler inside the $parse service and it looks like this: promise.then(function(val) { promise.$$v = val; }); (see code here). You can see that only a success callback are added so all the failures are going to be silently ignored.
Those are not the only limitations of the automatic promise resolution in the view. The other problem is that promises returned by a function won't be resolved correctly. For example, if you would rewrite an example like so:
myModule.controller('HelloCtrl', function($scope, HelloWorld) {
$scope.messages = function() {
return HelloWorld.getMessages();
}
});
and try to use the following markup:
<li ng-repeat="message in messages()"></li>
things would work as expected, which might come as a surprise.
In short: while the automatic resolution of promises might seem like a handy shortcut it has number of limitations and non-obvious behaviors. Evaluate those carefully and decide if saving few keystrokes are worth it.