Looking at Parse documentation, there is a saveEventually() method that can be used in place of save() and saveInBackground().
Can I use this function everywhere in my code in place of save and saveInBackground so I don't have to worry about the user switching between being offline and online and I won't have to handle saving in situations where there is no connectivity? Are there any drawbacks to using this approach?
According to Parse's iOS guide:
Most save functions execute immediately, and inform your app when the save is complete. If you don't need to know when the save has finished, you can use saveEventually instead. The advantage is that if the user currently doesn't have a network connection, saveEventually will store the update on the device until a network connection is re-established. If your app is closed before the connection is back, Parse will try again the next time the app is opened.
So you will use save if you need the callback when the save has finished. I think you can use both depending on the situation you are handling.
Related
I have a Finder Sync Extension that will display a badge on a file based on the state of a local database. It's straightforward enough to query this database in the requestBadgeIdentifierForURL function, but what if I want the badge to change for a Finder item that's already visible if the state of that database has changed (which can be via a notification through any variety of mechanisms). The documentation (https://developer.apple.com/library/content/documentation/General/Conceptual/ExtensibilityPG/Finder.html) would seem to imply this is possible with this statement:
You might also want to track these URLs, in order to update their
badges whenever their state changes.
The only ways I can imagine this would be possible (and most seem wrong) would be:
call setBadgeIdentifier:forURL from another application that is aware of the change
Launch a thread in the init function of my extension which listens for notifications and calls setBadgeIdentifier:forURL when it receives them
Call some OS API that prompts Finder that the extension should be triggered via requestBadgeIdentifierForURL.
Only the last one seems feasible, and could be managed via the extension informing the outside resource what needs refreshing via the beginObservingDirectoryAtURL/endObservingDirectoryAtURL callbacks, but i don't know what mechanism could do this.
I'm trying to use express-flash in a standard web express js app. I don't want to use session, because I want to do the app as stateless as possible, but when I try to use without session, the app show me this error:
req.flash() requires sessions
Can I use express-flash without session? Can I use other alternatives for this kind of messages?
Thanks.
Note: A flash message is a variable stored within a session that is only available once, for the next request. That is if we put a flash variable and renders a page, the flash variable is available but if we render the same (or other) page again the flash variable is not present (it is destroyed).
-- acanimal
Based on this premise, you need to have sessions to use message flashing.
One way I think you can accomplish what you want is to add an item to the request (req) object in your middleware, and then in your controller, check if the key exists. You can then pass a specific message to your template, assuming you're using a template engine or pass it as part of your response.
Hope this helps.
I need to generate logs in service now whenever the browser is closed or the session is expired. I tried using global business rule but couldnt achieve it. It will be greatfull if i can if i get an idea to achieve this.
Thanks in advance.
I assume you already know how to generate a log and such in ServiceNow, and the problem you're having, is how to run code when the user closed their browser.
The best solution would probably be to create an onload client script which sets onbeforeunload to a function that triggers a log.
More on that here: https://developer.mozilla.org/en-US/docs/Web/API/WindowEventHandlers/onbeforeunload
For the second part of your question, user sessions are tracked in a "user sessions" table. If you want to also log when theirs expires, you can do so with a business rule on that table.
You can use
GlideAjax to call from your client script to a server side script include.
Look at GSLog
Try this one
var gl = new GSLog("com.snc.sla.tasksla.log", "TaskSLA");
I'm using Sinch! Instant Messaging together with Parse-server in my application. Is there a good way to mark a message object as "read" without actually first saving it to the backend, and then pulling it down on the other side and mark is at read, and then re-saving it to the same backend, but now as "read" instead of "unread"?
I want the users to be able to see if they have read a message or not, so new message are highlighted. Is there an easy way to do this with Sinch? Or any suggestions on how to do this effectively?
we dont have read, but i dont see why you would need to save it to your backend first. I would mark them as read locally as soon as they are in you IM view
I kick off 5 uploads (of varying size) via the BackgroundTransferService. I have the following questions about the way it works:
It seems that on the emulator it does 2 uploads at a time. Is this how it works on the actual device? Can I programmatically change this behavior?
Can I count on the uploads going out in the order that I submitted them? I seem to be getting conflicting results in my testing.
When I inspect the BackgroundTransferService in my application, does it contain requests from other apps as well or just mine?
Do I need to reconnect events for all the BackgroundTransferRequest objects when coming back from being tombstoned? What about coming back from being reactivated?
Do I need to disconnect events from the BackgroundTransferRequest when I remove it from the BackgroundTransferService.Requests collection?
When I try to upload a non-existing URL:Port (on the localhost), the TransferStatus is reported as WaitingForNonVoiceBlockingNetwork. The upload never actually completes/fails. Is this how it is on the device? Should I remove the request when it encounters this TransferStatus?
You cannot influence the behaviour of the BTS. If you don't like the way it works you can write the transfer functionality as part of your own application but then you have to handle running in the background yourself.
There is no guarantee on sequence.
The BTS may be handling requests from other apps but you won't be able to see the details. Requests() will only return details for your app.
Surely a quick test will tell you this.
It's good practice to.
Have you checked the TransferError property whe you reach this situation? This is a perfectly valild status in other situations and so you shouldn't treat this as a automatic fail.