Scenario :
"My application may escape control during UI automation to another application like the browser etc"
Solution :
"I want to get back to my application which I am automating after it loses control and moves to another app so that I can proceed with my automation"
Tried :
I can figure out if an application escapes control by checking the bundle id's after each action so that if the actual and current bundle id's differ I get to know that my application lost control.
I am blocked on how to proceed further in getting back to my application in case it moves out of control
Thank you for your time and effort in going through till the end :)
This is a limitation of the "sandbox" in iOS -- once your app loses focus, UIAutomation must terminate as well. You will need to launch another instruments session to automate the browser (or whatever application you're switching to).
See this question for some information on launching an automation session against those apps.
Related
I want to test the sign in screen and once I complete one test, my app is signed in but for the next test I want to sign out and go to the first screen again. (PS: App does not have a sign out).
Is there any way out that I can clear application data without uninstalling the app so that I can resume my tests from the first screen without any break.
Or please suggest if there is any other option.
You could try cmd-shift-hh? then swipe the app up, then you can test the app again
This kind of feature is important, because in the case where the app fails a test (and is therefore in an unknown state), you want a reliable way to return to a known state -- like the first screen.
The bad news is that Apple doesn't give you this within instruments.
One way to do to it is to take advantage of the shake gesture -- assuming that you don't need it for other things in your app -- so that in a UIAutomation build, calling target.shake() will return you to your first screen.
Another way to do it would be to instrument your code so that you can send a reset signal from the shell as part of your test. In our framework (called Illuminator), we provide an automation bridge to accomplish this.
driver.resetApp(); It may work. try this.
I was wondering how it works to make changes to an app without re-uploading the binary and go through the whole process again. I have got an example for it:
The developer of Whatsapp made changes to his app twice already, just today for the second time. This "update" included the blue indicators which show wether the chat-partner read your message or not. The 1st time I noticed changes to the app without an update was when he introduced voice messages.
Does anyone have an idea how this works?
You can use Google Tag Manager to make simple tweaks to your app without having to update the entire app. Here is an overview of how it can work (I've used this on Android apps)
Suppose your app's interface is supplied in whole or in part from a server - i.e., it's really a web view showing HTML that you are serving. Then you can just change the code on the server.
I am using the HttpContext.Current.Session.IsNewSession to decide on what page to show when my MVC4 application launches.
This works great on desktop, iOS safari.
However on iOS Chrome, every time I close the browser (actually close tabs and close the application from the task manager) and relaunch it the IsNewSession is always false.
I am guessing it uses the session cookie ASP.NET_SessionId to track this as there is a new cookie value when I close my desktop or safari.
However on iOS Chrome, when I close and relaunch the cookie has the old value - which I am guessing is the root of the issue.
So why does iOS/Chrome not clear my ASP.NET_SessionId cookie even though it should be a Session cookie and deleted when the browser is closed.
Thanks.
I suspect this is because of a design feature of many modern mobile operating systems whereby apps don't really close when you might think.
With desktop applications you have a lot more screen real estate and so it's easier to manage windows and multitask. So closing applications feels natural and necessary when you're done with it.
With mobile applications, however, there is more of a focus on the user being able to open and switch between applications seemlessly and so the concept of closing or minimising apps is abstracted away and taken care of by the operating system.
This means that when you close Chrome, it's not really closing (and may not close at all before you enter the app again). Therefore the session is never cleared.
If you force close the app then your function will work as expected.
There's no elegant work-around that I can think of for your problem. One idea is to store the time of last activity for the user and if it's greater than, for example, 5 minutes, then you can show them your startup page.
I'm using Xamarin.Android and I would like to build an application that start in modal way and don't close if you push the home button.
So this application need to be the only one application than a user can use on device.
Somebody can suggest how it can be done?
You best way to do is to make a "Launcher"/"Home" application. The Android SDK comes with a sample on how to do this.
You basically do this by adding your main Activity to the android.intent.category.HOME and android.intent.category.DEFAULT category and you set the launchMode to singleInstance.
This will register it as a Home application, then when you press your home button it should ask you to choose which launcher you want to use. You will have to set it once and it can be changed by the user.
You can find the sample in: android-sdk\samples\android-17\Home\src\com\example\android\home (should also be available in the other API samples).
You cant stop people from installing applications on android devices. You would have to build your own hardware for that however, you can override OnKeyTouch and check for the key being home.
You could build a service that checks the package of each running application and log which applications are run on the device to prevent users from using company property on other things. However, if android ever decides to kill your application the service should stop and this wont work.
Long story short what you are trying to do is flawed in its inception given the platform you are trying to do it on.
I have an application built using XPages' mobile controls. On an ipHone the application behaves as I would like in the standard Safari browser. When I take the url and add it to the Home Page as an icon and use the application from there every time an action I take invokes a native application (Maps, Contacts, Phone, attachment viewers etc.) when I switch back to my application I am immediately asked for my userid and password again. Is there a way to control the behavior to not lose the login credentials the same way that the standard Safari application seems to.
This is a limitation in iOS. If you save it to the home page like that it works, but it will NOT multi-task. That's the problem. So it doesn't remember where you were or anything like that.
As David mentions it starts all over again when you switch back.... The problem is not only the credentials - it is also all the information you may have entered or where you have navigated to in the "app".
This is why I am changing to another approach. I am starting to write apps as web-apps that run locally (i.e. cache the ressources and run on the cached versions of the JS-files, CSS and images). Then I implement a localstorage where you can track where in the app you are - and return to that place again. This way you do not need the authentication for running the app - only for synchronizing the information with the server. My approach is to save data locally and sync them to the server (as a sort of replication). This obviously gives more work - but it also gives a better user experience since you can run the "app" without being connected.
I have tried to control the caching locally using a cache.manifest file. This can be done, however, it is a pain. Therefore, I am now using Sencha Touch which really does this nicely.
/John
PS. I think you may be able to handle the login issue by using the XPage Dojo login custom control (http://www.openntf.org/internal/home.nsf/project.xsp?action=openDocument&name=Xpages%20Dojo%20Login%20Custom%20Control) - however, it does not solve the issue with reloading the page...
It seems the secret to success here is NOT to tell Safari the XPage is capable of acting as a mobile web app. Add the following code inside for the XPage to ensure this is the case.
<xp:metaData
name="apple-mobile-web-app-capable"
content="no">
</xp:metaData>
Note: You can still provide an icon for the home screen, its just that icon will now act more like a bookmark with the Safari controls and (more importantly) you can switch between applications and when you return to Safari it will display your Xpages app just as you left it.