Device Full App Architecture. Building App. Device & Back-End


keikis org Jan 21, 2018 @ 10:35 pm

Apps Architecture

The picture that we can watch in detail following represents the principal pieces that conceptually enter in game during the app execution. In first view we have four principal pieces:

  • Client Presentation Layer: responsable of paint and manage the screen usability adapt to the user culture.
  • Client Integration Layer: in this case we are talking about the services and objects that have to get the information and resolve the logic on our app.
  • Client Services Layer: this are the services specialized in System Tasks like errors controls, tracing, communications, storing, security controls and more.
  • Back-end Services (REST / SOAP): is the layer on the back-end with responsibilities about resolve the logic data in the server side using multiples services, (microServices, Monolithic), Data Bases, ESBs, Transactions or finally Host integrations.

Ok, no panic!. The before is an intro, let’s go to zoom and detail step by step how manage and what are the components responsibilities in the next chapters.

Great Here We Go ! (Click on image to Zoom x 2)

Horizontal Architecture Diagram

Vertical Architecture Diagram

SmartDevice Architecture keikis Vertical

SmartDevice Architecture keikis Vertical

Objective

Define the conceptual generic base architecture for building Smart Client Mobile applications.

First approximation.

But we should begin at the beginning.

What’s an App (Smart Client App)?

Application that is executed in a terminal controlling and locally managing the user interface and integrating with different systems through services (data and peripheral mobility).

User interface

Visual Components

Flow Control

Label, InpuText, Layout, Navigator, Spinner, Date picker, Menu contextual, …

App and Mobility Services

Phone call, SMS, I / O and DB, Contacts list, Accelerometer, Gestures, Camera, Services Data “REST / SOAP / JSON”, …

Is it to be binary / native?

It does NOT need to be a binary application, but it needs a native boot point on the home screen terminal (e.g. WebView is an incrusted micro browser into native binary app).

Architecture Client & Server (Monolithic)

Begin for the begining:

Client - Server Architecture

Client – Server Architecture

Although MVC Pattern were very famous in the development of the servant part, we have to make it very clear in this case that in the multi-device development this pattern is in the client part, and the servant part will offer a set of data exposed via services. Then we have two main parts the Client App and the services on the back end. Next, we’ll go over and detail each of the pieces that appear in each area.

Domain Application Vs. Architecture

In an ideal domain all technical tasks that do not involve business logic would have to be solved by the architecture, in a real model 100% of responsibilities are not covered and will be complemented incrementally and based on experiences in the architectural area.

  • Solve Thickness Problems In principle, there will be architectural tasks to be performed by the developer.
  • Visual Components Management / Exception Control Flow control Direct use of mobile services.
  • The evolution will seek that the architecture takes more and more control.

What Should Cover a multi-device Architecture?

If we think that we start from scratch and ask us to build a solution for the development of mobile applications we find a dilemma. We will say good I need the app in the mobile, that is obvious, but you need something more?, we have everything in the mobile?.

The response is the most current solutions is NO. We need data, infrastructure, communications with the other systems, what we call the server part or back-in that will provide us with the information and integration that we lack. For example, for a movie app, we need to have updated the list of movies, critical comments and also share it with other users, what happens to the server side?.

Well, the servant part needs it, we need it to be escalable, to grow easily, and to adapt the information to the terminal differences. Well now we know that the mobility solution entails more than the application are necessary several layers in both the client and the server. Today and to align with reality we see the existence of Clouds, microServices, WEB REST APIs GateWay, Queue, Streams, Kafkas ESBs, NoSQL type Mongo, DynamoDB, Realtime, Events, etc. In fact all of them and depending on the case to a greater or lesser extent are necessary for our mobility solution.

In fact we must emphasize that the growth of what we know Cloud today was caused largely by the growth of mobile devices and the use of apps.

Go for it!

Architecture Client & Server Zoom x 1 (microServices)

Ok, and Here We have an evolution.

At the client side have appeared two principals modules based on Visual Components-Flows and Integration with Mobile Services.

In the back-end have several services exposed throw the GateWay (web server or nowadays API GateWay).

The services needs data as is stored in Data Bases or can be integrated by other systems for example by buses (ESB) or queues. In now days services are small functional operational process that work auto is the recent definition about micro services. This terms we are talking around in the server pieces in the next chapters.

Mobile App Client Service Architecture Picture

Mobile App Client Service Architecture Picture

With the two boxes we have the principal blocks of an app. Now we are going to detail each component.

User Interface

The User Interface is in charge of displaying the information and request data in the form of input fields, is therefore its role to interact with the user.

In the Keikis Base Android Training we have a wonderful explanation: Android Base Views, Layouts & Resources

In iOS Apple introduces the concept of “storyboard” in iOS5 SDK to simplify and better manage the screens of your application.

You can use the .xib development form. Pre-storyboard, each UIViewController had a .xib associated with it.

Storyboard is  essentially a single file for all screens in the application and shows the flow of the screens. You can add views and transitions between the screens. Therefore, this is the code needed to manage multiple screens. Minimizes the total number of files in an application. You can avoid using Storyboard while creating a new project by leaving the “Use Storyboard” option unmarked.

A segue established between two scenes

App Mobile (MVC)

Three principies define Model View Controller pattern.

(1) View represents the Look & Feel, must be consistent in appearance and behavior.

View objects should be reusable.

(2) Model Objects encapsulate data and operations.

Both separated, it seems a better idea.

(3) Controller integrates both.

MVC Pattern

MVC Pattern

This Basic Pattern is the original of the responsibilities partition between what is shown to the user (View), the data that we are going to manage internally in our app (model) and the actions that we are going to execute based on the user interactions with the view. Modern MVVM Microsoft’s Model/View/ViewModel, basically add a ViewModel that bind with directly with the view. The behind idea is separating the common model with a model more suitable to the view that can have additional information that later in the business logic of our activities we will not use. This are looking for more orthodox, clean and reusable components. 

Basic Flow Example in a App

Traditionally diagrammed with tools like xCode Story Board


Big Picture of Principal Pieces

Smart Device Architecture keikis_Horizontal Mobile Services

SmartDeviceArchitecture_keikis_Horizontal_v1.0

Client Side

Following for each piece in the Smart Client Device we are given and explanation about theirs responsibilities and integrations.

All pieces in orange color are components that the architecture, thirds frameworks should deliver.

Let’s Go!

User Interface Responsibilities

  • Achieving Productive Applications.
    Organization and manipulation of information.
    Correct treatment of orientation changes.
    Native Components (SDK owners) vs Custom.
  • Delegate events to the View Controller.
    Navigation System / Flow Controller.
    It manages I18N of static literals, locally.
  • Data validation; Functional Validation.
    • Simple: Format.
    • Complexes: Obligatory, Cross Dependencies.
    • Layout with the appropriate Tools by platform:
      • Interface Builder (iOS).
      • Android SDK (Layouts).
  • Usually each user interface will have the data service associated with it needed to be resolved.
  • Interface Stack Handling: allows you to return to previous stacked screens / cache (back).
    • Queries: It would be possible to use this stack to avoid calls System Navigation / Flow Controller.
    • Operative: (eg Transfer): The use of back will not be allowed once confirmed, avoiding to return to entered data (see more security).
    • Leave session: If the user clicks completely disappear once logged in.

View Driver | Controller

  • Receive Events / View Data.
  • Dialog with API Client Integration (all into the device, Synchronously or Asynchronously) based on actions change the Data Model (Integration data groups).
  • Model of the view. View data groups. Calculations (if any).
  • Only deals with business data and Functional Exceptions  (Technical issues should not be dealt with from the developer’s view).
    (Ideally) The Technician Expands are identified in the Integration / Services (Data Services Controller) handlers, it will dialog with the Error Manager.
    Problems in RunTime will be controlled by the part in question / Vista, which will dialog with the Error Manager
    Modifies view data with information returned by model.
  • Synchronous requests can cause the OS to cancel the App by excessive TimeOut (remote, local (BD)).
  • Developed with the appropriate Tools / Components per platform.
    Interface Builder (iOS) / Story Delegates View / ViewController.
    Android SDK (Layouts).

Data Services Controller (Rest / SOAP / …)

  • Responsible for performing control tasks / adaptation at message level type.
  • Include necessary headers shipping (Sessions Controller gives me the Token User).
  • Read cabbages with meta information.
  • Catch Error (Fault) in Message.
  • Dialog with Error Manager indicate errors / faults.
  • Log messaging activity.
  • Dialog with Session Controller to refresh Session / User Activity.
    (Generalized in Flow Controller).

HTTP/S Connector 

  • Responsible for performing HTTP/S communications.
  • Configuration of  GET / POST / PUT / DELETE Operations (REST ops).
    • Destination URI.
    • Input Data and Output Data.
    • MIME / Type & Encodings.
    • Proxy: capabilities to pass through proxies services
      • Certificate: Important certificate configuration.
        • Certificate Debug (Self-signed): only for test environments or debug.
        • Certificate CA: Trust in the CA Certificate.
        • Pinned Certificate CA.
        • Mutual-Authentication.
    • Set / Read Additional Headers, capability to set headers by param.
  • Control:
    • Reuse of connections. Pool | Queue of Connections.
    • TimeOut.
    • Control Technical Exceptions.
  • Reports, dump & traces about the communications and messages sent & received over HTTP:
    • Traces & reports about performance about the requests, times of establish the connection.
  • Possibility of Mock Connections  & Services Request:
    • For example you can mock different requests to resources with Mock JSON responses loaded for external files. It’s could be very useful for testing proposes.

Configuration

  • Configuration lets download information to apps without repacked and republish in app stores.
  • By the configuration enabled manage the app’s behavior from remote.
  • A Configuration standardization & structured for all apps.
  • Persistence in device & back-end.
  • Native Client Console to manage the configuration.
  • Different charging modes from Local or Remote.
  • Capability to change data from the terminal on testing operations.
  • SDK to manage the configuration & enable create configuration on fly.

Technical Log | Error Crashes

Piece in charge of generalizing the traces of information regarding the operation of the app, Functional, Technical and Error activity on the client side.

  • Handler Listeners for Crashes in Run Time.
  • Trace remote crashes and errors.
    • Capability to store the crashes on local or sent to remote.
  • Trace in different destinations and levels:
    • Into device (local).
    • Development Environments.
    • Remote.
    • Cloud.
  • Buffering & Persistence Traces.
  • Offline Controls to Sync Traces when turn online.
  • Reports.
  • Dashboards & Graphs.
  • The debugging traces have to be disabled prior to production:
  • Trace objects (two one Test / another FS Fatal).
  • All the architecture services must trace to the different levels D / I / W / E / F to console (Test).
  • Configuration of destinies and associated levels.
  • Identification ID Tag.
  • Correlation ID of trace, useful to link with traces of a seconds systems, for example en the server side we can used this identification to traces server side associated with a client traces.
  • Performance and system status information (CPU, Memory, Connection Type, Internal Space, …)
  • Performance Statistics from | to Two traces. Generate automatically spent time between traces.
    • Mark t1, start trace.
    • Mark t2, end trace.
  • Traces has to be very exclusive and seleted colletion data:

Init Service | Version control

It’s is true that systems like Android is checking the app store automatically for a apps updates. this is an optional option, but this check not control the complete state of the app, beside is necessary to have a mechanims to block the app when a dramatic bug, problem is killing the app. Also remember that the updates, even in Android could be disable, because the user estimate that it could be consuming very much space on the terminal.

Init Service Version Control is a critical service that help us to block, update, info to user diferentes states of the app from the server.  Great!

  • This service is the first to call when the app start.
  • Invokes a service at the start of the application (previous Login) that tells us the status of the App:
    • OK: There is no problem with the current app, and info message could be downloaded. Continue with the execution .
    • KO: An critical error or bug was found. Message to user to inform about the problem and exit.
    • UPDATE: An update information about the current version, shows a dialog when and when accept go to the Store to update  the app. An URL schema with the store new version information is downloaded.

The other point that we have to adjust is relative to how our graphics is going to be showed on different devices

Functional Analytics | Web | Native

The objective is to be able to trace, mark, know the behavior of the user by going through the different options, functions offered by our application, with the idea of being able to perform an analysis of the operative, most used functions or less of our app.

It allows to perform tagging for analytics of use of the app invoking a resource (traditionally it was a transparent image hosted in a web server from the browser, currently a REST service from apps).

The main features of this products are:

  • Input of key-value parameters to be sent associated with an event / view.
  • Configure in the URL End-Point app where the transparent image to be invoked from the client.
  • I work offline. Before the impossibility of sending nothing accumulates in client.
  • You can not disable tagging from a client point of view.
  • Add a proprietary user agent header.
  • The IP travels at the request header.
  • The tagging system can be issued on demand by programming or automatic as a result of different events, for example in the load of the app, or when you press certain buttons. It is also possible to examine the application click, boot, go to background, close, etc.

Products of this type with SDKs can be Google Universal Analytics, GTM Google Tag Manager, Tealium, Adobe Analyticis, IBM Bluemix analitycs, …

Tag Manager systems are able to easily manage a set of integrations between different analysis products in a transparent way, without having to modify our client applications. Be able to switch from Adobe Analytics to Google Analytics in a transparent way.

Manager Errors / Exceptions Service

A generic error management piece that helps us to identify, catalog the error (assigning a code), generating information and making decisions that we see fit. It is important to be able to handle and capture technical exceptions that are not controlled at run time (Crashes).

The responsibilities are:

  • Identify / Catalog the error / exception and make decisions in function.
  • Redirect views of Error / Generic or others would rely on Flow Control. May prevent the user from continuing with the application.
  • Generates traces of errors (based on the Logs service automatically, local to the device or remote server).
  • Create error objects / exception to return.
  • Types / (It is necessary to create a reduced classification).
  • Technical error known (Technical Exception).
    • Different between Client VS Server (BD, SD, GPS, API, Integration Data Services).
  • Crashes handler or technical error not explicitly controlled / Runtime with report.
  • What to do before a Functional Exception? Eye is not an Error, should not be handled this part of the control of the same

Exceptions

Functional generated from the Facades Customers Integration Services
Data
TYPE: Type
CODEXP: Exception Code
DESCRIPTION: Description (I18N)

Technical generated from services (I / O SD, BDs, GPS, HTTP, …) / Controller / Vista / Controller Data Services
Data
TYPE: Type
CODEXP: Exception Code
DESCRIPTION: Description (I18N)
INNEREXP: Stack Exceptions
Runtime / No explicit runtime unhandled exceptions, will ultimately be technical
Own system

Layer Integration Services Remote Data

Logical Client Adaptation; customer service that performs integration with the back-end Services.

Following the main requisites:

  • Integration layer with Remote Data Services.
  • Invokes the data / resource services exposed by the Web API.
  • This is a client object layer similar to signature and functional exceptions to the one exposed by the Web API.
  • Provide the necessary data structures and operations for the request and return of a service.
  • There are tools to auto-generate these client services, such as Swagger UI Generator.
  • It relies on unSerialize & Serializes Message. Although currently we use REST over HTTP with JSON is to isolate these elements help us to future integrations on new protocols.
  • Implemented custom or using a library (JSON, GSON, kSOAP). Be careful with Performance!.
  • It relies on the Data Services Controller to delegate the sending / receiving message.
  • Abstracts / isolates technical integration features: REST / SOAP protocols, HTTP, TCP, Queues, Streams,  …
  • Return the Functional Exceptions of the service.
  • Return the Run-Time Exceptions generated in the client integration layer.
  • Manage Configuration of necessary parameters related to the service connectivity.
    • REST / SOAP and details needed to achieve END-POINTs (URIs, IP, PORT), as applicable.

Example of Architecture Product

Mobile Architecture Keikis MBaaS

Mobile Architecture Keikis MBaaS

  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
Social media & sharing icons powered by UltimatelySocial