I've to share a mobile screen and display it on a browser using WebRTC. I then have to take control of the mobile screen.
I've researched this and know I can share a screen browser to browser using chrome(with extension) or firefox(after certain flags are set). Some information I've read suggests that screen sharing on mobile is not possible and then another article said it was but I think they meant be sharing through the chrome browser on a mobile.
Some of the the information and posts I read are dating back to 2013/2015/2016 and I wondered if there is any new information on this?
Is screen sharing on mobile devices(android or iOS) possible using webrtc now?
is screen control on mobile devices possible?
Thanks Andrea
I also investigated this topic a few days ago and it seems to me we are on the verge of the next step and the technology hasn't totally settled yet. Screencapture is mostly working with (very) up-to-date browsers and (still) an extension or some kind of white-listing. I could not find any kind of hint that a "remote control" mechanisms are part of webrtc and the getUserMedia implementations. Unfortunately.
ICE seems to work fine for most scenarios (if you don't mind waiting a minute) and Tickled ICE adresses the problem in an interesting way.
Mobile is very confusing indeed as the market is even more heterogeneous.
Maybe we should open a wiki or a chat channel or whatnot they habe nowadays on stackoverflow :-) I think I will have to read about this "community wiki" checkbox down there...
The most promising thing I could find was
https://inthelocus.com/
Still trying it out in different scenarios.
[This might not be an answer...] I was on the same topic and then I noticed there's an existing tool (SDK) to serve the similar purpose: https://cobrowse.io. It works good in both the demo video and the simulator web page. Yet I'm not sure if it utilises WebRTC...
Related
After making a duration/cost estimation, I'm about to start developing a desktop application using OpenLayers. I've never had experience on it before, but have the support of some coworkers who do.
Now we have to estimate the time and effort it would take the same application to be viewable in mobile devices. I know the existence of openlayers.mobile.js, but nobody in my company has ever worked with it before.
I know it has some advantages over the normal OpenLayers library, such as pinching for zooming, and so. But, does it has any blocked capabilities? I mean, if I write code to draw a line on a layer in the desktop application, change the simbology of a layer, add a buffer arround a polyline, etc.. will it still work with the mobile library?
Is there funcionality in the desktop version that is not in the mobile one?
I'd need to know before estimating what can I offer in the mobile version, and how hard will it be to get so.
See examples tagged with mobile:
http://dev.openlayers.org/examples/
The next OpenLayer versions will probably have better mobile support as this is something many users are interested in.
So I wired in Prettify.js and Prettify.css into my new Tumblr blog. It works out great in chrome, IE, and Firefox but I was astonished when I went to my Android Phone and suddenly the code inside ... looks like an atrocity.
I was about to go digging but figured before I spend hours trying to solve a problem someone else already fixed I would see if my ol' Stack Buddies have anything to say on the matter.
aquamoogle.tumblr.com
Any solutions will be greatly appreciated and if none are posted I'll likely toss up a solution by the end of the weekend.
Clarification EDIT This is viewing the post through the Tumblr Android application. I don't think it has anything to do with phone version but because someone is bound to ask it's a Motorola Droid Bionic running Android 2.3.4
Alrighty, since nobody came along with this one I'll throw the answer out there. The Tumblr application after decompiling it off the APK does not use a standard web frame. This means that javascript execution is not embedded in the view for the mobile application.
Sucks I know... Another possible solution would be to use straight CSS for formatting but alas this doesn't even work in the mobile version as the CSS sheets are overridden with mobile style sheets for more compact formatting.
So this one goes down as "unsolvable" due to the mobile application not operating within the same boundaries as the web driven blog does.
If someone does by chance have a solution to this that will work however, I would be interested in hearing it but at this time I don't have a valid solution. But, it's good to know.
Is there anything that is less intimidating than recaptcha for mobile apps? My app is built with JQuery Mobile and most likely will never be available on the desktop. I am hoping there is a more visual captcha that would not require typing. So far most visual captchas I have found seem too large for a mobile app. I am mainly looking for something that is visual and small enough to fit within the average mobile screen. Any suggestions would be appreciated, I would even be willing to build something from scratch if someone has a good idea.
I don't know if you are using HTML5 or not, but there is a pretty cool captcha that I've used called MotionCAPTCHA. What it does is it presents a shape and the user traces the shape with their finger on their mobile device. Its pretty cool. I've used it with Android and it works pretty well. It requires jQuery and HTML5.
Damn, that MotionCAPTCHA link appears to be dead. I found this question looking for similar things to what we're working on at my current company.
We have a HumanDetect mobile SDK trying to solve a similar problem. The overall idea is we grab sensor data from the phone so we can determine "bot or not". You ask the SDK for a token, then send that token along with your REST request, and then that token can be validated. If everything works as expected only a mobile device in the hands of a human should produce a token that validates as "not a bot".
It's native code, not using the browser. For the end-user's point of view, it is transparent, the user isn't asked to perform any action.
I have an existing website running. I want this site to be able to be viewed on mobiles smart phones as well. I am ready to shave off some stuff, but would like to know how can I test this and are there any tools/guidelines on how to repurpose the site to be best viewed on mobile phones ? How to detect on the web site whether a mobile phone or a PC is hitting the site and accordingly serve the appropriate content.
There are few factors to consider such as:
- screen size
- touch vs non-touch
To detect whether the mobile phone hitting your site, you can simply verify the user agent.
There is a good article on this at A List Apart which will answer your implementation questions: Put Your Content in My Pocket
You can test by setting the user agent of your browser to that of mobile device. This can be done in safari under the develop settings, or firefox has various plugins.
And a tip, don't use anything that requires hover functionality. Touch screens don't hover.
You will find out it's a strange new world at http://mtld.mobi/
First decision you should make is which mobile platforms you want to support, then start coding...
As some one mentioned http://mtld.mobi/ is the best place to start for resources but for testing I would use http://ready.mobi that will test and debug your site and provide interface to viewing your website in mobile platforms.
First you need to decide what platforms/browsers you are going to support. If it is only smart phones like Android/Iphone/Blackberry it would be a pretty safe bet that as long as the website works in crome and isn't VERY javascript intensive and the site is catered for smaller screens it would be fine.
That is the theory in practise mobile is mobile and real world testing is the only way to go for 100% coverage.
Since the launch of Silverlight 2 I was expecting a lot of full blown Silverlight applications popping up but still there seem to be little evidence of this. Does anybody know of such applications out there in the wild. And also what would be the obvious applications you would develop in Silverlight. I would say mail clients are bad examples as they just as well could be written as a web/ajax app. As Silverlight is far more powerful than web+ajax possible candidates should be impossible/akward implementing as a web/ajax app.
The ones that comes to my mind is
Photo and imaging editing apps
Reporting applications
Office applications, Word/Excel...
Edit:
Added from posts
Games
The point isn't that the app need to fill the whole screen just that it isn't just a small part of a webpage, or you could call it a full blown application running inside the webbrowser, only using the webbrowser as a host.
I think the Medical app that Microsoft itself developed shows pretty well what could be achieved with silverlight http://www.mscui.net/PatientJourneyDemonstrator/
As for image editing then as I understand its a bit difficult as Silverlight lacks a Bitmap API to be able to do per pixel image editing...
Edit:
I noticed you added Word/Excel to your question and there comes the problem that Silverlight doesn't have a rich text editor built in and there hasn't been real good examples of custom implementations. There is one http://www.codeplex.com/richtextedit but I haven't seen any applications that actually use it.
I'm working on one in the medical domain.
This started as an update of a Mac classic application but due to the amount of work involved, broadened to considering other toolkits. I convinced them to go for an initial WPF desktop port to be followed by a Silverlight version.
I don't know one so far, but I could imagine that it could be used in a kind like the fullscreen video playback on youtube.
How many fullscreen desktop apps are there? Most application don't need the entire screen. If you don't want to be distracted by menus and taskbars and so you go fullscreen. Another type of applications that can use fullscreen are games.
You are limited in fullscreen to certain key presses such as arrow keys, tab, enter, and space so this rules out some of those types of apps. They have done this for security reasons so an app can't hijack the screen and record the keypresses, but I wish they could come up with a scheme to sufficiently warn the user then allow it if they consent.
An application Microsoft seem to like to show case is the AOL mail client written entirely in silverlight.
Personally I follow the rule is if you would not write it in flash you would not write it in silverlight preferring AJAX in most cases. In the past most large flash application have failed such as the flash word processor (cant remember the name) while AJAX enabled applications such as google documents have taken off.
Finally I believe until moonlight (linux and mac support) has been released and more general users have silverlight downloaded developers will be reluctant to use it widely even for smaller apps and gadgets.