I'm working with Impinj Octane SDK for Java for a web app that requires connecting to the reader in every single session, but accessing to different anthennas.
Is there any way to do that without exceptions being raised?
That is unfortunately not possible, the Octane SDK uses a Low Level Reader Protocol under the hood, and LLRP only supports a single connection.
You need to build your own data 'broker', or use a platform like Nedap Harmony (nedap-harmony.com) that brings data to the cloud, and makes it easy to integrate the RFID actions into a web app.
Related
We have a iOS native app client making calls to a Bluemix speech2text service using Websockets in Direct interaction mode, which works great for us (very fast, very low latency). But we do need to retain a copy of the audio stream. Most audio clips are short (< 60 seconds). Is there an easy way to do that?
We can certainly have the client buffer the audio clip and upload it somewhere when convenient. This may increase memory footprint, particularly for longer clips. And impact app performance, if not done carefully.
Alternatively, we could switch to using HTTP interface and relay via a proxy, which could then keep a copy for us. The concern here (other that re-writing an app that works perfectly fine for us) is that this may increase latency due to extra hops in the main call thread.
Any insights would be appreciated.
-rg
After some additional research we settled on using Amazon S3 TransferUtility Mobile SDK for iOS. It encapsulates data chunking and multi-threading within a single object, and even completes transfer in the background after iOS suspends the app.
http://docs.aws.amazon.com/mobile/sdkforios/developerguide/s3transferutility.html
The main advantages we see:
no impact on existing code--simply add a call to initiate a transfer
no need to implement and maintain a proxy server, which reduces complexity
Bluemix provides cloud object storage similar to S3 but we were unable to find an iOS SDK that supports anything other than a synchronous, single-threaded solution right out of the box (we were initially psyched to see 'Swift' support, but that has proven to be just a coincidental use of terms).
My two cents....
I would switch to the HTTP interface, if you make things tougher for your users, then they won't use your app and will figure out a better way to do things. You shouldn't have to rewrite the app - just the communications, and then have some sort of server side application that will "cache" those audio streams.
Another approach would be to leave your application as is, and just add a step to send the audio file to some repository, AFTER sending it to speech to text, in a different thread. In this case you could save off not only the audio file, but the text translation as well.
Our application will have a website and a mobile app both communicating to the same API backend. I have one Nodejs application for serving only APIs and a second Nodejs app serving html pages for the website. I am using Expressjs web framework for both of these apps.
What are different methods to call APIs in one Nodejs from another Nodejs app? Additional information on when to use each method would be great.
EDIT:
Example,
I have the following applications
NodejsAPI (node & express)
NodejsWebsite (node & express)
MobileApp
NodejsAPI will provide access to APIs for the MobileApp and the NodejsWebsite. MobileApp will access APIs over http. But I want to know what are the options for NodejsWebsite to call APIs in NodejsAPI app. From what I understand this will be inter process communication between the two processes. For .net applications such communications could be done using .net pipes, tcp communication etc. What are the equivalent methods for Nodejs applications on unix and linux platforms?
Thinking from IPC perspective I found the following to be useful,
What's the most efficient node.js inter-process communication library/method?
https://www.npmjs.org/package/node-ipc
There's node's vanilla http client, http client swiss army knife, request, then there's superagent, similar to jQuery.ajax. To make your life easier there's armrest and fementa, both different flavors of the same thing.
Now if you want to reach for more performance and have another interface of your application, you can use one of these RPC solutions:
dnode: One of the most popular solutions. It's makes things very easy. It's makes using remote interfaces seamless. phantomjs-node uses dnode. Doesn't perform well with huge objects compared to others. For small stuff, it's perfect. There's other ports for other languages too.
zerorpc: Uses zeromq as it's socket library which is famous for being reliable. It supports connecting to a python client too.
smith: RPC systems used in cloud9 editor backend. Basically almost as nice as dnode, but faster. Both smith and zerorpc uses msgpack instead of JSON, so they will save bytes on the wire.
axon-rpc: A lightweight solution. As nice to use as zerorpc. You can configure it to use msgpack with axon-msgpack.
All of above work on both TCP(To be used on different machines) or Unix Domain Sockets(faster than TCP, but only on the same machine).
If you want more performance, you can embed your NodejsAPI in your NodejsWebsite, by just simply requiring it's interface module.
If you want answers better than this, write a more specific question. The question as it is, is too broad.
How can I send low latency data to a server and back with phonegap?
Considering I don't have access to php files locally, and don't have experience with node.js or WebSockets I don't know which ones I should use.
WebSockets aren't natively supported by the browsers in Android or older versions of Cordova under iOS, which means you'll need to use a PhoneGap plugin if you want to use them on the client.
There's more information at: http://remysharp.com/2010/10/04/websockets-in-phonegap-projects/
However, I'm not sure (even with the plugin) how resilient WebSockets are likely to be when the device moves between network connections (WiFi -> 3G -> WiFi), so using a simple polling web service may be a more reliable option if your app needs to continue receiving data as your users move around.
If you need to receive data initiated by the server, consider using push notifications instead: both iOS (APN) and Android (C2DM) provide APIs to do this which make more efficient use of the battery than having your app poll your server constantly.
You can use WebSockets in PhoneGap with iOS and Android. WebSockets are natively supported on iOS within Safari. For Android you will need to use a polyfill.
See: https://stackoverflow.com/a/13527585/39904
The answer above provides information about how to make a WebSocket object available within the Android WebView used by PhoneGap and also provides a link to a sample project which you can use to get started.
WebSockets were developed as a solution to 'Comet' hacks. As such they provide a very low latency solution for realtime bi-directional communication between a client and server. This means low bandwidth and low resource usage - battery on mobile - since you are holding a single connection open rather then opening and closing multiple HTTP connections. A polling solution which makes requests at regular intervals is likely to drain the battery much faster than a WebSocket solution. If you are polling at lower intervals then it may be fine - it depends on your use case.
In terms of WebSockets working as you change between network and network type (WiFi -> 3G -> WiFi) then if you are using WebSockets natively you need to detect the onclose and reconnect. You will also need to determine the best type of connection; unsecure (WS) or secure (WSS). I would highly recommend you use WSS for mobile since some mobile network providers use transparent proxies which interfere with WS connections. This might sound complicated but there are a number of libraries that handle this for you. Such as the Pusher JavaScript library (note: I work for Pusher). Libraries such as these also provide fallback to a less efficient HTTP-based solution when the environment will not let any WebSocket connection occur.
Also see: realtime web technology guide.
I'd agree with #rmc47 that you should consider native push notifications if it's for infrequent single notifications
Refer to this link to see WebSocket Support by Browsers and devices : html5test.com site - iOS 4.2+ already supports WebSocket
See this doc that explains how to develop a simple application with WebSocket.
Unfortunately the content is in the Portuguese (Brazilian) language but you can leave comments which I will answer.
I'm not sure what you mean by "access to PHP files locally". The use of node.js and web sockets is also not mutually exclusive.
If you have not made a decision on the server implementation you could go for either node.js or ASP.NET.
node.js has good support for sockets with Socket.io, which abstracts the client implementation for you. So it will use WebSockets if there is support, else it will fall back to long polling.
ASP.NET has a library called SignalR which does something similar for the .NET platform.
I'm trying to figure out how to insert data into a Meteor mongodb database from an external native mobile application that I'm writing (specifically for iOS using Cinder, right now). I'd like events that happen on the mobile device application to be written to my Meteor app's database, so that it can be immediately displayed on a browser elsewhere.
Importantly, I need to stay in my native application on the mobile device - I can't launch into a browser. I'm a bit new to Meteor, so apologies if I'm overlooking something obvious.
Any ideas on how to do this?
Thanks!
Your best bet is to use an iOS DDP client like this one. You can use this client natively in your existing iOS app and subscribe and write back to data in your Meteor ecosystem.
DDP stands for Distributed Data Protocol and is authored by the Meteor group as an external standard for real-time app frameworks to adopt. It's a much preferred method than communicating directly with the database because you can leverage the publish and subscribe methods within the Meteor ecosystem.
The protocol is under rapid development.
I believe there will be a release shortly that will expound on the current state of DDP and the evolution of its official specification. An official spec is slated for the 1.0 release.
Note: Here is a great video overview of DDP in its present form.
Another option is to have your iOS app write directly to the MongoDB instance used by your Meteor app. You can use any MongoDB driver such as NuMongoDB. Meteor polls the MongoDB database every ten seconds so web based users will automatically see updates, albeit with a short lag.
DDP is evolving quickly, as Tim mentioned, so this option might be a little more stable.
In terms of hosting, for scalability I recommend separating your MongoDB instance from the free meteor.com site, by using a Mongo host such as MongoHQ.
And what about other cases ?
I mean browser applications ?
For a notification project, would like to push event notifications out. These are things like login, change in profile, etc., and to be displayed to the appropriate client. I would like to discuss some ideas on putting it together, and get some advice on the best approach.
I noticed here that changes made to a CouchDB can be detected with a _changes stream, picked up by Node, and a process kicks off. I would like to implement something like this (I'm using SQL Server, but an entry point at this level may not be the best solution).
Instead of following the CouchDB example (detecting database-based events, I think this just complicates things, since we're interested in client events), I was thinking that when an event occurs, such as a user login, then a message is sent to the Node server with some event details (RESTful request?). This message is then processed and broadcast to all connected clients; the appropriate client displays notification.
Proposed ecosystem:
.Net 4.0
IIS
IISNode
Socket.IO
Node.JS
SQL Server 2008
This will be built on top of an existing project using the .Net framework (IIS, etc.). Many of the clients' browsers do not support web sockets, so using Socket.IO is a good option (fallback support). However, from what I can see, Socket.IO only still only supports long polling through IISNode (which isn't really a problem).
An option would be to expose the Socket.IO/Node endpoint to all clients, so that client-based notifications can be sent through JS to the Node server, which broadcasts the message. (follows the basic chat-server /client/server examples).
Alternately, an IIS endpoint could be used, but could only support long polling (through Socket.IO). This would offer some additional .Net back-end processing, but may be over-complicating the architecture.
Is there SQL Server-based event notification available for Node?
What would be the best approach?
If I didn't get the terminology ecosystem configuration right, please clarify.
Thanks.
I would recommend you check out SignalR first before considering adding iisnode/node.js to the mix of technologies of your pre-existing ASP.NET application.
Regarding websockets, regardless if you use ASP.NET or node.js (socket.io), you can only use HTTP long polling for low latency notifications, as websockets are not supported by HTTP.SYS/IIS until Windows 8. iisnode does not currently support websockets (even on Windows 8), but such support could be added later.
I did some research lately regarding MSSQL access from node.js. There are a few OSS projects out there, some of them use native, platform-specific extensions, some attempt implementing TDS protocol purely in JavaScript. I am not aware of any that would enable you to access the SQL Notifications functionality. However, the MSSQL team itself is investing in a first class MSSQL driver for node.js, so this is something to keep an eye on going forward (https://github.com/tjanczuk/iisnode/issues/139).
If you plan to use SQL Notifications to support low latency notifications, I would strongly recommend starting with performance benchmarks that simulate the desired level of traffic at the SQL server level. SQL Notifications were meant primarily as a mechanism to help maintain in memory cache consistent with the content of the database, so it may or may not meet the requirements of your notification scenario. At the very minimum these measurements would help you start with a better design.
I would highly recommend using Pusher. That is what we use and it makes it easy to implement as it is a hosted solution. So plugging it and making it work is really easy. It doesn't cost much unless you are going to push a crazy amount of messages through it on a massive scale.