I have a screen with a ScrollView and a Button which is in the very bottom and is partially visible, i.e. top part of the button is in the screen, but the title is not visible, unless I scroll down:
expect(element(by.id(BUTTON_IN_THE_BOTTOM))).toBeVisible() => the matcher fails.
element(by.id(BUTTON_IN_THE_BOTTOM)).tap() => all is good, button is tapped.
This seems to be an inconsistency and I would think that the framework should be consistent in such behaviors. Is this the expected behavior?
was using detox 7.3.2
Most likely an inconsistency between matchers in Earl Grey, our iOS backend framework.
Regardless, you are asking for trouble by not scrolling. The position on screen is dependent on several factors, including device size, RN layout system and the OS layout system and content. You should not really make assumptions about pixel accuracy. By not scrolling the button the visible, you are introducing flakiness where there shouldn't be.
Use the swipe action on the list to get to the bottom of the screen so the button will be visible. As stated above, This will prevent flaky behaviors such as testing on small res devices will fail your tests.
Related
I'm having some issues with a website that only occur in Safari. I'm running version 5.1.7 (7534.57.2) on a Mac.
You can view the site here: http://mcad.edu/annual-report-2011-12/.
The website is parallax scrolling, with a relative positioned content div that holds everything, including the 3 parallax scrolling backgrounds which are all fixed, top and left set to 0.
Within the fixed parallax background containers, colorized images fade into full color images when a user mouses over them. For each "image", there are two divs stacked, each with background images that are positioned by background-position. The div on the bottom has the colorized image. The div on top has the full color image as a background and has its opacity set to 0 until mouseover. The fade is achieved using a CSS transition on the opacity property so that the top div becomes visible.
So, in Safari only, when I mouse over any of these divs, the transition occurs smoothly but all of the content in the same parallax scrolling background div shifts/jumps in the process. If I remove the CSS transition, this does not occur.
I think that it might have something to do with the transition/webkit-transition property not playing nicely with a fixed position container in Safari. However, all of the issues I've found that relate to that are from 2010 and mention a Safari bug that I assume has been fixed…two years later. But maybe not.
There's also another issue with the Catalyst section (3rd dot down on the right navigation). These animated images work as links in Chrome, Firefox and Opera, but not Safari. Any ideas?
I have a similar issue with a fixed position and transition-duration for a header menu I've created. When a visitor scrolls down, the menu has a box shadow that fades into place. Well when this is viewed on safari in a MacOS, I get a weird sliding in issue. To easily fix this, after spending way to much time searching for answers, I'm removing the transition effect for macs. This fixes the slide in issue but gets rid of the transition effect sadly.
So as you were speculating, it probably is the transition duration on your project as well. The best thing for this would probably be to make a Mac-Safari CSS file, get rid of the transition-duration for that particular area and move on with your project.
Best I can suggest for now. Hope it helps.
I want to know that how one should proceed in building animated splash screen.
I already did the animated splash screen with images but here I want to add custom animation like something is drawn on screen etc.
can anyone guide me through this.
simply you need to present a UIViewController which is hold your animations and dismiss it when your app is ready to launch. but also I think its better to follow apple HIG .. as apple describe you should
Supply a launch image to improve user experience.
Avoid using your launch image as an opportunity to provide:
An “application entry experience,” such as a splash screen An About
window Branding elements, unless they are a static part of your
application’s first screen Because users are likely to switch among
applications frequently, you should make every effort to cut launch
time to a minimum, and you should design a launch image that downplays
the experience rather than drawing attention to it.
Generally, design a launch image that is identical to the first screen
of the application.
Exceptions:
Text. The launch image is static, so any text you display in it will
not be localized.
UI elements that might change. Avoid including elements that might
look different when the application finishes launching, so that users
don’t experience a flash between the launch image and the first
application screen.
I have an app that has a list of tags on the bottom of the window. This list grows over time and needs to be scrolled horizontally. This was fine before, but now in Lion they scrollbars automatically hide. If using a mouse without a horizontal scroll, there's basically no way to scroll these now in Lion. What are the best practices here to solve the issue? Do I need to get rid of the scrollview and change it to a "More" list or something?
If the user doesn't have a device available which supports touch-based scrolling (e.g, a touchpad, Magic Trackpad, or Magic Mouse), the horizontal scrollbar won't be hidden by default. It's controlled by this preference option:
I've got a tabbed iPad application with just about each tab running a UIWebView. I'm getting all sorts of callbacks, like when a user tries to leave the corporate site (which only displays the company site to users). In this case, I pop up a "toast" style window that tells them to click a button to open the page in Safari. I also pop it up with a spinner and no text to indicate that a page is loading. The approximate look that I'm going for is used in lots of applications, but you can see it best when changing the volume on the iPhone or iPad. It's just a translucent rounded square that fades in and out.
Right now I've got it implemented on one of my tabs, and I did it by creating the objects (a spinner, a label, and a UIImage with the square) and then programmatically hiding and showing them using [UIView beginAnimations] and changing the label's text. It works perfectly but I've got these nagging things hovering over my interface in Xcode, and it takes a lot of setup to accomplish if I wanted it to be in another tab, which I do. I can't help but think that there's a better way to accomplish this. I thought about making and adding a subview, but that would leave a white background to the toast. What I'm thinking is creating some sort of object that I can allocate in a tab's view controller whenever it's needed.
What are your guys ideas, or have you done this in the past? I see it in a lot of prominent applications, like Reeder, so I'm sure it's been done more eloquently than I have done it.
Matt Gallagher has a great class called LoadingView here Showing message over iPhone Keyboard. I use it.
MBProgressHUD is a popular library for this, as well.
I want to create a full Screen Cocoa application, however my app is slightly different from a conventional fullscreen app.
This app would be below everything else, so underneath the menu bar and the Dock, etc. It would have a large image covering up the Desktop and icons, with a custom NSView in the middle with a table view, etc. If this concept is hard to understand then here is an image:
http://img10.imageshack.us/img10/6308/mockupo.png
The only part that might be a bit confusing is the background image. This background image is NOT the wallpaper of the computer, but part of the app. So when the app is launched, it goes into full screen mode and puts itself underneath the dock and the menu bar, and underneath all other windows too. So it draws the background image to cover the screen (including Desktop and icons). Then has a custom NSView in the middle containing my controls.
What's the best way to go about doing this?
Thanks
Make a borderless window, the size of the menu-bar screen (screen 0—not [NSScreen mainScreen]), positioned at 0,0, with window level kCGDesktopWindowLevel.
Remember that you will need to observe for screen frame-change notifications (when the user changes the screen dimensions), and that you should correctly handle the case of no screen at all (headless Mac).
I think #Peter Hosey’s solution should work, but to make other windows go on top, you will probably need to change the window level to something else.
But, I implore you, do not do this. This will be the most bugly application the Macintosh has ever seen. There are a lot of really good user interface paradigms that you can use, and "replicating" the main desktop interface of Mac OS X is generally not one of them. That is, unless you are reimplementing Time Machine or something like that.