DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports
Events Video Library
Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
View Events Video Library
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks

Integrating PostgreSQL Databases with ANF: Join this workshop to learn how to create a PostgreSQL server using Instaclustr’s managed service

Mobile Database Essentials: Assess data needs, storage requirements, and more when leveraging databases for cloud and edge applications.

Monitoring and Observability for LLMs: Datadog and Google Cloud discuss how to achieve optimal AI model performance.

Automated Testing: The latest on architecture, TDD, and the benefits of AI and low-code tools.

Related

  • Unraveling Lombok's Code Design Pitfalls: Exploring Encapsulation Issues
  • Health Apps and Data Privacy: Best Practices for Developers
  • Data Management in Complex Systems
  • Choosing the Best Video Calling APIs and SDKs

Trending

  • AWS Amplify: A Comprehensive Guide
  • Writing Reusable SQL Queries for Your Application With DbVisualizer Scripts
  • Memory Management in Java: An Introduction
  • Selecting the Right Automated Tests
  1. DZone
  2. Data Engineering
  3. Data
  4. What’s Involved in Adding Mobile Real-User Monitoring to a Mobile Application?

What’s Involved in Adding Mobile Real-User Monitoring to a Mobile Application?

Wondering what goes into adding real-user monitoring to a mobile app? Here's a great overview.

Peter Kacandes user avatar by
Peter Kacandes
·
Aug. 19, 15 · Analysis
Like (2)
Save
Tweet
Share
1.66K Views

Join the DZone community and get the full member experience.

Join For Free

At some point, your enterprise is going to realize that it has to get serious about improving the performance/quality of your mobile applications. There’s a lot of confusion/misunderstanding about what’s involved in monitoring performance of mobile applications. In this blog I’m going to describe the overall process of what it takes to get started and how mobile application performance monitoring works in production.

In talking with a lot of companies about their enterprise mobile applications, I’ve noticed a trend for how mobile initiatives frequently get started. In many instances, someone in marketing or on the business side desperately wants a consumer-facing app for some new project or initiative for the company brand, be it for a promotional effort or some other type of campaign.

But the enterprise IT group doesn’t have the internal skills for native mobile application development and mobile apps in general are outside the domain of the traditional IT Ops group and it would take way too long for them to gear up to do it, so the business uses their discretionary, project, or advertising/marketing budget to engage with an agency or a consultancy to build the app in time for the project at hand.

Then, once the app is out in the wild among your customers for its initial purpose, the following process will inevitably happen:

      1. the desired scope of the application will expand as the company decides they want to use it for other purposes with additional features and functionality beyond the original minimally viable product definition,
      2. there will also certainly be problems with the app due to unanticipated issues or as a result of bugs and performance problems introduced by new features that got added later like tying the app into the enterprise IT infrastructure for services needed to support the new features,
      3. users will be upset by the problems/issues and write scathing reviews in the app stores or on social media, which will give the app poor rankings. They may even delete the app entirely,
      4. the company will realize that the poor app experience is hurting the company brand and costing it customers and good will, and
      5. there will be frantic calls that somebody has to DO SOMETHING about it to make it right.

At this point it’s likely that IT will have to get involved because now the app is become a critical part of the company’s business strategy and is tied into the enterprise IT infrastructure. The IT Ops group will already most likely be familiar with Application Performance Management (APM) for the enterprise apps that they are responsible for managing, but since they didn’t develop and manage the mobile app, they are probably not familiar with or know how APM works for mobile applications.

Monitoring the performance of mobile applications is a bit different than traditional IT Ops APM where the server side applications run on server infrastructure managed by IT in a corporate datacenter or private or public cloud environments. The main difference is that tradition IT enterprise apps are directly managed by the IT group itself, where they frequently are responsible for building (developing) the app, and then deploying it and managing it on the server infrastructure where they have direct access to it and control over it.

In the mobile application ecosystem, there is a level of indirection between the application and the process of accessing, controlling, managing and monitoring the application. In the traditional APM world, IT can add monitoring of the application performance via the application infrastructure without having to modify the app itself because they have that direct access to the systems where the application is being hosted and run.

The process for adding monitoring of the performance of mobile application as it is being used by your customers isdifferent due to the level of indirection involved and the lack of direct access to the devices where the application is running.

Since the mobile application is being used directly by your customers on their personal or corporate mobile phones, the mechanism of monitoring the performance of the app “in production” is called Mobile Real-User Monitoring or Mobile RUM. Figure 1 shows the overall process of adding AppDynamics Mobile Real-User Monitoring to your mobile applications so you can monitor their performance.

Screen Shot 2015-08-06 at 11.45.18 AM.png

Developer Process

The first thing you have to do is to incorporate the AppDynamics Mobile RUM SDK into your native mobile application.

            1. Developers download the iOS or Android SDK from the AppDynamics website
            2. Developers use the respective integrated development environment (IDE) which is xCode for iOS apps and Eclipse with Android Developer Tools plug-in or Android Studio for Android apps
            3. Developers compile the appropriate SDK into your application using the corresponding IDE
              1. As part of your testing and QA process you can have a limited number of beta user testing your app and monitoring the performance before you release it to the app store
              2. Distribute the beta using one of the available beta distribution mechanisms
            4. Developer submits the new version of your application to the appropriate app stores
            5. Once the app has been approved, the new version of the app will appear in the app store once it has been approved
            6. App is available in the app store for customers to download the new version

Data Exchange for Mobile Application Performance Monitoring

Once the end-user has updated to the new version of the app and starts using it, then a number of data flows will be triggered.

            1. The first thing that happens is that at some point the app will make some request via the network to some back-end infrastructure. As part of the request, the AppDynamics Mobile RUM agent that was built into the app via the SDK will automatically detect the request and will add an AppDynamics identifier to the header.
            2. When the response is sent back to the mobile application, additional information will be added to the header including GUID (Global Unique Identifier) which uniquely identifies that particular request for later analysis, the time that it took that particular Business Transaction to execute, the average BT execution time, and an identifier for that particular BT

Deployment Flexibility

The next part of the data flow depends on how you have chosen to implement your deployment options. AppDynamics offers flexible deployment options including a pure SaaS option, and pure on-premise option of a mixed hybrid SaaS/on-premise option.

The first option is to choose to use either the Mobile RUM Cloud SaaS data collector or the on-premise Mobile RUM Server. In step 3 of the data flow, the AppDynamics mobile application agent will send information to the Mobile RUM Cloud (3A in the diagram) or the Mobile RUM Server (3B in the diagram) including the object ID, the NSURL (in the case of iOS or the Android equivalent), any crash API data from a previous crash, and any custom data that you may have chosen to collect for your application.

The Mobile RUM Cloud or Mobile RUM Server collect this data from all of the mobile application clients that your customers are using, does some processing/aggregation of the data and then passes it on to the next step. There is no permanent data storage in this step.

The second option is to choose to use either the AppDynamics SaaS Controller or the AppDynamics on-premise Controller. In step 4 of the data flow, the processed/aggregated data is sent from either the Mobile RUM Cloud or Mobile RUM Server to either the SaaS Controller or the on-premise Controller.

The Controller is where all of your application performance data is correlated, baselined, stored, and accessed for monitoring, alerting, analysis, and action by all of the people in your organization that are involved in the running, maintenance, operation, and business of your application.

Your employees access the Controller via the AppDynamics web-based portal where they can have role-specific views of your application performance data and can work to collaborate to resolve issues faster (troubleshooting, problem identification and isolation) via the War Room or monitor the business via custom performance operations and business/executive dashboards.

mobile app Data (computing) IT Real user monitoring App Store (iOS/iPadOS) Integrated development environment

Published at DZone with permission of Peter Kacandes, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Related

  • Unraveling Lombok's Code Design Pitfalls: Exploring Encapsulation Issues
  • Health Apps and Data Privacy: Best Practices for Developers
  • Data Management in Complex Systems
  • Choosing the Best Video Calling APIs and SDKs

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 3343 Perimeter Hill Drive
  • Suite 100
  • Nashville, TN 37211
  • support@dzone.com

Let's be friends: