application

Reasons Why Mobile App Maintenance is Very Important

Posted on by Mario

The-Importance-of-Mobile-App-Maintenance_ywf

It is common among the app developers that an app should be maintained regularly. Just think about it, the two most popular Mobile Operating Systems, like Android and iOS keep upgrading their app version. Then, how can your app  survive if you don’t keep it up to date? Figure out the importance of maintaining the mobile apps, in the paragraph below. You will be astonished to find how important it is for your business.

Getting the Latest Versions of the Operating Systems

Both, Android and Apple keep updating their Operating Systems at regular basis whenever there is advancement in the technology. This is because a number of apps will stop operating on new versions that does not support them. For instance, Apple recently launched the iOS 11 version and as usual, apps working with iOS did not operate in the new version. Even Android has launched the Android 8 of which the OS gets updated once in a year. Therefore, as a solution, you should try to provide the proactive audit to the users when the beta version is made available.  Your developer should have a discussion as to what changes should be made in the app. This works as an attempt to maintain the app rather than lose the users.

In the Long Run Provide Financial Benefits

No matter how hard you try, it seems impossible to create a perfect and flawless app. This is why we need maintenance, for it will save the initial expenditure cost, then implementing the maintenance plan becomes necessary. In other words, you are updating the app timely and not incorporating the unnecessary features. Besides, you can monitor the apps in the proactive manner rather than reactive way which will bring in less technical issue.

The Improvement in Software Libraries

Software libraries is a well acquainted software in app development business. It is a prewritten code, configurations, and routines and the developers update or improve it. However, most apps do not have software libraries and when ones have; they must be completely up to date.

Offers an Updated User Interface (UI)

Mobile app is a thing that keeps changing rapidly. This is why the user interface of the mobile app should always be updated and advanced. Things that look cool a couple of years back, won’t have the same value in the present time. It should have a more sophisticated look. Now you can get all these pros if you are maintaining your app. The main point is, since manufacturers often produce different mobile phone size, so UI must be designed in accordance with the size of the phone.

Getting a Better User Experience (UX)

According to some studies, app maintenance has played a crucial role in generating more traffic and higher ratings from the users. Therefore, to get more audience and be on the top, then user experience becomes more than important. In fact, knowing that your app is highly maintained, will inform whether people will download your app or not.

 Allows Regular App Monitoring

Personalized app monitoring is very important, especially in this very competitive market. It becomes all the more vital in cases where the companies do not have sufficient resources to undertake the maintenance work. Therefore, they need the support of an external mobile app partner that can help them in this task. By doing the app monitoring, you can include all the four types of maintenance namely adaptive, corrective, emergency and perfective. Remember to monitor your app at regular intervals if your app is functioning efficiently and make sure that it remains bug free.

It is clear to see that the only way to keep your app on top is by providing a good maintenance. In fact, a good maintenance will prevent your app from getting uninstalled. This is why the app maintenance should always be your priority.

Json-api-normalizer: Why JSON API and Redux Work Best When Used Together

Posted on by Mario

As a web developer, we have to manage the data needed for every application we work on. There are problems when doing so, such as:

  1. Fetch data from the back end.
  2. Store it somewhere locally in the front-end application.
  3. Retrieve the data from the local store and format it as needed by the specific view or screen.

In this article, we are going to discuss about the data usage from JSON, the JSON API and GraphQL back ends, and from that, we can learn the practical way on how to manage front-end application data. As for the real use, let’s imagine that we have carried out a survey that asks the same questions of many users. After each user has given their answers, other users can comment on them if wanted to. Our web app will perform a request to the back end, store the gathered data in the local store and render the content on the page. In order to make it stay simple, we will leave out the answer-creation flow.

Redux Best Practices

What makes Redux the best is that it is changeable no matter what kind of API you consume. It doesn’t matter whether you change your API from JSON to JSON API or even GraphQL and back during development, as long as you keep your data model, so it will not affect the implementation of your state management. Below is the explanation on the best practice using Redux:

  1. Keep Data Flat in the Redux Store

First, here’s the data model:

 

 

Based on the picture above, we have a question data object that might have many post objects. It is possible that each post might have many comment objects. Each post and comment has respectively one author.

Let’s say we have a back end that returns a specific JSON response. It is possible that it would have a carefully nested structure. If you store your data in the same way you do in the store, you will face many problems after that, like, for instance, you might store the same object many times like this:

{

  “text”: “My Post”,

  “author”: {

    “name”: “Yury”,

    “avatar”: “avatar1.png”

  },

  “comments”: [

    {

      “text”: “Awesome Comment”,

      “author”: {

            “name”: “Yury”,

        “avatar”: “avatar1.png”

      }

    }

  ]

}

In the example above, it indicates that we store the same Author object in several places, which is bad, because not only does it need more memory but it also has negative side effects. You would have to pass the whole state and update all instances of the same object especially if somebody changed the user’s avatar in the back end.

To prevent something like that from happening, we can store the data in a flattened structure. This way, each object would be stored only once and would be easily accessible.

{

  “post”: [{

    “id”: 1,

    “text”: “My Post”,

    “author”: { “id”: 1 },

    “comments”: [ { “id”: 1 } ]

  }],

  “comment”: [{

    “id”: 1,

    “text”: “Awesome Comment”

  }],

  “author”: [{

    “name”: “Yury”,

    “avatar”: “avatar1.png”,

    “id”: 1

  }]

 }

  1. Store Collections as Maps Whenever Possible

After we have the data in a good flat structure, we can gradually accumulate the received data, in order for us to reuse it as a cache, to improve performance or for offline use. However, if we combine new data in the existing storage, we have to select only relevant data objects for the specific view. We can store the structure of each JSON document separately to find out which data objects were provided in a specific request to gain this. There is a list of data object IDs that we can use to gather the data from the storage.

Let’s say there is a list of friends of two different users, Alice and Bob. We will then perform two requests to gather the list and review the contents of our storage consequently. Let’s suppose that from the start the storage is empty.

/ALICE/FRIENDS RESPONSE

Here’s the User data object with an ID of 1 and a name, Mike, like this:

{

  “data”: [{

    “type”: “User”,

    “id”: “1”,

    “attributes”: {

      “name”: “Mike”

    }

  }]

}

/BOB/FRIENDS RESPONSE

This is another request that would return a User with the ID of 2 and Kevin as the name:

{

  “data”: [{

    “type”: “User”,

    “id”: “2”,

    “attributes”: {

      “name”: “Kevin”

    }

  }]

}

STORAGE STATE

This is what our storage state would look like:

{

  “users”: [

    {

      “id”: “1”,

      “name”: “Mike”

    },

    {

        “id”: “2”,

        “name”: “Kevin”

    }

  ]

}

STORAGE STATE WITH META DATA

In order to find out or distinguish which data objects in storage are relevant, we have to keep the structure of the JSON API document. With that focus, we can change it into this:

{

  “users”: [

    {

      “id”: “1”,

      “name”: “Mike”

    },

    {

        “id”: “2”,

        “name”: “Kevin”

    }

  ],

  “meta”: {

      “/alice/friends”: [

        {

          “type”: “User”,

          “id”: “1”

        }

      ],

      “/bob/friends”: [

        {

          “type”: “User”,

          “id”: “2”

        }

      ]

  }

}

With this, we can now read the meta data and gather all mentioned data objects. Now here’s the recap of the operations’ complexities:

As can be seen from the picture above, maps certainly works better than arrays because all operations have O(1) as the complexity instead of O(n). If we use a map instead of an array for the User data object, it would be like this:

STORAGE STATE REVISED

{

  “users”: {

      “1”: {

        “name”: “Mike”

      },

      “2”: {

        “name”: “Kevin”

      }

  },

  “meta”: {

      “/alice/friends”: [

        {

          “type”: “User”,

          “id”: “1”

        }

      ],

      “/bob/friends”: [

        {

          “type”: “User”,

           “id”: “2”

        }

      ]

  }

}

Now with this simple method, we can find a specific user by ID almost instantly.

Processing the Data and JSON API

There are many solutions to convert JSON documents to a Redux-friendly form. However, while there is no significant change within the application’s lifecycle, it will cause a failure if things are too dynamic, even though normalizing the function with the provision of a JSON document works great if your data model is known in advance.

Using GraphQL might be possible and interesting as well; however, if our APIs are being consumed by many third parties, we can’t adopt it.

JSON API and Redux

Redux and the JSON API work best together. The data provided by the JSON API in a flat structure by definition conforms nicely with Redux best practices. The data is typified in order to be naturally saved in Redux’s storage in a map with the format type → map of objects.

There are things to consider, though. First, it should be noted that storing the types of data objects “data” and “included” as two separate entitles in the Redux store can violate Redux best practices, as the same data objects would be stored more than once.

To solve these problems, we can use the main features of json-api-normalizer, such as:

  • Merge data and included fields, normalizing the data.
  • Collections are converted into maps in a form of a id=> object.
  • The response’s original structure is stored in a special meta

First, in order to solve problems with redundant structures and circular dependencies, the introduction of the distinction of data and included data objects in the JSON API specification is needed. Second, there is a constant update on data in Redux, although gradually, that can help with the performance improvement.

 Now that you know why JSON API works best with Redux, it can be concluded that this approach can assist us in prototyping a lot faster and flexible with changes to the data model. If you are in doubt whether using Redux with JSON API or not, this article will help you find the solution and reason why you shouldn’t doubt this method.

4 Mantras for Designing Scalable APIs

Posted on by Mario

4 Mantras for Designing Scalable APIs - YWF

The idea of scalability is often offered with a great selling point. For instance, you may be familiar with these tags, “Make your API scalable by tying into our simple API” or “you too can make your service scalable by licensing our endpoint collating system”. These are common sales pitches, but they’re tying into a magic service to make scalability happen, as a web developer, you are likely not being scalable – there’s no silver bullet, and adopting a quick fix doesn’t address underlying architectural deficiencies. Generally, scalable can be defined into 4 big definitions:

  • Extensible: At most basic level, scalable software is extensible. Instead of limiting the functionality, it allows multiple avenues to tie into the underlying services and systems to enable extensions and other services. Amazon’s API Gateway is one of the examples.
  • Built into the Architecture: Scalability can’t be separated from the API itself. So, to make it simple, please build for scalability from the onset. In fact, you can use third party to increase your scalability, especially when they assist a built-to-scale approach.
  • Implies Demand Balancing: As its name, “scale”, you can manage one hundred requests as with one million. However, scalability demands efficient performance, regardless of technique or methodology, both at extremely high traffic and extremely low traffic.
  1. Design for a Repeating Launch Day

Launching a product can be really stressful, you may have prepared for everything, but you simply cannot know the requirements your system might see. For instance when launching a service, what kind of traffic can we expect? Let’s say we’re launching a new social platform that ties into an API to handle 200k calls an hour but the rate has surpassed to several millions of calls. This means that you need to address the foundation of your API as if you are always on the verge launching. Besides, you may need to use load balancer as it can determine between your success and failure. Moreover, having failover paths and secondary functions will produce you to a huge difference towards user experience.

The last important thing is to integrate analytics into your system. By knowing trends developing in real time will help you develop in an agile way and address deficiencies as they arise organically, while predicting further failures down the road.

  1. Anticipate Success

No one will truly know how successful you’re actually going to be. This is because it’s not a simple consideration of traffic, either – traffic might be high even if you’re the second or third most popular choice. Therefore, a provider will plan for the most extreme case possible as he doesn’t know how much traffic they can expect. Another way to frame this would be to anticipate success.

  1. Non-Extensible is a Unitasker

If your application is not extensible, traffic management and scalable mindset is nothing. While extensibility is indeed its own concept, with its own considerations and implications, whether or not a service is extensible can have a direct impact on whether or not it’s scalable. In the end, there is no way that a provider can know literally every possible future use and application of their service while it’s a great practice to develop with scalablity from the onset.

  1. Efficiency is King

You will face so many complexities within your problem, so it is important to know how to simplify your API architecture and thus simplify the resultant solution applied to the problem. In fact, you can drastically reduce the actual resources needed by an application by increasing efficiency.