This is really common that i want to know an action is done and then do sth after that. for this we usually use events but i don't know how to use it in my case.
my scenario: There is an SplashScene which shows some animations for a constant time, after that time i navigate to my HomeScene. there are some other initializations which i don't want to be done unless SplashScene is gone and we r in HomeScene.
those initializations are in App component. and what im doing is that because the SplashScene animation time is constant i use a timeout to init things.
// Constants.ts
export const GlobalStaticData = {
initialDuration: 5000 // ms
}
// App
public componentDidMount() {
setTimeout(() => {
// initialize things
}, GlobalStaticData.initialDuration) // show dialogs after splash loading time
}
// SplashScene
private onAnimationEnd = () => {
NavigationActions.navigate(HomeScene)
}
but i know this is not good at all, i already experience sometimes which timing doesn't work as expected and things get initialized when app is still in SplashScene.
i was thinking for way to use events but i dont know how do that. what i want to listen to a value e.g called isSplashLoadCompleted in App component and in splash change that value when its works are done. then in App its event listener is called and initialing get started.
You can write a basic event system to subscribe to an event and then emit the event when certain thing happened on the other page:
const subscribers = {}
// Subscribe to loading your target page here Ex subsciber('home_load',()=>{ Your Logic })
const subscribe = (event,callback)=>{
if(subscribers[event] == null){ subscribers[event] = {}}
subscribers[event].push(callback)
}
const unSubscribe = (event,callback)=>{
....
}
// Call this inside your target page componentDidMount Ex: emitEvent('home_load',Some data or null)
const emitEvent = (event,data)=>{
if(subscribers[event]!=null && subscibers[event].length > 0){
for(const cb of subscribers[event]){
if(cb != null){cb()}
}
}
}
Sounds like the you want to trigger specific code when different scenes are loaded. I would recommend moving your animation/initialization logic into the compomentDidMount() for the respective scenes - SplashScene and HomeScene.
You're running into issues because your animation/initialization code is completely decoupled from your scenes. Couple the logic to the componentDidMount for these scenes and you won't have to worry about timing issues.
Related
I'm new to Dart/Flutter and would like to build a simple app where a LinearProgressBar gets updated every second.
Without getting too much into the actual code, I have the following setup working.
A function that calculates the progress, based on passed time.
A LinearProgressBar showing the progress.
A periodic Timer recalculating the progress and updating the progress bar every second.
I debugprint 'tick' every time, the recalculation is done.
Everything is working as expected with one exception. The 'tick' keeps getting printed when I move the app in the background on my Android device.
On native Android, I would cancel my periodic Timer when the 'onPause' event is triggered.
Is there something similar in Flutter? All I could find was 'initState' and 'dispose'. Dispose, however, does not get called when moving the app to background.
I don't want the timer to keep ticking in the background.
On my research, I found this Stack Overflow question onresume-and-onpause-for-widgets-on-flutter. It's answer suggests using TickerProviderStateMixin.
I used it the following way.
class _BarItemState extends State<BarItem> with SingleTickerProviderStateMixin {
Ticker ticker;
num progress = 1.0;
#override
void initState() {
super.initState();
ticker = createTicker((duration) => setState(() {
debugPrint('tick');
progress = duration.inSeconds / 30;
}))
..start();
}
// other stuff omitted
}
It is working, but I'm still not satisfied.
The reason is, that the ticker callback is getting now called every few milliseconds instead of once a second. This seems to me like a waste of resources (I don't need a smooth animation), ... am I overcomplicating things?
Even if it seems that I don't need it for my use case, I still would like to know:
How to handle the onPause/onResume events on my own?
You can override the didChangeAppLifecycleState of the WidgetBindingObserver interface to receive notifications for app lifecycle changes.
There's sample code in this page
You can use lifecycle channel from SystemChannels.
Example:
SystemChannels.lifecycle.setMessageHandler((msg){
debugPrint('SystemChannels> $msg');
});
Output:
I/flutter ( 3672): SystemChannels> AppLifecycleState.paused
I/flutter ( 3672): SystemChannels> AppLifecycleState.resumed
Can a "pure" HTML5/Javascript (progressive) web application intercept the mobile device back button in order to avoid the App to exit?
This question is similar to this one but I want to know if it is possible to achieve such behavior without depending on PhoneGap/Ionic or Cordova.
While the android back button cannot be directly hooked into from within a progressive web app context, there exists a history api which we can use to achieve your desired result.
First up, when there's no browser history for the page that the user is on, pressing the back button immediately closes the app.
We can prevent this by adding a previous history state when the app is first opens:
window.addEventListener('load', function() {
window.history.pushState({}, '')
})
The documentation for this function can be found on mdn:
pushState() takes three parameters: a state object, a title (which is currently ignored), and (optionally) a URL[...] if it isn't specified, it's set to the document's current URL.
So now the user has to press the back button twice. One press brings us back to the original history state, the next press closes the app.
Part two is we hook into the window's popstate event which is fired whenever the browser navigates backwards or forwards in history via a user action (so not when we call history.pushState).
A popstate event is dispatched to the window each time the active history entry changes between two history entries for the same document.
So now we have:
window.addEventListener('load', function() {
window.history.pushState({}, '')
})
window.addEventListener('popstate', function() {
window.history.pushState({}, '')
})
When the page is loaded, we immediately create a new history entry, and each time the user pressed 'back' to go to the first entry, we add the new entry back again!
Of course this solution is only so simple for single-page apps with no routing. It will have to be adapted for applications that already use the history api to keep the current url in sync with where the user navigates.
To do this, we will add an identifier to the history's state object. This will allow us to take advantage of the following aspect of the popstate event:
If the activated history entry was created by a call to history.pushState(), [...] the popstate event's state property contains a copy of the history entry's state object.
So now during our popstate handler we can distinguish between the history entry we are using to prevent the back-button-closes-app behaviour versus history entries used for routing within the app, and only re-push our preventative history entry when it specifically has been popped:
window.addEventListener('load', function() {
window.history.pushState({ noBackExitsApp: true }, '')
})
window.addEventListener('popstate', function(event) {
if (event.state && event.state.noBackExitsApp) {
window.history.pushState({ noBackExitsApp: true }, '')
}
})
The final observed behaviour is that when the back button is pressed, we either go back in the history of our progressive web app's router, or we remain on the first page seen when the app was opened.
#alecdwm, that is pure genius!
Not only does it work on Android (in Chrome and the Samsung browser), it also works in desktop web browsers. I tested it on Chrome, Firefox and Edge on Windows, and it's likely the results would be the same on Mac. I didn't test IE because eew. Even if you're mostly designing for iOS devices that have no back button, it's still a good idea to ensure that Android (and Windows Mobile... awww... poor Windows Mobile) back buttons are handled so that the PWA feels much more like a native app.
Attaching an event listener to the load event didn't work for me, so I just cheated and added it to an existing window.onload init function I already had anyhow.
Keep in mind that it might frustrate users who would actually want to really Go Back to whatever web page they were looking at before navigating to your PWA while browsing it as a standard web page. In that case, you can add a counter and if the user hits back twice, you can actually allow the "normal" back event to happen (or allow the app to close).
Chrome on Android also (for some reason) added an extra empty history state, so it took one additional Back to actually go back. If anyone has any insight on that, I'd be curious to know the reason.
Here's my anti-frustration code:
var backPresses = 0;
var isAndroid = navigator.userAgent.toLowerCase().indexOf("android") > -1;
var maxBackPresses = 2;
function handleBackButton(init) {
if (init !== true)
backPresses++;
if ((!isAndroid && backPresses >= maxBackPresses) ||
(isAndroid && backPresses >= maxBackPresses - 1)) {
window.history.back();
else
window.history.pushState({}, '');
}
function setupWindowHistoryTricks() {
handleBackButton(true);
window.addEventListener('popstate', handleBackButton);
}
This approach has a couple of improvements over existing answers:
Allows the user to exit if they press back twice within 2 seconds: The best duration is debatable but the idea of allowing an override option is common in Android apps so it's often the correct approach.
Only enables this behaviour when in standalone (PWA) mode: This ensures the website keeps behaving as the user would expect when within an Android web browser and only applies this workaround when the user sees the website presented as a "real app".
function isStandalone () {
return !!navigator.standalone || window.matchMedia('(display-mode: standalone)').matches;
}
// Depends on bowser but wouldn't be hard to use a
// different approach to identifying that we're running on Android
function exitsOnBack () {
return isStandalone() && browserInfo.os.name === 'Android';
}
// Everything below has to run at page start, probably onLoad
if (exitsOnBack()) handleBackEvents();
function handleBackEvents() {
window.history.pushState({}, '');
window.addEventListener('popstate', () => {
//TODO: Optionally show a "Press back again to exit" tooltip
setTimeout(() => {
window.history.pushState({}, '');
//TODO: Optionally hide tooltip
}, 2000);
});
}
i did not want to use native javascript functions to handle this inside of a react app, so i scoured solutions
that used react-router or react-dom-router, but in the end, up against a deadline, native js is
what got it working. Added the following listeners inside inside componentDidMount() and setting the history
to an empty state
window.addEventListener('load', function() {
window.history.pushState({}, '')
})
window.addEventListener('popstate', function() {
window.history.pushState({}, '')
})
this worked fine on the browser, but was still not working in the PWA on mobile
finally a colleague found out that triggering the history actions via code is what somehow initiated the listeners
and voila! everything fell in place
window.history.pushState(null, null, window.location.href);
window.history.back();
window.history.forward();
In my case, I had a SPA with different drawers on that page and I want them to close when User hits back button..
you can see different drawers in the image below:
I was managing states(eg open or close) of all drawers at a central location (Global state),
I added the followin code to a useEffect hook that runs only once on loading of web app
// pusing initial state on loading
window.history.pushState(
{ // Initial states of drawers
bottomDrawer,
todoDetailDrawer,
rightDrawer,
},
""
);
window.addEventListener("popstate", function () {
//dispatch to previous drawer states
// dispatch will run when window.history.back() is executed
dispatch({
type: "POP_STATE",
});
});
and here is what my dispatch "POP_STATE" was doing,
if (window.history.state !== null) {
const {
bottomDrawer,
rightDrawer,
todoDetailDrawer,
} = window.history.state; // <- retriving state from window.history
return { // <- setting the states
...state,
bottomDrawer,
rightDrawer,
todoDetailDrawer,
};
It was retriving the last state of drawers from window.history and setting it to current state,
Now the last part, when I was calling window.history.pushState({//object with current state}, "title", "url eg /RightDrawer") and window.history.back()
very simple,
window.history.pushState({//object with current state}, "title", "url eg /RightDrawer") on every onClick that opens the drawer
&
window.history.back() on every action that closes the drawer.
I am trying to implement a State Machine into my Android game (note that it is not a game that needs to be constantly redrawn with a UI as it just works using standard Android Activity structure). I have found this example below of how you can implement a State Machine with a switch statement:
main() {
while(true) {
collectInput(); // deal with common code for filling in keyboard queues, determining mouse positions, etc.
preBookKeeping(); // do any other work that needs constant ticks, like updating streaming/sound/physics/networking receives, etc.
runLogic(); // see below
postBookKeeping(); // again any stuff that needs ticking, but would want to take into account what happened in runLogic this frame, e.g. animation/particles/networking transmit, etc
drawEverything(); // any actual rendering actions you need to take
}
}
runLogic() {
// this is where you actually have a state machine
switch (state) {
case WaitingForInput:
// look at the collected input and see if any of it is actionable
case WaitingForOpponent:
// look at the input and warn the player that they are doing stuff that isn't going to work right now e.g. a "It's not your turn!" notification.
// otherwise, use input to do things that might be valid when it's not the player's turn, like pan around the map.
case etc:
// a real game would have a ton more actual states, including transition states, start/end/options screens, etc.
}
}
Whilst transitioning my game from the loop below to the State Machine, I am having issues. If say from this main game Activity, I launch another Activity in order to ask the player a question (happens inside playTurn()), I will then obviously utilise onActivityResult() and return the player's answer to the main game Activity. How should I handle the return of the player's answer and allow the code to then continue running in playTurn(), inside the main playGame() loop, without breaking the while loop flow? The only way I actually can figure out is by utilising a while loop inside playTurn() that simply keeps looping whilst the answer is 0 but that seems horrifically wasteful. Thanks in advance, any help is appreciated!
public void playGame() {
initialise();
boolean finished = false;
while (!finished) {
playTurn();
// Check if there is a winner after each turn is played
boolean winner = winner();
if (winner) {
finished = true;
}
}
}
I am developing android application with Titanium, android sdk 1.8.0.1.In my application there are three tabs.Every Time when I click on tab my window get refreshed.So my code structure looks like:
////// on tab click /////////////////////
var explore = Titanium.UI.createWindow(
{
//navBarHidden:true,
backgroundColor:'#f8f8f8'
});explore.open({animated:true});
////// m.js /////////////////
var explore = Titanium.UI.currentWindow;
Ti.App.addEventListener('feed_partial_action',function(e)
{
alert('inside event')
})
var new = Titanium.UI.createButton(
{
});explore.add(new);
new.addEventListener('click', function(e)
{
var explore_new = Titanium.UI.createWindow(
{
navBarHidden:true,
backgroundColor:'#f8f8f8'
});explore_new.open({animated:true});
});
/////// explore_new.js/////////////////
var explore_new = Titanium.UI.currentWindow;
Ti.App.fireEvent('feed_partial_action',{page_type:'new'});
so my problem is that on first load alert inside the event listner in m.js executed once but when I again call m.js it shows alert twice.on third time it shows alert 3 times and so on and after some time it forcefully close the app.I think event listener of window still open after refreshing widow.So is there any way to handle this problem.Thank you
What you have here is a memory leak.
When you add the event listener to Ti.App with the statement
Ti.App.addEventListener('feed_partial_action',function(e)
{
alert('inside event')
});
That anonymous function is stored within the Ti.App context (it has to retain a reference to the function so that it can invoke it when the "feed_partial_action" event is fired). That function will not be garbage collected until Ti.App releases its reference to it. Furthermore, it remains tied to the event.
There are several ways to deal with this. I don't know exactly how to tell you how to fix your problem because I don't have a lot of context with the provided code sample. So, here are some solutions. If one of the assumptions below is not correct, please give more detail.
If the 'feed_partial_action' event is truly supposed to be global event that has one and only one event handler, move
Ti.App.addEventListener('feed_partial_action',function...); code outside a block that gets executed multiple times.
If you need to stop receiving the event when the explore window is closed, then move the eventHandler function (the anonymous one) out to a named function or variable and call Ti.App.removeEventListener('feed_partial_action', myFunction); when you close the window. The easiest way to do this would be
function feedPartialActionCB(e) { alert('inside event'); }
Ti.App.addEventListener('feed_partial_action', feedPartialActionCB);
explore.addEventListener('close', function() {
Ti.App.removeEventListener('feed_partial_action', feedPartialActionCB);
});
I have a jQuery Mobile web app which targets iOS and Android devices. A component of the application is a background task, which periodically checks for a.) changes to local data and b.) connectivity to the server. If both are true, the task pushes the changes.
I'm using a simple setTimeout()-based function to execute this task. Each failure or success condition calls setTimeout() on the background task, ensuring that it runs on 30 second intervals. I update a status div with the timestamp of the last task runtime for debugging purposes.
In any desktop browser, this works just fine; however, on iOS or Android, after some period of time, the task stops executing. I'm wondering if this is related to the power conservation settings of the devices--when iOS enters stand-by, does it terminate JavaScript execution? That is what appears to happen.
If so, what is the best way to resume? Is there an on-wake event which I can hook into? If not, what other options are there which don't involve hooking into events dependent on user interaction (I don't want to bind the entire page to a click event just to restart the background task).
Looks like Javascript execution is paused on MobileSafari when the browser page isn't focused. It also seems if setInterval() events are late, they are simply fired as soon as the browser is focused. This means we should be able to keep a setInterval() running, and assume the browser lost/regained focus if the setInterval function took much longer than usual.
This code alerts after switching back from a browser tab, after switching back from another app, and after resuming from sleep. If you set your threshold a bit longer than your setTimeout(), you can assume your timeout wouldn't finish if this fires.
If you wanted to stay on the safe side: you could save your timeout ID (returned by setTimeout) and set this to a shorter threshold than your timeout, then run clearTimeout() and setTimeout() again if this fires.
<script type="text/javascript">
var lastCheck = 0;
function sleepCheck() {
var now = new Date().getTime();
var diff = now - lastCheck;
if (diff > 3000) {
alert('took ' + diff + 'ms');
}
lastCheck = now;
}
window.onload = function() {
lastCheck = new Date().getTime();
setInterval(sleepCheck, 1000);
}
</script>
Edit: It appears this can sometimes trigger more than once in a row on resume, so you'd need to handle that somehow. (After letting my android browser sleep all night, it woke up to two alert()s. I bet Javascript got resumed at some arbitrary time before fully sleeping.)
I tested on Android 2.2 and the latest iOS - they both alert as soon as you resume from sleep.
When the user switches to another app or the screen sleeps, timers seem to pause until the user switches back to the app (or when the screen awakens).
Phonegap has a resume event you can listen to instead of polling for state (as well as a pause event if you want to do things before it is out of focus). You start listening to it after deviceReady fires.
document.addEventListener("deviceready", function () {
// do something when the app awakens
document.addEventListener('resume', function () {
// re-create a timer.
// ...
}, false);
}, false);
I use angular with phonegap and I have a service implemented that manages a certain timeout for me but basically you could create an object that sets the timer, cancels the timer and most importantly, updates the timer (update is what is called during the 'resume' event).
In angular I have a scopes and root scope that I can attach data to, my timeout is global so I attach it to root scope but for the purpose of this example, I'll simply attach it to the document object. I don't condone that because you need should apply it to some sort of scope or namespace.
var timeoutManager = function () {
return {
setTimer: function (expiresMsecs) {
document.timerData = {
timerId: setTimeout(function () {
timeoutCallback();
},
expiresMsecs),
totalDurationMsecs: expiresMsecs,
expirationDate: new Date(Date.now() += expiresMsecs)
};
},
updateTimer: function () {
if (document.timerData) {
//
// Calculate the msecs remaining so it can be used to set a new timer.
//
var timerMsecs = document.timerData.expirationDate - new Date();
//
// Kill the previous timer because a new one needs to be set or the callback
// needs to be fired.
//
this.cancelTimer();
if (timerMsecs > 0) {
this.setTimer(timerMsecs);
} else {
timeoutCallback();
}
}
},
cancelTimer: function () {
if (document.timerData && document.timerData.timerId) {
clearTimeout(document.timerData.timerId);
document.timerData = null;
}
}
};
};
You could have the manager function take a millisecond parameter instead of passing it into set, but again this is modeled somewhat after the angular service I wrote. The operations should be clear and concise enough to do something with them and add them to your own app.
var timeoutCallback = function () { console.log('timer fired!'); };
var manager = timeoutManager();
manager.setTimer(20000);
You will want to update the timer once you get the resume event in your event listener, like so:
// do something when the app awakens
document.addEventListener('resume', function () {
var manager = timeoutManager();
manager.updateTimer();
}, false);
The timeout manager also has cancelTimer() which can be used to kill the timer at any time.
You can use this class github.com/mustafah/background-timer based on #jlafay answer , where you can use as follow:
coffeescript
timer = new BackgroundTimer 10 * 1000, ->
# This callback will be called after 10 seconds
console.log 'finished'
timer.enableTicking 1000, (remaining) ->
# This callback will get called every second (1000 millisecond) till the timer ends
console.log remaining
timer.start()
javascript
timer = new BackgroundTimer(10 * 1000, function() {
// This callback will be called after 10 seconds
console.log("finished");
});
timer.enableTicking(1000, function(remaining) {
// This callback will get called every second (1000 millisecond) till the timer ends
console.log(remaining);
});
timer.start();
Hope it helps, Thank you ...
You should use the Page Visibility API (MDN) which is supported just about everywhere. It can detect if a page or tab has become visible again and you can then resume your timeouts or carry out some actions.