HOSN-app/thesis/content/05-proof-of-concept/osn-selection.tex

To select a suitable \ac{OSN} for the development of a hybrid client, three factors were considered:

\begin{enumerate}
	\item the significance of the \ac{OSN},
	\item the adequacy of data protection,
	\item the \ac{API} functionality.
\end{enumerate}

Facebook was the obvious first choice due to the numerous negative headlines about data protection. With over 2.3 billion users per month (average Q4 2018), it is currently the most widely used social network in the world \cite{facebook2019reportq4}. In the recent past, it has often been criticized for its handling of its users' data. In particular, the scandal surrounding the data analysis company Cambridge Analytica, which had access to the data of up to 87 million users, hit Facebook hard \cite{facebook2018cambridge-analytica,facebook2018api-restriction}. As a result, CEO Mark Zuckerberg had to face the US Congress and the EU Parliament in question rounds and did not leave a good impression by avoiding many questions \cite{facebook2018us-congress,facebook2018eu-parliament}. As a result of this scandal, there were further restrictions to the Facebook \ac{API} \cite{facebook2018api-restriction}.

However, the Facebook \ac{API} is not suitable for developing a new client. The functionalities provided by the \ac{API} offer the possibility to develop an app that can be used within Facebook, for example for a game. So, it is not possible to give a \enquote{Like} for a post through this \ac{API}, which is part of the core functionality of a Facebook client. As discussed in Chapter \ref{ch:concept}, it is possible to access the data through crawling. However, the constant and rapid development would make this an arduous undertaking. Facebook writes in a blog post that the code changes every few hours \cite{facebook2017release}. Therefore it is almost impossible to adjust the crawler fast enough and roll out the updated code.

Even the mixed version of displaying and manipulating the mobile website in a WebView in a container app does not seem to be an option due to the short release cycles and frequent changes. Apps like \enquote{Friendly for Facebook} do not manage to keep up with the changes as reported in various user ratings on the Google Play Store. The false representations and bugs worsen the user experience and result in the frustration of the users.

For this number of reasons, Facebook dropped out as an \ac{OSN} candidate for the prototype despite the particular interest. As a further candidate, the \ac{OSN} Google Plus was dropped, as Google announced in October 2018 that it would discontinue its \ac{OSN} \cite{google-plus2018shutdown}.

Finally, Twitter was chosen for the prototype. With 321 million active users per month (average Q4 2018), it is one of the largest social networks \cite{twitter2019reportq4}. It is particularly well suited for the development of a hybrid client for two reasons: first, it has a comprehensive \ac{API} that provides almost full functionality free of charge, and second, compared to Facebook, it offers only a few simple functions. These are the ideal prerequisites for the first proof of concept.

Twitter offers several \acp{API} for developers that serve different purposes. The current \acp{API} are \cite{twitterXXXXdev-getting-started}:
\begin{itemize}
	\item \textbf{Standard \ac{API}}: the free and public \ac{API} offering basic query functionality and foundational access to Twitter data.
	\item \textbf{Premium \ac{API}}: introduced in November 2017 to close the gap between Standard and Entrprise \ac{API}. Improvements over the Standard \ac{API}: \enquote{more Tweets per request, higher rate limits, a counts endpoint that returns time-series counts of Tweets, more complex queries and metadata enrichments, such as expanded URLs and improved profile geo information}\footnote{https://blog.twitter.com/developer/en\_us/topics/tools/2017/introducing-twitter-premium-apis.html}. Prices to use this \ac{API} start at 149\$/month.
	\item \textbf{Enterprise \ac{API}}: tailored packages with annual contracts for those who depend on Twitter data.
	\item \textbf{Ads \ac{API}}: this \ac{API} is only of interest for creating and managing ad campaigns.
	%\item \textbf{Twitter for websites}: this is more a suite of tools than an \ac{API}. It's free to use and enables people to embed tweets and tweet buttons on their website.
\end{itemize}

In the case of the hybrid client, the standard \ac{API} can be used. In this process, the registration of a \enquote{Twitter App} is necessary to receive a consumer key and access token. These two authentication tokens are required to log in users via the hybrid app and successfully communicate with the \ac{API}.

Twitter offers almost the entire range of functions via the \ac{API}. The missing functionality (e.g., the targeted retrieval of replies to a tweet) is not so critical for building a client app. A significant limitation is a restriction on the number of requests. Twitter argues that this restriction is necessary to avoid the exposure of the system to too much load. It also aims to prevent bots from abusing Twitter. The exact limits can be found on a help page\footnote{https://developer.twitter.com/en/docs/basics/rate-limits}. In the app stores of Google and Apple, there are a number of alternative Twitter clients (Twitterific\footnote{https://itunes.apple.com/de/app/twitterrific-5-for-twitter/id580311103?mt=8}, Talon for Twitter\footnote{https://play.google.com/store/apps/details?id=com.klinker.android.twitter\_l}, Fenix 2 for Twitter\footnote{https://play.google.com/store/apps/details?id=it.mvilla.android.fenix2}), which are also subject to these restrictions in terms of functionality and requests.

The \ac{API} can be accessed using \ac{HTTP} requests. The data exchanged are in \ac{JSON} format. Furthermore, there are also various libraries (e.g., Twit\footnote{https://github.com/ttezel/twit}), some even are developed directly by Twitter (see Twitter Kit for Android\footnote{https://github.com/twitter/twitter-kit-android} or iOS\footnote{https://github.com/twitter/twitter-kit-ios}) and simplify the use of the \ac{API}.