I'm running an app, created using IBM MobileFirst 7, on iOS 8.4. At first it works fine: I can write to jsonstore and make other native function calls.
Then the application starts syncing and writing to the JSONStore (a lot of data) and it stops after a while (no errors in console). It usually happens while trying to call the WL.Client.invokeProcedure function.
I also noticed a strange behavior: if I double tap the home button it makes the next WL.Client.invokeProcedure call in the loop and I receive the results from the adapter but then it stops again (everytime I double tap the home button this happens). This also happens with other native calls (e.g. I tried to make a call to other native function in the JS console by using cordova and it only gets called after I double tap the home button).
Does anyone know what may be causing this behavior?~
EDIT:
Regarding the native calls: Since I'm using cordova, I can use a plugin to access some native functionality, example:
//this is what I meant by "native function calls"
cordova.exec(successCallback, errorCallback, 'SFRPowerSave', 'enable', []);
I'm not sure about WL.Client.invokeProcedure and WL.JSONStore functions, but I think they also use native code.
Here's what I'm doing:
//I get the first 50 dirty documents
function push(){
var numberOfDocumentsToPush = 50;
var dirtyDocuments = currentSyncStore.dirtyDocuments.splice(0, numberOfDocumentsToPush);
//then I call the adapter add method and return a promise
return when(WL.Client.invokeProcedure({
adapter : adapter.name,
procedure : adapter.push.procedure,
parameters : [ JSON.stringify(dirtyDocuments),
JSON.stringify({add: addParams}) ],
compressResponse : false
}, {
timeout: adapter.timeout,
invocationContext: {context: this, document: dirtyDocuments}
});
}
//after the promise is returned, I get the next 50 dirty documents and call the push function again, I usually have a lot of dirtyDocuments (lets say 10000).
//After a while it just stops, the WL.Client.invokeProcedure doesn't reject or resolve the promise and no timeout occurs.
//I can interact with the interface of the application but if I try to call some native function, it will not work (but it gets called immediatly after entering the multitask mode - double tap home button in ipad/iphone)
//In the adapter I call the stored procedure from the DB2 database one time for each document:
function pushLogs(logs, params, addFunction){
var parsedParams = JSON.parse(params);
var addParsedParams = parsedParams.add;
var addConfig = getConfig("logs", addFunction, JSON.stringify(addParsedParams));
var parsedLogs = JSON.parse(logs);
var globalResult = {
isSuccessful: true,
responses: []
};
for (var i = 0; i < parsedLogs.length; i++) {
var options = {
values : JSON.stringify(parsedLogs[i].document),
spConfig: addConfig
};
var result = invokeSQLStoredProcedure(options);
globalResult.isSuccessful = globalResult.isSuccessful && result.isSuccessful;
globalResult.responses.push(result);
}
return globalResult;
}
A PMR was opened to handle this question. It has turned out to be a Cordova defect and is now being handled via APAR PI47657: Application hangs when trying to call JSONStore asynchronously to sync data.
The fix will appear in a future iFix release, available at IBM Fix Central (as well as via the PMR opened).
Related
So I created an app using Ionic and Firebase as my back-end. When the app is run in a web browser or on an iOS emulator, the response is very fast and the app works really well. On iOS however, uploading anything to Firebase takes forever. Note that downloading information from Firebase is fairly fast and simple. Uploading however poses an issue. The wifi I am testing this on is very fast. Does anyone know why this is happening?
The app was released recently and this has been an issue for a lot of my users and myself included!
UPDATE: So after more testing it appears that the issue is specifically with certain functions. These methods are .update() and .add()
Anytime I try to update a field in Firebase it takes forever. Anytime I try to add a document to a collection it also takes forever. Why is this occuring? Here's some code that takes forever to achieve:
async createDMChat(otherUID: string, otherName: string) {
let newDoc: DocumentReference = this.db.firestore.collection('dmchats').doc();
let docId: string = newDoc.id;
let chatsArray = this.dmChats.value;
let timestamp = Date.now();
chatsArray.push(docId);
//Adds to your dm chat
await this.db.collection('users').doc('dmchatinfo').collection('dmchatinfo').doc(this.dataService.uid.value).set({
chatsArray: chatsArray
});
//Adds to other person DM chat
//-------------------THIS IS THE PART THAT TAKES FOREVER-----------------------
//The .update() method is the problem as well as .add() to a collection
await this.db.collection('users').doc('dmchatinfo').collection('dmchatinfo').doc(otherUID).update({
chatsArray: firebase.firestore.FieldValue.arrayUnion(docId)
});
//Pull info on person's UID
let otherUserInfo = await this.db.firestore.collection('users').doc('user').collection('user').doc(otherUID).get();
let otherAvatar = otherUserInfo.data().avatar;
//Sets message in database
await newDoc.set({
chatName: otherName + " & " + this.dataService.user.value.name,
users: [otherUID, this.dataService.uid.value],
lastPosted: timestamp,
avatar1: this.dataService.avatarUrl.value,
avatar2: otherAvatar,
person1: otherName,
person2: this.dataService.user.value.name
});
await newDoc.collection('messages').doc('init').set({
init: 'init'
});
await this.dataService.storage.set(docId, timestamp);
}
In the above code, the .update() is the method that takes forever. Also other functions with the .add() method adding documents to a collection takes forever.
Again THESE METHODS ARE FAST ON WEB BROWSERS AND EMULATORS. Just not in the mobile app.
===========================================================================
NEW UPDATE: So it appears that the problem is actually in waiting for the Promise to return. I rewrote all of the functions used to no longer use add() or update(), but rather used set() after making a new document with doc() to replace add(). I then used set({...},{merge: true}) to replace update().
This time around the changes to the server were instant, but the problem came when waiting for the methods to return a promise from the server. This is the part that is causing the lag now. Does anyone know why this is occurring? I could simply change my code to not wait for these promises to return, but I would like to keep await within my code without having this issue.
I'm building a ReactJs PWA but I'm having trouble detecting updates on iOS.
On Android everything is working great so I'm wondering if all of this is related to iOS support for PWAs or if my implementation of the service worker is not good.
Here's what I've done so far:
Build process and hosting
My app is built using webpack and hosted on AWS. Most of the files (js/css) are built with some hash in their name, generated from their content. For those which aren't (app manifest, index.html, sw.js), I made sure that AWS serves them with some Cache-Control headers preventing any cache. Everything is served over https.
Service Worker
I kept this one as simple as possible : I didn't add any cache rules except precache for my app-shell:
workbox.precaching.precacheAndRoute(self.__precacheManifest || []);
Service-worker registration
Registration of the service worker occurs in the main ReactJs App component, in the componentDidMount() lifecycle hook:
componentDidMount() {
if ('serviceWorker' in navigator) {
navigator.serviceWorker.register('/sw.js')
.then((reg) => {
reg.onupdatefound = () => {
this.newWorker = reg.installing;
this.newWorker.onstatechange = () => {
if (this.newWorker.state === 'installed') {
if (reg.active) {
// a version of the SW is already up and running
/*
code omitted: displays a snackbar to the user to manually trigger
activation of the new SW. This will be done by calling skipWaiting()
then reloading the page
*/
} else {
// first service worker registration, do nothing
}
}
};
};
});
}
}
Service worker lifecycle management
According to the Google documentation about service workers, a new version of the service worker should be detected when navigating to an in-scope page. But as a single-page application, there is no hard navigation happening once the app has been loaded.
The workaround I found for this is to hook into react-router and listen for route changes, then manually ask the registered service worker to update itself :
const history = createBrowserHistory(); // from 'history' node package
history.listen(() => {
if ('serviceWorker' in navigator) {
navigator.serviceWorker
.getRegistration()
.then((reg) => {
if (!reg) {
return null;
}
reg.update();
});
}
});
Actual behavior
Throwing a bunch of alert() everywhere in the code showed above, this is what I observe :
When opening the pwa for the first time after adding it to the homescreen, the service worker is registered as expected, on Android and iOS
While keeping the app opened, I deploy a new version on AWS. Navigating in the app triggers the manual update thanks to my history listener. The new version is found, installed in the background. Then my snackbar is displayed and I can trigger the switch to the new SW.
Now I close the app and deploy a new version on AWS. When opening the app again :
On Android the update is found immediately as Android reloads the page
iOS does not, so I need to navigate within the app for my history listener to trigger the search for an update. When doing so, the update is found
After this, for both OS, my snackbar is displayed and I can trigger the switch to the new SW
Now I close the app and turn off the phones. After deploying a new version, I start them again and open the app :
On Android, just like before, the page is reloaded which detects the update, then the snackbar is displayed, etc..
On iOS, I navigate within the app and my listener triggers the search for an update. But this time, the new version is never found and my onupdatefound event handler is never triggered
Reading this post on Medium from Maximiliano Firtman, it seems that iOS 12.2 has brought a new lifecycle for PWAs. According to him, when the app stays idle for a long time or during a reboot of the device, the app state is killed, as well as the page.
I'm wondering if this could be the root cause of my problem here, but I was not able to find anyone having the same trouble so far.
So after a lot of digging and investigation, I finally found out what was my problem.
From what I was able to observe, I think there is a little difference in the way Android and iOS handle PWAs lifecycle, as well as service workers.
On Android, when starting the app after a reboot, it looks like starting the app and searching an update of the service worker (thanks to the hard navigation occuring when reloading the page) are 2 tasks done in parallel. By doing that, the app have enough time to subscribe to the already existing service worker and define a onupdatefound() handler before the new version of the service worker is found.
On the other hand with iOS, it seems that when you start the app after a reboot of the device (or after not using it for a long period, see Medium article linked in the main topic), iOS triggers the search for an update before starting your app. And if an update is found, it will be installed and and enter its 'waiting' status before the app is actually started. This is probably what happens when the splashscreen is displayed...
So in the end, when your app finally starts and you subscribe to the already existing service worker to define your onupdatefound() handler, the update has already been installed and is waiting to take control of the clients.
So here is my final code to register the service worker :
componentDidMount() {
if ('serviceWorker' in navigator) {
navigator.serviceWorker.register('/sw.js')
.then((reg) => {
if (reg.waiting) {
// a new version is already waiting to take control
this.newWorker = reg.waiting;
/*
code omitted: displays a snackbar to the user to manually trigger
activation of the new SW. This will be done by calling skipWaiting()
then reloading the page
*/
}
// handler for updates occuring while the app is running, either actively or in the background
reg.onupdatefound = () => {
this.newWorker = reg.installing;
this.newWorker.onstatechange = () => {
if (this.newWorker.state === 'installed') {
if (reg.active) {
// a version of the SW already has control over the app
/*
same code omitted
*/
} else {
// very first service worker registration, do nothing
}
}
};
};
});
}
}
Note :
I also got rid of my listener on history that I used to trigger the search for an update on every route change, as it seemed overkill.
Now I rely on the Page Visibility API to trigger this search every time the app gets the focus :
// this function is called in the service worker registration promise, providing the ServiceWorkerRegistration instance
const registerPwaOpeningHandler = (reg) => {
let hidden;
let visibilityChange;
if (typeof document.hidden !== 'undefined') { // Opera 12.10 and Firefox 18 and later support
hidden = 'hidden';
visibilityChange = 'visibilitychange';
} else if (typeof document.msHidden !== 'undefined') {
hidden = 'msHidden';
visibilityChange = 'msvisibilitychange';
} else if (typeof document.webkitHidden !== 'undefined') {
hidden = 'webkitHidden';
visibilityChange = 'webkitvisibilitychange';
}
window.document.addEventListener(visibilityChange, () => {
if (!document[hidden]) {
// manually force detection of a potential update when the pwa is opened
reg.update();
}
});
return reg;
};
As noted by Speckles (thanks for saving me the headache), iOS installs the new SW before launching the app. So the SW doesn't get a chance to catch the 'installing' state.
Work-around: check if the registration is in the waiting state then handle it.
I've made an (untested) example of handling this. - a mod to the default CRA SW.
Getting a strange error from QBFC. This code fails:
var qbRequest = sessionManager.CreateMsgSetRequest("US", 7, 0);
qbRequest.Attributes.OnError = ENRqOnError.roeStop;
var qbQuery = qbRequest.AppendCustomerQueryRq();
// Don't get all fields (would take forever) - just get these...
qbQuery.IncludeRetElementList.Add("ListID");
qbQuery.IncludeRetElementList.Add("Phone");
qbQuery.IncludeRetElementList.Add("AltPhone");
qbQuery.IncludeRetElementList.Add("Fax");
var qbResponses = sessionManager.DoRequests(qbRequest);// <<- EXCEPTION: INVALID TICKET PARAMETER !!!
However - if I just put a delay in there it works fine. e.g.
System.Threading.Thread.Sleep(1000);
var qbResponses = sessionManager.DoRequests(qbRequest);// <<- WORKS FINE!!
I found this out because anytime I would set a breakpoint in the code to debug the problem - the problem would go away. So then I learned that I could just put a 1 second Sleep in there and simulate the same behavior. (btw - half second delay doesn't help - still throws exception)
This has got me scratching my head. I initialize the sessionManager at the start of the app and reuse it throughout my code. And it works everywhere else in this app but here. I have looked at the raw XML (for both request and response) and don't see anything wrong in there. The response just has an error: "The data file is no longer open. Cannot continue." but nothing to indicate why. (and the data file is open, after this exception I can use it for any number of OTHER things)
I suspect it has something to do with WHEN this code is called. I have a listener that listens for messages from the XDMessaging add-in (used for inter-process communication). When the listener receives a message the event calls this code. But this code is called in the same app (and same thread) as tons of OTHER QBFC code I have that does very similar stuff without a problem. And if it was a threading issue I would think the error would happen regardless of if I Sleep() for a second or not.
Anybody have any ideas?
What version of QBSDK are you using and what version of QuickBooks? I tested using QBSDK 13 (though I specified version 7 when creating the message request), with version 14.0 Enterprise R5P. I experienced no problems or exceptions without having a delay. Perhaps there's something going on with your SessionManager since it appears that you've already opened the connection and began the session elsewhere?
Here's my code that had no problem:
QBSessionManager SessionMananger = new QBSessionManager();
SessionMananger.OpenConnection2("Sample", "Sample", ENConnectionType.ctLocalQBD);
SessionMananger.BeginSession("", ENOpenMode.omDontCare);
IMsgSetRequest MsgRequest = SessionMananger.CreateMsgSetRequest("US", 7, 0);
MsgRequest.Attributes.OnError = ENRqOnError.roeStop;
var qbQuery = MsgRequest.AppendCustomerQueryRq();
qbQuery.IncludeRetElementList.Add("ListID");
qbQuery.IncludeRetElementList.Add("Phone");
qbQuery.IncludeRetElementList.Add("AltPhone");
qbQuery.IncludeRetElementList.Add("Fax");
IMsgSetResponse MsgResponse = SessionMananger.DoRequests(MsgRequest);
for (int index = 0; index < MsgResponse.ResponseList.Count; index++)
{
IResponse response = MsgResponse.ResponseList.GetAt(index);
if (response.StatusCode != 0)
{
MessageBox.Show(response.StatusMessage);
}
}
I'm trying to to write a javascript app that use the [SoundManager 2][1] api and aim to run in
all desktop and mobile browsers. On the iPad platform, Soundmanager is using the HTML5 audio api since there is on flash support. Now, when I'm trying to play two audio files back to back, both loaded in response to a click event, a [HTML5::stalled][2] event is occasionally raised. How do I set an event handler to catch the stalled event?
Since sound objects in my app are created on the fly and I don't know how to access directly to tags that are created by SoundManager, I tried to use a delegate to handle the stalled event:
document.delegate('audio', 'stalled', function (event) {...});
It doesn't work. the event did not raised in respond to stalled. (I had an alert in my handler).
Also tried to use [Sound::onsuspend()][3] to listen for stalled, but onsuspend pops out
on the end of sound::play(). How can we distinguish between stalled and other events that may raise the audio::suspend? Is there any other way to access the tags that SoundManager must create in order to play HTML audio?
I solved it with the following solution. This is not documented and found by reverse engineering.
It is all about accessing the html audio object, which is availalbe under _a.
currentSound = soundManager.createSound({..});
currentSound._a.addEventListener('stalled', function() {
if (!self.currentSound) return;
var audio = this;
audio.load();
audio.play();
});
The body of the method is based on this post about html5 stalled callback in safari
I can suggest a different "fix" I use with an html5 using platform (samsung smart TV):
var mySound = soundManager.createSound({..});
mySound.load();
setTimeout(function() {
if (mySound.readyState == 1) {
// this object is probably stalled
}
}, 1500);
This works since in html5, unlike flash, the 'readystate' property jumps from '0' to '3' almost instantanously, skipping '1'. ('cause if the track started buffering it's playable...).
Hope this works for you as well.
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.