How to detect user idle time since last touch and return the app to home page using phonegap - ios

I would like to check for the user idle time since last touch and return the app to the home page after some period of time. I want this to be done using phonegap.
I googled and did find few solutions but I want to detect the idle time and return the app to the home page.
Thanks.

Using jQuery you *could bind a start touch event and end touch event then using a timer to execute a function
$('body').bind('touchstart',function() {
clearInterval(myTimer);
});
$('body').bind('touchend', function() {
myTimer = setInterval(function() {
/* return user to homepage */
},30000);
});
Touch events are a little buggy in mobile devices. But you set an Interval timer to run after a set amount of time after the last touch is detected. Remembering to clear it on the next touchstart event. Its a bit messy but should work (I havent tested it btw)

I got this working by setTimeout('Redirect()', 10000); where Redirect fn is function Redirect() { window.location.href="mylink.html"; }

Related

Web Audio API on iOS Safari do not play even after user interaction

I know that there is a limitation in iOS Safari where the audio is not playing until user triggers an interaction. So I have placed the code inside a touchstart event. But unfortunately, I have tried almost every combination, and I couldn't get it to play on iOS Safari.
Here are the things I have tried:
putting the audio load outside the touchstart callback
try adding a gain node
use 0.01 as the start time
and none of the above works in iOS Safari, but they can all play in desktop Chrome and Safari. Here is the link to the gist, you can see the versions where I made the changes (P.S. the click event is used for testing on desktop)
https://gist.github.com/angelathewebdev/32e0fbd817410db5dea1
Sounds play only when currentTime starts to run, but scheduling sounds exactly at currentTime doesn't seem to work. They need to be a little bit into the future (ex: 10ms). You can use the following createAudioContext function to wait until the context is ready to make noise. User action doesn't seem to be required on iPhone, but no such success on iPad just yet.
function createAudioContext(callback, errback) {
var ac = new webkitAudioContext();
ac.createGainNode(); // .. and discard it. This gets
// the clock running at some point.
var count = 0;
function wait() {
if (ac.currentTime === 0) {
// Not ready yet.
++count;
if (count > 600) {
errback('timeout');
} else {
setTimeout(wait, 100);
}
} else {
// Ready. Pass on the valid audio context.
callback(ac);
}
}
wait();
}
Subsequently, when playing a note, don't call .noteOn(ac.currentTime), but do .noteOn(ac.currentTime + 0.01) instead.

OnBeforePlay .seek doesn't work on iPad

I've scoured the web, upgraded the player, rewritten it 5 times, and now completing my 5th day of failing, and still cannot accomplish what the folks at Longtail tell me will work. (Don't get me wrong, I love 'em there, but this has me ready to jump off a bridge).
I'm simply trying to load a video that will play with Flash or iOS, and upon loading it, immediately go to a specific point in the video useing the .seek() method. Longtail tells me to use the onBeforePlay() function because iOS apparently doesn't respect the start value of the playlist. This code works like smoke with Flash, but ignores the seek in iOS.
Can ANYone assist me with this - it has become the most expensive script I've ever worked on and I have made zero progress at all. :( :( :( Also, I removed all the console functions and tried that, but with the same result.
Full code/player can be seen at http://www.tempurl.us/jw6e.html. You can see that with Flash, the video starts at 60 seconds, but on iOS, it starts at 0.
jwp = jwplayer('jwp').setup({
title: 'Single File Player', width: '720', height:'240', autostart: 'false', listbar: {position: "right",size: 400},
sources:[
{ file: 'http://media3.scctv.net/insight/mp4:nursing_4_clips_400.mp4/playlist.m3u8'},
{ file: 'rtmp://fms.scctv.net/insight/nursing_4_clips_400.mp4'}
]
}
);
jwp.onReady(function() {
// Create a playlist item of the video to play
var newItem = [
{ title: 'Title4 ACUTE_ABDO_PAIN_400',
image: 'playlistitem.png',
sources:[
{ file: 'http://media3.scctv.net/insight/mp4:ACUTE_ABDO_PAIN_400.mp4/playlist.m3u8'},
{ file: 'rtmp://fms.scctv.net/insight/ACUTE_ABDO_PAIN_400.mp4'}
]
}
];
jwp.load(newItem);
});
jwp.onBeforePlay(function() {
// This Works on PC/Mac with Flash, but does nothing on iPad/iPhone
jwp.seek(60);
});
Simply to close the question, the bottom line on this problem was that iOS will not allow autostart - period. Knowing that, all the expected events that were not behaving as expected made sense. Once the user initiates the stream with Play, everything works as expected. In our case, this is still a problem because we want to start later in the stream, but knowing that made dealing with it more manageable.
If the problem is iOS will not allow autostart - period. Knowing that,
all the expected events that were not behaving as expected made sense.
Once the user initiates the stream with Play, everything works as
expected
then you can have a play button only for tablet and ios device and on Clicking the play button,
call jwplayer().play(), this could be a work around for your problem, and after you have invoked jwplayer.play, which is only possible with the touch event, after play is triggeredother events will work.
otherwise even if you try jwplayer().play() onReady(), or autostart nothing will work because of iOs will not allow autostart as you said
I've solved this problem on iOS using onBeforePlay with seek() and play(). This work on desktop flash and IOS. Doesn't work on Android using the parameter androidhls:true
jwplayer().onBeforePlay(function() { jwplayer().seek(60); });
jwplayer().play();
As Ethan JWPlayer mentioned in comment use onPlay event. To prevent "loop buffering" as you said just use flag variable:
var isFirstStart = true,
seekValue = 60;
jwplayer().onPlay(function(){
//exit if it's no first playback start
if( !isFirstStart ) {
return;
}
jwplayer().seek(seekValue);
isFirstStart = false;
});

Titanium How to get webview load to fire once and then reset

I am using webview load to detect when a page is loaded but i need it to only fire once but it fires many times i have come up with a solution below to get it fire once, but this will only happen once and once only i need it to fire every time a page is loaded but only once example.
webviewload = true;
webview.addEventListener('load', function() {
if(webviewload){
//run code to add stuff to webview this will run once
webview.remove(oldsidebar);
webview.add(newsidebar);
webviewload = false;
}
});
the above works fine for one webview load but if you run again it is obviously set to false so i can only run this code once.
I found a hack that kind off works for me but i am looking for a better solution i understand its firing because it fires on every element load ads etc on webview.
webviewload = true;
webview.addEventListener('load', function() {
if(webviewload){
//run code to add stuff to webview this will run once
webview.remove(oldsidebar);
webview.add(newsidebar);
webviewload = false;
}
setTimeout(function(){
webviewload = true;
},5000)
});
ok above works but isn't ideal if the page take longer than 5 seconds to load etc i am getting problems.
Can anyone give me a suggestion on how to fire webview load once then reset so i can run a block of code correctly.
Hope this makes sense thanks
Yea, this is due to the fact that the page you are loading, like almost any portal homepage, is comprised almost fully of ajax calls to other pages and scripts, etc. This is going to cause your load event to fire, and fire, and fire again until everything is loaded.
I suppose one way around this would be listen for the load event and set some interval that if passed would kill the listener and carry on.

Appcelerator: Event when reopening App

I want my app to reload data when it will be reopened (from iOS "Multitasking").
I've tested:
Ti.UI.addEventListener('reload', function() {
alert('reloaded app');
});
but this event just gets fired when the App will be opened the first time.
The app entering the foreground is an app level event. So you need to register on Ti.App, not Ti.UI. In fact I can't find any reference to the event you are using.
Ti.App.addEventListener('resume', function() {
alert('reloaded app');
});
Or you can use "resumed" for after it has completely returned.
See this page

PhoneGap navigator.compass.getCurrentHeading called multiple times on iPhone

I would appreciate any help in solving this - or at least where to look to solve it.
What I have is calling on iPhone navigator.compass.getCurrentHeading(succ, fail), the success function is called every time the device is moved even slighly. In the XCode debug log I see lots of entries of navigator.compass.setHeading calls being generated for every movement. If I try to poll for heading data again - the request just hangs. Here's the code:
function onBodyLoad() {
if (typeof navigator.device == "undefined") {
document.addEventListener("deviceready", onDeviceReady, false);
} else {
onDeviceReady();
}
}
function succ(heading) {
alert("compass " + heading);
}
function fail() {
alert('fail');
}
function onDeviceReady() {
navigator.compass.getCurrentHeading(succ, fail);
}
This is really strange behaviour, as I expect getCurrentHeading to be called just once and return a single result, instead of the unstoppable flurry of events.
I use PhoneGap 1.0.0. The same code on Android works perfectly. I've removed all custom JS code to prevent possibility of conflicts.
It is odd that noone else seems to encounter this. In any case, this (hacky) solution may help anyone who comes looking for an answer.
We had to stop using getCurrentHeading because of this issue, and replaced it with navigator.compass.watchHeading instead. On clearing the watch we also call navigator.compass.stop() function to prevent from further compass spamming (for iPhone platform only - Android is fine), and before calling watchHeading again we call navigator.compass.stop() and navigator.compass.start(), to reinitialize the compass "just in case" (again, on iPhone only).
After taking these measures the page that user compass no longer hangs on second entry, and there is no heading spamming outside of this page.

Resources