A Quick Look at Cross Platform Philosophy 729x423 729x423

A Quick Look at Cross Platform Philosophy

When evaluating or designing an approach for reaching users across a wide variety of platforms and devices, MentorMate applies our core mantra of ‘Business Needs First, From a User’s Perspective’. This means that the chosen solution should support the outcomes and end state desired by the business in a way that supports and engages users effectively.

Across the industry, there is a significant amount of literature and time dedicated to the notion of Cross Platform Frameworks. These frameworks attempt to reduce development time and complexity by abstracting shared components across two or more mobile mobile platforms and optionally the web platform. For the purposes of this document, only iOS and Android are considered.


Cordova is a framework that acts as a layer between HTML5-based applications and native capabilities. With Cordova, the native capabilities of mobile platforms such as Contacts Integration, GPS, Filesystem, and other sensors are exposed to the application via a series of Javascript APIs.

Cordova applications are built by taking a client-side web (no server side code is supported directly within Cordova) application of one or more pages and enriching it with native capabilities. Cordova applications can be mixed with native functionality and screens, but this use case is less often desirable.


If the application you are developing is an offline client-side responsive web application, you have already written most of the code that will allow your “application” to function. This means that a well written web application utilizing a framework such as AngularJS can be leveraged as-is to begin offering offline mobile application experiences.

One of the best aspects of Cordova is that it allows developers experienced in the Web platform to begin building mobile experiences that take advantage of mobile paradigms and capabilities without significant retraining.


Cordova has two main downsides. . First, all of your UI will be web-like. This means that your input fields will look like web forms rather than native input boxes, it means that transitions and animations will render and perform like those found on a website (or worse), and that standardized components such as the Android Action Bar, or the iOS Tab Navigation cannot be leveraged by your application. By not matching the standards of iOS and Android, your users will need a small amount of additional time adapting to your custom experience, or may feel like the experience is less modern. This can be mitigated somewhat through creative experience design and/or the use of cross platform design frameworks such as Material Design, but will still make your application feel less like a smooth shiny native application.

The second core downside is that Cordova applications are limited by the Cordova framework. The Cordova framework is always going to be several releases or features behind “main line” Android and iOS. A great example of this is that there is still not an official way to build Android Wear or Apple Watchkit applications with Cordova. There are 3rd party libraries (including one we have written), but they don’t have the focus or attention that the native tools have.

There are other downsides with Cordova for Android such as the widely varying versions of the WebView that ship across multiple Android devices. In All Android versions before 4.4, the WebView was bundled with the OS and immediately out of date upon shipping, meaning new features of HTML5 are inaccessible. This can be worked around by shipping Android applications with a custom-built WebView called crosswalk using the latest version of Chromium, but this introduces another dependency and more complexity.


Xamarin is a framework indirectly supported by Microsoft that allows developers to build iOS, Android, and OS X applications using C#. These C# applications can be designed to have both a data and services layer built in C# as well as a User Interface built in C#, or developers can blend C# and native functionality.


Unlike Cordova applications, Xamarin applications are compiled instead of being interpreted at runtime. This means Xamarin applications have better performance than Cordova applications. Additionally, Xamarin applications use reflection to expose native APIs automatically, meaning that Xamarin developers do not need to wait for the Framework to update in order to gain access to new or device-specific native APIs.


Xamarin is a new platform It does not have the same level of extensive and numerous application frameworks as HTML5. Tools like Xamarin Forms which allow users to build shared UI code that renders well across platforms are still in their infancy, and can create significant barriers to building top-notch experiences. User Experience elements such as gestures and animations can be difficult to achieve due to the fundamentally different ways these are natively achieved by the platforms.

It should also be acknowledged that because Xamarin ties so closely to the platforms, many things that one might expect to be cross-platform may not be. One example of this is Wearable interfaces. If you are building wearable experiences using Xamarin, you must still build them twice to target both iOS and Android.

According to Xamarin, best of breed applications are able to achieve around 70% of the code between platforms, so expect to be working on platform-specific behaviors as well as overcoming unexpected issues with the shared code.

Last, to get started or to continue working in Xamarin, each developer will need a license to Xamarin, which serves as an additional barrier to entry for new team members to get up to speed.

Native Development

Native development of an application for each target platform may seem to be the most costly approach, but with fewer risks and compromises required the cost can sometimes be less than an equivalent Cross Platform application.


Across both of these Cross-Platform frameworks, there may be an overall reduction in development time in exchange for limiting the types of interactions and experiences that can be built to those that are “lowest common denominator”, but these platforms are evolving every day. This must also be considered in combination with the additional developer skill sets implied and required by the use of an additional framework. For a Cordova solution to work successfully, the development team must be familiar with both Blink and Webkit capabilities and peculiarities (including their mobile components), as well as the best practices for building mobile applications. Xamarin developers need to understand the iOS and Android platforms and capabilities as well as have extensive experience building C# applications.

Finally, packaging and designing an application should be done intentionally for each platform. Each store has separate submission and review processes. Things like screen shots and marketing text may be significantly similar, but users hate seeing platform-specific images for the wrong platform in either store, and may risk the rejection of your application.

Wearable Strategy for Your App 780x423

Wearable Strategy: Do You Have One Yet?

If you have a mobile app, you need a strategy for supporting Android Wear and the Apple Watch. Supporting these devices can be as simple as displaying an improved notification or as complicated as having app that can run independently on the watch. Wearable applications should be glanceable and serve as an extension to your mobile app.

Glanceable, Adjective, Understandable at a glance, or with occasional glances, and therefore requiring only minimal attention.

Glanceable is a word that started getting a lot more usage lately, parallel to the accelerating discussion about smartwatch interfaces. The face of a watch has always been glanceable, now everything needs the same simplicity. In some cases, you can improve watch notifications without creating a separate app for the watch. It’s possible that your existing notifications may even work without any changes.

Minimum Wearable Strategy

Android: Bridged Notifications, iOS: Short Look / Long Look Notifications

If you have existing notifications, start here. Test your notifications on a wearable device. Identify areas for improvement. Make changes as necessary.

Things to look out for:

  • Does your app replace existing notifications or do they stack indefinitely? (stacking indefinitely is a bad watch experience!)
  • Does your text fit on the screen?
  • Does it match your brand?

What you get:

  • Notification with title, text, background and icon
  • Ability to communicate back to the phone with simple actions
  • Optionally, add stacked notifications or big text (expandable) notifications



  • Low cost
  • Minimal changes to existing code
  • Easy to test (QA)
  • Leverages existing UX principles


  • Limited functionality
  • Limited design

Standard Wearable Strategy

Customize layouts and show the user information just when they need it. Use geo-fencing or activity tracking to intelligently display notifications.

What you get:

  • Notifications with custom layouts
  • Ability to send and receive more complex data between the phone and watch



  • Medium cost with high value
  • Additional control over UI
  • Leverage some existing UX patterns


  • Extra QA effort
  • Some limitations to design
  • UX required

Comprehensive Wearable Strategy

Android: Custom Layouts, iOS: WatchKit Apps

Build a full screen wear application that can communicate with the phone or work completely independently of the phone. This is great for sport or fitness apps that may want to track information even if the phone is not present. You can also make stand alone apps like a calculator or compass. With this option, you get all services and functionality available within the wear platform. This option should only be considered if you have a large budget and would like to make wearable devices a core part of your mobile strategy.


  • Highest level of integration
  • Maximum feature set
  • Complete control of UI


  • High cost
  • Requires in depth UX
  • Lengthy QA (lots of integration points to test)

Additional Resources

Find my iPhone 845x360

Loss and Redemption – A Play Inside a Blog Post

Let me set the scene briefly.

There is nothing like the attachment we have to our smartphones. We can forget how important our one-touch lovers are to our lives, our business, and our emotions. In one minuscule, seemingly insignificant moment in the cosmos, we can lose that which binds together the fabric of our entire beings. This happened to me very recently, to a degree which I hadn’t experienced before.

It had been an extremely busy day, and I had already planned to treat myself by having my most guilty pleasure for dinner that night: Pesto Cavatappi with Parmesan Chicken from Noodles & Company.

noodles company

I recently moved to a new part of the city, and was unfamiliar with the area, so I navigated my way to the restaurant nearest to my apartment with Google Maps, and lay my phone in my lap as I parallel-parked a block away. In a rush to grab my food, I stepped out of my vehicle with my eyes on the prize. To the register I went. I order, ask for “to go”, give my name, and sit down in the waiting area. I reach for my phone for the usual reasons, to make believe that I am doing something important while just playing Clash of Clans, or Candy Crush (Yes. Candy Crush). I reach into my purse, and…




We all know that feeling. An electric shock of panic spikes through my fingertips and I think… “No, it’s ok, it’s just on the seat of the car.” A thin veil of calm washes over me like a wave of sedentary gas just waiting for the catalyst spark.

I obtain my nourishment in the form of swirly carbs and head back to my car, on a mission. First, I open the driver side door and take a glance. Nothing. Then I check outside of the car, thinking it may have fallen out of my lap onto the ground, in my rush to get to Noodles. I begin tearing through my relatively clean car, throwing things aside that are very obviously not hiding my beloved mobile device. Once I obsessively comb my vehicle and the surrounding area nearly eight times, I give up. I am officially panicking.

Side note: I have ZERO sense of direction. I use my phone’s GPS to get  nearly everywhere, and it hadn’t occurred to me until this very moment that I might not even be able to get home.

I get in my car and take a deep breath, trying to steady my confused mind. I turn the key, and merge out onto the street looking for things that I recognize that might help me find my way home. Luckily, by some grace of whatever witchcraft that was about me that night, I made it home safely. Immediately, I pull up my iPhone’s location on my iPad, and after a little hiccup wherein the app tells me that all of my devices are offline, I find a little solace in the little blue dot that indicates my precious. A little blue, moving, dot. Heading away from my home. This is where my savage brain jumps to the most severe of conclusions- It’s been stolen. *INSERT SILENT SCREAMS* My finger is hovering over the “Erase my iPhone” button, as I quietly go through all seven stages of grief in a matter of milliseconds. Here is where our play begins:

Enter: Roommate Katie

Roommate Katie: Hey, you got Noodles!

Tessa: I think my phone was stolen.

Tessa shows Roommate Katie said moving blue dot. Roommate Katie gasps with an appropriate amount of sympathy for her friend, knowing this problem can be easily solved.

Roommate Katie: Do you want me to call…

Tessa: YES! Please. Thank you.

Roommate Katie finds her own phone, dials Tessa’s number, and waits…

Roommate Katie: Hello?

Male Voice: Hello.

Roommate Katie: I am looking for my friend’s phone.

Male Voice: Yeah…?

Roommate Katie: Do you have it?

Male Voice:… Uh… I am talking on it, aren’t I?

Roommate Katie: (with a nervous giggle) Oh… Yeah. Well, can we come and get it?

Male Voice: Yeah, we’re uh… We’ll meet you at the “SA” on University.

Tessa feels lost in her automobile, without even a podcast to listen to on the journey.

They pull into the parking lot, which is empty, except for a suspicious looking, and colorfully-clothed couple riding bicycles. They are carrying what looked to be everything they owned with them in bags and knapsacks.

Tessa and Roommate Katie exit the vehicle, and tentatively approach the wiry, greater-than-middle-aged but less-than-geriatric bicycle enthusiasts.

Wiry Woman: Are you Tessa?

Tessa: Yes! You have my phone?

Wiry Woman points to the phone and Tessa, forgetting any etiquette she may have learned in the past, goes straight into the woman’s purse and snatches her phone up.

Tessa: Thank you! Thank you so much!

Mirthless Man (played by the same actor as Male Voice): (With the sternness of a father that apparently has some sort of financial and emotional stake in the device.) You really should be more careful, young lady. That could have been smashed by a car, or stolen.

Tessa: I know, thank you so much for rescuing it.

Wiry Woman: (Cackling) Yeah, honey.. I know what you mean. I feel absolutely LOST without MY phone.

Tessa: (sighs in giddy relief) Anyhoo, thank you so much for finding it and staying here so we could come pick it up. I really appreciate it. Have a wonderful night!

Throughout the last exchange, the Mirthless Man maintains his disappointed gaze and Roommate Katie realizes that she is still in her pajamas. Afterwards, Tessa and Roommate Katie edge their way back towards the car, Tessa’s eyes FIXED on her phone, inspecting it for damage or corruption of any sort, thinking to herself, “THIS is why I leave the annoying and extremely obvious passcode on my phone.”

Roommate Katie: They had no teeth. Like… at all.

Tessa: I know… but they had my phone!


My life resumed as I knew it. I had sworn to myself that I would never be one of “those” people. You know, the ones that take their pocket computer for granted. The people who misplace it every weekend, and inconvenience others by either being unreachable, or soliciting help from unsuspecting but well-intended companions. Either way, I know that I learned something that day:

“Not all people have teeth.”
– Roommate Katie


Supercharging your apps with iOS8 500x360

Supercharging Your Apps with iOS 8

Apple has announced their plans for iOS 8 and it brings the biggest change in API and features since the original iOS SDK, which allow developers to build apps that haven’t been possible thus far. And with iOS 8 just around the corner, I’m here to sum up how your applications would benefit by fully adopting it.

App Extensions

Let’s start off with a big one – iOS apps can now communicate with each other, access each others’ files and perform tasks for each other. All of that functionality can be broken down into a variety of applications:

  • Widgets

    Finally iOS has added supports of widgets! Living in the Notification Center’s Today view, they enable people to get information about your app at a glance. More importantly, they provide a way for your users to briefly interact with your app, in order to accomplish a common action that your app might explore.

  • Share extensions

    You’re building out the next great social network and you want people that have your app to be able to share content on it system wide, well now you can do that with the new share extension. It provides a convenient way for your users to share content on your service, as if your service has been integrated into iOS itself.

  • Actions

    Action extensions let your apps hand off work to another app or provide a way for other apps to take advantage of a particular feature or action that your app provides. Your users can use other apps to access your app’s particular feature, like editing an image in a particular way, styling a document, or translating text.

  • Photo editing

    With the photo editing extension, your app can now modify the users’ images in the Photos app, using your custom image processing functionality. With that the user can apply that patented filter of yours to every one of their photos directly.

  • Storage provider

    Your apps can now access any document or media that other apps provide. If your text based app wants to style a document that the Pages app has, it can now edit it or even copy it to your particular app and modify it in any way. Alternatively, your app can expose its files so your users can access them from similar apps. You can even move files to and from the new iCloud drive.

  • Custom keyboards

    The last of the extension is custom keyboards. Have you ever wanted a custom keyboard developed? Well now you can provide your users with the custom keyboard of their dreams. A keyboard with all new emojis? Done!

  • Touch ID Authentication

    Apple now provides a way to tap into the Touch ID sensor and let your users authenticate themselves into your app. Gone are the days where they’ll have to type in passcodes or provide passwords to access your services.

Game development

With Metal, iOS now provides an extremely low-overhead access to the hardware, which enables us to achieve incredibly high performance graphics, which would bring your games to a whole new level. And with SceneKit 3D games have never been easier to develop on iOS. It simplifies 3D development, so that you could focus on bringing your game to life, instead of getting bogged down in low-level APIs.


HealthKit enables you to develop the next great health and fitness tracking app, by accessing all of the data that iOS has gather about the user, without having to add support for fitness-tracking devices. With HealthKit, if a measurement is too high or low, you can automatically alert your user to take action or you can even contact their doctor so that they’ll be aware of the user’s condition.


HomeKit brings the internet of things to iOS, it allows your user to securely control their connected devices, all from their smartphone. For example your app will be able to turn down the A/C and lock the doors, whenever your users leave the house.


CloudKit brings effectively free cloud solutions to iOS. You won’t have to bother with setting up server Push notifications, manage database servers, deal with load balancing or scaling issues and most importantly – paying your server hosting provider.


With Handoff, you could tie in all of your users’ devices in one coherent user experience. Your users would be able to pick up any of the work that they’ve been doing on their iPhone and continue that same work on their iPad or Macbook without losing any progress.

Location improvements

Apple has brought indoor location to iOS 8, which will enable your app to be smarter about what floor, in a multistory building, your user is on. Imagine tying in that information to HomeKit, so that you could control lights, heating and other appliances in your users’ homes, depending on the floor they’re on.

iTunes Analytics

With the new iTunes analytics, all the information about an app would be a click away, all of it in real-time, without having to sacrifice your users’ privacy to third parties. And you get all of that without you having to do a thing, for free!
New beta testing with TestFlight


With Apple’s recent acquisition of TestFlight, they’ve integrated it fully into the AppStore experience. You’ll now be able to invite 1000 people to beta test your app or your app’s update, without having to deal with provisioning profiles.

That sums up a brief overview of some of the new features that iOS8 will be bringing. You should be looking into updating your apps as soon as possible, so that your users aren’t left waiting when iOS8 hits in September. If you need help updating your applications our developers are standing by.

51262107 29dc 47d3 8fdd ce19890d5e09
rusty keys

6 Mobile Application Security Techniques

Securing mobile apps is complex, especially when sensitive data needs to be stored locally on the mobile device. Security is one of the most critical characteristics of mobile apps in verticals such as financial, insurance and healthcare. In many instances, mobile apps must adhere to a variety of privacy standards (FDA, HIPAA, etc.) and often require offline capabilities and online network communication, whether on a small-scale network, the cloud or the web.

Audit your mobile application security by asking yourself (or your developer) these six questions:

Secure application integrity

1. Do you obfuscate the binary executable file as part of the build?

Compiled, binary source code can be obfuscated in order to make it more difficult to decompile and reverse engineer using tools such as Proguard (for Android). For the iOS platform, a different technique can be applied to rename strategic class names and method names as part of the preprocessor phase (e.g. PersonalData -> NSNumber_Extension) and enable deployment post processing, and strip linked products to hide the important parts of the code.

2. Are app integrity checks performed during runtime?

Repackaging is often used by a malicious attacker as a way to trick users into providing private information or to install malware. By checking the application signature with which the application was signed against the expected signature, we can determine at runtime whether or not the app has been compromised. In addition, you can also checksum your binary by putting a well hidden MD5 hash (preferably a salted hash or double-hash) somewhere in your app, which makes it more difficult for a potential hacker to figure out how to get the correct hash. Where you store it doesn’t matter (as long as it’s not in the binary) and then set up a script that will re-generate the new hash at every build (when your binary changes). In your code, check the stored hash against the binary. If they are different, that means the binary has been modified, in which case it should display an error message asking to re-download the app.

Secure locally stored data

3. Does your app encrypt its local storage?

A best practice to ensure locally stored data is not readable on compromised devices is to encrypt the data with AES, DEC or other standard encryption algorithms. The SQLite local databases can be encrypted on iOS and Android, on a file level and on an individual data field level. A popular open source library for encryption at file level is SQLCipher. A unique private key for the encryption is dynamically generated for each device, but not hardcoded in the source code in order to minimize risk of obtaining the key by decompiling/reverse engineering the mobile app executable. Be aware that the tradeoff of any encryption applied is increased code complexity and more intensive processing on the device, which impacts performance and battery life.

223f2526 7eb8 43d4 8b42 be2446424e98

4. Is compromised local data being detected by the app?

Mobile apps cannot detect when local storage is being accessed by an external entity to read data on a compromised device. However, one can detect when local storage has been compromised by accessing encrypted files from a separate application process that is signed with the same signature as the main application. Additionally, data field checksums generated using MD5 or SHA1 algorithms may invalidate a data file if it’s being modified by an unauthorized code.

Secure data transfer

5. Do you use a secure connection to access APIs or data sources?

Always transfer data from/to external services and the cloud using secure HTTPS-encrypted protocol. Furthermore, to secure serial communication, a best practice is to have every data packet encrypted and decrypted at runtime by applying a standard encryption algorithm, such as AES or DEC.

6. Does the app session expire?

Access to remote data should expire during a certain period to protect the data in the event a user left the device unattended. This feature is available for all mobile development approaches. For native apps, it is possible to detect when the app is suspended in order to terminate the session and require a user to authenticate the next time they launch the app.
A few additional techniques for maximizing security that are worth mentioning:

  • Preventing the mobile app from running on a jailbroken/rooted device
  • Preventing taking screenshots of the app screens
  • Detecting if the application is running on an emulator
  • Restricting debuggers

Overall, there are multiple approaches to securing mobile apps and each one comes with pros, cons and risks. Understanding the implications of each technique is essential for a solid mobile strategy. MentorMate uses extensive knowledge base and continuous research on ever-changing mobile platforms and development frameworks to provide strategic IT and technology consulting services to help companies adopt mobile and minimize risks.

app icons

App Icons as Art? Best iOS Icon Designs

Have you ever uninstalled an app because you felt it’s icon was too ugly to be seen on your screen? I know I have (I’m looking at you Mass Effect Infiltrator). The app icon, while often an afterthought during development, is one of the most visible elements of any application. It literally just sits there, exposed, 100% of the time you have the app installed. Make it look good, don’t just phone it in.

While surfing around looking for inspiration I ran into this amazing app icon which looks like a hyper-realistic sunny-side-up egg. How badly I wish that icon was on my iPhone right now. Unfortunately, this delicious icon (especially in the morning hours) doesn’t belong to an actual application, it is only a designer’s flight of fancy. Maybe someday… But for now, there is an entire subculture of artists designing app icons just for the sake of it! Practice I suppose.

Some of these icons are made for actual apps, some of them are just for fun. All of them are works of art and deserve to be seen. They are presented in no particular order. If you find a beautiful icon that didn’t make the list let us know in the comment section.

Have you ever uninstalled an app because you felt it’s icon was too ugly to be seen on your screen? I know I have (I’m looking at you Mass Effect Infiltrator). The app icon, while often an afterthought during development, is one of the most visible elements of any application. It literally just sits there, exposed, 100% of the time you have the app installed. Make it look good, don’t just phone it in.

While surfing around looking for inspiration I ran into this amazing app icon which looks like a hyper-realistic sunny-side-up egg. How badly I wish that icon was on my iPhone right now. Unfortunately, this delicious icon (especially in the morning hours) doesn’t belong to an actual application, it is only a designer’s flight of fancy. Maybe someday… But for now, there is an entire subculture of artists designing app icons just for the sake of it! Practice I suppose.

Some of these icons are made for actual apps, some of them are just for fun. All of them are works of art and deserve to be seen. They are presented in no particular order. If you find a beautiful icon that didn’t make the list let us know in the comment section.

creativedash egg
by Creativedash
favicon dribble twitter-favicon globe-favicon
by Creativedash
favicon-dribble twitter-favicon globe-favicon

by Creativedash
favicon-dribble twitter-faviconglobe-favicon

by Ramotion
favicon-dribble twitter-favicon globe-favicon

by Lobanovsky
favicon-dribble twitter-favicon

by Ryan Ford
favicon-dribble twitter-favicon globe-favicon

by Artua
favicon-dribble twitter-favicon globe-favicon

by Michael Flarup
favicon-dribble twitter-favicon globe-favicon

by Michael Flarup
favicon-dribble twitter-favicon globe-favicon

by Michael Flarup
favicon-dribble twitter-favicon globe-favicon

by James Cipriano
favicon-dribble twitter-favicon globe-favicon

by Denis Shoomov
favicon-dribble twitter-favicon globe-favicon

by Denis Shoomov
favicon-dribble twitter-favicon globe-favicon

by Nick Kumbari
favicon-dribble twitter-favicon globe-favicon

by Rosetta Icon Design
favicon-dribble twitter-favicon globe-favicon

by Rosetta Icon Design
favicon-dribble twitter-favicon globe-favicon

by Rosetta Icon Design
favicon-dribble twitter-favicon globe-favicon


Mapping XML Document to Object Model Using DOM in iPhone Application

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.

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.
Fig.1 The DOM presents an XML document as a tree structure

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).

Fig 2 Using a DOM Tree

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:


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


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


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:

and Image.h files


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.


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.