recently i found that when we change in resolution or changing the screen resolution percentage it will reflact on site or desktop UI not showing like we need
i need same UI for all resolution
Related
I'm currently developing a Flutter app which contains online videos. Since users don't want to be bothered with the slow download speeds and high mobile data usage, we decided to introduce two different formats for the video content, where one is more optimized for slower connections and those who prefer using Power Saving Mode (or Low Power Mode in iOS) and Data Saver (or Low Data Mode in iOS).
While some packages including power already exists to detect for Power Saving Mode (thanks to Flutter/IOS Low Power Mode), I can't seem to find any Flutter plugins to detect those functionalities, unless if I can spend some time building native bindings for:
Android: https://developer.android.com/training/basics/network-ops/data-saver
iOS: Is there any way to detect iOS 9 low power mode programmatically?
Searching for pub.dev for "low data mode", Android's "ConnectivityManager" and iOS' "ProcessInfo" does not work, too. And no, connectivity_plus does not detect for this feature, too.
And even worse, searching for "data saver" and "ConnectivityManager" in the site returns Flutter's material library for some reason 🙃
So, is there any packages which I can use for this? Or should I create one from scratch?
Since I don't have watches with xxhdpi and xxxhdpi,I've tried manually configuring an AVD to support both the resolution watches in emulator.
I'm trying to create a new profile for this(Parameters are added in attached screenshot)
But It is creating 480*480 hdpi watch device.As per DisplayMetrics provided by android, 480*480 will have xxhigh
There is no XXHDPI or XXXHDPI WearOS hardware in production (or announced); the highest screen density in the wild is 348dpi, which is still in the XHDPI bucket.
So, I'd conclude that the WearOS emulator hasn't been built to support densities higher than XHDPI.
I have Eddystone UID functioning correctly for nearby Android phones who have Bluetooth enabled. In other words, a notification appears in the notification window with a brief call to action (or as specified) along with the favicon pulled from the linked website. The issue is that the favicon is very low resolution. The icon that's being pulled is obviously not optimal and is being blown up to fill the notification window.
What is the preferred favicon format for these display windows to show the icon in optimal resolution? I have seen them displaying correctly with high resolution icons, so I know that it can be done.
I am trying to accomplish this task:
Running an app on a Samsung Smart TV (in background, kind of)
This app should check the screen content in an interval and calculate the main color of screen content or the main colors of each border (lets say 20% of width and heigth from border)
Use the remote accessible api for HUE to control n Philips HUE Lights to accomplish a roomwide ambilight.
Now as I am an android developer and do not have any experience with Smart-TVs I would ask you, if this could be accomplished (or if there is any show stopper) and you have some tips for me, prior to diggin into this very deeply? The actual "How to get startet developing a SmartTV App" will not be the main problem and I am into this right now.
So my actual questions are:
What is the best bettern (or is it impossible) to have something like an background job in an Samsung SmartTV? Maybe something like a ticker app with no actual visible overlay or a very small one, would also be a solution?
Is there a way to access the currently shown picture on TV, so I get access to the rgb values of the areas/pixels or maybe a screenshot or thumbnail of the screen, no matter what the source of the signal is, as I have to analyze it to get the color.
Would be great I you could advise me some resources specially to this tasks and give me some advice if this will be working or if there are any limitations or better concepts.
It seems the Huey app in the Play Store does what you want but accomplishes it in a different manner, using the camera of a device set in front of the TV to determine the colors.
Steve,
Hue API is not fit to be used as Ambilight control facility, since Hue API is not run real-time.
Overheads generated by client and server make it possible to develop Hue API - based Ambilight apps supporting 1-2-3 Hue Lights,
since hue, sat, bri are updated by server-side run scripts, so upddate is slow.
You need to run Ambilight real-time ( 5-10 updates in 1 sec) and have 8-10 or more Hue lights controlled real-time.
So I develop real-time hardware based Ambilight demo for my students.
Hue API alone is not heavy but Hue API calls are server-side processed by API handlers, to send calls via Zigbee master to Hue Lights with Zigbee
hardware and protocol embedded.
Smart TV is hardware based solution, so runs almost real-time and you can get video image updated frequently.
This may pique your interests: Build your own Ambilight clone with the Raspberry Pi
I just wonder if the devicePixelRatio related to the web-kit based browsers and Apple's device is really useful, Or it's just apple's private asset. You know, the web-kit engine is also belongs to apple inc. I think this kind of stuff was only meaningful for Apple's Retina screen, and i always think that the deference between the screen's resolution and OS's resolution should be handled properly by the OS, it's not our task.
If there are lots values of devicePixelRatio range from 0 to 1000000, how many pictures should i prepared for those screens.
Web browsing is the most popular activity for mobile device users and webpages themselves are served in a variety of shapes and sizes.
Apple and the various companies that followed them into the mobile hardware arena needed to make the web browsing experience as easy as possible in order to maximize the amount time spent using and relying on their devices. They needed to avoid having the user pinch and zoom and pan around a page in order to read content, so they exposed an API to web developers known as "meta viewport" which allowed them to serve with little extra effort a small screen adapted versions of their website.
Later they realized that scaling in such a manner made images look like absolute crap when scaled up in a higher dpi device like apple retina AND android devices like the galaxy sIII and nexus devices. So they made a variable devicePixelRatio and a corresponding CSS Media Query to enable web developers to detect that a given device needs higher resolution images in order for a website to look good after being scaled. No one expects website owners/developers to waste 2x the bandwidth serving bitmaps with subpixel data to EVERYONE just because 0.2% of their users happen to be using a device with 2x the usual amount of pixels for a given physical size. In order for a high dpi device to be successful they needed to make the web look good on it and the only way for the web to look good on it is to make it easy and worthwhile enough for a website owner/developer to opt into making their website look good on it.
its up to the website developer to weigh the cost and benefit of taking the extra time to selectively serve images so that a website will not look bad on high pixel density devices. If the web ever comes to a point where most websites are doing this, the consumer will be under the impression that YOUR website is of low quality, not due to some shortcomings in the hardware they are using.
and just to clarify:
apple only uses 1 and 2 for their devicePixelRatio.
google promotes use of 1, 1.5, and 2 (although they cannot always enforce this).
microsoft uses 96dpi (1) 144dpi (1.5) 192dpi (2) in their screen.deviceXDPI value
most people just serve one 2x resolution version of their assets to all devices above some sort of threshold like 1.3 and 1x versions to devices below that. For those web developers who understand what exactly all these device values mean and how to use "CSS Media Queries" or their respective javascript values, it is extremely easy and not as frustrating as I suspect you are imagining it to be.