altf

iOS Wireless (OTA) App Distribution

Posted in Apple, mobile, QA, Tech by AltF on May 18, 2011

One of the major annoyance of developing a native mobile application for iOS is distributing internal builds to enterprise users/beta testers. Using the ad-hoc distribution method developer has to create a release build (.ipa or .app) with provisioning profile (.mobileprovision) and send both the files to the users who then copies these files to iTunes and syncs their device to the computer. And the users have to repeat this process each time there is a new build.

With iOS 4 you can now have over-the-air installation of applications. You can distribute in-house software to users without have them to use iTunes/Computer. Installing the app is simple. Users download the manifest file from your website to their iOS 4 device, which instructs the device to download and install the apps referenced in the manifest. You can distribute the URL for downloading the manifest file via SMS or email. You can also create a custom, easy-to-remember tiny url (http://tinyurl.com/) and share with your users.

It’s up to you to design and host the website used to distribute apps (I use simple touch friendly template for nested list of directories http://dev.sencha.com/deploy/touch/examples/nestedlist/) . You need to make sure that users are authenticated, perhaps using basic auth or directory-based authentication, and that the website is accessible via your intranet or the Internet. The app and manifest can be placed in a hidden directory, or in any other location that’s readable using HTTP or HTTPS.

Step 1. Creating the app (.ipa) and the manifest (.plist) file

  • In Xcode, you create an app archive using the “Build > Build and Archive” command.
  • Then, in the Archived Applications source in Xcode’s Organizer, select the app and click the “Share Application…” button.
  • Then click the “Distribute for Enterprise…” button.
  • In the distribution window, enter the title and the full url to the app (.ipa) file (path to the app on your webserver) for example, http://apollo42.com/testapp.ipa.
  • Xcode will then create the app (.ipa) and manifest (.plist) file based on the information you provided
  • The manifest file is a file in XML plist format. It’s used by an iOS 4 device to find, download, and install apps from your web server.

Step 2. Hosting the files on your web server

  • Along with the generated .plist and the .ipa files, you’ll need the provisioning profile and a simple index file.
  • Create a simple index file with the following href

<a href=”itms-services://?action=download-manifest&url=http://apollo42.com/testapp.plist”>Install app</a>

Note: When you archive using XCode4 + iOS 4.3 you might see “No Packager exists for the type of archive” message in the organizer when you click on share and Distribute for Enterprise option may also be missing in XCode4. This happens when you have some linked projects inside your main project. Go to the Build settings of linked projects and set the setting “Skip install” (Deployment section) to “Yes” (leave the “Skip install” of the main project to “No”). Build and Archive again and you should be able to select the ipa and the identity and when you click next you should see an option to “Save for Enterprise Distribution”

Advertisements

UIAutomation on iPad

Posted in Apple, mobile, QA by AltF on November 17, 2010

UIAutomation is only available in iOS 4.0+ SDK – so to run UIAutomation on the iPad make sure your application is compiled to run on 4.x simulator/device. You will need to download the latest version of the SDK to get the 4.x version of the iPad Simulator (also you can upgrade your device firmware to 4.x to run on the device). Download the latest version of the SDK from Apple Dev Center.

Refer to my previous post “Automating iOS User Interface Testing with UIAutomation” for getting started with UIAutomation.

For those of you who are still getting the error like “Automation is not available for this version of the iPhone Simulator.” when trying to run UIAutomation on iPad Simulator – please check the following things:

1. Ensure that you build your application for the correct version of iOS SDK. Select iOS 4.x as Base SDK in the project info before building.

2. Also ensure that the Instruments is running the application on the correct version of iPad Simulator. Select your application in the “Choose Target” and select the correct version of iPad Simulator under “Launch Options” (by default it’s selected to iPad Simulator 3.2, change that to iPad – Simulator – iOS 4.x)

Once you have selected iOS 4.x in Instruments – you should be able to run your UIAutomation scripts on the iPad Simulator.

Automating iOS User Interface Testing with UIAutomation

Posted in Apple, mobile, QA by AltF on November 14, 2010

Update: 25 June 2011
iOS 5 now supports recording these user interactions in UIAutomation which means no need to write these scripts manually.

Apple included Automated Testing support in iOS 4.0 which lets you automate testing of your iOS applications by scripting touch events. It allows you to write test scripts to exercise your application’s user interface elements as the application runs on a connected device or simulator. You write the tests in JavaScript to the UI Automation API, which simulates user interaction with the application as it runs and returns log information to the host computer.

In a nutshell:
– Automates UIKit based applications.
– Works on all iOS devices (iPhone, iPod Touch, iPad) and simulator.
– JavaScript automation scripts.
– Integrated in Instruments.
– Accessibility based.

Step 1 – Getting Started.
– Make sure that you have the latest iOS SDK (4.0+) installed | iOS SDK
– Familiarize yourself with Instruments | Instruments User Guide

Step 2 – Preparing your application.
Ensure accessibility is enabled and all the UI controls and views in your application are tagged with unique accessibility labels which makes it easy to access them in our test scripts. Using Interface Builder, you can set an element’s accessibility status and provide custom content for the label.

Step 3 – Writing test scripts.
In essence, your test script is an ordered set of commands, each of which accesses a user interface element in your application to perform a user action on it or to use the information associated within it. All the user interface elements in your application are represented to the script through an ordered hierarchy of objects defined by the UIAElements class and its subclasses.
To reach a specified UI element, the script simply calls down the element hierarchy, starting with the top level target object obtained by calling UIATarget.localTarget() The control hierarchy looks like:

var target = UIATarget.localTarget();
var application = UIATarget.localTarget().frontMostApp();
var window = UIATarget.localTarget().frontMostApp().mainWindow();

For example, if your application has a table view in the main window the hierarchy should looks like:
• Target application ■ Main window ■ View
window.tableViews()[0];

Similarly, within a view there are elements:
• Target application ■ Main window ■ View ■ Element
window.tableViews()[0].cells()[0];

And to access the child elements within an element:
• Target application ■ Main window ■ View ■ Element ■ Child element
window.tableViews()[0].cells()[0].elements()[“0”];

The Automation instrument maintains a complete element hierarchy that represents your application’s user interface. To view that hierarchy, use the logElementTree method to write an outline of it to the log:
application.logElementTree();

Once you are able to access the elements you can perform various actions on it. I’ll show you how to simulate basic touch events.

Tapping buttons:
Example: If you want to tap on the Add button on the top navigation bar. (Note that the navigation bar is outside the main window, hence we access it via:)
application.navigationBar().buttons()["Add"].tap();

Scrolling to an element:
Example: If your main application is an address book app, with the main window consisting of a tableview with elements in it. You can simply scroll to a particular element:
window.tableViews()[0].scrollToElementWithName("John Appleseed");

Logging
You can write a few assertion functions to verify if the expected results matches the actual results. You can log the results based on pass/fail. Simple example:


var testName = "Test Case 1";
UIALogger.logStart(testName);
UIALogger.logMessage("Assert Text - Check if element 5 is John Appleseed");
var expected = "John Appleseed";
var actual = window.tableViews()[0].cells()[5].elements()[5].name());
if (expected = actual) {
UIALogger.logPass(testName);
}
else {
UIALogger.logFail(testName);
}

Step 4 – Executing the test.
– Once you are ready with the test script. Compile your app in the debug mode and create a simulator build.
– Launch Instruments and select Automation from iOS Simulator templates.
– Select your target application from “Choose Target” option on the top.
– Select the test script from “Choose Script” option on the left window.
– Hit the red record button once done. It will fire up the simulator with your target app and start executing the tests.

Update:
– If you are facing any issues running UIAutomation on the iPad, refer UIAutomation on iPad

References:
API Documentation


Tagged with: , , , , , , ,
%d bloggers like this: