django-channels databinding on model.save() - django

I have a channels app that is using databinding. When changes are made with django admin they are being pushed to the web as expected. I have loop set up on a socket connection to do some long polling on a gpio unit and update the db, these changes are not being pushed to the web. Channels documentation says:
Signals are used to power outbound binding, so if you change the values of a model outside of Django (or use the .update() method on a QuerySet), the signals are not triggered and the change will not be sent out. You can trigger changes yourself, but you’ll need to source the events from the right place for your system.
How do I go about triggering these changes, as it happens with admin?
Thanks and please let me know if this is to vague.

The relevant low-level code is in lines 121-187 of channels/binding/base.py (at least in version 1.1.6). That's where the signals are received and processed. It involves a few different things, such as keeping track of which groups to send the messages to. So it's a little involved, but you can probably tease out how to do it, looking at that code.
The steps involved are basically:
Find the right groups for the client
Format your message in the same way that the databinding code would (see this section of the docs)
Send the message to all the relevant groups you found in step 1.
Alternatively, you might consider using a REST API such that the socket code submits a POST to the API (which would create a database record via the ORM in the normal way) rather than directly creating database records. Your signals will happen automatically in that case. djangorestframework (server-side) and requests (client-side, if you're using python for the long-polling code) are your friends if you want to go that way, for sure. If you're using another language for the long-polling client, there are many equivalent packages for REST API client work.
Good luck!

Related

Web API that itself sends data to client on availability

I am currently working with Django but I am stuck as I don't know if I am pursuing the right model given the nature of my application.
Problem Statement:
I have to make a REST API for a client such that whenever I get a trigger for a new entry/entries in my Database I have to send those to the client which is supposed to listen to a URL and has asked for data only once and now is open to receive data whenever available to him.
It is not sending a GET request now and then.
There will be different endpoints of the APIs. One is where I provide him all the new data available to me and in other where it asks for specific data (ex: '/myAPI/givemethis')
I can easily implement the second requirement as it is a simple request-response case.
I am not sure how to send him data that too on availability without him making a repeated request as client.
It appears a Publisher-Subscriber model is better suited for my use case but I don't know how to implement it on Django.
I bumped into several concepts like StreamingServices and MQTT but I am not sure what should be the right choice to go with.
Kindly provide some suggestions.

How to properly notify client of changed status?

I am writing a (Django-based) website which is working just fine. It displays a list of sensors and their status. If a new sensor is attached, the user needs to wait for a certain amount of time until it is warmed up and ready to use. Also, when the sensors are updated (which the user can trigger, but can also be done automatically by the system) - the user needs to wait.
On the server side I have all signals/Status updates/whatsoever available. Now I want to create an overlay for the current webpage where the statuschange is displayed for x seconds and userinput is disabled.
I have no clue what technology to use. I could frequently ask for updates client -> server but that doesn't feel like the correct way. Any suggestions on what to search for?
No code here because the answer is probably independed of my website code
Standard solution is to use Ajax (JavaScript) or similar to get state from your backend on specific intervals, that is the approach you're mentioning.
You can also "push" changes from your backend to frontend using WebSockets but that is a bit more complex. A popular framework is socket.io, I recommend you take a look at it.

Notifying clients about an event via DRF

I want to know if there really is a way of notifying clients about a certain event, VIA Djangorestframework. I know it can be achieved with websockets via channels, but I couldn't find any material that explains everything in a step by step process. If anyone can help me than thanks already.
After a long time, I find the solution.
Actually I am using django rest framework(DRF) and django channels. What I wanted to achieve was to send message to a particular user and not to broadcast it in a group, by the api request. That is of course, a call from asynchronous code.
You can achieve this by sending message to specific channels as mentioned in django channels official docs.
This is possible because whenever client joins the group, it is automatically assigned a channel that can uniquely identify that client. So what we need is that we save that channel into the database and whenever required, get it from database, as specified here. You can save the channel to the database like so
I hope this was helpful.

Use the same WebSocket to push messages to a client

I'm starting with WebSockets, I already built a chat web-application as an exercise and it went something like this:
Every user has an opened websocket connection at their arrival to the chat-room, and when new messages are available, they're simply pushed to each user. The different messages are then displayed using javaScript.
Now, I'm trying to push the exercise a bit further by creating a one-on-one chat. Basically, there will no longer be a unique chat-room but private chat conversations. A user should be able to talk to different people from the same page. (Something like Google chat or Facebook chat).
After thinking about ways to do so, I came down to two solutions:
Open multiple websocket connections. (if possible)
Use the same connection to handle all opened conversations. Basically, each message that is pushed to the client will carry a field saying to which conversation it belongs, a javaScript will then handle the display of each message under the right conversation.
To me, the second solution seems better than the first. So, my questions are:
1- Will this solution have any performance problems? (Lost messages...)
2- Is there any other-better way of doing this?
The way to go depends (IMHO) on what framework you are using to do this communication.
I (as you) would go for multiplexing (second option) where you use one connection to handle all communication.
I assume that your framework of choice supports publish/subscribe and multiplexing?
I can provide you with a simple example if you like.
Regards
Uffe, Team XSockets

Windows Phone: Updating backend datastore (via web service) while keeping UI very responsive

I am developing a Windows Phone app where users can update a list. Each update, delete, add etc need to be stored in a database that sits behind a web service. As well as ensuring all the operations made on the phone end up in the cloud, I need to make sure the app is really responsive and the user doesn’t feel any lag time whatsoever.
What’s the best design to use here? Each check box change, each text box edit fires a new thread to contact the web service? Locally store a list of things that need to be updated then send to the server in batch every so often (what about the back button)? Am I missing another even easier implementation?
Thanks in advance,
Data updates to your web service are going to take some time to execute, so in terms of providing the very best responsiveness to the user your best approach would be to fire these off on a background thread.
If updates not taking place (until your app resumes) due to a back press is a concern for your app then you can increase the frequency of sending these updates off.
Storing data locally would be a good idea following each change to make sure nothing is lost since you don't know if your app will get interrupted such as by a phone call.
You are able to intercept the back button which would allow you to handle notifying the user of pending updates being processed or requesting confirmation to defer transmission (say in the case of poor performing network location). Perhaps a visual queue in your UI would be helpful to indicate pending requests in your storage queue.
You may want to give some thought to the overall frequency of data updates in a typical usage scenario for your application and how intensely this would utilise the network connection. Depending on this you may want to balance frequency of updates with potential power consumption.
This may guide you on whether to fire updates off of field level changes, a timer when the queue isn't empty, and/or manipulating a different row of data among other possibilities.
General efficiency guidance with mobile network communications is to have larger and less frequent transmissions rather than a "chatty" or frequent transmissions pattern, however this is up to you to decide what is most applicable for your application.
You might want to look into something similar to REST or SOAP.
Each update, delete, add would send a request to the web service. After the request is fulfilled, the web service sends a message back to the Phone application.
Since you want to keep this simple on the Phone application, you would send a URL to the web service, and the web service would respond with a simple message you can easily parse.
Something like this:
http://webservice?action=update&id=10345&data=...
With a reply of:
Update 10345 successful
The id number is just an incrementing sequence to identify the request / response pair.
There is the Microsoft Sync Framework recently released and discussed some weeks back on DotNetRocks. I must admit I didnt consider this till I read your comment.
I've not looked into the sync framework's dependencies and thus capability for running on the wp7 platform as yet, but it's probably worth checking out.
Here's a link to the framework.
And a link to Carl and Richard's show with Lev Novik, an architect on the project if you're interested in some background info. It was quite an interesting show.