I need to develop a videocall application for telemonitoring, where a user in a Web Browser (on a Desktop PC running a Web App) calls a user in an Android App (on a Smartphone/Tablet).
Is it possible to use Android's Telecom Framework from a Web Browser? I was looking at this tutorial.
If it's not possible to do such a thing, I was thinking about using a VideoConference service like Vidyo along with FCM or GCM, to notify the Android App that it should connect to the Conference Room.
But that seems overly complex for this case of use, so a second question would be: Is there a simpler way to achieve a Web Browser to Android App Videocalling service?
No. That requires a native app, or requires the web browser to provide access to those APIs. TO my knowledge, none do. And if they did, it would not likely be the same API, as they'd want it to work across OSes.
Related
I have a web application developed with RoR, and I was wondering if it was plausible to use it as the backend for an Android application that I would develop in Java or Kotlin?
For example, if the web applications authentication is handled with devise, can I get the Android application to send the name and password to my web application and have it return the user as a JSON?
Absolutely you can.
Usually the Android app would call an API rather than a web page. That is you don't exchange HTML like a browser does, just the essential JSON. Lots of things work the same as a web site. For example you can use the same authentication mechanism for the API as for the web-site.
This is a good starting point for RoR to create an API.
https://guides.rubyonrails.org/api_app.html
Here's a starter for Android making a web-service call:
https://developer.android.com/training/volley/simple
That's just a get, which you might use to get a list of something that's publicly available. It's probably worth understanding the other pages just there because with web calls it's really easy to do bad things like lock up the UI thread, so best to use the example patterns and methods.
I'm really new to mobile world, so I'd like to get some opinion from experienced people.
After several days searching over the internet, I'm wondering if it's possible
integrate Appcelerator Cloud Services to a custom website made with ASP.NET, for example.
Although my mobile application, built with Titanium, it's linked to ACS, and works fine, I don't know if
it's possible to manage data stored in ACS from a custom website. To clarify, in one point there is my mobile application
talks to a webserver (ACS, for example) and other point there is a website, to manage the data stored in ACS.
What do you think, someone achieved this?
Or is it preferable to write a webserver from the scratch, store my data in somewhere, and forget about ACS?
Thank you.
Appcelerator says
Appcelerator Cloud Services (ACS) is a Mobile Backend as a Service
(MBaaS), offering a fast and easy way to build connected mobile apps.
Choose from a library of services such as push notification, status
updates, photo storage, and social integration, or create your own
custom cloud services.
Here in this page - Getting Started: Using the Javascript SDK - you can see how we can use javascript SDK which lets you access the Appcelerator Cloud Services server through some simple to use JavaScript calls. You can use this to develop web-based app.
ACS has a REST API which you can access through anything that supports xhr (which .NET does). For instance, to create a new user in ACS, you use the following link:
https://api.cloud.appcelerator.com/v1/users/create.json?key=YOUR APP APP KEY?email=john.smith#company.com&role=teacher
There are other properties you can tag onto the querystring to create a new user from a REST call. They have a complete API using REST. It's all documented. You can even send push notifications to devices from your custom website using the REST API! It's pretty cool.
http://cloud.appcelerator.com/docs/api/v1/users/create#rest
Good luck!
One of the advantages I thought of writing a HTML5 based app for mobile devices would be I wouldn't have to deal with (many) quirks.
I want to push changes from my server to a mobile phones browser, for example if my users goto http://mysite.com they should be notified when something changes. Is it possible to do this for android chrome browser and apple safari?
Yes this is possible if you build a server that can handle push (typically via WebSockets). Take a look at socket.io.
Yes if the changes are instant you can use websockets. Recently I started using http://pusher.com/ which is a quite good service. Alternitively create your own websockets to do this. Here is an article on websockets: http://www.html5rocks.com/en/tutorials/websockets/basics/
Here, Google is talking about "web apps". Is a "web app" just an Android app that is connected to the web? Android app you need internet access for?
"Web app" is simply a broad term that can be used to refer to any web based/hosted site or service that involves a significant amount of user interaction, user generated content, or provides a "rich" user experience or a service API for third-parties to integrate with. A web app interface will "run" inside of a web browser, while typically all of the state handling and business logic will be handled by a backing server.
Google App Engine exists to provide a platform for implementing the "backing server" component of a web app (as well as basic hosting for the static resources needed by the app).
The concept of a web app really has nothing to do directly with Android apps. However, an Android app may (and many Android apps commonly do) communicate with a web app to provide various features or services within the app (think weather, Facebook integration, etc.). And in certain cases it is possible to implement a "quick and dirty" Android app by simply pointing a WebView at an existing web app's URL. In such a case that Android app's WebView becomes the "browser" that the web app's UI runs in.
Web app traditionally means a browser-based UI.
Google Web Apps was introduced in 2008, before the rise of the iPhone and Android. I would say those are a later addition to the definition.
If the client is using HTTP as its communication protocol with back-end services, I would call it a "web app", regardless of what the client hardware is.
I have been looking into android development for some time and would really like to create a networked game. I also think this would be an excellent oppurtunity to familiarize myself with the app engine framework, but it seems more app engine applications are built around browser services.
This is not nessecarily a problem for me, but I do not want this to appear as a browser based game (I want live chat, more dynamic interaction/movement/combat). I have been looking into AJAX/Java as a possible solution, but I am having trouble visualizing how i will actually connect the app to the server, since all tutroials I have found seem to be hosted web applications. Are there any resources for android applications hooking transparently into App Engine services?
Or maybe there is a better service similar to app engine I should look into.
Thanks! (if i was unclear about anything let me know)
AppEngine is completely prejudiced towards delivering web applications: HTTP in, HTTP out. So, as long as you can design your game's communication layer to be implementable in HTTP (stateless, finite-life requests) there's no reason that this wouldn't work.
Your game doesn't have to run in a browser to use an HTTP-based API to communicate with the server. I doubt that there are any special "transparent" communication libraries between Andriod and AppEngine, as the web request-style of communication that is possible with AppEngine is effectively indistinguishable from the same techniques that would be used to communicate with any other HTTP-based API running on any platform.
I'm currently developing an application that will involve a browser based webapp and also an iphone "installed app" (that's google's terminology) that connects to the GAE service. I simply GET/POST xml to a basic servlet and it works fine. Just keep in mind that to keep the client snappy, you will have to use memcache extensively as even minor calls to the datastore tend to to take a long time, and a "waiting" dialog in an installed app starts to get old very quickly. I would try to use memcache (as opposed to datastore) extensively to hold game-state data, since this data probably doesn't need to be "permanently" persisted, and memcache is significantly faster than the datastore.
Also I don't think there's any way for clients to be notified of game-state changes, app engine doesn't do "push," so all the clients will have to poll for updates.
You can use the Http Component classes that are in packages org.apache.http.HttpConnect.* classes in the Android SDK.