UI Features & Data Processes
Much of the learning that I've been doing for the past few weeks has focused on two main areas. First, how to structure the MOOVPAD WebAPI's so that they provide a more modular, adaptable and reliable framework for the server-side systems. Second, how to build each of these API's so that they better represent the MOOVPAD apps in terms of feature-sets.
Each of the images shown here represents an example where both of these factors are important. In each case, the UI needs to load initially, retrieve some data from the server through a webAPI, and continue functioning on the UI thread as data continues streaming to the client-side. To achieve this, the server-side architecture needs to be segmented in a way that allows the client to call on specific parts/modules for the relevant data without placing so much load on the servers, from too many requests made at once to databases and API's that are too-highly coupled, that the entire process is slow.
The other important thing I've been trying to learn more about is how to make an initial set of data requests, enough to keep the user and UI functional, while also retrieving more data in the background that may be relevant to other parts of the MOOVPAD app. For example, a user may open their uploads of shared training updates, but then select to see a different part of their profile. If it's possible, I'd like to have such processes operating as smoothly as possible. And this will be the focus of the planning this weekend and perhaps into next week.
You see? Thinking, thinking, thinking... 🙂
Stay awesome,
EMH
HOW MOOVPAD IS BEING BUILT
For the overview of how MOOVPAD apps are being developed, the reasoning behind particular decisions during development, policies, and more in relation to all the technical things, please see the link to the left.
This will be an ongoing work in progress, and will always be linked to the bottom of each upcoming Blog post.