I have a webrtc application and I am using Google TURN servers used by appr.tc in my own app and it's working fine.
Any idea what are the limitations and implications of using Google TURN server in my own app?
Related
I am developing a web application which makes use of the Sony Camera API with an Alpha 6300.
The web-app needs to access the camera and internet at the same time. Therefore, I am using a laptop with two network adapters, one connecting to Wi-Fi and one to the camera access point. I got this to work without the discovery phase, which is not possible from a browser (that's ok, the IP address of the camera is always the same).
However, in order to get it working on the production server (which is secure), I need some ugly hacks, due to the camera endpoints being only available in HTTP (no HTTPS) and with no CORS headers:
I need to use a Chrome extension to bypass CORS
I need to click on 'load unsafe scripts' in Google Chrome
A quick solution would be to pack everything in an Electron app, thus overriding Chrome's (more than legitimate) security concerns. However, this would strongly complicate the deploying and testing process. I would rather go with a web-based solution, if possible.
Anybody knows if there's a way to enforce HTTPS and set Access-Control-Allow-Origin on the Camera server?
You can use a local CORS proxy. That's what I've done for development.
I went the similar route of "Electron" for disabling the same origin policy, only I used PhoneGap because I needed this for a phone.
We (me and my team) are building a food delivery real-time Web and Mobile app (using react-native) which also includes payment integration and admin dashboard for a client.
The tech stack we've chosen for the app:
View
React (Web app)
React-native (Mobile app)
Back-end
Express
Firebase
We thought of sharing the app data using a common back-end for the web and mobile app. Basically, we would've created an API that provides the end-points using Express and then Express would Save/Retrieve data to/from Firebase. Express would be our middle-ware.
We created 2 project folders keeping first of all only web app in mind:
react-webapp
express-webapp
And then, we start the respective server for the packages.
Unfortunately, API's aren't real-time and we may have to implement our mechanism to make the flow real-time.
So, we switched to merging firebase with react. We decided that'll use express just for sending emails. So, the folder structure for the web app is something like:
react-webapp
node_modules
public
src
firebase
With this approach, we created a demo and we do get real-time updates and we can also use ReactFireMixin. Later we can use the same folder and add it to react-native as well for Saving/Retrieving data from the database.
My question is, as we don't have any prior experience of building a Web and Mobile app with a common database/back-end and React/React-native, is this approach apt? Is there anyway in which we can segregate the front-end code from the back-end and utilize the real-time feature of firebase?
The reason for segregating the backend from front-end is to keep a common real-time backend for react and react-native without having to keep 2 separate firebase folders for the web and mobile app.
Note: If you are wondering why real-time then the client has asked for a real-time order placement mechanism.
It may work to use socket.io with express to allow for realtime back end updates that come from firebase.
I'm interested in using Azure Mobile services with SPA applications... perhaps with PhoneGap and or Kendo.UI as well.
I would like to add authentication to my app, and am looking at Azure Mobile Services. What isn't clear to me is if I can use Zumo (mobile services) to authenticate my app?
Example
User downloads app from store (or uses HTML5 caching to store the app)
The SPA app connects to Azure Mobile to get the OAUTH credentials
The Credentials secure my REST calls to the database (as secured by Azure Mobile)
Can anyone clarify if this architecture is possible?
You can definitely do this. If you go into the quickstart page after creating a new Mobile Service, you'll see one of the supported platforms is HTML/JS. You can download that quickstart application to run a local website that will connect to your Mobile Service and can set up authentication using this flow (http://www.windowsazure.com/en-us/develop/mobile/tutorials/get-started-with-users-html/). Dropping this into a PhoneGap application is very simple and just requires downloading the jQuery and Mobile Service javascript files locally (phonegap can't reference remote JS files). The bulk of the HTML can be the exact same. You'll just need to take the JS from the HTML/JS quickstart and drop it into the onReady method (I believe that's what PhoneGap calls once the device is ready for you to use). Hope that helps.
Does google drive SDK ios api support proxy setting? Currently I am using goodle drive sdk in my own ios application and I would like to know that is there anyway for me to set up proxy setting in the code or will the google drive will automatically add the proxy setting in the request?
google-api-objectivec-client doesn't support proxying at the moment. If you're not planning to use the client library, you can't proxify the requests.
I am new to Worklight and am currently doing proof of concepts to understand the features and strengths of the platform to create mobile web apps, hybrid apps and native apps.
Can IBM Worklight also be used for developing static information websites for multiple mobile devices?
Even if all you want to do is serve dynamic content form your server to the mobile device there are some advantages to use Worklight, for example by wrapping your site in a hybrid shell you can gain the presence in application stores (Apple iTunes and Google Play).
You can check "Module 45.1 – Worklight App as a Container For Server Generated Pages" ftp://public.dhe.ibm.com/software/mobile-solutions/worklight/docs/v505/Module_45_1_-_Worklight_App_as_a_Container_for_Server_Generated_Pages.pdf for more information about how to do it.
If you will not use your static site as the resource of the content but will use the Worklight application you will have a few advantages
1) Will work offline
2) Faster response time (no round trips (HTTP requests) to get the whole HTML, CSS, JavaScript, images)
At the end of the day Worklight application are for applications, where there is a interaction between backends and the client and usage of device capabilities (like location, camera, etc.) and not only static content.
Can it be used to create static sites? Yes. Is that a good use of the software license? Probably not. There is a lot more power in Worklight than just creating a static site. I would suggest really understanding responsive web design and using that to create your mobile friendly sites.