There are many advantages to this approach. This allows our teams to work more effectively concurrently, to deliver & deploy enhancements more quickly, and to provide a wide-range of flexible options to our customers.

Our iOS and Android industry solutions are made up of modules, which sit on top of SDKs, which call various APIs. Let’s look into each of these in more detail.

Industry Solutions

Phunware provides tailored industry solutions for healthcare, hospitality, and various other sectors, offering personalized mobile apps designed to enhance customer satisfaction. From the moment they leave home to every step of their visit and back again, consumers expect a seamless experience.

Some of our largest customers, like Atlantis Bahamas, Gaylord Hotels, and Virginia Hospital Center, appreciate the rapid deployment and easy updates our solutions provide.

Our mobile app solutions are packed with features like dynamic content, indoor wayfinding, push notifications, analytics, and more—all designed to enhance user experiences.

Under the hood, these solutions are pre-integrated with several of our modules, described below.

Modules

You can think of modules as different components of a mobile app that have a specific feature set.

For example, our Mapping Module includes everything an app might need to deliver a robust wayfinding experience. The app simply needs to launch the Mapping Module and the user is now presented with a map displaying points of interest, search capabilities, and a discovery section.

Features such as static routing, GPS routing, and indoor BLE routing are supported. Users can select handicap accessible routing, enable voice directions, view turn-by-turn directions, or tap on points of interest to view detail pages.

Another popular module is our Mobile Engagement Module, which includes support for broadcast push notifications, geofence alerts, and beacon proximity messaging, all with a nice inbox to hold those messages and allow users to view promotions or re-trigger links.

Other modules include the Core Module, which handles content management, Forms Module, for form input, and Permissions Module, for handling app permissions such as location, bluetooth, or push notifications.

SDKs

But what if a customer wants the capabilities we offer, but prefers to develop their own UI and UX? That’s where SDKs come in. Our native iOS and Android SDKs act as true Software Development Kits. Third party developers can integrate our Mapping & Location SDK, Analytics SDK, or Mobile Engagement SDK and create whatever UI/UX they can imagine. We provide sample code, but it’s up to the developers to decide the look and feel.

APIs

Just about every app will need to connect to a web service to perform actions such as downloading content, registering for push notifications, or sending analytics.

Our solutions are no different. They are powered by our RESTful APIs for Mapping, Location, Content Management, Mobile Engagement, and Analytics.

The same is true for our web portal. When a customer updates their map, changes a piece of content, sets up a push notification campaign, or views how many app launches they received, they are using the same APIs that our SDKs use to deliver those experiences to end users.

Advantages

Now that we’ve covered our modular approach to architecture, it’s time to discuss the advantages.

The first is that this approach allows our developers to work on different components of our solutions without stepping on each other’s toes. For example, each module is in its own code repository so the developer working on the Mapping Module isn’t going to create merge conflicts for the developer working on the Mobile Engagement Module. It also allows developers to become specialists focusing on specific feature sets.

The second advantage is that this approach allows us to roll out changes quickly. For example, let’s say we wanted to add a new feature to our map. It wouldn’t make sense to make this change in every app codebase. Instead we implement it in the Mapping Module and release a new version. Each app, whether it’s a Phunware-developed Industry Solution app or a third-party developed custom app, can simply update to the latest version of the Mapping Module to receive the changes. This is as simple as updating the version number in a dependency management configuration file and rebuilding.

Finally, another major advantage to this approach is that we are able to offer a wide range of options for our customers. For the customers who want a complete solution, our Industry Solutions contain everything pre-integrated and ready to submit to the store. For customers who have an existing app, a better option might be to license individual modules. For example, a customer can add wayfinding capabilities to their app with a drop-in Mapping Module that can be integrated in as little as a day. For the customer who just wants the wayfinding capabilities but would prefer to design their own UI and UX, the Mapping & Location SDK is ideal for that. And for those who want maximum control, our APIs are always available.

At Phunware, we see ourselves as more than just a technology provider—we’re your partner in success. Think of us as your concierge in unifying your customers’ journey. Whether you need the complete solution or just the key components to build it yourself, we’re here to support you every step of the way. From design and implementation to integration, launch, adoption, and ongoing support, we ensure a seamless experience that lasts for years to come

As always, feel free to reach out! Contact us and our team of experts will guide you through Phunware’s mobile solution offerings, showing you how they can be tailored to meet your unique needs.

The post Tech Blog: Modular Approach to Mobile App Architecture appeared first on Phunware.

When defining a new feature for a mobile app, it’s important to follow best practices to ensure the feature is complete, stable, and easy to maintain.

Let’s use a new Leaderboard screen as an example. A less experienced manager may write user stories for the Engineering team asking them to satisfy acceptance criteria that ensures the proper UX is followed, the UI matches the designs, and the points are populated by the appropriate data source. But there is so much more to consider.

Feature Flags

It’s imperative that a mobile app has an external config file. This file will typically contain various configuration settings, urls, strings, etc that an app needs before it launches. Phunware’s Content Management Engine is a great place for developers to create a JSON-based app config file. 

Feature flags are an important component of any config file. Feature flags are simply set to true or false and determine whether a feature should be enabled or not. Using our Leaderboard screen example, we may not want to launch the Leaderboard feature until the first of the month. We can go live with the app release, but keep the flag set to false until we’re ready for users to experience it in production. 

This is also helpful if an issue occurs and the data populating the Leaderboard is corrupt. Rather than delivering a poor user experience, we can temporarily disable the Leaderboard until the issue is resolved.

Externalized Strings & Images

The app config file is also a great place to externalize text strings and image URLs.

Let’s say there’s a typo in our Leaderboard screen or a Product Manager simply wants to change the copy. It’s much quicker and easier to update the text in the config file than to make the changes in code, submit to the stores, wait for approval, and then try to get all our users on the latest app version.

At Phunware, we actually take this a step further and externalize strings for each language. For example, we may have a strings_en key for English strings and a strings_es key for Spanish strings. We serve the appropriate text depending on the user’s language settings.

Externalizing image URLs is also helpful when we want to change images on-the-fly. We’re always uploading new images to Phunware’s Asset Manager and updating URLs.

Analytics
After launching a great feature, we’re going to want to know how it performs. Are users visiting the Leaderboard screen? Are they interacting with the filters?

Analytics is often an afterthought. If we train ourselves to write a corresponding analytics ticket whenever we write a feature ticket, we’ll find that our coverage will be very complete.

Phunware Analytics is a great tool for capturing app launches, unique users, retention cohorts, screen views, and custom event analytics.

Error Handling

So we wrote user story tickets for the Leaderboard screen and the developers have finished implementing it. But what happens when the API goes down and returns a 500 error? Will the app provide an informative error message, a generic one, or simply get into a bad state?

By writing an error handling ticket we can define the behavior we would like when something goes wrong. At Phunware, we like to use a mix of specific and generic error messages.

For the Leaderboard example it may be more appropriate to display a message such as “Unable to load Leaderboard data. Please try again later” rather than “An unexpected error has occurred”. However, the latter might be best as a catch all for any situation where a specific error message wasn’t implemented.

Deep Links

Chances are, if the new Leaderboard is doing well, someone is going to ask if they can send a push notification promoting the Leaderboard which, when tapped, sends users to the Leaderboard screen.

If we considered deep links when writing the initial user stories then we’re probably covered. These days there are many places that may link into an app. Deep links can come from push notifications, app share URLs, emails, or even websites redirecting to the mobile app.

Considering deep links when implementing a new screen saves the time and overhead of having to do the work in a follow up release.

Offline Caching

There are times that our users have a poor network connection. Perhaps they are on a train or their WiFi is down. Ideally we realized that this may occur and tried to create a good user experience when it does.

At Phunware, we make sure to cache as much content as possible. If the user launches the app without an internet connection we’ll still display the images and content that were available the last time they launched the app.

While it’s possible some of the content is outdated, this is a better experience than showing a blank screen.

Displaying a banner at the top showing the user doesn’t appear to have a connection is also helpful in informing the user they are being shown something slightly different than if they had a good connection.

Unit Tests

We try to cover as much of our code as possible with Unit Tests and write them when developing new features.
Unit Tests allow developers to be confident the feature works as expected. We set up our build jobs to run unit tests when new builds are being generated, so a few months down the road, if a developer introduces a regression, we catch it right away. This frees up our QA team to focus on edge case issues rather than discovering breaking changes.

Documentation

So we wrote the user stories the Engineering team needed to implement the Leaderboard screen. Everything has been externalized, deep links have been tested, analytics are in place, and unit tests are all passing. Now it’s time to update the documentation.

Keeping documentation up to date is very important as codebases and feature sets are always changing. Ensuring we have proper documentation allows team members to quickly look up that deep link URL scheme or the analytics event that fires when a user toggles something in the Leaderboard.

In addition to documentation, this is also a great time to update submission checklists and QA test plans, since we’ll want to make sure the new Leaderboard is tested with each new release.

Store Guidelines

Our final best practice to follow is keeping up to date with Google and Apple’s App Store Review Guidelines. We check these weekly because we never know when new guidelines will be announced.

It’s critical to know these before the feature is completed and the app is submitted. There’s nothing worse than getting rejected because we violated a guideline. At that point any deadline we had to launch the app went out the window.

For example, there’s a guideline that requires that any app that allows users to create accounts must also provide a mechanism for users to delete their account. If we knew this when writing that user story for Sign Up and Log In, then we’re covered. If we found out the hard way, then we’ve lost precious time because it may be another sprint or two before the Engineering team can deliver that new flow.

Luckily we followed the other best practices and we’re able to disable it for now!

The post Tech Blog: Engineering Best Practices appeared first on Phunware.