I have a AngularJS app (embedded in a Cordova app).
To get and set data, it uses a REST API (that runs on a Django backend server).
I need that the app keeps working for several features even if the network is down.
For example, I'm expecting this kind of behaviour:
Online Mode
A client does something in the app
a POST request (to create data) is sent to the API
The client gets a "Thank you for doing xxx"
Fallback offline mode
A client buys something on the app
The client gets a "xxx can't be done right now, but it will be done as soon as possible"
Nothing can be sent to the server since we're offline. So how to do? Is there a way to put the API requests in a queue that will be executed when we're back to online mode?
How would you technically design this? It seems there is lots of differents technologies for offline mode, and it's a little bit confusing to me. Any guidance would be welcome.
Thanks a lot.
I would like to use such app, that would make me feel stupid. But there is
You can check network status with this plugin.
https://github.com/apache/cordova-plugin-network-information/blob/master/doc/index.md
Each request will need a switch between sending HTTP POST and saving POST data to local storage.
Then you would just create callbacks for following events:
document.addEventListener("offline", onOffline, false);
function onOffline() {
// Turn on saving to local storage
}
document.addEventListener("online", onOnline, false);
function onOnline() {
// Read local storage, send all requests
}
I'm not sure what the pressure in the comments are not to do this. We have this functionality in an app we are developing.
Basically we package up the iOS app as a Cordova wrapped web container and also run a local proxy server as part of the app. It passes all data through it to the web service. If the requests fail, it returns an identifier to the app so you can determine that the connection to the server is down, and the app then saves the requests to localStorage. That way the UI can adapt to being in "offline mode." you can later push data from the app through the proxy once the connection to the server is restored. The app connects directly to the proxy rather than to a webservice.
As far as I'm aware, there's not an easy library to solve this situation though, and you have to be aware of how the requests will affect the online application (can things go out of sync in your system, if the user runs requests that are cached until later?)
It is definitely something that can be done, though.
Related
This is kind of a weird question I think to ask, but I have browsing about for the past some time and cannot find a clear definite answer.
I understand that a client connects to its own server and communicates with the web-server through sockets and I kind of see how that works in php (I have never used php but have used sockets before so I understand the concept).
The issue is I'm trying to get a real view of this.
The question is, do websites generally use sockets and contact a web-server to fetch data or the actual html? Or is it a rare choice made in some areas?
If it is generally used, then is the "real" js usually in the server? or is it client-side (for performance sake)?
Context:
Let me explain a bit where I'm coming from, I'm not a web expert, but I am a computer engineering student so most concepts are easy to understand. A "real"-er view of this would be very helpful.
Now, onto why I'm asking this. I'm developing a web-app as part of a project and have done a fair bit of progress on it but everything was done on a local dev server (so basically a client?)
I've started wondering about this because I wanted to use a database for my website and since I want to connect to something, I will need to connect to a web-server first (for security sake).
My question's intent is to guide me on how and most importantly, where, to setup this server.
I don't think showing any code would be of help here, but assume I have my client running on localhost:1234, my database on localhost:3306, I think I should have a web-server on another port so I can establish this communication, but I want to do it in a clean and legitimate way so all of my current solutions can be ported online with little to no changes (except the obvious)
There's a bunch to unpack here.
First of all, servers can be distant or local. Usually they are distant, local server are mostly used for development purposes.
Even if your server is on your local machine, it still isn't the client. The client is the part that is connecting to your server. For web development it is usually the user browser.
Javascript is a language that can be used server-side, with a NodeJS server, but more often client-side, in your user browser.
Your website, or web application, communicate with your server through various means. Most common one is the HTTP protocol, used to make server requests such as data request to populate your page (in case of an API server, REST or otherwise), or simply request the actual page to display in the browser. The HTTP protocol works by resolving URLs, and making requests to your server registered to this url using special methods such as GET, POST, DELETE, etc...
Sockets are used to create a persistent connection with your server that works both ways. It is mostly used for realtime updates, such as a live chat, as it allows you to push updates from the server instead of having the client request everything.
In most cases the database can be found on the same server as the one serving the website or application, as it is a lot easier to handle, and often faster without the extra networks requests to get the data. However it can be placed on another server, with it's own API to get the data (not necessarily web related)
Ports such as 1234 or 3306 are often used for local development, however once your move your project to a host service, this is usually replace by urls. And the host service will provide you with a config to access the associated database. Or if you are building your own server you might still use ports. It is heavily dependent on your server config.
Hope this clear some things up.
In addition to #Morphyish answer, in the simplest case, a web browser (the client) requests an URL from a server. The URL contains the domain name of the server and some parameters. The server responds with HTML code. The browser interprets the code and renders the webpage.
The browser and the server communicates using HTTP protocol. HTTP is stateless and closes the connection after each request.
The server can respond with static HTML, e.g. by serving a static HTML file. Or, by serving dynamic HTML. Serving dynamic HTML requires some kind of server language (e.g. nodejs, PHP, python) that essentially concatenates strings to build the HTML code. Usually, the HTML is created by filling templates with data from the database (e.g. MySQL, Postgres).
There are countless languages, frameworks, libraries that help to achieve this.
In addition to HTML, the server can also serve javascript that is interpreted in the browser and adds dynamics to the webpage. However, there could be 2 types of javascript that should not be mixed. NodeJS runs on the server and formats the server response, client javascript runs on the browser. Remember, client and server are completely isolated and can communicate only through an HTTP connection.
That said, there ways to make persistent connections between client and server with WebSockets, and add all kinds of exotic solutions. The core principle remains the same.
It does not matter if server software (e.g apache, nginx) is running on your local machine or anywhere else. The browser makes a request to an address, the DNS and network stack figures out how to reach the server and makes it work.
Hey everyone so I have a question, can I have an endpoint api in my Mobile application?
For example I have a server that would do stuff with data and then I would send a post request to my mobile application letting it know new data had came in. How would I go about that? Is that even possible?
My solution I came across was to use firebase api since I remember It has a watcher. So I can easily change some data inside the firebase database by using my server. The mobile application will have the firebase watcher and see that something in the FB database got changed and it will proceed to react to it.
Without using firebase. If I were to send a get request to my server from my mobile application every second(as a watcher) is that bad practice? Or is that pretty much what firebase's watcher is doing?
I know that when you deploy a web application you can have a backend inside the directory. Would mobile applications even allow that?
Is there a simpler way?
also note
I'm using Ionic framework so its a javascript framework
And I'm using nodejs/express as my server
If I were to send a get request to my server from my mobile
application every second(as a watcher) is that bad practice? Or is
that pretty much what firebase's watcher is doing?
This is a bad practice and that is not what it is doing.
I know that when you deploy a web application you can have a backend
inside the directory. Would mobile applications even allow that?
You can't have easily a backend in your mobile application. You can call it but not having one inside your application.
Using Firebase is the good practise.
If you want to create your own server, you can create also a firebase cloud messaging server.
What you are doing is called push notifications. More infos here : https://stackoverflow.com/tags/push-notification/info
I'm attempting to make a Web app that needs to communicate to a program written in C Sharp. But I can't find a good form of communication. What I need is if a user clicks something on the Web app, it will notify the C Sharp program. Also, if an event happens on the C Sharp program, it needs to alert the Web app. Both of these are going to be running on the same machine.
Right now I'm mainly focusing on the C Sharp program just periodically "asking" what the status of the Web app is.
I've tried using POST requests to the Web app and I've had a bit of success with this but I don't know how to essentially store and update a "status" on the Web App. For example, C Sharp program sends a POST/GET request asking for the status, the Web app responds with "nothing has changed" or some sort of status code. I don't know how to keep track of that status.
I've attempted using Web Sockets but I don't think it is going to be possible on the C Sharp side. However, I'm definitely open to suggestions on how this might work.
I've looked into using the ReST architectural style but I'm having a hard time understanding how I would implement it. I'm using mainly AJAX on an apache server and most of the ReST examples I saw used IIS.
One way I've been successful with this is a horrible workaround. I use 3 files to store contents, status of Web app, and status of C Sharp program. But this requires me constantly fetching files, reading them, writing a new one, and uploading it.
Sorry if this question is poorly formed, I'm obviously new to a lot of this and this is my first SO post. Also, I'd include example code but I'm posting this from my tablet so it's not accessible right now.
If they are on the same machine, you can use 'pipes' (Unix), local sockets or file handlers.
These are all types of IO objects both applications can 'listen' to without exposing themselves to the network and without blocking while they are 'waiting' for data..
... But this will limit your scalability.
Another option is to use a Pub/Sub service such as Redis. This is a better option than websockets, because you can have multiple C# apps listening to multiple web apps on a centralized data source.
It uses the same IO concept (using sockets) behind an abstraction layer coupled with a database - it's very effective.
Good luck!
I implemented something similar to this. I needed a desktop application to listen for api calls from the browser. I ultimately decided to implement a "web connector" which can either be created as part of the application OR installed as a service.
Here is a good example: https://msdn.microsoft.com/en-us/library/system.net.sockets.tcplistener(v=vs.110).aspx
I'm creating an app where the server and the clients will run on the same local network. Is it possible to use web sockets, or rather more specifically, socket.io to have one central server and many clients that are running native apps
? The way I understand socket.io to work is that the clients read the web-pages that are served from the server but what happens when your clients become tablet devices running native apps instead of web pages in a browser?
The scenario I'm working with at the minute will have one central server containing a MEAN app and the clients (iPads) will make GET requests to the data available on the server. However, I'd also like there to be real-time functionality so if someone triggers a POST request on their iPad, the server acknowledges it and displays it in the server's client-side. The iPad apps will (ideally) be running native phonegap applications rather than accessing 192.168.1.1:9000 from their browser.
Is this technically possible to connect to the socket server from the native apps or would the devices have to send POST requests to a central server that's constantly listening for new 'messages'? I'm totally new to the whole real-time stuff so I'm just trying to wrap my head around it all.
Apologies if this isn't totally clear, it's a bit hard to describe with just text but I think you get the idea?
Correct me if I am wrong.
You have multiple iPads running native app. They send a POST request to your node JS server which is running in a computer in the same local network. Whenever the server receives a request from app, you want to display that a request has been received in your computer screen.
If my assumptions about the scenario is correct, then it is fairly easy to do. Here are the steps to do it.
Create a small webpage (front end). Load socket IO in the front end page like this -
<script type="text/javascript" src="YOUR_SERVER_IP/socket.io/socket.io.js"></script>
Then connect to server using var socket = io(). This should trigger connection event in your backend.
Handle all POST request from apps normally. Nothing special. Just add a small snippet in between. socket.emit('new_request', request_data). This sends new_request event to front end.
Handle the new_request in your front end using socket.on('new_request', function(request_data) { ... });. That's it. No need to add anything to your native app for realtime update.
The second step would be a little complicated as it is necessary to make socket variable available inside all POST requests. Since you chose node.js, I don't think you need any help with that.
Not totally clear on your project, but I'll try to give you some pointers.
An effective way to send data between native apps and a server is using a REST server. REST is based on HTTP requests and allows you to modify data on the server, which can connect to your database. The data returned is typically either JSON or XML formatted. See here for a brief intro: http://www.infoq.com/articles/rest-introduction
Android/iOS/etc have built in APIs for making HTTP requests. Your native app would send a request to the server, parse the response, and update your native UI accordingly. The same server can be used from a website using jQuery ajax HTTP requests.
Express.js is more suited to serving web pages and includes things like templating. Look into "restify" (see here: mcavage.me/node-restify/) if you just want to have a REST server that handles requests. Both run on top of node.js (nodejs.org).
As far as real-time communication, if you're developing for iOS look into APNS (Apple Push Notification Service). Apple maintains a persistent connection, and by going through their servers you can easily send messages to your app. The equivalent of this on Android is GCM (Google Cloud Messaging).
You can also do sockets directly if that's easier for you. Be careful with maintaining an open socket on a mobile device though, it can be a huge battery drain. Here's a library for connecting ObjC to Socket.IO using websockets, it may be useful for you: https://github.com/pkyeck/socket.IO-objc
Hope that helps!
To answer your question, it is definitely possible. Socket.io would serve as the central server that can essentially emit messages to all of the client. You can also make Socket.io listen for the messages from any of the clients and serve the emitted message to the rest of the clients.
Here's an example of how socket.io can be used. Simply clone, npm install, and run using 'node app.js'
All you have to do is to provide a valid server address when you connect your socket from the iPad clients:
var socket = io.connect( 'http://my.external.nodejs.server' );
Let us know if you need help with actual sending/receiving of socket events.
It is possible to connect to Websockets from your apps.
If you are using PhoneGap then you need a pluging that gives support to websockets in your app (the client) and then use websocket like normal way using Javascript see this.
If your app is native iOS look into this it could help you.
The primary use of the Sockets in your case is to be a bidirectional "pipe" between an app and server. There is no need of server sending the whole web-page to the native app. All what you need is to send some data from server to the client(app) in response to POST (or GET) request and then using this data on client side to update client's UI in real-time. If you are going to use moderate amount of devices (say tens of them), you may have connected all of them to the server permanently keeping individual socket connection open for every individual link server-to-app. Thus you may deliver data and update client's state in real time.
In fact web browsers also employ sockets to communicate to web servers. However as in general case there is no control on amount of concurrent clients in Internet, for the sake of limited networking resources conservation, servers do not keep sockets open for a long time, closing it just after the web-page was sent to client (or timeout has expired). That's how HTTP protocol works on the low level. The server waiting for the HTTP clients (browsers) by listening the 80 port, responding them by sending the whole web page content, then closing the connection and keep waiting for another requests on the same port.
In your case it's basically a good idea to use socket.io as it's a uniform implementation of sockets (ok WebSockets) on both client and server side. The good starting point is here
I'm developing an application using sails in which I have to connect from external sources. they can be IOS or android mobile applications or simply an external html client.
In that regard I cant't use sails helper methods to make web sockets request be handled by controller actions.
as I read through the sails.io client file i figured I could just use.
socket.emit('get' , {url:'/tomato' , data:{message:'pony'}} , function(response){});
to mimick the sails socket.get() function but it is not working.
sails log in terminal shows the following message : No session data returned, and an error was encountered saving session data for the first time: undefined.
Sorry you had to give up! This is a fairly common issue that comes up around communicating via sockets with a 3rd party. It actually has nothing to do with the Sails helper functions, and your usage of socket.emit to replicate the socket.get functionality is perfectly valid . Unfortunately the error message for this case is (clearly) broken in Sails v9, but the gist is: you need to get a cookie from the 3rd party domain before you connect the socket. This means making a JSONP request to that domain. Socket.io can actually do that for you, although you may have to set io.util.ua.hasCORS = false manually before calling io.connect. Or you can create a JSONP endpoint on the remote server and hit it yourself. Either way, once you have that third-party cookie in place, the socket handshake should work fine and allow perfect communication between your site and the Sails server.
Edit
The io.util.ua.hasCORS method is not valid, as it turns out--it will cause a JSONP request to be made to the remote server, but the response won't have a cookie attached so it's not going to get the job done. However, when the next version of Sails is released it will include a mechanism to request a cookie from the external domain, and will handle the connection automatically in the background within sails.io.js. Also note that you need to set authorization to false in the /config/sockets.js file in your Sails app in order to allow sockets to connect from remote domains.