Best way to convert a vision mobile app to perspective

[compuzak]

We just purchased the perspective module after upgrading to 8.1. We are looking for the best resources for learning how to convert our vision mobile apps to the perspective platform. What are your recommendations to streamline the learning and the conversion?

[dkhayes117]

The manual has really good information on getting started:
Perspective - Ignition User Manual 8.1 - Ignition Documentation (inductiveautomation.com)
Plus, you can watch free videos from inductive university:
Building in Perspective Course at Inductive University

I personally would start out understanding the design hierarchy, ie sessions, pages, views, containers. Learn how to utilize different containers, such as flex, to adapt to your screen sizes, then move to components and bindings which are very similar to Vision. After that you'll want to look into message handlers, and styles, and CSS.

[Steve_Laubach]

I agree with with was already said.

If you're planning to support both mobile along with tablet and other larger resolutions I would recommend learning how to use breakpoint containers to change what you display based on the device that's interfacing with your screen.

[lrose]

A few links (there are other links posted in these which are also very applicable):

How to learn perspective the right way?

Hi I am learning perspective trying to be “project ready” (which might arrive soon). I covered perspective section of the inductive university and also elective study (Building in perspective which was excellent). Just wonder what would be the best idea to do next: 1 I have demo VM which i might start analysing - is there any additional documentation related to the demo VM? or is the project self explanatory 2 i consider reviewing all perspective library objects to have good gist what each…

Building for Performance

In this example, #3 is the most performant, though it could be argued that the performance gain in this instance would be negligible. Anytime you add an additional processing step you add latency. In general for the best performance I follow these guidelines: If you can achieve what you want with a binding, use a binding. Always use the binding type that is the most direct. (e.g. if all you need is a binding to a property use a property binding, not an expression binding.) Given the choice b…

IMHO, the biggest hurdles to wrapping your head around perspective (in no particular order) are:

1. Layout management (e.g. when to use which kind of container)
2. Styles are really, really powerful use them!
3. Embedded views are great but use them sparingly.
4. EVERYTHING executes in the gateway. EVERY-THING!! So if it doesn't say available in gateway or perspective scope, don't even try it.
5. The script console will pretend to be your friend. The script console executes in designer scope which is a variant of Vision Client scope, see No. 4 for why this is important.
6. Message Handlers are your real friends. You should have at least one that is set up to function for testing. This will allow you to use your old friend the script console to test your scripts in Gateway scope, again see No. 4 for why that is important.
7. Transforms are cool, but they're also slow* so if you can do something without them you really should.
8. Expression Structures are a amazing, don't avoid them you'll be surprised how often they're the answer you were looking for.
9. Test in the designer and a browser. If it doesn't work in the designer then there is a good chance it doesn't work in a browser, if it works in the designer, it might not work as expected in the browser (especially if you're not using some chromium based browser).
10. Browser security will block your efforts. Think about everything from that point of view, things you could do rather simply in vision (communicate over a clients com port, manipulate files on the clients hard drive, etc...) are unavailable, and there isn't a whole lot that IA can do about it.

You should know the syntax for:

• CSS
• JSON
• Jython (Note: not the same as Python)

Good Luck! The paradigm shift is real.

* Transforms are slow relative to pure bindings. Different types of transforms have different performance factors, you should be aware of that if speed is a concern.

[compuzak]

Thank you everyone for the detailed advice. I finally got some time to move back to this project and really appreciate you all steering me in the right direction.

[nminchin]

@lrose

Embedded views are great but use them sparingly.

Moreso, I would say avoid nested layers of embedded views. Embedded views without nesting are perfectly fine and quite performant. It's when you start trying to nest them that they start giving the operator a chance to go grab a coffee. Or two..
Otherwise though, really good points!

I'll add:

11. CSS themes go hand-in-hand with Perspective Styles. I would recommend creating your own theme files: a common theme which imports the light theme, and defines all of your never-changing colours/borders/etc. like device state colours, alarm priority/state colours, etc., and then a light and dark (if you want to be cool) that import the common theme to swap out the colours that should change with the theme. More info in the themes directory under the Ig install path ../data/modules/...perspective.../themes
12. Perspective Styles naming and structuring is hard! When you think you've got it right, you'll find a new use-case that doesn't conform...
13. I recommend avoiding referencing CSS variables where you can in Perspective components, and only referencing them in PStyles, since CSS variables are not selectable and thus make picking them more difficult.
14. Font sizing is surprisingly difficult to get right for display on different screen sizes. You can utilise PStyles to define your font sizes that make use of the orientation media query to specify different sizes for the two orientations (landscape/portrait).
15. CSS property style.gap for flex components is a godsend to put gaps between your components. It's also important to understand margin, padding, and border (outline is also useful)!
16. Grouping components in Perspective coordinate containers is often more effort than it's worth It's a far stretch from the benefits they provide in Vision.
17. Message Handlers can be used to send data/payloads to other components which can then use a script to do something with it. Very useful.
18. "Template" Views can have drop config added to act in a similar (but far superior) fashion to Vision's infamous "UDTType" parameter data type. You can attach UDT types to a View and configure it to copy the path to the UDT instance into a particular param when you drag a UDT instance of that type onto the screen.
19. Know when to use Coordinate containers and when to use Flex containers. These are going to be your main two containers used to develop your projects. In general, if you're not displaying a p&id, then chances are you should be using a flex container View.
20. I avoid using magic map transforms for common things, for example a map transform that returns the style class to set the colour of a device symbol to, to show its state based on a tag binding. I would recommend using a tag dataset to store these maps and then use the lookup function to lookup the value of your device tag within the tag dataset, and return the associated style class that way. Then you have your style class mappings defined in a single central location, rather than having magic mappings all over the place with no way to change them easily.