Does anyone know how, or if, it is possible to detect programmatically on tvOS if the TV is turned off?
The case is that I’m developing a video content app, where I don’t want the content to continue to play when the user turns off the TV. This is expensive due to bandwidth fees and give imprecise analytics.
I’ve tried searching around and could find any clues.
Best regards.
FWIW
tvOS does automatically pause the content when the TV is turned off.
In my case I was test on live content. I found out that the property linearPlayback was set to true. This lead to that the AVPlayerViewController was unable to pause the (live) content.
Setting this to false didn't had significant side effects in my case and thus making my case work.
Related
Chrome introduced splash-screens as a PWA feature to make it look and feel more like native apps. It generates the splash-screen from name, icon and bg_color in the web app manifest. More details here:
https://developers.google.com/web/updates/2015/10/splashscreen
https://developers.google.com/web/tools/lighthouse/audits/custom-splash-screen
While all of that is fine, there is no proper documentation on how long Chrome decides to keep the splash-screen visible.
Ideally I'd imagine that it should be till the point something is meaningful painted on the screen (just the above-the-fold stuff) but in my experience it seems like Chrome keeps this splash-screen for a quite long time (might as well be till page load?)
This is pretty bad for people browsing my website from slow connections - previously at least they could see something working and happening on the screen, now they just see a static image (splash-screen with icon and name) - they don't know how long it will take to open the web app, can easily get bored and drop-off. This is very risky.
Can I control when the splash-screen goes away or even disable it altogether?
You can register an event of DOMContentLoaded, which is the first event fired, even before your other stuff like images, css and all are still getting loaded. Using this, you can fade out / remove the splash screen even (may be) before when your first paint happens (depending on your site requirements/implementation). Check out an example here, where he tries to add an animation to the fading of the splash screen rather than a simple transition. You can definitely try removing the splash screen earlier on similar grounds.
P.S.: Couldn't find anything to disable/time out splash screen. Hence the work around!
It seems that your first page is taking too long to be ready (first paint), maybe you have:
A big HTML file
Loading stylesheets synchronously
Javascript take long time to settle
Check these things see if resolving each one could help.
You can see other PWA apps, like twitter how they are loading pretty much fast in webAPK and learn from them using chrome dev-tool on your desktop.
I already used RecordRTC, but I had to abandon this decision, because I was getting videos with low quality and small fps. I tried change the options (videoBitsPerSecond, frameInterval) to improve quality, but nothing helped. Maybe I was not competent enough on this issue, but searches on this topic were futile.
If solution isn't exist, I'll look in universal plug-ins direction. Tell me what is better to use in a plugin to record a screen or region in good quality.
Presently only Firefox supports Screen Capture at navigator.mediaDevices.getUserMedia(). You can try testing various constraints at the Firefox implementation for screen, application, and window at getUserMedia Test Page.
we have website with slideshow control which display a set of images. Client requested to "protect" them from downloading. I know about simple ways to do this:
Disable right click
Put transparent overlay on top of the real image
Use CSS background
Use canvas
Watermarking
etc...
all of these are only for "casual" users - those ones who are not aware of Dev Tools in chrome.
Are there other ways to "protect" images? The only approach I could think of is to develop custom flash (or silverlight) plugin which will send image ID to the webserver and receive "encoded" byte stream - and decode it and display it. Am I over-complicating this? are there other ways to prevent image download?
if flash plugin + webservice approach is the right way to go - are there any ready-to-go solutions, or I should develop everything from scratch?
Thank you.
THere's no way to protect your image against being downloaded. Your users have to download it to view it. Your proprietary player will fail too if someone uses screen capture tools.
EDIT:
The best thing you can to is to make the reuse (I assume you don't want your visitors to use it elsewhere?) of the image as difficult as possible. Watermarks might be a good start to deter some people because they don't have the resource and expertise to de-watermark. Or you can embed steganography as a proof of origin so you can sue them afterward. Again, it's all about trade off between cost to do this and benefit from this.
It's impossible to prevent people from downloading your images. But, I want to offer another perspective -- you can create images that people like to view and play with but don't necessarily want to download.
Here's an example:
xkcd: Click and Drag
If the images have an intrinsic value that the client wants to protect, yet has to allow potential purchasers to view prior to purchase, then you need to minimize the value of the pre-purchase image. Only displaying thumbnails, adding visible watermarks, and otherwise distorting the image in ways that humans can easily see past, but will still see are usual here.
Then there is the issue of protecting the post-purchase images. Invisible watermarking (one example here, another here) can allow the customer to purchase and use the image as you allow, but if the image appears somewhere, used in an inappropriate manner, you can use the ID embedded invisibly (to a human) to identify just which customer violated the Terms of Use. These watermarks may even survive a degree of image manipulation and even digital photography of the image on a monitor.
If any user of the site has to be able to view the full, un-devalued image, you could add an unique ID linked to their IP address to the image as it is delivered to the slideshow control, so that each user receives a unique "copy", and you can trace misuse of an image to an IP address (and date, as many users have dynamic IPs, but ISPs keep records of IP assignments over time) for potential prosecution.
I am working on a web app that will be run off a local server on Windows 8 on Chrome. Unfortunately, Chrome doesn't seem to handle touch events very well. For example, often instead of clicking on a button, it will select it instead. Is there any way I can make it behave more like native touchscreen apps do?
I can't make it a metro app because I need to talk to a Python service.
I've done some testing in Chrome with a touch screen and don't seem to run into this issue (of course not doubting you are though!). If you have a site I'd be more than happy to check it out.
One option is to try scaling the content larger, I'm wondering if your touch surface is very sensitive to tiny movements upon touch and treating it as a touch/scroll ie select. Try a simple test in the browser to start by increasing the size before trying any css scaling transforms (which I'm not sure how in this how well that approach would even work)
What type of hardware is it being tested on?
Can you elaborate a bit more on the python service? What part of the service makes it so you can't interact with it? Is it just an http service object or something else?
Is there any significant performance/load time impact if single web page will load, say, 10 identical flash objects? 20? 30?.. any evidential data on sustainability of such kind of setup?
This would be the same flash app, each instance serving its own stream.
There's definitely going to be some overhead in size as there is a certain amount of code that is contained in every swf regardless of it's developer created content.
I'm almost certain there would be speed issues as well, which would see frame rates drop right down the more swfs you add to the page.
To be honest the concept smells a little fishy and i would think there must be a better solution to your problem.
EDIT
Also there is a restriction on having two steams coming over http per domain. Sure you could get around this but it will definitely be an issue.
I found this post which might help. The trick is to use SWFObject to embed your swf files.
I ran into a strange problem today. On the music charts page on Muziboo, I was displaying a list of songs and a playlist on the right. Each song has a small button player done in OpenLaszlo. In firefox everything was fine and in IE (not unusually), the page would freeze for sometime. This would happen once and repeat only if I delete cache and try again. I googled a bit and learnt that it's a good idea to embed give each swf a unique id otherwise the browser misbehaves. I then went ahead and used swfobject to embed the swf files and everything started working great!
Yes, it'll likely nuke the browser if you go too far down that road.
If you want to deal in multiple streams, perhaps combining all your would-be applets into one giant one might work better. It'll certainly offset the serious overhead you'd have with 10-40 of the little blighters.
If this is a music player, you want to have a serious look at doing some JavaScript remoting. It's fairly trivial to control a flash app via JS so you could have standard HTML/CSS controls without having to load up a billion flash instances.
Design-wise this just sounds like a bad idea. You'd be running multiple instances of the Flash player inside a browser, each of which has an individual cost, and the host (in this case the browser) will run all of them on the same thread (with the exception of certain elective asynchronous processes), so you're almost surely going to run into problems of various kinds -- jittery playback, UI blocking, processor burden, memory bloat, consequent instability of the host, etc.
Unless the SWFs are very tiny, and doing very little work, it seems like a design that's just asking for trouble. Indeed you could test such a thing fairly easily; have you run any tests yet? Just curious.
Also curious as to the requirements; we might be able to offer more constructive alternatives if we knew a little more about what you were aiming for. Have you considered simply loading all the SWFs into a single container SWF requiring only a single browser-hosted instance of the Flash player?