3 Replies Latest reply on May 8, 2014 1:37 PM by Jon Tara

    Reusing a module in two different apps.

    manohar nagaiah

      Hi,

          1. I have a rhomobile module/model, say for example Profile(add,delete,view,update and many other actions) and I want to reuse the Profile module in two different rhomobile applications Application1 and Application2. How do I do it?

           2.Is it possible to call a controller of Application1 from Application2? if yes, how do we do it?

        • Re: Reusing a module in two different apps.
          Kutir Mobility

          Hi Manohar,

          To my knowledge you cannot re-use it.

          The other option may be to build a gem out of it and have it used for different projects.

           

          Visnupriya R

          Kutir Mobility

          1 of 1 people found this helpful
            • Re: Reusing a module in two different apps.
              manohar nagaiah

              Hi Visnupriya,

                                   Thanks for the reply. I think making a gem out of it and reusing it in various rhodes app will not be going to make life any easier. We have to copy paste the lib directory from gem folder into rhodes framework (Or am I missing something here?). It is as good as copying model folders from one project to another

            • Re: Reusing a module in two different apps.
              Jon Tara

              On almost all mobile OSs, each application runs in it's own sandbox. There is no ability to access any part of another application. There is no opportunity to share code between applications.

               

              Rhodes does not support Gems. You could write a Rhodes Extension, though.

               

              This issue is more properly addressed using your version control software (for example, you could incorporate it as a Git submodule), or your pre-build system (if you have one).

               

              We have 7 different apps that share a great deal of code. I created a pre-build system using rake (we call the rake script "prepare") some .yml files, mustache, and a set of conventions for overlaying of files and directories. It's similar to an approach often used (but at run time, not as pre-build) in Rails back-ends.

               

              The common code is in a directory called "framework", and then there's a directory for each of the 7 apps. When you run the "prepare" script, you tell it which application you want to build. It copies files from "framework" and the specific application directory into a "build" directory for the specific application, following the "override rules". (e.g. files found in the  application-specific directories are substituted for framework files if present.) There can also be substitution of text using values from the .yml files and {{mustache}} variables in the source code.

               

              We have quite a number of models that are common to all of the apps. Some apps have additional models. Some apps have models that act differently than the framework models. In many cases we use Ruby mixins to provide functionality to models or controllers, and sometimes the applications override the framework mixins.

               

              Of course, none of this has anything to do specifically with Rhodes. It's a common need for anybody producing multiple applications that derive from common code. Using this approach, you don't need any specific support in your framework, as it's all done before you ever build the application.

               

              Even though it copies and modifies hundreds of files, the "prepare" process only takes a few seconds, so it is a trivial addition to build time.

               

              Everything is in a single Git repo. Previously, we'd been managing a separate repo for each app, and it was getting quite unwieldy to keep them in sync. We'd not need to change a particular application for several months, and then we'd need to bring it up to date, and it might then take days to weeks to resolve all the differences and bring in the new features. Now, every app is always up-to-date with the core functionality in the framework.

               

              It is a rather complex system, and there are literally hundreds of differences between the 7 different apps, but has evolved over time and works well. In many cases, we don't change code at all but just values in .yml files. (e.g. most titlesQuite a bit more than 50% of our code is in the common framework. It's really contributed to the stability of the apps.