142 posts tagged with "Apps"

While using an app, users expect it to be highly responsive and fast loading. At times apps may take an abnormal amount of time to open a new screen. In Android, this issue is known as screen load delay.

Normally screen load delay occurs in Android apps when the main thread consumes a lot of time to execute complex processes while loading a new activity or a fragment.

Screen load delays affect the user experience, but they go unnoticed by developers and cause users to even rate the app poorly on the android play store. Therefore, it is important for developers to be notified about screen load delay at the earliest.

This is where Appxiom comes in.

With a simple 3 step integration process, Appxiom SDK for Android apps is capable of automatically detecting screen load delay. For more detailed integration guide, visit our documentation pages for Android (Java & Kotlin)

Detecting screen load delay with the help of activity trail​

When an activity or a fragment in an Android app takes more than 6 seconds to load, Appxiom immediately reports it as an issue. Bug reports from Appxiom include relevant data points like activity trail, device and device state data, that will help developers to reproduce the bugs faster.

Activity Trail​

Activity trail is a chronologically ordered list of app events, that will aid the developers to understand the user flow for a minute prior to the occurrence of the issue.

Activity trail has three components

• The Activity segment, that has details of the app event.

• The timestamp segment, that has details of the time at which the event got recorded.

• The memory segment, that shows the percentage of free memory.

Screen loading delay reported by Appxiom SDK for AndroidThe above screenshot shows that Appxiom SDK has detected a delay in the loading of ‘ChatActivity’.

To identify the root cause of the issue, let us take a close look at the activity trail. Here 'ChatActivity:onStart' started after the event 'ChatActivity: loading user from db' with a gap of more than six seconds. The delay is caused during the event 'loading user data from the database' and this information gives a clear direction on what the fix should be.

Fixing screen loading delay​

It is better to execute all time-consuming processes like database operations, I/O operations and calculations through separate threads. This approach will help in avoiding such delays.

Appxiom also detects screen load delay in iOS and watchOS apps. Apart from screen load delays, Appxiom is capable of detecting API call issues, ANR issues, memory leaks, abnormal memory usage, function failures, crashes and custom issues.

Visit appxiom.com to learn more about Appxiom. Detailed documentation is available at docs.appxiom.com.

Though it is often advised to keep the app’s memory footprint as low as possible, developers tend to overlook this aspect during app development. As a result, the elements that consume the app’s memory go unchecked, which leads to the app consuming an abnormal amount of the device’s memory.

When the iOS app consumes a considerable amount of allocated memory, it leads to an out of memory exception, resulting in an app crash and affecting user experience. This makes it important for developers to be notified about abnormal memory usages in both development and production environments at the earliest.  

Abnormal memory usage occurs when unused memory is not reclaimed properly or because of inefficient object reuse.​

With Appxiom, abnormal memory usage can be detected at the earliest and developers get to fix the issue fast.Appxiom is an automated bug reporting tool that is capable of detecting abnormal memory usages and memory spikes in iOS apps.

Using Appxiom to track memory issues in iOS​

With a simple 3-step integration process, Appxiom framework for iOS detects and reports abnormal memory usage in both development and production environments. Please visit our documentation page for more details. 

Tracking memory usage with Activity trail​

Appxiom reports high memory usage when the iOS app consumes more than 30% of the physical memory. The bug report will have data points like activity trail with memory usage patterns along with device and device state information, which will aid developers to reproduce the bug. 

Activity Trail from an issue reportActivity trail consists of a list of events that occurred one minute prior to the issue occurrence. The app events along with the percentage of free memory available at each point are displayed in a chronological order. 

Components of Activity trail​

Section of Activity Trail

Activity​

The activity segment has details of the app events. The user event will have two components separated by a colon

•  The name of the class in which the event gets reported

•  The textual description of the event.

Timestamp​

The timestamp segment has details related to the time at which the event gets recorded. 

Free Memory​

The memory segment also contains the percentage of free memory available for the app at the time of the event. 

How Appxiom helps in finding the root cause​

Abnormal memory usage reported by AppxiomLet’s consider a use case as indicated in the above screenshot. Here, Appxiom has detected high memory usage in an iOS app. The issue is that the app’s memory usage crossed 2587213824 bytes, which is more than 30% of the physical memory size i.e 8589934592 bytes. 

With an in-depth evaluation of the activity trail section in the issue report, we understand that while loading the first banner image, the free memory was around 79%. But when the final banner image was loaded, the memory dipped down to almost 71%. So with each banner image, the amount of free memory available goes down. By analysing the issue further in code, we can come to the conclusion that the root cause for the free memory dip was that the allocated objects for banner images are not released. 

This scenario may lead to an app crash. In order to avoid the app from crashing, Appxiom detects and reports whenever the app consumes more than an ideal amount of free memory.

Activity trail helps developers to pinpoint where exactly the issue is so that necessary changes can be made in the code and a patch version be released fast. 

Custom Activity Trail events​

Apart from default events, Appxiom allows developers to set custom app events in activity trail (refer our Objective-C and Swift documentation) with an API, which can be called anywhere in the code. These custom events will be recorded and shown along with default app events in the activity trail section in Appxiom dashboard. 

Along with high memory usage and spikes, Appxiom also detects memory leak in iOS apps. To know more read our blog Detect memory leaks in iOS

Apart from memory-related issues, Appxiom capable of detecting and reporting crashes, API call issues, frame rate issues, ANR, function failures, exceptions, delays and custom issues.  Appxiom is available for iOS as Objective-C and Swift Frameworks, watchOS as Objective-C and Swift Frameworks, and Android as Java and Kotlin SDKs platforms. 

Visit appxiom.com to know more about Appxiom. Detailed documentation is available at docs.appxiom.com

One of the challenges mobile app developers face is collecting as much relevant data to reproduce bugs reported during testing and more so production. In production even detecting bug occurrences becomes a challenge. Manual bug detection and data collection in Android mobile apps during testing and development environment is time consuming and in production it is near impossible. Here is where tools like Appxiom aid the developers.

Appxiom is an automated, light-weight bug reporting SDK for Android apps that helps developers to reduce the bug fixing time by providing clear and crisp issue reports with detailed data points for effective root cause analysis.

First things first, Appxiom has an easy three step integration process.

• Register with Appxiom using the ‘Get Started’ button in https://appxiom.com and login to the dashboard. 

• Use ‘Add App’ to link your Android app to Appxiom.

• Integrate Appxiom SDK to your app as a gradle library.

For a more detailed integration guide, visit our documentation pages for Android (Java & Kotlin).

Appxiom is capable of reporting multiple bug types in Android apps. Some of the main types of bugs in Android apps are,

Types of Issues captured and reported by Appxiom​

​

Memory Leaks​

​

Memory Leaks occur in Android apps when unused objects are not cleared from the device’s memory. Appxiom SDK has out of the box capability to detect memory leaks in Android apps. and reports it to the dashboard with data points like class stack, activity trail, device and device state info. 

Memory Leak in Android

Crashes​

​

App Crashes are fatal and will affect the user experience, which may lead to user’s uninstalling the app. 

App Crash in AndroidWith basic integration, Appxiom SDK is capable of reporting crashes along with data points like device and device state data, activity trail and full stack trace.

​

API Failures​

With a single line of code, Appxiom SDK is capable of reporting API issues like status code errors, delayed API call executions or even duplicate API calls. Appxiom reports API failures with detailed data points including network parameters like full URL, request-response headers and request body. 

API Issue in Android

Abnormal memory usage​

​

When an app consumes a high amount of device’s memory, Appxiom SDK immediately reports it. Activity trail in issue report will enable developers to identify the reason for the spike in memory usage.

Abnormal Memory Usage in Android

Function failures​

​

Issues in code level functions like unexpected return value, delay in function execution are called function failures. Appxiom SDK provides a single line API to track code level function failures. Data points like function parameters are sent along with each issue report with will aid developers in fixing the issue fast.

Function Failure in Android

Feature failures​

​

Using the function tracking API, SDK allows developers to chain multiple functions. Once chained Appxiom will monitor if the second function is executed within the stipulated time (can be set by the developer) after the execution of the first function. If not, then Appxiom SDK reports it as an issue. This will enable developers to report any app feature failures.

Feature Failure in AndroidBug reports will include data points like activity trail, function parameters and return values.

​

Custom issues​

​

Appxiom SDK provides a single line API for developers to report any custom issues. 

Custom Issue report in Android

ANR​

​

ANR or App Not Responding occurs due to frame rate issues in Android, that block the UI thread for more than 5 seconds. By tracing the Activity trail events, developers can reproduce and can fix ANR issues fast. 

ANR report in Android

Screen loading delay​

​

Delay in loading of any activity or fragment will be automatically reported by Appxiom SDK. 

Screen Loading delay in AndroidNow, let us take a look at the data points in bug reports of Appxiom that help developers to reproduce the bugs effectively. 

Data Points Explained​

​

Error insights​

​

Error insights help the developers to find commonalities across occurrences for faster root cause analysis. Error insights consist of information like bandwidth strength, battery level, low memory warning, OS versions, device names, country name and timezone offsets. 

Error Insights from an issue report in Android

Activity Trail​

​

Activity trail is a list of chronologically ordered app events, that helps developers to identify where the issue occurred. It consists of three components, 

• The Activity segment, that has the details of the app event.

• The timestamp segment, that has time at which the event got recorded.

• The memory segment, that shows the percentage of free memory.

Activity-trail from an issue report in Android

Stack trace​

​

Stack trace helps the developers to track the exact line of code where the crash occurred.

Stack trace from an issue report in Android

Network Parameters​

Network parameters provide in-depth information on network request and response data. Network parameters will have request headers, request body, request body size, response headers, status code and response body size. 

Network parameters from an issue report in Android

Device & Device State info​

​

Device & Device state info gives the developer information about the device and the state of the device at the time of bug occurrence.

Device and Device State data from an issue report in Android

Function Parameters​

​

Function parameters section of data points will contain parameter value and data type of all the parameters passed to the function being tracked during runtime.

Function parameters from an issue report in Android

Data Security & Data Privacy​

​

Appxiom SDK is architectured in such a way that all our app users remain anonymous to the system as we do not collect any PII which ensures data privacy. All data collected, sent and stored by Appxiom are secured with end to end encryption. Appxiom is also GDPR compliant.

Call back mechanism​

​

For every issue that is raised by the Appxiom SDK, a callback function will be triggered, which allows developers to handle the issue gracefully. You can read more about the same in our Java and Kotlin documentation pages.

Appxiom is also available as Objective-C and Swift frameworks for iOS and watchOS. Visit appxiom.com to know more about Appxiom Detailed documentation is available at docs.appxiom.com.

Memory leak is a critical bug in watchOS apps, that often go unnoticed during development. Memory leaks can lead to EXC_BAD_ACCESS error and will manifest as app crashes in watchOS.

Memory leaks are caused when unused objects are not cleared from memory. It slows down the app, which affects the experience of the user. So detecting and fixing memory leaks as fast as possible is important for maintaining good user experience and thus retaining users. Tools like XCode Leaks Instrument available for watchOS will help developers detect memory leaks during the development of apps.

There are situations where developers tend to miss figuring out leaks during development. Such leaks are very likely to manifest in production.

This is where Appxiom come in. Appxiom watchOS framework monitors InterfaceControllers for retained objects and reports it in real-time.Appxiom detects memory leaks in watchOS apps just by extending InterfaceControllers from ObservableInterfaceController, a custom InterfaceController class provided by Appxiom.

Objective-c Integration​

@interface ProfileController : ObservableInterfaceController

@end

Swift Integration​

class ProfileController: ObservableInterfaceController {

}

Find the detailed documentation for Objective-C & Swift, on how to track memory leaks.

Appxiom reports memory leaks with relevant data points like leaked InterfaceController name, activity trail, device info, and device state info. This will help the developers to reproduce the memory leaks and find the root cause.

Here is a screenshot of the memory leak detected by Appxiom in a live watchOS app.

Memory Leak in watchOS appsMemory leak bug report provides the name of the InterfaceController where the leak occurred along with the total memory consumed by the app.

Apart from memory leaks, Appxiom also detects API call issues, frame rate issues, abnormal memory usage, crashes, exceptions, function failures & delays along with custom issues. For knowing more about how Appxiom detects memory leaks in iOS apps, please read our blog post Detect memory leaks in iOS (Objective-C & Swift).

Visit appxiom.com to know more about Appxiom. Detailed documentation is available at docs.appxiom.com.

Related Blog Posts

• How to detect memory leaks in Android

• Detect memory leaks in iOS (Objective-C & Swift)

Memory leak is one of the most dreadful issues developers fear. It's even bigger challenge for mobile app developers as very often the device where the issue manifests is out of their reach. Most of the time developers will not even get crash reports caused by memory leaks. They usually manifest in the form of EXC_BAD_ACCESS.

Tools like XCode Leaks Instrument for iOS help developers identify such leaks during development time itself. But what is the guarantee that all such leaks are identified and all possible use-cases are tested properly? There is no guarantee, and that is the hard truth.

So what if the developer and the tester missed some use cases and there are memory leaks happening in production? Here is where Appxiom help the developer to get notified about the issue in real-time and that too with as much relevant data as possible so that (s)he can reproduce the bug. Appxiom auto detects memory leaks.

Appxiom report bugs to the dashboard with important data such as activity trail, device info, and device state info. This will help the developer to be aware of the leaks happening in their app that is running in their users' devices and also helps them to reproduce the memory leak.

Here is a screenshot of such a leak detected by Appxiom in a live app.

With such reports, developers are notified of the occurrence of a memory leak in a ViewController. Developers can then use the Leaks instrument to drill down the corresponding ViewController for the leak.

Apart from memory leaks, Appxiom detects API call issues, frame rate issues, abnormal memory usage, crashes, exceptions, function failures & delays. It also has the capability to report custom issues. The memory leak detection is available in our iOS Framework starting from version 3.1.0. For knowing more about how Appxiom detects memory leaks in Android apps, read the blog How to detect bugs in Android.

Visit appxiom.com to know more about Appxiom. Detailed documentation is available at docs.appxiom.com.

Related Blog Posts

• How to detect memory leaks in Android

• How to Detect Memory Leaks in WatchOS apps that are created using Objective-C or Swift

Most of the mobile and wearable apps will have a cloud back end with which they communicate using APIs. Any failure in this communication may result in unexpected outcomes and broken features. It is very difficult for developers to be aware about any such problem once the app has gone live.

Appxiom provides a simple-to-implement feature to detect HTTP(S) issues. Adding a single line of code will enable Appxiom to monitor all API calls originating from the app. For implementation details visit documentation for iOS (Swift and Objective-C) and Android (Java and Kotlin).

Appxiom monitors HTTP(S) calls for duplication of calls, error status codes and delay in receiving response (based on bandwidth strength). The bug report will contain request details including request header, query parameters, request body, response header and response body size.Is it important to detect API call issues in app side? Here is our blog on why it is - Detecting API issues in mobile app.

Below is the bug report of an API call issue. The response status code indicates that the URL is wrong and the possible reason is that the user id mentioned in the URL does not exist. This is a bug that need to be fixed in the client side. It's a common mistake that the app sends wrong information in URL, header, query parameters or body and such issues need to be fixed at app side. Also it's very difficult to track some API issues like duplicate API call and delay related issues in server side.

Bug report of an API call issue.This detailed report will enable the development team to reproduce and fix these issues faster.

Appxiom provide a mechanism to mask sensitive header parameters, like authentication token. The SDK will not even send the value of that parameter, instead a ★ is sent. This will help developer to confirm that there is a value for that parameter, but it is masked. Refer documentation for iOS (Swift and Objective-C) and Android (Java and Kotlin).Visit appxiom.com to know more about Appxiom. Detailed documentation is available at docs.appxiom.com.

Most mobile apps have a server-side application that it talks to over HTTP / HTTPS. These API calls are usually critical for the successful execution of the features in the app. Any failure during API calls results in incorrect execution and bad user experience. It’s critical for mobile app developers to get notified about such issues so that they can fix them at the earliest and thus prevent bad user behavior.

API calls from mobile apps fail because of the following reasons

• Server-side Application layer issues

• Web Server issues

• Wrong request parameters

• Wrong request headers

• Network issues

• Network and execution delays.

Monitoring at the server side can detect only if the request reaches the application layer. For web server issues, network layer issues and delays, monitoring at server side will not help. The mechanism that helps in detecting all issues related to API call will be to monitor at the request source.

While monitoring API calls from the mobile app side, it’s important not to induce any delay or performance impact in the execution process. Which means, the monitoring tool should not act as a proxy, rather should just be a listener to request and response. It was with this in mind that we built API call failure reporting feature in Appxiom. The tool successfully identifies network issues, error status codes and API call delays and reports the same to the developer.

API call monitoring method comparisonA few days ago, one of our customers faced an issue where a critical feature was not working for some customers. They checked the server side logs, wrote code to monitor API calls and did everything possible, but could not detect any anomaly or error. It was around that time they heard about Appxiom and decided to try it out.

They integrated Appxiom into their app quickly and released a new version with that. Within hours they noticed that one of the API calls was not getting through and was failing to reach the server. As more occurrences of the issue started getting reported by Appxiom, the tool showed them an important data point that all the failures happened from one country.

That’s it. They were using a third party API for one of their features and that particular API was failing in one particular country. Now they could go behind the issue with clear direction. They further dug in and found out that the third party API was in fact blocked in that country. It took some time for them to get the issue fixed as it was outside their control, but they were able to find what the issue was rather than being blank about it.

Appxiom is a mobile SDK which when integrated to mobile apps, identifies memory issues, API failures and delays, failures, and delays in function calls and failures and delays between function calls