There are several ways to customize your basic application behavior to provide the user experience you want. The following sections describe some of the customizations that you must make at the application level.
Launching in Landscape Mode
Applications in iPhone OS normally launch in portrait mode to match the orientation of the Home screen. If you have an application that runs in both portrait and landscape modes, your application should always launch in portrait mode initially and then let its view controllers rotate the interface as needed based on the device’s orientation. If your application runs in landscape mode only, however, you must perform the following steps to make it launch in a landscape orientation initially.
The UI Interface Orientation property hints to iPhone OS that it should configure the orientation of the application status bar (if one is displayed) as well as the orientation of views managed by any view controllers at launch time. In iPhone OS 2.1 and later, view controllers respect this property and set their view’s initial orientation to match. Using this property is also equivalent to calling the set Status Bar Orientation: animated: method of UI Application early in the execution of your application Did Finish Launching: method.
Communicating with Other Applications
If an application handles URLs of a known type, you can use that URL scheme to communicate with the application. In most cases, however, URLs are used simply to launch another application and have it display some information that is relevant to your own application. For example, if your application manages address information, you could send a URL containing a given address to the Maps application to show that location. This level of communication creates a much more integrated environment for the user and alleviates the need for your application to implement features that exist elsewhere on the device.
Apple provides built-in support for the http, mail to, tel, and sms URL schemes. It also supports http–based URLs targeted at the Maps, YouTube, and iPod applications. Applications can register their own custom URL schemes as well. To communicate with an application, create an NSURL object with some properly formatted content and pass it to the openURL: method of the shared UI Application object. The openURL: method launches the application that has registered to receive URLs of that type and passes it the URL. When the user subsequently quits that application, the system often relaunches your application but may not always do so. The decision to relaunch an application is made based on the user’s actions in the handler application and whether returning to your application would make sense from the user’s perspective.
The following code fragment illustrates how one application can request the services of another application (“todolist” in this example is a hypothetical custom scheme registered by an application):
If your application defines its own custom URL scheme, it should implement a handler for that scheme as described in “Implementing Custom URL Schemes”. For more information about the system-supported URL schemes, including information about how to format the URLs, see Apple URL Scheme Reference.
Implementing Custom URL Schemes
You can register URL types for your application that include custom URL schemes. A custom URL scheme is a mechanism through which third-party applications can interact with each other and with the system.
Through a custom URL scheme, an application can make its services available to other applications.
Registering Custom URL Schemes
To register a URL type for your application, you must specify the subproperties of the CF Bundle URLTypes property, which was introduced in “The Information Property List”. The CF Bundle URLTypes property is an array of dictionaries in the application’s Info.plist file, with each dictionary defining a URL type the application supports. Table describes the keys and values of a CF Bundle URL Types dictionary.
Keys and values of the CF Bundle URLTypes property
Figure shows the Info.plist file of an application being edited using the built-in Xcode editor. In this figure, the URL types entry in the left column is equivalent to the CF Bundle URL Types key you would add directly to an Info.plist file. Similarly, the “URL identifier” and “URL Schemes” entries are equivalent to the CFBundleURLName and CFBundleURLSchemes keys.
Defining a custom URL scheme in the Info.plist file
After you have registered a URL type with a custom scheme by defining the CF Bundle URLTypes property, you can test the scheme in the following way:
Handling URL Requests
The delegate of an application handles URL requests routed to the application by implementing the application: handle OpenURL: method. You especially need the delegate to implement this method if you have registered custom URL schemes for your application.
A URL request based on a custom scheme assumes a kind of protocol understood by those applications requesting the services of your application. The URL contains information of some kind that the scheme-registering application is expected to process or respond to in some way. Objects of the NSURL class, which are passed into the application: handle OpenURL: method, represent URLs in the Cocoa Touch framework. NSURL conforms to the RFC 1808 specification; it includes methods that return the various parts of a URL as defined by RFC 1808, including user, password, query, fragment, and parameter string. The “protocol” for your custom scheme can use these URL parts for conveying various kinds of information.
In the implementation of application: handleOpen URL: shown in Listing, the passed-in URL object conveys application-specific information in its query and fragment parts. The delegate extracts this information—in this case, the name of a to-do task and the date the task is due—and with it creates a model object of the application.
Handling a URL request based on a custom scheme
Be sure to validate the input you get from URLs passed to your application; see Validating Input in SecureCoding Guide to find out how to avoid problems related to URL handling. To learn about URL schemes defined by Apple, see Apple URL Scheme Reference.
Displaying Application Preferences
If your application uses preferences to control various aspects of its behavior, how you expose those preferences to the user depends on how integral they are to your program.
When determining whether a set of preferences is integral, think about the intended usage pattern. If you expect the user to make changes to preferences some what frequently, or if those preferences play a relatively important role in how the application behaves, they are probably integral. For example, the settings in a game are usually integral to playing the game and something the user might want to change quickly. Because the Settings application is a separate application, however, you would use it only for preferences that you do not expect the user to access frequently.
If you choose to implement preferences inside your application, it is up to you to define the interface and write the code to manage those preferences. If you choose to use the Settings application, however, your application must provide a Settings bundle to manage them.
A settings bundle is a custom resource you include in the top level of your application’s bundle directory. An opaque directory with the name Settings.bundle, the settings bundle contains specially formatted data files (and supporting resources) that tell the Settings application how to display your preferences. These files also tell the Settings application where to store the resulting values in the preferences database, which your application then accesses using the NS User Defaults or CF Preferences APIs.
If you implement your preferences using a settings bundle, you should also provide a custom icon for your preferences. The Settings application looks for an image file with the name Icon-Settings.png at the top level of your application bundle and displays that image next to your application name. The image file should be a 29 x 29 pixel PNG image file. If you do not provide this file at the top level of your application bundle, the Settings application uses a scaled version of your application icon (Icon.png) by default.
Turning Off Screen Locking
If an iPhone OS–based device does not receive touch events for a specified period of time, it turns off the screen and disables the touch sensor. Locking the screen in this way is an important way to save power. As a result, you should leave this feature enabled except when absolutely necessary to prevent unintended behavior in your application. For example, you might disable screenlocking if your application does not receive screen events regularly but instead uses other features (such as the accelerometers) for input.
To disable screen locking, set the idleTimerDisabled property of the shared UIApplication object to YES. Be sure to reset this property to NO at times when your application does not need to prevent screen locking. For example, you might disable screen locking while the user is playing a game but should reenable it when the user is in setup screens or is otherwise not actively playing the game.
IPHONE APPS Related Interview Questions
|C Interview Questions||IPHONE APPS Interview Questions|
|Mobile Testing Interview Questions||Oracle apps Interview Questions|
|Java Native Interface (JNI) Interview Questions||JNDI (Java Naming and Directory Interface) Interview Questions|
|Mobile computing Interview Questions||jQuery Mobile Interview Questions|
|Mobile Security Interview Questions||Objective C Interview Questions|
|Mobile Developer Interview Questions||Mobile Application Testing Interview Questions|
|Apps Associates Manual Testing Interview Questions||Mobile Marketing Interview Questions|
Iphone Apps Tutorial
The Core Application
Window And Views
Graphics And Drawing
Text And Web
Files And Networking
All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd
Wisdomjobs.com is one of the best job search sites in India.