On my work, technology and related stuff....

Archive for January 2017 | Monthly archive page

1 comment

There are many options available to display charts within your [native] iOS apps. You could write one yourself (why?) or use one of the many third party libraries that are available . Check out this GitHub repo for a list of charting libraries in swift/ ObjC.
 
However, if you are interested in using Highcharts within your app, then read on . Highcharts is a popular JS charting engine and you can learn more about it at http://www.highcharts.com.
 
 This  post will demonstrate how you can load a Highcharts based chart into a iOS native app.  We will use the example charts available as part of the Highcharts library. A more interesting and complete example that demonstrates how you can dynamically load chart data is available at https://github.com/rajagp/iOS_Highcharts_Sample.
 

1)   Download the sample xcode app project from http://www.priyaontech.com/wp-content/uploads/2017/01/HighchartDemo.zip.  This is a simple single view application that will load a .html file into a WKWebView.

2)   Download the Highcharts library from http://www.highcharts.com/download

3)   Once downloaded , unzip its contents and examine it. You should see contents list similar to screenshot below

4) Navigate to the “examples” folder

5) Copy the “index.htm” file from any of the examples into your project. Make sure you copy it into your project

6)  Your project should look something like this

7) In your xcode project, open and review the the index.htm file that you just copied over. It contains a JS function that creates a chart  using the Highcharts chart API as defined in http://api.highcharts.com/highcharts/chart. The chart data and options are defined statically. 

8) Now, open the “ChartViewController.swift” file and review it.  This is a simple view controller that manages a WKWebview and loads the index.html into the web view. 

 Look for  the “loadContainerPage” function . This is where the index.htm is loaded.


9) That’s it !  Run the app and you should see the sample chart load …

 The chart data and chart options were statically predefined as part of the JS function. In a real world application, you would probably want to load the chart data and options dynamically.

A complete example that demonstrates how you can dynamically load chart data is available at https://github.com/rajagp/iOS_Highcharts_Sample.

No comments

A software pattern is a template for solving a repeatable problem. Any user facing client app can be broadly composed of three main layers –
·      The Presentation / UI Layer:  Layer that a user interacts with.
·      The Business Logic Layer: Layer that handles the data model and interactions for local/remote databases
·      The Application Logic Layer : The glue between the Presentation and Business Logic Layers.

The Model View Controller (MVC):

 

The MVC is a well-known architectural pattern used for building iOS Apps.  
·      The View , which is generally not passive, corresponds to the  Presentation Layer
·      The Model , corresponds to the  Business Logic Layer
·      The Controller sits between the View and the Model , corresponds to the Application Logic Layer.
However, the controller becomes the catch-all for everything that isn’t exactly a UI control or a data model,  leading to the  “Massive View Controller” issue.
 
Two popular alternatives to the MVC pattern are the MVP and MVVM patterns, both of which are essentially variants of the MVC pattern.
 

The Model View Presenter (MVP):


The MVP defines the following
·      The View , which is generally passive, corresponds to the  Presentation Layer
·      The Model , corresponds to the  Business Logic Layer and is identical to the MVC pattern
·      The Presenter sits between the View and the Model , corresponds to the Application Logic Layer.
A View is typically associated with one Presenter.
 
In iOS, the interaction between the View and Presenter can be implemented using the Delegation Pattern (https://developer.apple.com/library/content/documentation/General/Conceptual/DevPedia-CocoaCore/Delegation.html). The Delegation Pattern allows one object to delegate tasks to another object. In iOS, the pattern is implemented using a Protocol. The Protocol defines the interface that is to be implemented by the delegate.

In the MVP pattern, the View and Presenter are aware of each other. The Presenter holds a reference to the view it is associated with.
 
The PresenterProtocol defines the base set of methods that any Presenter must implement. Applications must extend this Protocol to include application specific methods.
 

 
The PresentingViewProtocol  defines the base set of methods that View must implement. By providing default implementation of the methods in this interface, the conformant view does not have to provide its own implementation. This interface can be extended to define application specific methods.
 

 
 
 

The Model View View Model (MVVM) :

 

 
 
The MVVM defines the following
·      The View , which is generally passive, corresponds to the  Presentation Layer
·      The Model , corresponds to the  Business Logic Layer and is identical to the MVC pattern
·      The View Model sits between the View and the Model , corresponds to the Application Logic Layer.
The key aspect of the MVVM pattern is the binding between the View and the View Model.  In other words, the View is automatically notified of changes to the View Model.

In iOS, this can be accomplished using Key-Value-Observer (KVO) Pattern. In the KVO Pattern (https://developer.apple.com/library/content/documentation/Cocoa/Conceptual/KeyValueObserving/KeyValueObserving.html) , one object is automatically notified of changes to the state of another object. In Objective C, this facility is built into the run-time. However, it’s not as straightforward in Swift. One option would be to add the “dynamic” modifiers to properties that need to be dynamically dispatched. However, this is limiting as objects now need to be of type NSObject.  The alternate is to simulate this behavior by defining a generic type that acts as a wrapper around properties that are observable.
 
 

 
The View can “bind” an appropriate callback to the ViewModel by using the “bind” method on the DynamicType. Every time the property value changes, the callback is automatically invoked.
 

Code and More:

A sample app that showcases the implementation of the MVC, MVP and MVVM pattern is available on GitHub at https://github.com/rajagp/iOS_MVC_MVP_MVVM_SampleApp
 
Slides from a related talk on supporting the MVP and MVVM patterns in iOS apps can be downloaded from iOS_MVP_MVVM_Patterns  .