Posts tagged Testing

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.

Automated Production Testing and Monitoring

With almost two years under my belt of having an app in production on Microsoft’s Azure I’ve learned some hard, hard lessons. One of the biggest is you need to have active testing and monitoring of your production environment from both inside and outside the environment. It sounds like a no-brainer, but it’s so far down the priority list for most developers and startups that it takes a long time to get to, if ever.


Some history is in order; Resgrid is a system designed to provide logistics and management capabilities for first responder organizations like volunteer and career fire departments, EMS, public safety, search and rescue, HAZMAT and more.

Resgrid was founded by myself and a partner staxmanade. It started as a simple website and a couple of mobile apps with one page and some big buttons. A year later it’s now a complete end to end management and logistics system that runs on Windows Azure.

Because our market is first responders we need to ensure uptime and that information is relayed quickly, having something down for even a short period of time can impact our customers and in our market there is no good time to go down.

Create Test Accounts/Data

One of the first hard lessons what not creating seed data that we could use for testing and verification on the production system. We use Entity Framework as our backing repository mechanism and it’s very easy to add data into the Seed method of the Configuration for migrations:

protected override void Seed(Contexts.DataContext context)
            //  This method will be called after migrating to the latest version.

            //  You can use the DbSet<T>.AddOrUpdate() helper extension method 
            //  to avoid creating duplicate seed data. E.g.
                  p => p.FullName,
                  new Person { FullName = "Andrew Peters" },
                  new Person { FullName = "Brice Lambson" },
                  new Person { FullName = "Rowan Miller" }

Use this method and seed your database! What you going to seed you may ask yourself? Anything that you may need to log into the system and perform actions, customer records, login records, etc. Even if you never plan to do production testing, create the data, and you’ll have it just in case.

Do no try and use the Seed method after you have data in the system already, it starts to not turn out well. We had an instance where we tried creating a test department after we had customers in the system already and it created over 300 test departments.

Monitor/Test Externally

Finding our your system is down from your customers is not good practice. You should know that there is an issue, well before your customers let you know. A critical part of this, is testing your site from a place on the Internet that isn’t on the same network or backbone as your system. Azure recently introduced Endpoint Status Monitoring that helps with this, but it’s just high level check.

If your using Team City as your CI server you can setup configurations that run on a schedule that can test your system with complex code, scripts, calls and much more. Have your CI server from another provider, like if your using Azure, have your CI server on Amazon, etc. Also I recommend using a backup service like Pingdom to provide backup monitoring and uptime analytics.

Fully Test Critical Processes

In Resgrid, we send out dispatches (calls) via email, text messages and push notifications. This is a mission critical process for us as our customers need these systems to work. Although we cannot guarantee delivery of the message we can say that if it never gets sent, they will never receive it. So we have jobs that run that perform user actions that would generate those messages and we monitor to ensure we receive them. We test the full flow in production at least once an hour.

Test Multiple Paths

If you have a website and an API site living on different systems, test them both. Don’t just rely on testing say the website path to ensure the system is working end to end.

You don’t always have to automate

You don’t have to automate everything, if it takes you 5 minutes to check something and it takes you 8 hours to develop an automated solution you would have to test something 96 times to break even. As a small/micro business you need to use your time where it’s most effective and that will bring in new customers and keep existing ones happy. If a manual test works and is not high friction, that might be your best bet.

Go to Top