Posts tagged Android

The Best Phone for Ionic Framework Development

I have found the one phone that every mobile developer should have on their desks. So what is this remarkable device and why should you add another one one to the many of devices any good mobile developer already has? Well let me dive into that, but first, let me show you the glory that is the BLU Grand XL.

smartphone-blu-grand-xl-dual-sim-3g-tela-5-5-hd-cpu-4core-c-m--8mp-5mp-pretoThis puppy is about the size of an iPhone 6/7 Plus, and a little bit thicker and a noticeable amount heavier. The one I picked up is running the latest. at the time, version of Android 7 (which is why I stumbled across this gem). I picked mine up for $100 unlocked at BestBuy but I have been seeing them show up for less online as well.

The screen, device feel and size all make it a pretty decent device to have to pick up and set down all the time. The screen is fairly responsive so that doesn’t complicate any testing and it easily hooks into Windows and MacOS out of the box for USB debugging and deployments.

But the magic occurs when you look at the device specs and start testing your apps on it.

Category Value


Mediatek MT6580 Quad-core 1.3Ghz
Storage 8GB


Don’t be fooled, that quad core 1.3Ghz processor is not as powerful as it sounds. For the most part it seems to run Android 7 ok, but there isn’t much left over for apps. But there is where the magic occurs for us developers, that processor and amount of RAM is almost the perfect modern day worst case performance scenario. Here at Resgrid we’ve been developing against the Ionic Framework since around 2014’ish and developing on the hybrid stack mean performance is a big concern, but also something that can be difficult to really test and gauge.

Us developers usually have pretty good phones, which means our apps usually run very well. But what are your users using? Prepaid phones and now phones like the BLU Grand XL are out there and very affordable. A lot of people out there using phones a few years old and a lot of people have gotten off the “upgrade every year or 2” train.

Because of the nature of the Resgrid app, targeting emergency management and first responders, we have a pretty high target in terms of performance (our goal is a usable app within 3 seconds), but given the fact that we are at the mercy of the device and browser on that device it can be a difficult target to hit across the board.

But if you can get your app working well on the BLU Grand XL, it’s going to work well on so many other devices. When we first loaded our app on that puppy (in prod mode with aot) it took almost 18 seconds to be fully usable. Because of this we implemented lazy loading, removed plugins and packages and so far have that time down to 12 seconds and still have a way to go.

If you’re a First Responder or know one check out Resgrid which is a SaaS product utilizing Microsoft Azure, providing logistics, management and communication tools to first responder organizations like volunteer fire departments, career fire departments, EMS, search and rescue, CERT, public safety, disaster relief organizations.

Why is my mobile app slow???

I have been part of many hybrid verses native mobile app performance discussions over the last 6 months. In my experience as being a developer of native mobile apps (iOS/Android & WP) in the past and lately in the hybrid space (Cordova with Kendo or Ionic) I’m slowly learning that the client side implementation doesn’t have a lot to do with performance of a mobile app in the ‘grand scheme of things’. What can affect performance of either platform, and in my option matters more than your client side technology, are your services.

high-speed-internetIn my experience the easiest and usually the most important performance gain you can make is optimizing your services and your client to talk to those services. If your used to developing web sites, internal/corporate apps and the like chances are you’ve never thought of API calls as expensive, “Dude I’m using WebAPI and JSON, I’m set”.

Below we are going to talk about your mobile app to your mobile services. Lets assume that your mobile services and everything behind them are well tuned and performant.

Below are some key points I’ve noticed when mobile apps talk to remote services.

Data Size

1 ANSI character = 8 bits, a 3G connection transfers of at least 200 kbit/s which means to transfer 1 ANSI character takes just under 1/2 a millisecond, not including TCP/Network overhead, latency, etc. It doesn’t sound like much, 1/2 a millisecond really, but it adds up. How much data are you sending over the wire, when you don’t need to? When looking at some of our JSON payloads we found that that in the worst case scenarios we could be adding 1/2 a second in data that didn’t need to be on the wire.

Take a look at this data model, pretty standard in the .Net space. ActionTypes and UserStateTypes are simple Integer enumerations.

public class PersonnelStatusResult
    public string UserId { get; set; }
    public string Name { get; set; }
    public ActionTypes ActionType { get; set; }
    public DateTime ActionTimestamp { get; set; }
    public string DestinationId { get; set; }
    public string DestinationName { get; set; }
    public UserStateTypes StateType { get; set; }
    public DateTime StateTimestamp { get; set; }

So how does this look on the wire:

"UserId": "f3a48991-3e5e-4f4c-ab3d-5e7a43a428e3",
"Name": "Shawn Jackson",
"ActionType": "StandingBy",
"ActionTimestamp": "2014-11-26T14:46:16.517",
"DestinationId": null,
"DestinationName": null,
"StateType": "Unavailable",
"StateTimestamp": "2014-12-01T12:24:52.047"

As you can see the JSON serializer used the String values of our enumeration, this instead of transmitting integer values we have long strings. Also for this request I’m sending back the users name, this is something that will rarely change, and probably shouldn’t be send with every request. Also although the names for the parameters are nice it cost of 4 milliseconds of 3G wire time to transmit them.

I’ve recoded the service to send less data on every request. Destination Names (which rarely change) along with users name’s are now loaded up and cached locally on the device.

public class PersonnelStatusResult
     public string Uid { get; set; }
     public int Atp { get; set; }
     public DateTime Atm { get; set; }
     public string Did { get; set; }
     public int Ste { get; set; }
     public DateTime Stm { get; set; }

Now lets see what the new data looks like over the wire.


Much more concise and very little wasted data. The delta between the first request and the 2nd one over a 3G connection is 5 milliseconds. The above data is in a list, with 100 items in the list I’ve saved 1/2 a second in unneeded transmission time.

The serialization mechanism used is also very important. You should not be using something verbose like XML/SOAP to communicate with your apps, instead utilize JSON or Protobuf. For any serialization mechanism you need to think about the serialization/deserialization speed but you still need to think about the syntax of it on the wire.

Data Types

As seen in the example above I’m using Guid’s for user’s id value. Each Guid will cost me almost 2 milliseconds of 3G network time. Although I cannot change that data type now, I need to ensure that all data that goes across the wire is as compact as possible, i utilizing Integers for Id’s instead of Guids.


Never assume your users are on a great WiFi connection, LTE or 4G. There are A LOT of 3G connections out there and congestion in populated areas could easily kill your data transfer speeds of better networks. Just because your lucky enough to be on a 4G network doesn’t mean it’s fast, you need to think about latency, see the table below.

Generation | Data rate      | Latency
2G         | 100–400 Kbit/s | 300–1000 ms
3G         | 0.5–5 Mbit/s   | 100–500 ms
4G         | 1–50 Mbit/s    | < 100 ms

Even on a 4G network your latency could be 1/10’th of a second. This is without any other issues like, retries timeouts, dropped packets, etc.


TCP overhead matters. Every time you make a data call from your mobile app to an external service that goes out over the wire. Your TCP header is normally 20 Bytes but can be up to 60 depending on what options are being set. Then your IPv4 header is another 20 Bytes. That means for every connection you have 40Bytes of overhead occurring in the best case scenario. That means that 2 milliseconds are spent with every call over a 3G connection with TCP/IP overhead.


So below I have the following tips for service performance for mobile apps.

  1. Plan for the worst case but realistic network connection scenario. In the areas that my app works you can see Edge connections which are typically limited to 135 kbit/s. If you plan for the worst your app will perform just fine at better connections and speeds more typically seen.
  2. Don’t assume you’re going to be fast just because your on a 4G/LTE connection. If your doing connection based logic just determining the connection type isn’t enough. Latency, cell strength, congestion, etc can make a 4G or LTE connection just as slow as a 3G one.
  3. DRY (Don’t Repeat Yourself) and Cache your data on the device. Keep list calls and redundant data to a minimum.
  4. If you haven’t changed it in the last 3 months, chances are you wont! Don’t store configuration data on the server only to serve it up to the device every time. Keep it on the device or cache it.
  5. Don’t transmit or contact the server unless you have to. Every time you ‘leave process’ it’s a slow operation. Don’t do it unless you have it.
  6. For lists, utilize 1 call to bring back all the list data, then use that data to populate detail views. Unless the detail data is grossly larger then the data for the list it’s worth it to not make a detail view call.

So if you currently have a slow mobile app take a look at your services first and ensure they are as performant as possible before you go re-writing your app.

Mobile Development and the Support Burden

Thinking of selling a mobile application? You should be aware of the support burden of supporting an on-device mobile application. When you really think about it applications on mobile devices are the wild-wild west when it comes to their install base, hardware configuration, operating system, capabilities and current state. Android is by far the most fluid with Windows Phone 8 probably the most static.


In the last 2 years I’ve really gotten into Mobile Apps, both native at the start and now hybrid. I will save the Native verses Hybrid discussion for a latter time, but they both have positives and negatives when dealing with support for your customers.

It wasn’t until I started developing the mobile apps for Resgrid did I fully appreciate the support burden that can arise form mobile app development.

Resgrid is a cloud service company providing logistics and management tools to first responder organizations like volunteer fire, career fire, EMS, search and rescue, public safety, disaster relief organizations, etc. It was founded in 2012 by myself and Jason Jarrett (staxmanade). We have currently 2 hybrid mobile applications 1 one legacy native one that we are in the process of replacing.

In the last year I’ve also had the luxury of being part of enterprise grade mobile app development at Paylocity, which is a cloud service provider of payroll, human resources and time & attendance products and services. Both of those experiences have given me some great insight into challenges faced by companies supporting mobile applications.

So your only going to develop for iOS, seeming it’s Apple, they control everything and it’s all a known quantity. Well your first problem is that every phone is it’s own unique little snowflake, in addition that unique little snowflake varies wildly depending on where it is. For Apple, say you only do phones, and iOS 7.1+, that gives you the iPhone 5, 5S and 5C (pretty small right?). You still have a good size support burden.

Factor 1: The Hardware

Even with a hardware universe as small as the iPhone 5, 5C and 5S there are some drastic differences between the phones. Between those 3 phones there are 21 models. Check out this article from EveryMac that breaks down the hardware and usability differences between the 5,5C and 5S. So potentially in just those 3 phones you have 21 instances where you app could operate or act differently. That’s assuming a constant baseline of OS, installed apps, running apps, network, environmental conditions, accessories and user.

Although the newer phones high end phones have some good hardware spec they still can have some serious performance concerns. How many background tasks are running? Is there competition for the same resource? Mid range and cheap phones have pretty much barebones specs.

Factor 2: The Operating System

Operating System fragmentation is a huge issue. Up until iOS 7 the Apple iOS fragmentation wasn’t a big deal, but iOS 7 cannot be installed on older devices, like iPhone 3’s and older, first gen iPads’ etc. Here is a good article from December 2013 detailing the fragmentation issues on iOS and Android.

Factor 3: The Network

Can you hear me now? Ok sorry. This really is a huge issue. Most of our apps need to transmit and receive data. But how performant and error prone that process is can vary wildly depending on the network, the connection, signal strength and congestion. Just walking around my house on a cell connection I can get errors in my app sometimes, it’s not the apps fault or the backend service, it’s the network.

Factor 4: The Browser

This is more a problem that specifically affects hybrid applications, but it’s such a huge problem for mobile apps that it needs to get it’s own section. Mobile browsers pretty much suck. Some are far better then others, I think Mobile Safari is probably the best default browser. Sencha has a great article on mobile browser performance, the gist, mobile performance can suck especially on older operating systems and hardware.

I’ve found through experience that Android mobile browser is worse then iOS, especially on Android 4.2 and older. In one case I’ve seen something completely usable in an iOS 7 device and unusable on an Android 4.2 device.

Factor 5: Accessories

You design your app with swipe gestures, say to open a drawer menu, did you take into account the cases people have on their phone? An Otterbox Defender case adds a 1/4’th the depth of the phone lip before the screen, making it hard for people to swipe in from the sides.

Other accessories like screen protectors can fade out the screen or wash it out. Making text harder to read, or small details to be visible.

Factor 6: Environment

You wouldn’t think that environment can be a problem, oh but it can be. From a app details being washed out in the sun, to trying to get a GPS fix where your customers are physically using your app can impact perceived and actual performance and usability.


Based on the factors above support request and issues from even a single user can vary wildly. At Resgrid we’ve had the same user say the app’s performance is amazing over a cell connection and the next day (in the same area over the same connection) say the app is unusable. I’ve even had people that somehow got the Resgrid Responder app loaded on jail broken devices and sent scathing support emails when it wasn’t working.

There is a lot of upside to developing mobile apps, but you need to take into account all the form factors, hardware configurations, networks and usage scenarios to help prevent errors and user issues before then happen and to better support your users.

Go to Top