AddInWork

How does Isogeo ArcGis Pro Add-In work ?

Modularity

• Isogeo ArcGis Pro Add-In is composed of one main UserControl : Dockpane
  • This dockpane own two userControls as TabControls : Search and Settings
    • They are themselves composed of multiples controls for each section of the visual
• It's important to understand that, basically, each controls can't access to elements that aren't in subElements
  • For example : Result items from search tab can't access to search button from search tab
  • Search tab can't access data from Settings tab and vice versa
• Reason is simple : Easy to maintain
  • You don't have to be worried if this element modify properties of this element in wrong case, interdependences etc. : it's not possible. Simple !
• Each controls is composed of one View (visual) and one ViewModel (logic), and that all, they have to work with that.
  • Other benefits is that it's easier to recode an element of Add-In, because there're no hard dependencies with the rest of the software.
  • If you remove a part of the software (view/viewModel), it will continue to work, Isogeo Add-In will just have less functionalities.

"Ok, so Isogeo ArcGis Pro Add-In is modular. But How can it work ? If I click on Search button, I want results items to be generated"

-> Utilization of mediator and singleton patterns

Mediator and Singleton patterns

Singleton Pattern (Variables class)

This element comes from Isogeo ArcMap Add-In that I modified a lot. (Goal in the future should be to remove the last remaining variable of this class, and then delete this class).
Necessary to understand singleton to continue : definition of Singleton

History

• Originally, inside Isogeo ArcMap Add-In (ancestor of Isogeo ArcGis Pro Addin), majority of components/logics were referenced inside Variables class
• All elements could access to all elements from Variables instance (Singleton), do anything and everything
• On the surface, seemed like a good idea :
  • Easy to develop : if you need something, you just have to take it
  • Example : I'm inside Network class (RestFunctions class), I need an offset to use for API request -> I will take the current page of Add-In
    • I can also set the current page after obtaining API response ! Why not ? Everything is possible.
• In reality :
  • There're lot of interdependences.
  • Not possible to edit an element without verifying that it's not used by another elements
    • modifications can easily break the program
    • Because there a lot of interdependences, sometimes, program can crash just because you change order of function calls that not seems to be related (kind of spaghetti code)

At early development of Isogeo ArcGis Pro Add-In, variables class, the singleton, was the same as ArcMap.
I've tried to make as few changes as possible to adapt ArcMap Add-In to ArcGis Pro Add-In in logic/code/etc.
1 month after beginning of freelance development, Isogeo ArcGis Pro Add-In worked same as ArcMap : same visual, same functionalities, same performance : almost identical.
Problems occurred when I tried to make improvements.

• After long attempts, I took decision to remake a lot of elements inside architecture, including the singleton variables.

Now

• Singleton Variables still exists. You can find variables.cs inside ArcGis Pro Addin's code
• However, it is less important in the software than before
  • it no longer has a predominant place, but still important to delete it in the future commit(s).

"Ok, so Isogeo ArcGis Pro Add-In have no more a predominant singleton. How did the software replace its use ? If I click on Search button, I want results items to be generated"

-> Mediator pattern

Mediator pattern (Mediator class)

Necessary to understand Mediator pattern to continue : explanation about Mediator Pattern

• There're multiples solutions to solve what we want to do here, I chose to use Mediator pattern here

  • Reasons :
    • Easy to implement : No need a lot of elements and there're a lot of explanations about it on internet
    • Easy to understand : there're a lot of explanations about it on internet

• Everything is not perfect about mediator pattern, you can also encounter problems with it, but in your case, it suit very well

• So, with mediator pattern, it's possible for an object to Notify an action, with an argument.

  • Objects that Register (subscribe) to this notification will receive a callback
    • In this callback, function's argument will be the argument given in Notify method
  • Objects can Unregister (unsubscribe) its callback, and so, no more be notified

• By doing this, it's possible to communicate data and actions between controls/network class/etc. without have dependencies/interdependencies between them :

  • If you remove an object, and so, also a subscriber, it's not a problem, program will continue to work, notifications will continue to be send to other subscribers, it will just remove a functionality from the software.

Current limitations :

• Current mediator pattern implemention inside Isogeo ArcGis Pro is basic
• You can't have two callbacks with the same function name
  • If you do two callbacks with same function name, only the first subscriber will be called (also, two instances of an object couldn't subscribed at same time to a same notification)
• you have to cast object argument (object type)
  • can be better to improve this
• Don't know what you receive in the callback (because sender can decide to send a string and not an integer for example, no "contracts")

-> It's basic but do the job and is easy to understand (better than previous singleton pattern from ArcMap).

PS : current Mediator implementation is also based on a singleton ("Mediator"), but with another operation than variables class. However, could be interesting to make it not a singleton but a simple class like "NetworkManager" or "MapManager" or "ConfigurationManager".

MVVM pattern

• MVVM Pattern : Definition
• MVVM pattern is a novelty inside Isogeo ArcGis Pro Add-In compared to Isogeo ArcMap Add-In.
  • A bit complicate to do it in the beginning with the old architecture of ArcMap Add-In
• By utilization of this pattern, Isogeo ArcGis Pro Add-In is more up-to-date with current practices
• Easier to develop : you can remake/interchange visuals without have to change logics
• Better performance
  • For example : if I switch search to settings tab Controls, then come back to search tab, I don't have to regenerate all executions. Because modelViews are already loaded, and keep data. Visuals will be generate based of theses data by binding (quicker)
    • If it wasn't MVVM, it would be necessary to remake a research to Isogeo API, load data, refresh visuals, etc.
      • so more latencies, freeze, etc.