Posts Tagged ‘mobile’

Queen of the Net

Morgan Stanley analyst Mary Meeker stole the show last week with her “State of the Web” presentation at the Web 2.0 Summit in San Francisco. Crowned “The Queen of the Net” in 1998 by Barron’s Magazine, Meeker started covering the nascent tech sector in the mid-eighties as an analyst with Solomon Brothers. Throughout the years, she has published a long list of research reports and leading insights into the future of technology — most notably, a 322 page tome titled “The Internet Report” Co-authored with Chris DePuy in 1995.

Successful stocks Meeker championed early on included Dell, Microsoft, Intuit, Netscape, AOL, Amazon.com, Yahoo!, eBay and Google. Failed picks included AOL after its takeover of Time Warner, Excite@Home and drugstore.com.  In 2004, Morgan Stanley (with Meeker as research analyst) served as lead manager for the initial public offering of Google. Recently named one of the 10 smartest people in tech by Fortune Magazine, Meeker is currently a managing director at Morgan Stanley and serves as head of the investment bank’s global technology research team.

The land grab for Internet access

Smartphone sales to pass PCs in 2012 Chart
Slide #10 suggests that Smartphones will pass PCs in 2012.

The topline data point shows that smartphone sales will outpace those of PC’s — both notebook and desktop computers combined — in two years, with more than 450 million smartphones projected to ship in 2012.

Apple iOS devices “ramping faster than any new thing”

The report shows that usage of Apple iOS devices — the iPhone, iPad and iPod touch with 120 million users — has ramped up faster than any previous technology including NTT Docomos’s imode Web phones, the Netscape browser and AOL’s early dial-up Internet service.

The report also points to Apple and Google’s Android platform driving “excitement and momentum” in mobile, with their respective smartphone platforms together accounting for 37% share of the market.

It’s a Smartphone future

It’s increasingly clear that smartphones are here to stay as mainstream devices and the research underscores the necessity for organizations to understand essentials of the brave new mobile world. Fundamental themes of  mobile application development, mobile advertising, mobile commerce and mobile website optimization should all be part of the mobile innovation strategy as the gap between PC’s and mobile closes over the next 12-24 months.

Nielsen’s mobile phone statistics for the third quarter showed smartphones now account for more than 28 percent of the entire U.S. cellphone market. As such, mobile smartphone applications (apps) are the newest “must-have” item for retailers and businesses wanting to connect with tech-savvy consumers.

While mobile apps definitely have the potential to build your business by engaging customers in unique ways, many overlook a logical starting point: making your website mobile friendly. Some businesses have chosen to circumvent website compatibility and usability issues by offering apps that try to provide the same features as their website. While apps do have their time and place, they are not the silver bullet.

The benefits of mobile website optimization vs. applications include:

  • Better Compatibility: apps are extremely platform specific, meaning that without having an app on each platform, you are alienating a portion of your potential traffic.  As opposed to developing mobile applications for 2, 3 (or more) platforms, one standard website optimized for all smartphones can be accessed anytime on any device.
  • Lower Cost: many times the mobile website can deliver the same functionality as would a stand-alone application at less than half the price of a full-fledged app. You may get more bang for your buck from the properly optimized mobile site than you would from an application.
  • Customer Usability: the end-users experience is ultimately what matters. While applications can serve advanced purposes, it can still be difficult to navigate simple sites if it’s not properly optimized for finger-based browsing.
  • Maximum Reach: mobile websites can reach a broader audience than can an individual app, based on the fact that they are aligned with your businesses website.

In order to make the case for mobile sites, it is important to look at the market and an increasing percentage US adults use their smart phones to browse the web; as the next generations of smart phones are launched, mobile browsing will only continue to grow. Many carriers are also requiring mandatory data plans with the sale of web-enabled phones, anticipating the growth of mobile web use.

Additionally, many non-phone mobile devices use a “limited function” browser to browse the web. This includes tablet devices such as the iPad and Amazon’s Kindle Reader. These devices also usually benefit from a mobile site, though not as significantly as smart phones.

This presents challenges to many companies who have invested in a very good and very effective website, but suffer from it being incompatible with mobile browsers, or just plain difficult to use on mobile devices.

Specifically, sites programmed in Flash are currently not compatible with almost any phone browser. Flash sites are excellent tools for traditional desktop browsers, and provide great tools for customer engagement, but are completely dysfunctional on mobile phones. Even if this changes with some of the new OS launches and upgrades this year, Flash sites will still require some mobile optimization to exhibit the same level of effectiveness.

None of this is meant to completely discount the value of apps for the right situation, just to emphasize that taking a step back to start with the overall mobile browsing experience makes sense. Apps and widgets definitely have their place and may ultimately work better for your particular business – but don’t ignore the basics when it comes to mobile website optimization.

The idea here is to parse the XML response from a Wunderground Data Feed Web Service, which provides information for current weather conditions. The conceptual part of target XML follows. More details about XML and available weather API can be found on the Wunderground Data Feed site.

<current_observation>
  <credit>Weather Underground NOAA Weather Station</credit>
  <credit_URL>http://wunderground.com/</credit_URL>
  <image>
    <url>http://icons.wunderground.com/graphics/wu2/logo_130x80.png</url>
    <title>Weather Underground</title>
    <link>http://wunderground.com/</link>
  </image>
  +<display_location></display_location>
  +<observation_location></observation_location>
  <station_id>KSFO</station_id>
  <observation_time>Last Updated on July 14, 9:56 AM PDT</observation_time>
  ...
  <local_time>July 14, 10:01 AM PDT</local_time>
  ...
  <local_epoch>1247590877</local_epoch>
  <weather>fog</weather>
  <temperature_string>52 F (11 C)</temperature_string>
  <temp_f>52</temp_f>
  <temp_c>11</temp_c>
  <relative_humidity>76%</relative_humidity>
  ...
  <icon>fog</icon>
  ...
</current_observation>

For processing this XML we decided to use DOM parser for the following reasons:

  • To save the structure of data (more flexible usage for presentation and further processing)
  • To ensure good maintainability and adaptability (external provider may change XML structure)
  • The XML is not so large that it would not cause memory issues.
Figure 1 the DOM presents an XML document as a tree-structure

DOM Tree

The DOM presents an XML document as a tree-structure. The parser creates a tree object out of the document. The user accesses data by traversing the tree. The API allows for constructing, accessing and manipulating the structure and content of XML documents (Figure 2).

Figure 2 Using a DOM Tree.

For our implementation we use a very simple and effective parser - XMLTreeParser/XMLTreeNode. The implementation consists of two classes: XMLTreeParser and XMLTreeNode. It uses NSXMLParser to read the document and for every one <element> tag creates a XMLTreeNode object. That way, it creates the tree that contains nodes of type XMLTreeNode.

To create a parser, simply instantiate the XMLTreeParser class:

XMLTreeParser* parser = [[XMLTreeParser alloc] init];

After that start parsing – call the parse method and provide the XML data:

&lt;strong&gt;XMLTreeNode* root = [parser parse:xmlData];

Now you can traverse through the tree manually looking for things.

NSArray* items = [stuffindChildren:@&quot;icon&quot;];

Architecture of an XML application using DOM

The DOM model is easiest to understand. On Figure 3, a basic architecture of an XML application using DOM is presented:

Figure 3 Architecture of an XML application using DOM

So here’s what happens: A parser reads the XML file and builds a DOM document to match the XML file. From that point until a save is performed, all interaction between the application and XML hits the DOM document rather than the corresponding XML file. It’s interesting to note that almost all XML parsers use SAX. Before you build a DOM document you must detect events such as the start of an element (start tag encountered), end of an element (end tag encountered) and/or a new attribute (name followed by equal sign followed by quoted string encountered). DOM can be thought of as an extra abstraction to lessen the programmer’s workload, at the expense of memory usage.

Modifications are made directly to the DOM document. Elements can be added, deleted, renamed, and rearranged. Text nodes can be added, delete,d or changed. Elements can be moved either within the same level, or promoted or demoted to different levels.

Choose a design pattern for implementation

Choosing the appropriate pattern is a critical step. The Dynamic Document architectural pattern was used in our case. This pattern contains XML not typed by DTD or schema, but follows assessors for underlying program objects. It allows for unlimited extension by multiple, uncoordinated parties at the cost of lack of type-checking, and it’s simple to implement.

Figure 4 Map the XML document to object model.

The DOM API is used to read information from an XML document. There is an easier way of getting around using DOM for modifying and saving the XML data — creating an object model for the information in the document. You can create this object model by giving it a DOM object that holds all the XML document information. That is, the XML document should be mapped to an object model.

Figure 4 shows how to map the Current Observation XML document to a set of related classes (object model). The <current_observation> element is mapped to the CurrentObservation class; the <display_location> element is mapped to the DisplayLocation class. The <observation_location> element is mapped to the ObservationLocation class. Single elements (without sub elements or others attributes) are mapped to the parent element class properties.  Each class can be instantiated using a method or Factory implementation by providing a part of XML tree, with root – class element. In this the exampleinit method was used -(id)initWithData:(NSData *)data;.

Here is a partial code listing from CurrentObservation.h:

  @interface WUCurrWeather : NSObject {
   NSString *credit;
   ...
   Image *image;
   DisplayLocation *displayLocation;
   ...
   NSString *icon;
  ...
  }

  @property(nonatomic, retain) NSString *credit;
  @property(nonatomic, retain) Image *image;
  @property(nonatomic, retain) DisplayLocation *displayLocation;
  ...
  @property(nonatomic, retain) NSString *icon;
  ...

  - (id)initWithData:(NSData *)data;

  -(NSString *)description;
  @end;
and Image.h files

@interface Image : NSObject {
NSString *url;
NSString *title;
NSString *link;
}
@property(nonatomic, retain) NSString *url;
@property(nonatomic, retain) NSString *title;
@property(nonatomic, retain) NSString *link;
- (id)initWidthData:(XMLTreeNode *)root;
- (NSString *) description;
@end
Now you can use your object model to manage data as you wish – save it in a database or show it in a GUI for example.

Example

Below is an example of a View Based iPhone Application that calls a Wunderground Data Feed Web Service to get current weather conditions. The update button repeats the call and refreshes the screen when new data arrives. The screenshots below visualize the application’s behavior:

In the provided source code you can find all these steps implemented.

Existing APIs for XML processing fall into two categories:

  • SAX (Simple API for XML) is a serial access parser API for XML. It provides a mechanism for reading data from an XML document. The quantity of memory that a SAX parser must use in order to function is typically much smaller than that of a DOM parser. Unlike DOM, there is no formal specification for SAX.
  • The Document Object Model (DOM) is a cross-platform and language-independent convention for representing and interacting with objects in HTML, XHTML and XML documents. It represents a tree structure based API. The Dom parser implements the DOM API and it creates a DOM tree in memory for a XML document. Because DOM supports navigation in any direction (e.g., parent and previous sibling) and allows for arbitrary modifications, an implementation must at least buffer the document that has been read so far (or some parsed form of it).

Cocoa offers a “complete” XML parser with the NSXML family of classes.

  • NSXMLParser is a SAX parser, meaning that it traverses the XML tree and informs a delegate of events as they happen. This is an event-driven parser, which calls methods on a delegate to handle “events” as it parses through the XML.
  • NSXMLDocument provides tree parser functionality. An instance of NSXMLDocument represents an XML document as internalized into a logical tree structure. This tree-based parser is fairly sophisticated but it is not included in Cocoa-Touch.

In the spirit of small and simple, iPhone developers have the NSXMLParser class to use. Because NSXMLParser only generates messages for a delegate, and doesn’t store data about the XML tree, it requires less memory and is better for accessing small pieces of data or parsing large XML documents. The basic operation of the NSXMLParser class will not be covered here. This is well documented in the Apple Programming Guide.

For devices like iPhone where memory usage is critical, using tree parser is not recommended. I guess that is why Apple doesn’t provide NSXMLDocument on iPhone/iPod touch. However, the model of event parsing may not be acceptable by your code. NSXMLParser is probably adequate, but it is not going to handle all your XML parsing needs. The biggest problem with this type of streaming parser is that you lose the structure of your data; your call-backs do not provide any context or hierarchy. Because of the above mentioned or by some other reason like often changing XML format [1] you may need to use something like DOM model implementation.

Available Libraries (DOM model implementations) for iPhone

Which parser (DOM or SAX) should you use?

Well, if you’re going to need to parse very large XML documents, then you should probably consider NSXMLParser. What “very large” means depends a lot on the available memory you have to work with? The model of iPhone and the memory already in use by your app may prevent you from being able to use DOM model.

While DOM model usage may seem easier, NSXMLParser really excels in situations where you’re loading in many instances of the same kind of data, such as an address book or twitter feed. However, if memory is not an issue, I would recommend DOM model. It makes it easy to access the data you want and also allows you to manipulate the tree.

References

  1. Arash Payan(Salman),APXML: NSXMLDocument ’substitute’ for iPhone/iPod Touch – Arash Payan,Sep 27th, 2009
  2. jongampark, Tree XML parser for iPhone, 2009
This post will cover the basic setup and creation of an application with web content for iPhone that will load local CSS and some useful JavaScript functions. Most of these hints I found partially in different blogs and forums listed in the reference section. The idea is to collect all them together. You can use the following technique to create a more attractive application design.
Creating an application using UIWebView control is not the focus of this post. Here is a helpful beginner’s tutorial for creating an application using UIWebView. We assume that you are already familiar with this topic.

UIWebView load

Our work will start with a little change in calling load method of the UIWebView instance. Instead of loadRequest

[[webView graphWebView] loadRequest:requestObj];

we use the loadHTMLString method, providing an NSString object that contains HTML code of our page as a parameter:

[[webView graphWebView] loadHTMLString:htmlPageStr baseURL:baseURL];

To get this page to load resources and styles correctly, you have to set up the right URL:

Set baseURL property of UIWebView to refer your bundle’s resources directory

MentorMate

Initial loading screen with progress indicator

On the following reference[2] you can find a short and clear revision of the problem of displaying local images in a UIWebView. To use relative paths or files in UIWebView, you have to load the HTML into the view with the correct baseURL parameter. The following example shows how to do this:

NSString *path = [[NSBundle mainBundle] bundlePath];
NSURL *baseURL = [NSURL fileURLWithPath:path];

And then call load method of UIWebView provide above NSURL parameter:

[[webView graphWebView] loadHTMLString:pageStr baseURL:baseURL];

A short explanation: An NSBundle object represents a location in the file system that groups code and resources that can be used in a program. mainBundle method returns the NSBundleobject that corresponds to the directory where the current application executable is located. bundlePath instance method of NSBundle returns the full pathname of the receiver’s bundle directory. NSURL class is used to create an object which will hold the URL information. It provides a way to manipulate URLs and the resources they reference. loadHTMLString method of UIWebView has parameter baseURL that accept an NSURL object instead of a pathname as the file reference. Giving the above baseURL to UIWebView, you can refer to your bundle’s resources directory like this:

&lt;img src=&quot;myimage.png&quot;&gt;

Or from within CSS like this:

background-image: url(loading.gif)

It’s important to note that resources (images, CSS and JavaScript Files) inside your application bundle are at the root of the bundle, even if you place them in an separate group (folder) in your project.

Giving the correct URL to UIWebView will allow you to refer to local resources in your page, but it does not work in all cases. If you want to use JavaScipt, some additional settings have to be done.

Link a CSS and JavaScript files

MentorMate

Second loading screen with progress indicator

Now you can use generic HTML technique to add CSS and JavaScript to the web page and displaying in a UIWebView.

&lt;link href=&quot;default.css&quot; rel=&quot;stylesheet&quot; type=&quot;text/css&quot; /&gt;
 &lt;script type=&quot;text/javascript&quot; src=&quot;showhide.js&quot;&gt;&lt;/script&gt;

Do not forget to add your CSS and Javascript files to the xCode project (if you are using external files).

Some additional actions have to be taken before starting your application and using JavaScript functions.[3]

XCode setup (*.js) javascript as some type of source code needs to be compiled in the application. We would like to include it as a resource so I’ve solved it by doing two things:

  1. Select .js file and in the “Detail” view unselect the bullseye column indicating it is compiled code
  2. In the “Groups & files” view expand the “Targets” tree and expand the application then go to “Copy Bundle Resources” and drag the *.js files into it.

The Apple dev forums has a posted solution. [4] You need to do two things – select the .js file in your project, and turn off the checkbox that indicates that it is compiled (the “bullseye” column). If you don’t do this, you’ll get a warning in your build log about being unable to compile the file (which should be your first warning – always try to figure out and and correct any and all warnings that appear in your build).

Set transparent background color for UIWebView

MentorMate

Final screen with graph representation.

In our example we need to figure out a transparent background for UIWebView. On the parent View Container we have additional controls (buttons, labels) and already defined background. The following code will set this:

[[webView graphWebView] setBackgroundColor:[UIColor clearColor]];&lt;/code&gt;

[[webView graphWebView] setOpaque:NO];

Example

MentorMateDemoJS is a simple application example which uses the settings described above. It is a view-based application that shows a graphical representation of some data. Application behavior consists of a predefined call with formatted data to Vvidget Service[5] for graph generation. The service returns an image that is loaded in UIWebView Design Resource. The update button is added to resend the graph request and update view.

The Problem: Graph image requires some time for loading.

Our Decision: Notify user of graph loading process by showing a progress bar during load time.

To achieve this, we use UIWebView with local resource of two JavaScript functions. One to show/hide notification messages and the other to visualize a progress bar during loading time. In the provided sources you can find all these steps implemented.

Sources of the example iPhone application

References

  1. iPhone SDK Articles, UIWebView Tutorial, August 19, 2008
  2. iPhone Development Blog, UIWebView – Loading External Images and CSS, February, 2009
  3. StackOverflow, iPhone UIWebView local resources using Javascript and handling onorientationChange
  4. Developer Forum, UIWebView and JavaScript, 2009
  5. Vvidget, Vvidget Server™ Reference Manual , 2010