Developing native mobile apps with IBM Worklight

Mobile applications are quickly becoming the primary means through which companies engage their customers, partners, and employees. As the need for mobile applications grows, companies are looking for better and more efficient ways of handling this relatively new demand. IBM® Worklight® is a mobile application platform that is uniquely positioned to help in this regard. One example of Worklight’s flexibility is the ability for users to create mobile web, hybrid, and native apps on the platform. In this article, we will explore the use of IBM Worklight for the creation of native mobile applications. This content is part of the IBM WebSphere Developer Technical Journal.

Share:

Dustin Amrhein, IBM MobileFirst Solution Architect, IBM

Author photoDustin Amrhein is a MobileFirst Solution Architect at IBM. In this role he helps clients to evaluate, design, and adopt solutions that support their enterprise mobility strategy. Dustin started with IBM as a developer for WebSphere Application Server where he worked primarily on Web and REST services runtimes. While in the development lab, Dustin also worked on cloud computing and web communication technologies.


developerWorks Professional author
        level

Steve Mirman (samirman@us.ibm.com), Client Technical Specialist , IBM

Steve Mirman is a WebSphere Application Infrastructure Expert covering the eastern United States with over 15 years experience. His primary areas of focus are on the emerging Mobile (Worklight), Web (WebSphere eXtreme Scale (WXS), WebSphere Virtual Enterprise (WVE), WebSphere Compute Grid (WCG)), Cloud (IBM Workload Deployer (IWD)) and DataPower appliance (X150 and XC10) technologies. Steve received his IBM Senior IT Certification in 2013 and has numerous other certifications in WebSphere (v5.1, v6, v6.1, v7, v8), Java (SCJP), Linux (RHET), and Worklight (v5, v6). In his current role he leads proof of concept (POC), proof of technology (POT) and infrastructure workshop engagements to demonstrate IBM product capabilities to clients.



Eliran Ben Ishay (eliran@us.ibm.com), Solution Architect, IBM

Eliran Ben Ishay is a senior mobile applications developer with +9 years experience in mobile development for iOS & Android smart phones and tablets as well as legacy mobile devices, Eliran has core programming expertise in web technologies and UI frameworks and native coding. He also maintains expert-level experience in Object-oriented development (full life cycle) and design of mobile applications, as well as integration with 3rd party SDKs such as Facebook, Twitter, Bump, etc. Eliran worked for multiple customers developing mobile solutions including MobileESPN and Motorola IDEN Group.



30 October 2013

Also available in Japanese Portuguese

Introduction

If you have any experience with mobile application development, you know that one thing you have plenty of is choices. From development tools, to development languages, to run time platforms, there are many important choices to be made. In particular, though, there is one choice that is typically the subject of more discussion than others. This is the choice of application architecture and packaging.

One of the first decisions you make as you are beginning a mobile application project is what kind of application you will create.

Figure 1. Mobile application architecture choices
Mobile application architecture choices

As a mobile application developer you have, as depicted in Figure 1, a choice between mobile web apps, hybrid apps, or native apps. There is much debate about the “right” answer, but the reality is that there is no wrong answer. Some projects might favor the ubiquity and portability of a mobile web application, while others favor the optimization and device exploitation afforded by the hybrid or native approach. Each of these approaches has its pros and cons, and any one might be the right choice for a given application project.

The decision that you make in terms of which application architecture to utilize for a given project is an important one, as it has a direct impact on user experience. Having said that, it is critically important that you retain the ability to make this choice. In other words, the tools and technologies that you use to develop, run, and manage mobile applications should not make this choice for you.

This is precisely the stance that the IBM Worklight mobile application platform takes in terms of application architecture. The platform supports all of the application types shown in Figure 1 and enables you to decide which approach is right given your project’s requirements. Regardless of the choice you make, Worklight provides you with high value runtime, integration, security, and management services for your mobile applications.

This article focuses specifically on using Worklight to develop, deliver, and manage native apps. The majority of time will be spent walking through the process of creating, building, deploying, and managing a native mobile app in Worklight. But before doing that there is an important point to make: Why choose Worklight for building native apps when there are plenty of tools out there already for creating native apps — most of them, in fact, provided directly by the platform vendors?

To answer that question, there are a number of factors to consider:

  • Holistic platform: When considering what you need in order to support mobile app development in the enterprise, some requirements are obvious. In particular, you know that you need a set of development tools to support this endeavor. However, it might be easy to forget that you need to be able to build, distribute, and manage the applications you deploy. In other words, you not only need a development tool, you need a complete platform. Worklight is an enterprise-grade, end-to-end mobile application platform that enables you to develop, build, deploy, run, and manage mobile applications.
  • Common platform: If your organization has multiple mobile app projects for multiple different constituencies, it is likely you will find yourself embracing many, if not all, of the mobile architectural styles. You can either have a tool and lifecycle management approach for each of the different architectural styles, or you can have a common platform and toolset that supports each of these different styles. If only for sanity’s sake, the latter is the better choice. Worklight provides a single platform and toolset for all of the mobile application architectural styles discussed in this article.
  • Common services: Again, considering the fact that you are very likely to embrace multiple architectural styles within your organization, it would be nice (and convenient and smart) to be able to use a common security and integration approach for all the different types of apps. With Worklight you can develop a common set of integration services, security services, and mobile app services (for example, push notification services) that you can leverage across many different mobile apps in your enterprise. Furthermore, these apps do not need to be of the same architectural type in order to share these common services.

Using Worklight APIs in native iOS applications

The next sections will take you through the process of developing a native iOS application using Worklight. The sample application will utilize Worklight’s built-in native APIs to demonstrate the invocation of remote procedures, parsing of remote data, and integration with native iOS user interface controls. The objective is to clearly demonstrate how a native application can effortlessly be written to take advantage of the numerous capabilities and benefits the Worklight platform has to offer.

The application itself will use Worklight native APIs to read an RSS feed from a publicly accessible website (for this example, cnn.com).

Figure 2. Sample Worklight application
Sample Worklight application

This particular application scenario is deliberately simplistic in nature to help you observe how Worklight handles both the native client side interactions and the invocation of remote server side adapters. Worklight offers numerous client and server side capabilities designed to improve the development experience as well as the management of mobile applications.

Overview of steps to create sample application:

  1. Create a Worklight native API
  2. Create and configure an iOS native application
  3. Invoke a Worklight procedure
  4. Handle a procedure response

This article includes the following material for you to dowbnload:

  • WLNativeRssReader.zip - Worklight native API project
  • RssFeedReader_v1.zip – Clean native Xcode project that you will work with
  • RssFeedReader_v2.zip – Finished native Xcode project
  • Worklight native API Snippets.doc - code segments

Creating a Worklight native API

Worklight provides the ability for native iOS applications to communicate with a Worklight Server by using the Worklight native API library. To serve a native iOS application, the Worklight server must be aware of it, and to do that you create a native API folder in your Worklight project. This folder contains a native API library and configuration file to be copied into your native project, and it contains the application-descriptor.xml file that you deploy to the Worklight Server. This file contains metadata that describes the application to the Worklight Server and enables the server to begin servicing requests for and managing the application.

To build the Worklight native API project:

  1. Open Worklight Studio and create a new Worklight project (Figure 3).
    Figure 3. Creating a Worklight Project
    Creating a Worklight Project
  2. Name the project WLNativeRssReader. Select the Native API option and click Next (Figure 4).
    Figure 4. Application types in the Worklight project wizard
    Application types in the Worklight project wizard
  3. Enter the Application name WLNativeRssReader. Select iOS for the Environment field. Click Finish (Figure 5).
    Figure 5. The Native API application wizard panel
    The Native API application wizard panel
  4. Click Yes to open the associated prospective (Figure 6).
    Figure 6. Perspective change prompt in Worklight Studio
    Perspective change prompt in Worklight Studio
  5. You are now ready to deploy the application to the Worklight Server. This means the server will be aware of the application and be able to service requests. To do this, right-click the WLNativeRssReader app folder and select Run As > Deploy Native API.
    Figure 7. Deploying the Native API project
    Deploying the Native API project
  6. Expand the WLNativeRssReader folder and double click on the worklight.plist file (Figure 8).
    Figure 8. Locating the properties file in the native project
    Locating the properties file in the native project
    Figure 9. worklight.plist file properties
    Select Native option
  7. Edit the worklight.plist file that holds the server configuration. In this file:
    • protocol: The communication protocol to the Worklight server, which is either HTTP or HTTPS.
    • host: The hostname of the Worklight server.
    • port: The port of the Worklight server.
    • wlServerContext: The context root path of the application on the Worklight server.
    • application id: The application ID as defined in the application-descriptor.xml file.
    • application version: The application version.
    • environment: The target environment of the native application (Android or iOS).

Before we continue lets look at the project components. These include (Figure 10):

  • WorklightAPI: This folder is a Worklight API library that must be copied to your native iOS project.
  • application-descriptor.xml: File used to define application metadata and to configure security settings to be enforced by a Worklight server.
  • Worklight.plist: File that contains connectivity settings to be used by a native iOS application. This file must be copied to your native iOS project.
  • server\conf: Like with any Worklight project, you create the server configuration by modifying files in the server\conf folder.
Figure 10. Worklight Native API project structure
Worklight Native API project structure

Creating an HTTP adapter

Adapters run on the server and connect to mobile apps.

Adapters are the server-side part of applications that are deployed on and serviced by Worklight. Adapters connect to enterprise applications (otherwise referred to as back end systems), deliver data to and from mobile applications, and perform any necessary server-side logic on this data.

Various benefits provided by Worklight adapters include:

  • Fast development: Adapters are developed in JavaScript and XSL. Developers employ flexible and powerful server-side JavaScript to produce succinct and readable code for integrating with back end applications and processing data. Developers can also use XSL to transform hierarchical back end data to JSON.
  • Read-only and transactional capabilities: Worklight adapters support read-only and transactional access modes to back end systems.
  • Security: Worklight adapters use flexible authentication facilities to create connections with back end systems. Adapters offer control over the identity of the user with whom the connection is made. The user can be a system user, or a user on whose behalf the transaction is made.
  • Transparency: Data retrieved from back end applications is exposed in a uniform manner, so that application developers can access data uniformly, regardless of its source, format, and protocol.
  1. Within Worklight Studio, right-click the Worklight project and click on New > Worklight Adapter (Figure 11).
    Figure 11. Creating a new Worklight Adapter
    Creating a new Worklight Adapter
  2. Select Adapter HTTP Adapter. Enter Adapter name RSSReader. Click Finish (Figure 12). Worklight will now generate the appropriate JavaScript, XML, and XSL files that make up the server side component of an adapter.
    Figure 12. The adapter creation wizard
    The adapter creation wizard
  3. For the purpose of this article, use the default HTTP adapter files generated by Worklight (Figure 13).
    Figure 13. Worklight Adapter files
    Worklight Adapter files

    Let’s look at the basic adapter structure:

    • RSSReader.xml: Defines the adapter properties and procedures.
    • RSSReader-imp.js: Uses JavaScript to create procedures.
    • filtered.xsl: Use XSL to filter received records and fields (optional).
  4. Listing 1 shows the RSSReader.xml file that was generated by Worklight.
    Listing 1. RSSReader.xml
    <displayName>RSSReader</displayName>
    	<description>RSSReader</description>
    	<connectivity>
    		<connectionPolicy xsi:type="http:HTTPConnectionPolicyType">
    			<protocol>http</protocol>
    			<domain>rss.cnn.com</domain>
    			<port>80</port>	
    			<!-- Following properties used by adapter's key manager for 
    			choosing specific certificate from key store  
    			<sslCertificateAlias></sslCertificateAlias> 
    			<sslCertificatePassword></sslCertificatePassword>
    			-->		
    		</connectionPolicy>
    		<loadConstraints maxConcurrentConnectionsPerNode="2" />
    	</connectivity>
    
    	<procedure name="getStories"/>
    <procedure name="getStoriesFiltered"/>

    In this file:

    • protocol: The end point communication protocol (http or https).
    • domain: The end point hostname or domain name.
    • port: The end point port.
    • procedure: Declares a procedure that is exposed by the adapter.
  5. Next, you want to deploy the adapter to the Worklight server. Doing so will make the adapter, and subsequent back end services, accessible to applications pointing to the same Worklight server (Figure 14).
    Figure 14. Deploying the new adapter
    Deploying the new adapter
  6. Open your web browser and navigate to http://localhost:10080/WLNativeRssReader/console.
    Figure 15. Viewing the application in the Worklight Console
    Select Native option

Creating and configuring an iOS native application

You can either create an Xcode project or use an existing one (for this exercise, use existing he existing Xcode project included with this article). You will now integrate your Worklight project with a native iOS application.

The integration consists of the following steps:

  1. Link the project to some native Worklight libraries.
  2. Import the WorklightAPI and worklight.plist files to the native project.
  3. Add Worklight procedure code.
  4. Solidify the connection between native and Worklight code.
  5. Run the completed application on the iPhone simulator.

Now, let’s continue:

  1. Open the attached RssFeedReader project in XCode by double clicking on the RssFeedReader.xcodeproj file.
    Figure 16. Native iOS project in XCode
    Native iOS project in XCode
  2. Copy the WorklightAPI folder and the worklight.plist file from the project in Worklight Studio to the root directory of your native project. You can drag and drop the files from Worklight Studio to the Xcode environment. This will include the required Worklight library files in the native Xcode project.
    Figure 17. Files to include in the native project
    Files to include in the native project
  3. Make sure you check the Copy items into destination group’s folder (if needed) and click the Finish button (Figure 18).
    Figure 18. Adding files to the XCode project
    Adding files to the XCode project
  4. When finished, your project explorer should look similar to Figure 19.
    Figure 19. XCode project after copying required files
    XCode project after copying required files
  5. Link the following libraries in your native iOS application. This ensures all the necessary native libraries are included in the project (Figure 20):
    • CFNetwork
    • SystemConfiguration
    • MobileCoreServices
    • CoreData
    • Security
    • libz.dylib
    • sqlcipher.framework (if not included already)
    Figure 20. Linking libraries in the project
    Linking libraries in the project
  6. Click the + sign and type the name of the library you want to add from the list above into the search box (Figure 21).
    Figure 21. List of available libraries for the XCode project
    List of available libraries for the XCode project
  7. After you add all the required libraries, your project structure should look like Figure 22.
    Figure 22. XCode project after linking required libraries
    XCode project after linking required libraries

Creating and testing adapter invocation

  1. Create a new class by selecting File > New > File (Figure 23).
    Figure 23. Creating a new class in XCode
    Creating a new class in XCode
  2. Select Objective-C class and click Next (Figure24).
    Figure 24. The new file wizard in XCode
    The new file wizard in XCode
  3. Name the Class MyInvokeListener and click Next.
    Figure 25. Naming the new class
    Naming the new class
  4. Select the folder where you want to save the file (within the project folder) and click Create (Figure 26).
    Figure 26. Saving the new class
    Saving the new class
  5. Now you get to write some code. Open the MyInvokeListener.h file and add the code shown in Listing 2. The purpose of these modifications is to configure initWithController such that it will hold a reference to the MainView after being invoked during the initialization of MyInvokeListener.
    Listing 2. MyInvokeListener.h
    #import <Foundation/Foundation.h>
    
    #import "WLClient.h"
    #import "WLDelegate.h"
    #import "MasterViewController.h"
    
    @interface MyInvokeListener : NSObject <WLDelegate> {
    @private
        MasterViewController *vc;
    }
    
    - (id)initWithController: (MasterViewController *) mainView;
  6. Open the MyInvokeListener.m file and add the code shown in Listing 3.
    Listing 3. MyInvokeListener.m
    #import "MyInvokeListener.h"
    
    @implementation MyInvokeListener
    
    - (id)initWithController: (MasterViewController *) mainView{
        if ( self = [super init] ){
            vc = mainView;        
        }
        return self;
    }
    
       @end
  7. Add the two methods in Listing 4:
    • onSuccess: will be invoked when the procedure successfully finished.
    • onFailure: will be invoked when the procedure failed.
    Listing 4. The onSuccess and onFailure methods for adapter invocation
    //onSuccess callback - called when the adapter Invocation finsih successfully.
    -(void)onSuccess:(WLResponse *)response {
    
    }
    
    
    //onFailure callback - called when the adapter Invocation failed.
    -(void)onFailure:(WLFailResponse *)response{
    
    }
  8. Implement the onFailure first. If a failure occurs, you would like to display a message to the user and then stop the UiActivityInidcator (Listing 5).
    Listing 5. Implementation of the onFailure method
    //onFailure callback - called when the adapter Invocation failed.
    -(void)onFailure:(WLFailResponse *)response{
        NSLog(@"\nProcedure Invocation Failure: %@", response);
        NSString *resultText = @"Invocation failure. ";    
        if ([response responseText] != nil){
            resultText = [resultText stringByAppendingString:[response responseText]];
        }
        NSLog(@"\nProcedure Invocation Failure: %@", resultText);
        //Display a message to the user.
        UIAlertView *alert = [[UIAlertView alloc] initWithTitle:@"No network connection"
    
    message:@"Please check your network connection and make sure the adapter been deployed."
    
    delegate:nil
    
    cancelButtonTitle:@"OK"
    
    otherButtonTitles:nil];
    
        [alert show];
    [vc.spinner stopAnimating];
    }
  9. Next, implement the onSuccess method. On successful execution, you would like to get the JSON object from the response and then extract the items into an array so that you can iterate thorough the items, adding each to the tableView (Listing 6 shows the procedure response).
    Listing 6. Invocation result of procedure 'getStoriesFiltered' from the Worklight Server
    "Items": [
          {
             "description": "Russian President Vladmir Putin says everyone will be 
    welcomed at next year's Winter Olympics, regardless of their \"nationality, race 
    or sexual orientation.\"",
             "guid": "http:\/\/edition.cnn.com\/2013\/10\/28\/world\/europe\/
    russia-putin-olympics-gay\/index.html",
             "link": "http:\/\/edition.cnn.com\/2013\/10\/28\/world\/europe\/
    russia-putin-olympics-gay\/index.html?
    eref=edition",
             "pubDate": "Tue, 29 Oct 2013 03:16:43 EDT",
             "title": "Putin: Gays, lesbians come to Sochi"
          },
          {
             "description": "An Israeli air strike hit two concealed rocket launchers in 
    the Gaza Strip Monday, 
    the military announced.",
             "guid": "http:\/\/edition.cnn.com\/2013\/10\/28\/world\/meast\/
    israel-gaza-airstrike\/index.html",
             "link": "http:\/\/edition.cnn.com\/2013\/10\/28\/world\/meast\/
    israel-gaza-airstrike\/index.html?
    eref=edition",
             "pubDate": "Mon, 28 Oct 2013 11:53:11 EDT",
             "title": "Israel launches Gaza air strike"
          },
  10. Add the code in Listing 7, which performs the iteration and parsing:
    Listing 7. Handling adapter invocation results in the onSuccess callback
    //onSuccess callback - called when the adapter Invocation finsih successfully.
    -(void)onSuccess:(WLResponse *)response {
        NSLog(@"\nProcedure Invocation Success: -------------------------");
        //Retrive the JSON response.
        NSDictionary *responseDict = [response getResponseJson];
        //Get all the items within the JSON response to array.
        NSArray *itemsArray = [responseDict objectForKey:@"Items"];
        //For each item in the array create a new cell in the tableView.
        for (int i=0; i<[itemsArray count]; i++){
            NSDictionary *itemDict = [itemsArray objectAtIndex:i];
            NSLog(@"Title :: %@" , [itemDict objectForKey:@"title"]);        
            [vc addNewObject:itemDict atIndex:i];
        }
        
        //Stop the UIActivityIndicator spinning.
        [vc.spinner stopAnimating];
    }
  11. Build and run the application to ensure you don’t have any errors. Your application should look like Figure 27.
    Figure 27. Sample application on the iPhone simulator
    Sample application on the iPhone simulator
  12. Open the MasterViewConroller.m file and add the code necessary to invoke the Worklight adapter. You will first define the myInvocationData with the adapter name and procedure you want to invoke. Then, you define an invokeListener that will listen to the procedure invocation and fire the onSuccess or onFailure methods implemented within MyInvokeListener.
  13. First, add the imports shown in Listing 8.
    Listing 8. Adding imports for the new classes
    //Add reference to the Worklight API
    #import "MyInvokeListener.h"
    #import "WLProcedureInvocationData.h"
  14. Within the MasterViewConroller.m file, locate the invokeWorklightProcedure method and add the code shown in Listing 9.
    Listing 9. The invokeWorklightProcedure method
    //invoke the worklight procedure to get rss feeds.
    - (void)invokeWorklightProcedure
    {
        NSLog(@"%@", @" in invokeWorklightProcedure() ...");    
        WLProcedureInvocationData *myInvocationData = [[WLProcedureInvocationData 
    alloc] initWithAdapterName:@"RSSReader" procedureName:@"getStoriesFiltered"];
        MyInvokeListener *invokeListener = [[MyInvokeListener alloc] initWithController: self];
        [[WLClient sharedInstance] invokeProcedure:myInvocationData withDelegate:invokeListener];
    }
  15. Now, add some code that will call the inovkeWorklightProcedure once the application starts. Search for method viewDidLoad.
    Listing 10. Code to call the Worklight Adapter on application start
    - (void)viewDidLoad
    {
        NSLog(@"%@", @"viewDidLoad - MasterViewController");
        //self.tbViewObjects = [[NSMutableArray alloc] init];
        [super viewDidLoad];
        
        //Add refresh button to the navigationBar.
        UIBarButtonItem *refreshButton = [[UIBarButtonItem alloc] initWithBarButtonSystemItem:
    UIBarButtonSystemItemRefresh target:self action:@selector(refreshRssFeed:)];
        self.navigationItem.rightBarButtonItem = refreshButton;
        
        //Create a UIActivityIndicator
        [self initUIActivityInticator];
        
        //Set the tableView bacground image.
        UIImageView *bg = [[UIImageView alloc] initWithImage:[UIImage imageNamed:
    @"page_background.jpg"]];
        [self.tableView setBackgroundView:bg];
        
        //Set padding of 5px to the cells.
        UIEdgeInsets inset = UIEdgeInsetsMake(5, 0, 0, 0);
        self.tableView.contentInset = inset;    
        
        //Call worklight procedure.
        [self invokeWorklightProcedure];
        [spinner startAnimating];
    }
    - (void)viewDidLoad
    {
        NSLog(@"%@", @"viewDidLoad - MasterViewController");
        //self.tbViewObjects = [[NSMutableArray alloc] init];
        [super viewDidLoad];
        
        //Add refresh button to the navigationBar.
        UIBarButtonItem *refreshButton = [[UIBarButtonItem alloc] initWithBarButtonSystemItem:
    UIBarButtonSystemItemRefresh target:self action:@selector(refreshRssFeed:)];
        self.navigationItem.rightBarButtonItem = refreshButton;
        
        //Create a UIActivityIndicator
        [self initUIActivityInticator];
        
        //Set the tableView bacground image.
        UIImageView *bg = [[UIImageView alloc] initWithImage:[UIImage imageNamed:
    @"page_background.jpg"]];
        [self.tableView setBackgroundView:bg];
        
        //Set padding of 5px to the cells.
        UIEdgeInsets inset = UIEdgeInsetsMake(5, 0, 0, 0);
        self.tableView.contentInset = inset;    
        
        //Call worklight procedure.
        [self invokeWorklightProcedure];
        [spinner startAnimating];
    }

    Navigate to the end of the method and add the lines in Listing 11 immediately after the //call worklight procedure.

    Listing 11. Invoking the adapter procedure
    //Call worklight procedure.
    [self invokeWorklightProcedure];
    [spinner startAnimating];
  16. These two lines invoke the Worklight procedure once the application starts (viewDidLoad), and when onSuccess is executed, it will add the items to the table view. If an onFailure event occurs, an alert will be displayed to the user.
  17. Build and run the application in an iPhone simulator (Figure 28).
    Figure 28. App running in iPhone simulator
    App running in iPhone simulator
    Figure 29. Xcode console window
    Xcode console window
  18. In Figure 29, you will notice that you are receiving a server connectivity error. There are four possible explanations for this error:
    • You forgot to deploy the application.
    • You deployed the application but didn’t deploy the adapter.
    • You deployed both application and adapter properly and can see them in the Worklight console (http://localhost:10080/WLNativeRssReader/console/) but the host address in the worklight.plist does not match your machine’s IP address.
    • Your wlServerContext within the worklight.plist file does not match your server context. In this case, your wlServerContext should be /WLNativeRssReader and not /.
  19. Open the web browser and navigate to http://localhost:10080/WLNativeRssReader/console/ to ensure you can see both the application and the adapter deployed.
    Figure 30. Viewing the application and adapter in the Worklight Console
    Viewing the application and adapter in the Worklight Console
  20. Next, open a command line terminal and type ifconfig (for Mac OS).
    Figure 31. Determining the IP address of the local environment
    Determining the IP address of the local environment
  21. Open the worklight.plist file and ensure the host IP address and the remaining parameters match your application configuration (Figure 32).
    Figure 32. Configuring the proper IP address for the Worklight application
    Configuring the proper IP address for the Worklight application
  22. Save the file and then build and run your application again.
    Figure 33. RSS feed listing in the application
    RSS feed listing in the application
  23. Now you are seeing the RSS feeds properly, but what happens when you click on the Refresh button? You will notice that all the cells in the tableView disappear. This is because you have not yet implemented that functionality.
    Figure 34. Feed listing content after clicking the refresh button
    Feed listing content after clicking the refresh button
  24. Open the MasterViewController.m file and look for refreshRssFeed (Listing 12).
    Listing 12. The refreshRssFeed method
    //refresh the rss feed.
    - (void)refreshRssFeed:(id)sender
    {
        //remove all objects & refresh the tableView
        [self.tbViewObjects removeAllObjects];
        [self.tableView reloadData];
        self.tableView.separatorStyle = UITableViewCellSeparatorStyleNone;
    
        [self invokeWorklightProcedure];
        [spinner startAnimating];
    }
  25. Add the two lines shown in Listing 13 so that on refresh the invokeWorklightProcedure will be executed and the bustIndicator will once again be displayed.
    Listing 13. New code to implement the refresh functionality
    [self invokeWorklightProcedure];
    [spinner startAnimating];

Worklight application management

Now that your application is deployed and working properly, let’s take a look at Worklight’s application management capabilities.

  1. Open your web browser and navigate to http://localhost:10080/WLNativeRssReader/console/#catalog.
  2. Change the application version 1.0 status from Active to Active, Notifying Figure 35). Enter the message you would like your user to see and click the Save button. You should see a yellow notification indicate that the change was saved.
    Figure 35. Setting a notification rule in the Worklight Console
    Setting a notification rule in the Worklight Console
  3. Build and execute your application again. You should now see your notification message displayed on the iOS simulator (Figure 36).
    Figure 36. The notification dialog in the application
    The notification dialog in the application

Conclusion

This article explained how native applications, along with hybrid and mobile web apps, can be developed using the Worklight mobile application platform. You also learned about Worklight’s vast client side APIs and native integration with back end systems using the built-in native API components. From a management perspective, you observed Worklight’s functionality around server connectivity, application versioning, service notifications, and remote disable. Now you have the knowledge to port your current native iOS applications to Worklight or start from scratch with a new project.


Download

DescriptionNameSize
Sample codeWLNativeRssReader_iOS7.zip16.3 MB

Resources

Learn

Get products and technologies

Discuss

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into WebSphere on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=WebSphere, Mobile development
ArticleID=950516
ArticleTitle=Developing native mobile apps with IBM Worklight
publish-date=10302013