Reason for having all screens in one eSpace in a mobile application

Reason for having all screens in one eSpace in a mobile application

  

Hi,

In several posts people stated that in a mobile application all screens should be in one eSpace. No one however mentioned the reason for this.

From a maintenance perspective I'd like to split my UI in several eSpaces (like I do in a web application). I've created a sample and it worked. I have a main screen which is the module from the orchestration layer, which calls a screen from another module  as an "External Site". As long as the user providers of both screens are the same no problem arises from an authorization perspective.
The application also works fine, when deployed as an apk on an Android device.

Does anyone know the problems which may arise from splitting a mobile application in several UI eSpaces?

Your help/thoughts are apreciated,

Matthieu de Graaf



Hi,

This is purely for technical reasons (I'm not from the Engineering team so I won't bother trying to explain).

The best practice (especially if you have a large mobile app) is using public blocks:

  • Split your UI over different modules (eg functional/business area), using public blocks.
  • Your main module includes all the screens, but these become "shells" including the referenced blocks and little else.

Matthieu de Graaf wrote:

Hi,

In several posts people stated that in a mobile application all screens should be in one eSpace. No one however mentioned the reason for this.

From a maintenance perspective I'd like to split my UI in several eSpaces (like I do in a web application). I've created a sample and it worked. I have a main screen which is the module from the orchestration layer, which calls a screen from another module  as an "External Site". As long as the user providers of both screens are the same no problem arises from an authorization perspective.
The application also works fine, when deployed as an apk on an Android device.

Does anyone know the problems which may arise from splitting a mobile application in several UI eSpaces?

Your help/thoughts are apreciated,

Matthieu de Graaf



In a project, before the screens are split, but there is performance penalty, so all are put in one module. I think this is performance issue.


regards

 


Hi Paulo,

Thanks for your reply. I had already tested the solution you proposed and that works fine too. I'm still curious though, what the rationale is for this best practice.

Regards,

Matthieu

Pasar Anyar wrote:

Matthieu de Graaf wrote:

Hi,

In several posts people stated that in a mobile application all screens should be in one eSpace. No one however mentioned the reason for this.

From a maintenance perspective I'd like to split my UI in several eSpaces (like I do in a web application). I've created a sample and it worked. I have a main screen which is the module from the orchestration layer, which calls a screen from another module  as an "External Site". As long as the user providers of both screens are the same no problem arises from an authorization perspective.
The application also works fine, when deployed as an apk on an Android device.

Does anyone know the problems which may arise from splitting a mobile application in several UI eSpaces?

Your help/thoughts are apreciated,

Matthieu de Graaf



In a project, before the screens are split, but there is performance penalty, so all are put in one module. I think this is performance issue.


regards

 


This could be an issue. I noticed a perfomance difference between the 2 solutions (calling screens from another eSpace and calling screens with webblocks from another eSpace).

regards,

Matthieu


That's the trade off: monolithic is faster than modular, but modular is more maintainable.

The reason, I think, is exactly in the way Mobile is different from Web.

Mobile is a "One Page" application.

Everything is in a single page, and the different "views" are created on the fly using JavaScript.
I think (not sure) if you call an "external page" (a page in another module), you have to "reconstruct" everything again, than the perfomance penalty, because it is (again, I think), a different page.

Now imagine the impact of you going forth and back to different pages in different modules... 

Cheers.

Hi guys,

Curious about this. What kind of performance difference have you found using blocks? Slower transitions between screens? Slower data loading? Slower splash screen?