Joining client with the back end service

Bridge

Sooner or later any Android, iOS or Windows application wants to get outside of the local hardware box and start to communicate with the outside world. In case of our application we new that already from the very beginning that we are going to have a back-end web services in one or another way. At the beginning of the project, after the user requirements were set, and the architecture of the solution designed, it seamed quite straight forward to implement our back-end services. Bellow is the architecture we decided to use for our Fitradar system.

But in the process of the implementation we realized that quite often we have to adjust our back-end web services API. So in this article I want to share some experience we had while joining our client applications with back-end web services.

Initial approach

First we divided the whole system in 4 sub-projects:

  • Android application
  • iOS application
  • back-end web services application
  • the project website application

and created 3 teams. We thought the client application teams and web services team will be able to work independently after the APIs and data contracts on the web services were defined. Once we received the UI designs we started to model web services API and data contract between the applications. And when the data contract between the applications was defined the back-end team started to work on the web service implementation, meanwhile application teams started to work on the UI (User Interface) part.

We estimated that by the time application teams will complete one use case UI, back-end team will implement the web services for that use case to the degree that they can start to receive and send data.  The first use case we picked up was user profile creation. The interaction between the client application and back end services went smoothly. Web service received the user profile data and stored that in the database. So we took the next use case – displaying full user profile information to the profile owner and limited information to other application users.

The problem

As we started we thought it will go fast and smooth since all we needed was to fetch already stored data from our web service. But soon we discovered that the data coming from the web service is not complete. We needed to display some statistics about the user activity. Since on early stage of development and user requirement gathering we new very little how the statistics will be calculated, we assumed that some of them we will be able to calculate in the clients application and some we will be calculated on the back-end server. It turned out that some statistics we were not be able to calculate in the client’s application and we needed to fetch more data from the server but on the other hand to calculate statistics on the back-end server we needed more input data from the user during the profile creation. So we had to change the data contract for the user profile creation and for user profile fetching web service end points. And when was the time to move to the next use case – sport event creation, we decided to call for a meeting to find a better approach.

Different approach

After some brainstorming we decided that both teams should work simultaneously on one or two use cases. When we had to work on use case that shows some data we kept an eye on the use case that sends this data to the back-end web service.  It means that we always started with the use case that fetches data from the web service and displays data to user. Application team started with UI that was unambiguous, since we had UI designs and we new quite well what we want to see in the UI. In the development process along with UI layout View Model was created. This View Model clearly defined what data we need in order to meet the design and functional requirements. Now we could see what business layer entities can provide the required data. And once the entities were defined for the use case we could tell what endpoint we need and more important what data these endpoints should provide. So at this point the data contract for fetching data was quite stable (it had some minor changes later nevertheless, but mostly because we decided to introduce change in UI design).  And the back-end team now could see if they can provide the required data form the data they will gather. If something was missing on the server the back-end team adjusted the data contract for incoming data accordingly.

To make this process more smoothly and allow the teams to work independently as much as possible application team instead of real network calls used mock objects that returned the required data. And the same did the back-end team for incoming data.

Another thing that back-end team had to keep in mind was, if we really should be the ones that provide the requested data. For example, after user profile use case analysis it quickly became clear that we should delegate the user’s profile picture storage to third party services like Cloude Storage

Conclusion

The one thing we learned is that the more complex project is the more difficult is to come up with precise requirements. We were familiar with the agile development model and applied it extensively on the project bases, but we thought that the interface between the client and the back-end is clear from the initial requirements. We were wrong, the web service interface was changed in several iterations because the discovered more requirements for the client application. So the conclusion we made is that for bigger projects we have to apply iterative development approach for the whole system, we can’t really make the projects independent from each other. We had to check the initial web service interface after each implemented use case and see if we need to make changes there. So are final web service API and data contracts after several use cases looked quite different than that we designed in the beginning.

http://fitradar.me/

The benefits of being a personal trainer

Are you interested in a career in personal training? Here are some of the amazing benefits that come with this career!

Stay healthy

Whether you work in a gym or at home, you will be able to stay healthy and keep in shape whenever you have some free time. This could be at the start of your day or when you are waiting for your next client. You will have all the proper equipment you need and keeping in shape will attract more clients!

Help other people

One of the main benefits of being a personal trainer is that every day you help your clients achieve their goals and become fitter, healthier and more confident. You have the ability to help your clients change their lives for the better and that is very fulfilling.

Turn your passion into a career

If you decide to become a personal trainer because you are passionate about health and fitness then this is the perfect career as you will be able to do something you love every day. You will have the knowledge and skills to teach other people and help them improve their lives whilst fitting in some time to workout yourself.

Career Opportunities

You can work in a gym, health club, sports club, hotel, on a cruise ship or you could even set up your own business and work in your own gym. The opportunities are endless and personal trainers can work almost anywhere in the world!

Meeting new people

You will meet and work with all sorts of people being a personal trainer. The social side makes the job very interesting and you will also have to help clients with different needs and goals so each day will be different.

Choose your own hours

If you work for yourself, you can set your own hours and enjoy a flexible schedule. However, you should consider clients who may only be able to train early in the morning or late at night due to being at work during the day. However, you can still choose which hours suit you best and you wont have the same work hours every single day.

P.S. Visit our website and join the mailing list! Our app is coming soon:

http://fitradar.me/

Source: https://www.velocity-pt.co.uk/blog/benefits-personal-trainer/