Subscribe via RSS
Toggle Submenu
  1. Categories
  2. Recent
  3. Tags
View Replies (2)

Resolved Common Application PBLs & PBDs

  1. Advice
0
Votes
Undo
  1. Michael Hartnett
    Michael Hartnett
  2. PowerServer Mobile (Obsolete)
  3. Thursday, 11 April 2019 09:33 AM UTC

Hi All Appeon Experts,

We have been developing Desktop Apps for a significant number of years and have started developing Appeon Mobile Apps to compliment these over the last 2-3 years.  To date our Deskptop and Mobile App codebase have been kept in separate development projects, so there has been duplication of logic.

In one particular Mobile App we have been developing using a DAO and Bean methodology for encapsulating the Data Access Objects and also some of the Business Logic.  Much of this DAO will be common between the Desktop and Mobile developments, so we were hoping to share the DAO and Bean PBL's between the 2 development project (Desktop & Mobile).

Our initial thoughts were to create a standalone set of PBL's to house the common non-visual business logic and include the compiled PBD's (from the standalone project) in our projects, however an initial test this morning indicates that a compiled PBD does not seem to work or deploy as part of our Appeon Mobile deployment.

Prior to now, we have always just selected the PBT for the Mobile Application Deployment configuration, which has meant that the configuration used the selected list of PBL's specified in the PBT.

************Here is the Question bit!!

Would we be better integrating our Mobile PBL's into our Desktop Project and only selecting the required mobile libraries when creating our Mobile Application Deployment Profile.

This would allow us to maintain a single set of PBL's for deploying both types of application (Desktop and Mobile), inherently sharing the DAO and Bean PBL's.  However, the drawback I do see is that our Desktop deployment will grow to include the extra Mobile PBL's.

OR

Using the Mobile App as a Master project for the development of the DAO and Bean PBL's and instead include the compiled PBD only in the Desktop Project.

 

What advice would anybody have on doing this?

Have others had to deal with a similar situation?

Thanks In Advance,

Michael

  1. Deployment
  2. PBD
  3. PBL
  4. PowerBuilder (Appeon)
  5. PowerServer Mobile
RESTClient on Mobile App in 2019
Mobile App was working & suddenly now App abort.
Responses (2)
Kevin Ridley
Kevin Ridley Accepted Answer Pending Moderation
  1. Monday, 15 April 2019 15:56 PM UTC
  2. PowerServer Mobile (Obsolete)
  3. # 1

Why not create a web service layer for all of your common code (using PB2019).  Then you can have it deployed in only 1 place and have your desktop and mobile clients access the same code via web services?

Comment
Armeen Mazda @Appeon
  1. Armeen Mazda @Appeon
  2. Monday, 15 April 2019 16:28 PM UTC
This is definitely the way apps should be architected for a cloud deployment or app with multiple UI technologies (native desktop, web browser, mobile, etc.).
  1. Helpful
There are no comments made yet.
Chris Pollach @Appeon
Chris Pollach @Appeon Accepted Answer Pending Moderation
  1. Thursday, 11 April 2019 19:50 PM UTC
  2. PowerServer Mobile (Obsolete)
  3. # 2

Hi Michael;

     This topic is "near and dear" to my heart from the perspective of my frameworks (EAServer, PocketBuilder, Native PowerBuilder, Web Service, Assembly, Web & Mobile) and trying to tie one code base that supports(ed) all of the above PB environments. Today of course, that common framework code base is for: Native PowerBuilder, Web Service, Assembly, Web & Mobile as the EAS and PKB products are no longer.

     I think that they key thing that I did when rewriting the frameworks in the third major revision (integration phase) was to make everything a "dynamic reference". In other words, there is no hard coded reference to any object that might be optionally used. Also, extensive use of the framework's "go_ac.of_get_client_type( )" method to inform the PowerScript code if the App is instantiated as Native, Web, Mobile, IWA, etc and then subsequent methods to identify the specific O/S, Device, Language, etc of the running application and allow further tailoring of the App at run-time from that information.

     The revised architecture that I came up with allows me to build any type of application with one base-line code, yet only deploy the PBL's and/or PBD's that an application needs depending on how it is to be used (ie: 32 bit vs 64bit) at run-time. This allows an unlimited way an App can be packaged depending on the environment, functionality and features you want to expose - while maintaining a "slim & trim" execution model.

    I gave a presentation at last years Elevate 2018 Conference on the integrated framework and how building Apps the way I do (via my framework's architecture approach) leads to more reusable, faster, more flexible, stable, etc business applications.

Regards ... Chris

 

Comment
There are no comments made yet.
  • Page :
  • 1


There are no replies made for this question yet.
However, you are not allowed to reply to this question.