I am developing a website that will be used by two sets of people. One set will have 22 inch monitors, then other set have varying sizing but some are antique and some are pretty small.
My question is, is testing on one monitor under different resolutions (e.g. using Screenfly) the same as testing on several monitors of different sizes? This question created some debate with my colleagues, but ultimately we don't really know.
There are few things to consider.
Device what is viewed on, a Mobile device, PC, etc. Mobile devices treat websites differently. Even if the resolution of the screen is to say 720p, browsers tend to display them as a 340px wide screen in portrait view.
Also besides screen size, you have to consider the resolution of the screen, You can have a 14-inch screen with a resolution of 1920x1080, or you could have a 40-inch screen with the same resolution.
So with all of these in mind, it becomes quite cumbersome to test for specific screen sizes. Programs like Screenfly and many others do a good job. But can hide some bugs and glitches. As they cannot copy the native support of the device, they mimic as well as they can. If your website is simple, it should do fine if you have followed responsive design practices. However if it JavaScript heavy website it could fail to display potential problems.
So in conclusion. No, Screenfly is not 100% guaranty there will be no bugs on the actual device. The best solution would be to test on actual devices of varying size.
Related
I am looking for a wireless communication technology for exchanging data between devices via sound in ultrasonic frequencies.It is possible to communicate with two mobile devices.I want to communicate a mobile and an embedded device.Is it possible?Any device is working with this protocol?
Of course it is possible. Back in the 1970's my TV remote control used ultrasound to change the channel and turn the TV off. The control was somewhat rudimentary IIRC a short press changed the channel up and a long press turned the TV off. It worked quite reliably for these functions.
Providing more functionality would require a more complicated modulation scheme which, as has been said in another answer, would be prone to interference from other sound sources. This probably explains why infra-red communucation signals are used in more modern remote control systems.
It is possible - why shouldn't it be? Smartphones are just embedded computers too. I imagine getting CE/FCC/etc certifications with such an embedded device will not be so easy. And production testing ...
But is it feasible? Probably not. Power consumption is a lot higher than with any RF-link, it's more susceptible to noise (quite literally) and the required components (microphone+speaker) are bigger than RF-components (antenna).
And then there's a whole bunch of other things you need to keep in mind when working with ultrasound, starting with the plastic design of the embedded device. But also things like the effect of ultrasound on people and their pets etc.
I'm new to Roku development (in R&D phase actually). I read that we can't test Roku app on simulator and need real device. If we develop an application, how will we test it?
I checked Roku developer site and different links on internet, but could not find anything that answers my questions
As per my info, Roku sells 5 devices so:
Can we do one app that supports all 5 devices?
Do we need assets in multiple resolutions?
Do I need to buy all devices?
Can we do one app that supports all 5 devices?
Yes. Roku is trying hard to keep their platform coherent, though there are performance issues between the OpenGL and non-OpenGL devices. The "legacy" models (<2222) are no more supported, the firmware is kept current for the others.
Do we need assets in multiple resolutions?
Theoretically yes, practically - not really. You can make-do with assets in only one resolution, if you RTFM and pre-plan carefully. You'll need 3 sizes of app icon, no sweat. For the real UI though, you can either do HD (720) or FHD (1080) and leave it scale accordingly - the thing is TV is very forgiving to scaling graphics because of 10ft watching distance (60" 1080p screen is "Retina" beyond 8ft). Can largely snub SD.
Do I need to buy all devices?
No. And there are much more than 5 devices that are in use - see https://forums.roku.com/viewtopic.php?f=34&t=86471&start=15#p536994 for some statistics (RokuCo does not publish statistics, so that's about the best info available). If you buy only 2 devices, i'll say get
a #42xx (Roku 3 or current Roku 2) as reference model with OpenGL
a #27xx (Roku 1 or SE) or #5xxx RokuTV as reference for "slower", non-OGLES
As 3rd model i'll say the "new HDMI stick" #3600. You can get that one as the only device, its performance is somewhere between (1) and (2) above... but i don't think developing with only 1 device is a good idea.
One thing you may not have noticed is that there are also these "Roku TV" things under Hisense/TCL/Sharp/Insignia brands, models #5xxx. These are proper TVs with proper Roku smarts - meaning can run your Roku app. And one can be had for as little as... (skimming BestBuy web) $130-150 for 24-32" screen.
And i haven't even mentioned the 4k/HDR craze here, nor the new 37xx/46xx models that will be out for the holiday season (i only expect minor, evolutionary changes there).
Disclosure: I am a Roku employee.
That's correct, you'll need an actual Roku device to test your application. You can buy them used on eBay for very cheap ($20-35), or you can buy a brand new unit from our website for $50. The latest Roku Streaming Stick (Model #3600X) is my personal favorite option, and a great value.
You don't need to buy all devices, although we do recommend having many models so that you can QA test across devices. However, one popular development approach is to build your channel on a lower-end model, which theoretically will assure it works on higher-end models as well. This will also mean you have to spend less on your purchase.
Download our Precertification Checklist and open the third sheet, which includes a list of all our model numbers and corresponding code names. I'd recommend building on a "Giga" or a "Paolo."
Think of this cost as an R&D expense. Plus you'll get to enjoy the device on your free time as well!
As for your other questions:
Yes, you will only build one app that will work on all different devices. We do recommend taking the time to make sure your app is optimized across all devices, including older devices with less processing power. Our Performance Guide is a great starting point for this.
The other option is to check if the first number of the device model is less than “3” (which indicates it's a lower-end device) and add conditionals off that, such as removing animations.
You can find two examples of this on our RokuDev GitHub page:
Hero-Grid-Channel —> Components —> LoadingIndicator —> LoadingIndicator.brs —> Line 244
Multi-Live-Channel —> Source —> Main.brs —> Line 21
Yes, you do need different assets based on resolutions. Take a look at this document: https://github.com/rokudev/docs/blob/master/design/channel-artwork.md
Can Somebody suggest me whether it is effective to Test all as many mobile device as possible to ensure a website compatibility.
As per my view, it is good for some extent to test various version of a Browser to check the Page view and compatibility rather testing many mobile or tablet devices.
Please share your thoughts.
Your correct to some extend.When testing a mobile web site we need to be concerned about following
Browser compatibility
Page rendering in different screen resolutions/sizes
From above, we should pay more attention to Browser compatibility. And your correct on putting more weight on same.
By testing on many devices we can cover the screen resolution/form factor support.However, you should be able to create a good set of target test devices(Around 10)to cover the most used devices in the market.
For most used Android device types based on screen size, you can refer Android Dashboard for latest data
https://developer.android.com/about/dashboards/index.html
My suggestion based on current data, is to focus on following combination
Small Size - ldpi Density
Normal, Large, X Large - mdpi density
Normal Size - hdpi density
Normal Size - xhdpi & xxhdpi density
So for Android you can manage with around 7 devices for the initial round of testing based on current status
For iOS you could check the latest iPad & iPhone cause the platform has very few different screen sizes & adoption of the latest OS and device is better in iOS
Reference
http://www.fiksu.com/ipad-iphone-and-ios-7-adoption-trackers#ipad-usage
http://www.fiksu.com/ipad-iphone-and-ios-7-adoption-trackers#iphones-usage
Based on my experience with less than 10 devices you can have significant coverage on form factor support for mobile web testing.
Hope this is helpful..
Suppose I have a 3D (but not stereoscopic) DirectX game or program. Is there a way for a second program (or a driver) to change the camera position in the game?
I'm trying to build a head-tracking plugin or driver that I can use for my DirectX games/programs. An inertial motion sensor will give me the position of my head but my problem is using that position data to change the camera position, not with the hardware/math concerns of head tracking.
I haven't been able to find anything on how to do this so far, but iZ3D was able to create two cameras near the original camera and use it for stereoscopic stuff, so I know there exists some hook/link/connection into DirectX that makes camera manipulation by a second program possible.
If I am able to get this to work I'll release the code.
-Shane
Hooking Direct3D calls in its nature is just hooking DLL calls. I.e. its not something special to D3D but just a generic technique. Try googling for "hook dll" or start from here: [C++] Direct3D hooking sample. As it always happens with hooks there are many caveats and you'll have to make a pretty huge boilerplate to satisfy all needs of the hooked application.
Though, manipulation with camera in games usually gives not good results. There are at least two key features of modern PC game which will severely limit your idea:
Pre-clipping. Almost any game engine filters out objects that are behind the viewing plane. So when you rotate camera to a side you won't see the objects you'd expect to see in a real world - they were just not sent to D3D since game doesn't know that viewing plane has changed.
Multiple passes rendering. Many popular post processing effects are done in extra passes (either thru the whole scene or just part of it). Mirrors and "screens" are the most known such effects. Without knowing what camera you're manipulating with you'll most likely just break the scene.
Btw, #2 is the reason why stereoscopic mode is not 100% compatible with all games. For example, in Source engine HDR scenes are rendered in three passes and if you don't know how to distinguish them you'll do nothing but break the game. Take a look at how nVidia implements their stereoscopic mode: they make a separate hook for every popular game and even with this approach it's not always possible to get expected result.
I today had basic question in my mind ,what is the difference between
testing functionality in browser and same in mobile. say testing
m.gmail.com in browser and same directly in mobile using selenium.Is
there any difference other than the fitting into screen etc.
If you have a different server to handle mobile requests, you might have different implementation of the features, thus, you need to test both platforms.
The content might also be delivered according to the mobile browser used (Safari on the iPhone is much more feature-rich than the default N95 browser, for example).
Let’s look at some of the major differences.
Limited Real Estate
The most obvious difference is screen size. Responsive design is relatively easy to code for desktop and laptop browsers – most of which come with predefined ratios anyway.
By contrast, mobile devices are much smaller. Aligning images and text becomes a real challenge – especially when you factor in features like portrait orientation (i.e. the ability to rotate a mobile device and have the image flip accordingly).
Worse still, there is so much more variation – even when dealing with the same manufacturer.
For example, the iPhone 5 has a 4” display, whereas the iPhone 6 is 4.7” on the diagonal. When you add in the iPhone 6 Plus (5.5”), iPad Mini (7.9”), and iPad standard (9.7”), it becomes harder and harder to code and test mobile applications that look “good” on all screens.
Storage and RAM
Screens are not the only spatial constraint mobile software testers face. You also must factor in the limited storage and processing power of today’s mobile devices. Even high capacity phones can quickly fill up as users download apps and multimedia.
In the browser world, such constraints are moot. Desktop storage is essentially unlimited (measured in terabytes). And cloud-based storage is easy to increase, even if this requires charging higher prices to end-users.
Internet Access
With the exception of a few off-line browser applications (e.g. Gmail), Web-based software always requires an Internet connection.
Mobile apps may or may not need online access (although those that don’t often take up more space – see point #2 above). When Internet is needed, however, mobile software testers must factor in 3G and 4G – in addition to normal Wi-Fi.