I am using Settings app to store application settings. I also userdefaults to store internal application settings (which are not exposed in Settings app). For eg, I use user defaults to store the last tab bar index which is not exposed in Settings app.
I am subscribing to NSUserDefaultsDidChangeNotification to listen to any changes in settings while my app is in background and that works fine.
The issue is that when I update user defaults (for my internal application setting parameters) from within my app, this also triggers NSUserDefaultsDidChangeNotification and which I do not want.
Is it possible to just listen to change in settings from Settings app and not from within the application?
Is it possible to listen to the notification only when the app is in background? I tried to subscribe to notification only in applicationWillResignActive (just before moving into background) (and that works fine for registration), but I could not find a way to deregister once the application is made Active again (applicationDidMakeActive does not seem to be the correct callback since notifications are delivered after this callback).
Or is there some other simple way to achieve this?
applicationDidMakeActive? You must mean applicationDidBecomeActive.
You might consider implementing applicationDidEnterBackground and applicationWillEnterForeground instead of applicationWillResignActive and applicationDidBecomeActive.
The "Active" methods are also called when the app starts and ends, which mean you will stop listening to the notification once it starts (you weren't actually listening to this notification) and if you implement applicationDidBecomeActive you will start listening to the notification once your application ends (for nothing).
Related
I want to use a node script that contains an events listener function (e.g. https://portal.thirdweb.com/sdk/advanced-features/contract-events#listen-to-all-events) inside my Next.js app.
As there is no server and the serverless functions need a trigger, I'm not sure where this kind of code should live.
How can I handle this case?
Any event listening should live on it's own server/not on serverless functions. The issue is that if you want to listen for events constantly and save them somewhere/act on it, the scripts that's listening for events needs to be constantly running.
With serverless functions (which is what all Next.js API endpoints are), they're only active when they get called, which won't work for event listening.
I would suggest building a simple Express server for event listening, and then deploying it somewhere like Zeet to have it always listening.
I have a nodejs app that is acting as a server that's controlling multiple industrial machines and I want to make a dashboard with electron that presents real time data of the various machine's states (this information being stored on the server). How can I establish some sort of connection between my nodejs server and my electron application/dashboard (and update its contents accordingly)?
I have written a similar Electron app, in my case, an app that periodically interrogates an application over the network that is connected to / controls an HF Amateur radio via a raw Socket.
From the electron app's main.js, I start up a service that polls the radio control application over the Socket. In your case, I'm assuming the would be an http client.
When the response comes back, I use Electron's ipcRenderer to push the data from the main electron process to the GUI app, in your case, your dashboard.
The connection code is a bit complex, due to the need to reconnect automatically if the connection is dropped (e.g. the radio is turned off, and then turned back on), but for an example, you can have a look at my repo.
My Chrome Extension's background page is set up as an event page, i.e., most of the time it is asleep unless some registered event listener wakes it up.
I'd like to be able to occasionally send messages from my server to the event page of an individual user of my extension. They should not necessarily show up as a desktop notification, it would rather be up to the background script to decide what to do with any incoming message. It might very well store some information in localstorage for example. If the user client was offline at the moment the message is being sent, it would ideally be delivered once it comes back online.
I'd like to avoid polling my server at regular intervals every time the background script is awake, though that would be an obvious solution.
My question is therefore if it is possible to register a special kind of event in my event page so that it wakes up and triggers some functionality once there's an incoming message from my server. Ideally, the server message would not be a general broadcast to all my users, but rather a targeted message to a specific user.
What options do I have?
I read about service workers and their Push API but it seems they are only slowly being rolled out to Chrome Extensions. I am not sure if they are ready for the browser's stable release yet and didn't find any documentation on how they work with extensions.
I also read a bit about Google Cloud Messaging but it is deprecated in favor of a new costly Firebase solution.
Service worker functions like a proxy server, allowing you to modify requests and responses, replace them with items from its own cache, and more. While Chrome has its own approach to caching/installing the resources need to display a Chrome Extension. Therefore, there will be an error when you will attempt to intercept the registration of a service worker to a Chrome Extension.
See for more information:
Introduction to service worker
Service Worker script errors if run in chrome extension
See related SO post:
Chrome Extensions with service worker receiving push notifications
I have an application which is written in nodejs hosted in azure. At present, when a user make a rest call, I will perform some calculation by building a grid and send a JSON data of the current state of the grid. Different factors affect the grid, it could be user requests or change in system settings.
I want to modify the current state of the application which evaluates grid only on user requests to constantly running (or sending timed events constantly). I would like anyone interested in a particular event to subscribe to the grid for that event. Based on either user request or timed event or system change event, grid needs to recalculate and then fire any events it might generate. Who ever is interested in the events then act on it.
I did see grid compute in azure website but it looks like it is inactive, no downloads or starred. Could anyone suggest how to approach the problem either in nodejs or C# leveraging azure eco system?
Whenever you're thinking about events and Json and .Net, think SignalR
SignalR is an WebSockets based event engine that has built-in a ton of fallbacks all the way down to long-polling for those clients that do not support WebSockets to begin with.
With SignalR, you can basically create a "real time" website for your grid compute engine, so that any client connected to it recieves updates in near realtime.
I'm working on an App that sends audio and video content to a chromecast. But I don't want to stop the playback when we disconnect our Sender App.
In the mediaroute-v7 package we find reference to an option to either disconnect or stop the connection. In fact the button to disconnect is hidden on https://github.com/android/platform_frameworks_support/blob/master/v7/mediarouter/res/layout/mr_media_route_controller_material_dialog_b.xml#L103 and to make it visible mediaroute-v7 gets the SelectedRoute and checks the boolean canDisconnect() on https://github.com/android/platform_frameworks_support/blob/39b32a9feea6b821d6a5c92202c400aa1f252200/v7/mediarouter/src/android/support/v7/app/MediaRouteControllerDialog.java#L259.
Is there any way to change the boolean value of canDisconnect(), so we can show the button, with VideoCastManager? Or how is supposed to get that button visible?
I presume you are using CCL (since you'd mentioned VideoCastManager). The current dialog that you see there is put out by CCL and is not the one provided by the mediarouter framework (unless you have overridden getMediaRouteDialogFactory()). In CCL, you have an option to decide if you want to simply disconnect from the cast device or stop the running app on the cast device when you click on that "Stop Casting" in the dialog; by default it just disconnects you and to change that, you have to call setStopOnDisconnect(true) to force it to stop the app. That said, the most common behavior on the receiver side (the default and styled receivers follow that as well) is to stop the app if the last connected device intentionally disconnects (i.e. if the last connected device is disconnected due to, say, network disruption, it doesn't stop the app). This behavior can be controlled on the receiver side by overriding onSenderDisconnected(reason) callback there.