I am totally new to iOS, Xcode and automated test frameworks.
I would like to confirm 3 things about iOS testing using EarlGrey:
It cannot access elements outside of the test app. For example, the test app cannot press the 'HOME' key
It does not support the 'swipe up' gesture to bring up the control centre
It cannot not put a test app in background and then bring it to the foreground
If I understand correctly, EarlGrey only allows control of the UI elements defined inside the test app.
Is this correct?
Thanks
Yup, you are right but Out-of-app interaction is being worked on please follow along here.
Related
Im using Appium to test my notifications in my iOS app.
Im sending with another device a notification while the iOS app is in BG. Then I swipe down using :
((IOSDriver) wd).swipe(500,0,500,1000,1000);
The above works, the screen get scrolled down and I can physically see the notification. The issue is that the appium still inspects the screen below.
I checked appium inspector and it verified that it doesn't recognize nothing but the elemnts of the layer below the notifications one.
Any approach ??
As long as I know it is known limitation for iOS now.
You can get notification bar elements on Android only
But based on top comment it should be possible to wrap up with Appium since Xcode 9 introduced interaction with multiple apps, so its matter of time.
I found a workaround that fits my needs.
I found out that if I click the home button and then swipe down the notification are visible to Appium.
Because Appium not having key events for iOS, iPhone has the an accessibility option for home button, I toggled that on and I can simply click it during the test and swipe down the notification center.
I know it's not ideal but its working.
Thanks for the help.
How do you programmatically hide the menu bar in a cocoa app? I would like to make full use of the screen area.
There are two good ways I know of to do this.
1
In Cocoa, you can call the NSMenu class method setMenuBarVisible: to show or hide the menu bar.
As of this writing, the documentation for the NSMenu class does not tell you the following additional information.
The menu bar will only be hidden for the app that calls this method.
The Dock will also be hidden at the same time.
(This is true at least in 10.9 and I have not tested any other versions.)
This is useful when you want to use an app in a full screen way where you have a cover window, a borderless window the size of the screen.
The nice feature of this (as opposed to playing with LSUIElement settings) is that your app can continue to be in the application switcher cycling, as well as visible in the Dock when other apps are active.
This allows users to still activate a full screen app through the Dock or application switcher.
That means you can still use your app's Dock menu to access a preferences window for your app or other features.
This is incredibly convenient if your app is indeed a full screen cover window that runs at a window level higher than other apps, but you still want to make preferences and the ability to quit your app available, and you want your app's visual functionality available when other apps are active.
2
Another option is via NSApplication's method setPresentationOptions: with the arguments from NSApplicationPresentationOptions enum, such as option NSApplicationPresentationHideMenuBar
With this approach be very wary of reading the documentation, although it gives you additional options, and is still app-specific only, you need to know that some of the options are mutually exclusive. There are rules you must follow, or you get nothing but exceptions spewed to the console.
3 There is a 3rd and crappy option. If you have a helper app that is a daemon, you can use it to change your app's LSUIElement state and basically relaunch your app. It's dumb and it takes you out of the app switcher completely, which is great if you really are writing something that should not be there, but that is rare.
There is also the NSView enterFullScreenMode:withOptions: method, although most apps for which that would be appropriate prior to 10.7 should probably use the modern full-screen-window API on 10.7 and later.
I know this might seem odd, but I am working on a windows Metro app which would be displayed on touch screen monitors in our local university.
Now I am using the simulator for debugging, but in the simulator you have to start "Touch Mode" to even use the touch interface.
So when using the touch monitors, do we have to specifically specify touch mode ? Or it will automatically integrate the touch functionality ?
Thank you.
Touch is a first class-citizen in Windows Store applications, so no special accommodations are needed. I would recommend you test on a touch device though before deploying, it's a different way of interacting, and even though the simulator does a decent job of handling the mechanics, it will "feel" different to a user - especially if you're leveraging pinch-zoom, swipe and other gestures.
On another note... is this app intended for a kiosk-type application? If so, keep in mind with Windows 8/RT, you won't be able to easily prevent the users from swiping to the charms, navigating to other programs, etc. You may want/need to take a look at Windows 8 Embedded depending on the specific deployment requirements.
I have an iOS 5.0 app presently and had a few questions regarding deploying the app across multiple platform and multiple OS upgrades. I would like to know if there is a clean and configurable system that allows me to have one project handle deployment to the iPhone iOS5 and iOS6 and the latest iPad iOS without having ugly selection statements everywhere determining the platform the app is being currently run on. So I would like to know if there is a way to manage the code from a dev prespective so i can support all version/platform specific features of my app depending on what platform/version it is being currently run on (for ex. automatically switching to use the longer dimension background images if the app is being run on an iPhone 5 with iOS 6)
Is there any way to have this functionality?
I am slightly confused with your question, but I'll explain what I know. Xcode already has a way to change your app depending on what Device/iOS Version the user is running. If you use storyboards, then it will automatically resize your app content depending on whether the screen has retina support, and the size of the screen. In addition, you can have a storyboard for iPad, so that when you run the app it will use the iPad version. It also will change the app icons. Just go to the project settings and scroll down until your get to the icons and lunch images.
Now, if you mean you want to change how your app works using the source code directly, then there is no easy to way to manage it. Your best bet is to go with Storyboards, as it makes it very easy to resize content depending on what device your using.
I have implemented iphone application using Titanium..But I want to convert in to android application.
Is it possible doing small chnges?
There are changes, but not major changes. Here is what i would do in my case?
Understand How iPhone works and Android works. Compare them in terms
of working model and OS Architecture. This will purely give you more idea on how to make an real Android App... else you would end up cloning your iPhone feel to Android again.
List out all the components i have used in iPhone and check out the
similar component available for me to replace. { For instance,
TableView has a delete option for iPhone and not for Android }
I would remove the back button implemented in iPhone and check how i
can move between windows with the Android BackKey.
Styles and Animation i have used in iPhone will not be the same for
Android. I think they don't have full supported ones too.
For example: style:Titanium.UI.iPhone.ActivityIndicatorStyle.BIG,
maybe you experience some performance differences depending on your implementation since the javascript engine is not the same. if so, you maybe need to restructure your app to ensure a performance enhancement.