Applications Installer

From Tizen Wiki
Jump to: navigation, search

This document is still in draft mode. Some content may change.


Needs

The needs to create a package as application-installer comes from the existence of software similarities between native installers and web app installer , so we need to standardizing the implementation of them.

The package app_installer provides a base that would be use to develop other package type installer.

git repository : review.tizen.org:platform/appfw/app-installers

gitweb : https://review.tizen.org/gerrit/gitweb?p=platform%2Fappfw%2Fapp-installers.git;a=shortlog;h=refs%2Fheads%2Ftizen

Overview

Indeed all installers do same step in Tizen

  • Uncompress archive in temporary directory
  • Check privileges needed by the applications
  • Apply security rules
  • Copy files in final directory
  • Register the application through the application Framework

Diagram

As described by the following diagram.

Each step respresented in blue are common to all installer backend. They are independant of the package type of the application.

Each green step are package type specific.

For example in the case of widget. Green steps are :

  • Unpack step : it could be conciderate specific (eg wgt is zip archive).
  • Parser Step : this step consist to retreive information from config.xml)
  • Symbolic link step : this specific to widget, it permits to execute the webapp by using a simple symbolic link that points the WRT launcher.


Application Installer State Machine.jpg


Implementation concept

As all installer has a simmilar logic independent of the type of the application installed. We can introduce a new framework that harmonize the way to implement an installer


Installer Workflow.jpg

The implementation can be easily done by define a set of function corresponding to the set of step or action for an installer.

By this way, we can implement all installer corresponding to all kind of app by implement a "plug in".


/*
  A step is made of 3 functions (that can be defined or NULL)
  and one data pointer.

  The functions are:
    - process  process the installation step
    - undo     undo the installation step after failure
    - clean    remove temporary data of the step after success

  These functions all have the same signature: they accept
  a pointer to something and they return an integer value stating
  the execution issue. 

  At the execution time, this functions if not NULL, will receive
  the 'data' pointer as first argument.

  The returned code of 0 indicates a succeful execution.
  Otherwise, the returned code should be set to -1 with errno set
  to some meaningful value.
*/
namespace common_installer {

class Step {
public:
 enum class Status {
   INVALID_VALUE = -2,     /**< Invalid argument */
   ERROR = -1,             /**< General error */
   OK = 0                  /**< General success */
 };

 explicit Step(ContextInstaller* context) : context_(context) { }
 virtual ~Step() { }

 virtual Step::Status process() = 0;
 virtual Step::Status undo() = 0;
 virtual Step::Status clean() = 0;

protected:
 ContextInstaller* context_;
};
 
}  // namespace common_installer
 
 


namespace common_installer {

class AppInstaller {
public:
 explicit AppInstaller(pkgmgr_installer *pi);
 virtual ~AppInstaller();

 // Adds new step to installer by specified type
 // Type of template parameter is used to create requested step class instance.
 // Context of installer is passed to step in this method
 // and is not being exposed outside installer.
 template<class StepT>
 void AddStep() {
   steps_.push_back(std::unique_ptr<Step>(new StepT(context_.get())));
 }

 int Run();

protected:
 std::unique_ptr<ContextInstaller> context_;

private:
 AppInstaller(const AppInstaller& /*other*/) = delete;
 AppInstaller& operator=(const AppInstaller& /*other*/) = delete;

 std::list<std::unique_ptr<Step>> steps_;
};
 
}  // namespace common_installer