From Event Planners to the CEOs of major companies, the reach of applications for smart devices has become a common tool to coordinate information among large groups of users. It’s easy to think that you always need to build an application from the ground up, but this is often not the case – especially when many modern applications have common configuration, connection, and feature similarities. In these instances, a reusable framework can be more appropriate and cost effective.

Frameworks are self-contained code ecosystems designed to handle common tasks uniformly and efficiently. Hallmarks of framework codebases are reusability, modularity and updateability.

Framework modules work as building blocks for a complex application, or can be the structure for an entire series of applications. Many of the development environments that we program in store code for common tasks inside a framework, code to store images to your device or parsing network data are common examples.

Taking this model of modularity and expanding on it, we can also think of an application as a framework that can be reused for multiple purposes.

How or when do you create or use a framework? What goes into it, and when should a framework be used over creating a custom feature or application?

To answer these questions, you must begin with another question: “Will you want to do this again?” If that answer is yes, then taking the time to design your code as a framework is likely the way to go.

The next question you need to ask is:

“How do you maintain a unique look and feel for your application while reusing code?”

This is a more complicated question to answer, and at Vectorform, we have been researching and developing more and more ways to address it. We have found that the following steps are essential to making framework based applications work, not only from a development standpoint but from a UX standpoint as well:

• Keep applications content driven: “Content first” applications have longer lifespans and create greater user delight.
• Have designer involvement from day one: Application development is a team effort that needs to be approached holistically, so as to leverage the insight and talents of all individuals.
• Have a clear game plan from the beginning about what will be accomplished: Scope definition is critical to the success of any development cycle.
• Think about ways to both expand your framework externally, while also being able to make your code something that can be dropped into a project: Be mindful of what can become “core” functionality, and extrapolate that code as much as possible.

On the surface, building a framework might seem like simply reusing old code, but in reality it serves as a foundation upon which any user experience is built.Your application actually becomes more flexible as you build incrementally, instead of starting from scratch each time. With the right architecture in place, a screen that was once designed to simply display images can be adapted to display videos, interactive 3D models, or file content.

As broadband and high speed cellular data have become more accessible, applications have taken advantage of using server and cloud storage as a central place to house data. Every day, we see more and more applications using this as a way to sync, download, alter and create data. Vectorform breaks this concept down into two parts: a backend server, and the device (client) itself. Here is an example of how a typical framework architecture would appear for each.

Backend

The “Backend” consists of a hardware component and several software components. Hardware components of a typical framework architecture are what you would expect; either a physical machine running a web server instance, a database instance, and your custom software or a cloud based solution (Azure, Amazon, etc…) running the same. Choice of physical hardware over Cloud solutions depend heavily on expected use and expandability and are a whole other conversation that we will not try to tackle here. While the hardware component of a framework backend is obviously critical, it is the software that drives the functionally, effectiveness, and efficiency of a framework-based solution. This software is typically comprised of a central data source, a web based API, and a front-end content management system (CMS). These components work together to create a functioning platform for the given device application (client).

Central Data Source

The Central Data Source contains the stored content your application needs to customize its look and feel, and populate it with relevant data. In this framework ecosystem, the CMS allows for the end user to update values and data contained in the Central Data Source in real-time. Changing the value in a table in the Central Data Source for instance, could change the coloring of all the buttons within the client application.

One of the most flexible web technologies we’ve found for building custom framework architecture is Microsoft’s .Net framework. Using .Net, you are able to generate classes and database models, easily utilizing technology such as LINQ to access data structures swiftly and with little custom code. As with many modern web technologies, .Net allows for cross device compatibility with basic XML or JSON serialization of data by the web application (API). When creating the Central Data Source access layer, try to keep the entities as simple as possible, by using MVC design patterns, and creating functions/components in a modular and generic way so they can easily be placed throughout an application as needed.

Data Access Layer (Web API)

Our Web API’s tend to focus on using a REST approach to updating and downloading data, and generally contain GET, POST, and PUT type functions for accessing and serializing data stored in the Central Data Source. Again, the .Net framework has many convenient API’s, which we are able to leverage in creating a custom Data Access Layer for client data population and configuration. The endpoints created for the Web API are generally designed for flexibility (written to retrieve and serialize data that can remain un-typed) but can be easily modified to perform a specific task when needed.

Content Management System

The Content Management System is the user interface used to interact with the Central Data Source via the Web API. Generally speaking, this is a website that someone can access in order to change content that will populate or configure the client application. When creating a CMS, we are able to focus on an intuitive UX because the logic and data itself is kept outside the “View” and merely responds to data and logic.

Device (Client)

Local Content Manager

Within the client application on a device, the logic for syncing with the backend server is stored and implemented. The Local Content Manager integrates a series of classes used to pass data to the rest of the application. Subclasses help keep data modular which allows for easy access throughout the application. A single content manager also reduces the need to constantly reuse memory to access this data, and can speed up load times. Further, the content manager contains the business logic for changing or updating values throughout the application and syncing with the backend Central Data Source. So whether you want to change a user’s profile picture or update the badges earned at an event for completing a task, this is all done from the Local Content Manager.

Local Data Source

Once the Local Content Manager has synced with the backend server, the data is stored to the device itself, giving quick access to the stored values for an application’s content instead of always relying on a data connection to the server. This way, if the user does not have access to the internet, information is still available from the last session. This type of “offline” functionality is an item that sets an application apart from its competition – showcasing a level of thoughtfulness, professionalism, and know-how often not considered or achievable by one off or inexperienced developers.

Whether the application is an event organization tool, a social network, a news aggregation tool, or a peer to peer chat utility, all can benefit from the framework based considerations described above. Frameworks are constantly stress tested, easily unit tested, and frequently improved upon as they are a part of multiple development and quality assurance cycles. The result is an extremely well architected, feature rich code base that is often refactored in a fraction of the time and cost needed for an application built from scratch.