I'd like to know what the best approach is to delay the loading of my model data till after an animation has completed.
In my application I'm listening to changes to the route. Then, when a certain route is matched, I open a panel with an animation. But I'd like the loading of the data to start after the animation completed.
Here's how I listen to the route:
App.ApplicationController.reopen({
currentPathChanged:function() {
App.panelView.setNeedsOpen(this.get('currentPath') == 'index' ? false : true);
}.observes('currentPath')
});
And this is one of the routes that is called when the panel has to open:
App.NewsitemsRoute = Ember.Route.extend({
model: function() {
return App.Newsitem.find();
}
});
But as you can see, the data gets preloaded when the animation is still running. How should I solve this?
I would not at all delay loading itself as you should use this precious time to load data in background and 'distract' the user with the animation.
So why are you not showing the animation but load the data in parallel and as soon as the animation is finished you remove the corresponding dom revealing the rendered data?
Related
I am using a Column chart from the Google Visualization API, and have set up a "click" event for when I click on one of my columns as so:
google.visualization.events.addListener(chart, 'select', function(event) {
if (!isWebview) {
log.logInfo("Selected Sum");
$("#reportBody").trigger("app:update", { toXYZ: true});
} else {
}
});
However, this fires 4 times every time that I select a bar in the chart. This also happens to be the amount of rows that I have in the chart - could this be connected?
Thanks in advance.
Answer:
I found the problem - there were two. Firstly, the html file for this js file loaded the same js code twice - once for ios and once for android, but on the browser loads both, thus adding the same event listeners twice.
Furthermore, both these ways of setting the onLoad callback were used:
google.charts.load('visualization', '1', {
'packages': ['corechart', 'table'],
'callback': drawAll
});
and
google.setOnLoadCallback(drawAll);
The latter of which is a deprecated version if I'm not mistaken.
Therefore, the drawAll function, which creates the event listener, ended up being called 4 times, so I had 4 event listeners for the same event, all executing the same code.
I'm building a custom Chromecast receiver based on the [CAF SDK][1]. I've tried to set the receiver application in IDLE state mode for handling the splash screen during the 5 minutes after the media has ended...
I tried to use :
var video = document.createElement("video");
video.classList.add('castMediaElement');
video.style.setProperty('--splash-image', 'url("img/logo-mySplash.svg")');
document.body.appendChild(video);
var context = cast.framework.CastReceiverContext.getInstance();
context.setInactivityTimeout(300);
playerManager.addEventListener(cast.framework.events.EventType.ALL,
function (event) {
switch(event.type) {
case 'CLIP_ENDED':
context.setApplicationState('IDLE');
break;`
}
})
When the media ended, the receiver dispatches :
{type: "CLIP_ENDED", currentMediaTime: 2673.986261, endedReason: "END_OF_STREAM"}
{type: "MEDIA_FINISHED", currentMediaTime: 2673.986261, endedReason: "END_OF_STREAM"}
and sends error to debug console :
[ 32.846s] [cast.receiver.MediaManager] Unexpected command, player is in IDLE state so the media session ID is not valid yet
I can't find any documentation about this issue. Thanks anyway for your answers.
The context.setApplicationState simply updates the application's statusText. See: https://developers.google.com/cast/docs/reference/caf_receiver/cast.framework.CastReceiverContext#setApplicationState.
What you probably want to do is add a listener to the playerDataBinder on cast.framework.ui.PlayerDataEventType.STATE_CHANGED event. This way you can make your idle screen visible whenever the state property changes.
Also, in order to get the full advantage of using CAF you probably want to to use the cast-media-player element. Additional information on the benefits of using this element instead of a custom video element can be found here: https://developers.google.com/cast/docs/caf_receiver_features
What is the best technique to generically change to a busy cursor during transition to a new route in Ember.js (1.13.10)? With data retrieval, this may take a couple of seconds.
The answer here indicates a method to do this with saving data:
Changing mouse cursor while Ember content is saving
...and indicates this is very straight forward with route transitions, but I can't seem to find an example or anything in the documentation.
Thanks in advance for any help on this.
We can use loading hook of Route.
app/routes/application.js:
import Ember from 'ember';
export default Ember.Route.extend({
actions: {
loading(transition, route) {
$('body').css({ cursor : 'wait' });
this.router.one('didTransition', () => {
$('body').css({ cursor: 'default' });
});
return true; // Bubble the loading event
}
}
});
Working demo. (output is sandboxed so make sure your mouse is over body in output window)
Full code behind demo.
I've used $('body') as element to style cursor. You can probably use more global approach.
So, I was hoping to be able to create a helper (master) view for my application, the main reason is that I want to implement a resize function.
Example.
App.View = Ember.View.extend({
init: function() {
$(window).resize(this.resize.bind(this));
this._super();
}
});
And then extend it
App.AmazingView = App.View.extend({
resizing: false,
resize: function() {
this.set('resize', true);
}
});
So, that's an example of what I wanted to achieve, but unfortunately it causes some problems.
If I go to the route that is using the Amazing view then everything works fine, it's only until you navigate around the application after and then return to that same route I face the following error.
Uncaught Error: Something you did caused a view to re-render after it rendered but before it was inserted into the DOM.
I'm pretty sure this is happening because I'm extending that view, any ideas on why this happens or what I should actually be doing?
When you do $(window).resize(this.resize.bind(this)); you are attaching an event not managed for ember. When you leave the view, transitioning to other route, ember will cleanup event listeners and destroy the view. Now your view is in a "dead" state. But the resize handler is still present and when it triggers, a change is performed in a dead view. I think that it is causing your problem.
You can use the didInsertElement and willClearRender to bind and unbind your event.
App.View = Ember.View.extend({
_resizeHandler: null,
didInsertElement: function() {
this._super();
// we save the binded resize function to keep the identity, so unbind will remove
this._resizeHandler = this.resize.bind(this);
$(window).bind('resize', this._resizeHandler);
},
willClearRender: function() {
this._super();
$(window).unbind('resize', this._resizeHandler);
}
});
This sound like a feature that would fit perfectly into an ember mixin. This solution would offer more flexibility, then you could extend other views and also provide the resize features...
http://emberjs.com/api/classes/Ember.Mixin.html
I am trying to get my head round the connectOutlet method and when a view that is returned from connectOutet is actually inserted into the DOM.
The view that is created in connectOutlet leaves connectOutlet in the preRender state.
connectOutlet: function(name, context) {
// method body
view = this.createOutletView(outletName, viewClass);
if (controller) { set(view, 'controller', controller); }
set(this, outletName, view);
return view;
}
I've not tracked down where or when the view is inserted into the Dom and the view transitions to the inDom state.
I suspect the runloop is at play and it transitions after the current runloop has finished.
Can anyone shed any light on this?
The run loop is indeed in play here. The run loop processes events by draining an ordered collection of queues. In order, they are: sync, actions, render, afterRender, destroy, and timers. View rendering is where the view is actually inserted into the DOM and it is always scheduled on the render queue.
If you have other questions about this, leave a comment, and I will be happy to expand this answer to cover them.