<commit_before>%!TEX root = ../report.tex

%
% Related work
%

\section{Related Work}
\label{sec:related_work}
In this section we describe related work about
development and deployment of mobile native and web 
context-aware applications and we discuss the 
limitations and the main benefits of each one of
the following solutions, providing, at the same time,
motivation to develop our framework.
\begin{description}
  \item[Dynamic frameworks for Mobile web DTN applications:]
  There are multiple frameworks to deploy localized
  mobile native or web apps, even if the user is using an
  unstable Internet connection. One example of this
  kind of frameworks is the one
  described in \cite{Sankaran2014}.
  This framework supports the deployment of localized 
  native and
  web apps in Delay Tolerant Networks (DTNs).
  A DTN is an approach to computer networks that 
  addresses issues about the lack of continuous network
  connectivity. Mobile networks are good examples of DTNs. 
  It also has an embedded web server 
  and has an implementation that runs on a PC, which allow
  developers to test the applications before deploying
  to production environment.
  However, the owner of a given point of interest does not
  have access to any interface to install apps that will
  belong to that point. Also, it does not support, in the
  same app, multiple points of interest with different
  meanings and different behavior in each one of them. 
  \item[Dynamix:]
  Dynamix \cite{Carlson2012} is a framework to develop
  mobile native and web apps that allow them to receive
  context information, for instance, position and device's
  orientation. This framework has plug-ins that get
  one or more sensor's raw data and turn that into event
  objects, that contain more high-level information.
  This framework supports many kinds of context information
  and it is possible to develop more plug-ins to allow the
  apps to events that are not
  already supported. It is similar to the previous
  framework but is more focused on delivering context
  information to apps instead of deploying them.
  To achieve our goal, our framework could be just a
  plug-in for Dynamix. The plug-in would
  need to get the beacon's raw data and
  turn that into a more high-level information 
  using a back-end. In this framework,
  the user needs to install an app, that manages the service
  that runs in background, and needs to define some
  security policies. This could mean a big overhead since
  we are more focused on developing proximity-based
  web applications, that don't require such complex security
  policies. In our framework, the user would only need to
  install one app, let it run in background and turn on
  bluetooth. Also, this does not offer a complete solution
  since the owner of one or more points of interest
  has no way of installing new apps on them.
  \item[Ionic:] Ionic is a framework to develop mobile apps
  using web technologies, such as HTML and JavaScript. The
  same code is deployed, as a native app, to multiple mobile
  platforms. Each app is nothing more than an embedded browser
  that runs a local web application. 
  Using some plug-ins, the apps can access some
  device's functionalities, such as bluetooth. However,
  the developer has to configure a back-end and write the
  code that will interact with it. Also, since the apps are
  installed like native ones, we still have the problem of
  having one app for each smart place.
\end{description}
To finish this section, each related work has it's own
advantages and it's limitations. Our framework tries 
to offer a complete solution that solves all
these limitations, in such a way that, developers don't
need to think about the technology behind proximity-based
apps, but only about the application logic and the meaning
of each point of interest.<commit_msg>Changed layout of related work<commit_after>%!TEX root = ../report.tex

%
% Related work
%

\section{Related Work}
\label{sec:related_work}
In this section we describe related work about
development and deployment of mobile native and web 
context-aware applications and we discuss the 
limitations and the main benefits of each one of
the following solutions, providing, at the same time,
motivation to develop our framework.\\ \\
\textbf{Dynamic frameworks for Mobile web DTN applications:}
There are multiple frameworks to deploy localized
mobile native or web apps, even if the user is using an
unstable Internet connection. One example of this
kind of frameworks is the one
described in \cite{Sankaran2014}.
This framework supports the deployment of localized 
native and
web apps in Delay Tolerant Networks (DTNs).
A DTN is an approach to computer networks that 
addresses issues about the lack of continuous network
connectivity. Mobile networks are good examples of DTNs. 
It also has an embedded web server 
and has an implementation that runs on a PC, which allow
developers to test the applications before deploying
to production environment.
However, the owner of a given point of interest does not
have access to any interface to install apps that will
belong to that point. Also, it does not support, in the
same app, multiple points of interest with different
meanings and different behavior in each one of them. \\
\textbf{Dynamix:}
Dynamix \cite{Carlson2012} is a framework to develop
mobile native and web apps that allow them to receive
context information, for instance, position and device's
orientation. This framework has plug-ins that get
one or more sensor's raw data and turn that into event
objects, that contain more high-level information.
This framework supports many kinds of context information
and it is possible to develop more plug-ins to allow the
apps to events that are not
already supported. It is similar to the previous
framework but is more focused on delivering context
information to apps instead of deploying them.
To achieve our goal, our framework could be just a
plug-in for Dynamix. The plug-in would
need to get the beacon's raw data and
turn that into a more high-level information 
using a back-end. In this framework,
the user needs to install an app, that manages the service
that runs in background, and needs to define some
security policies. This could mean a big overhead since
we are more focused on developing proximity-based
web applications, that don't require such complex security
policies. In our framework, the user would only need to
install one app, let it run in background and turn on
bluetooth. Also, this does not offer a complete solution
since the owner of one or more points of interest
has no way of installing new apps on them. \\
\textbf{Ionic:} Ionic is a framework to develop mobile apps
using web technologies, such as HTML and JavaScript. The
same code is deployed, as a native app, to multiple mobile
platforms. Each app is nothing more than an embedded browser
that runs a local web application. 
Using some plug-ins, the apps can access some
device's functionalities, such as bluetooth. However,
the developer has to configure a back-end and write the
code that will interact with it. Also, since the apps are
installed like native ones, we still have the problem of
having one app for each smart place.
To finish this section, each related work has it's own
advantages and it's limitations. Our framework tries 
to offer a complete solution that solves all
these limitations, in such a way that, developers don't
need to think about the technology behind proximity-based
apps, but only about the application logic and the meaning
of each point of interest.
{'fraction_non_alphanumeric': 0.03311867525298988, 'fraction_numerical': 0.0021027730319358655, 'mean_word_length': 4.230240549828179, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '4411366', 'n_tokens_mistral': 1866, 'n_tokens_neox': 1788, 'n_words': 1191}