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

When selecting a suitable OSN for the development of a hybrid client, Facebook was the obvious first choice due to the numerous negative headlines about data protection. With over two billion users per month, it is currently the most widely used social network in the world. 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. 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. As a result of this scandal, there were further restrictions to the Facebook API.

However, the Facebook API is not suitable for developing a new client. The functionalities offered by the 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 make a like for a post through this 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\cite{facebook2017release} that the code changes every few hours. Therefore it is almost impossible to adjust the crawler fast enough and roll out the adjusted 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 users.

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

In the end, Twitter was chosen for the prototype. With 336 million active users per month, it is one of the largest social networks. It is particularly well suited for the development of a hybrid client for two reasons: on the one hand, it has a comprehensive API that provides almost full functionality free of charge, and on the other hand, compared to Facebook, it offers only a few simple functions. These are the ideal prerequisites for the first proof of concept.

Twitter offers different APIs for developers that serve different purposes. The current APIs are:
\begin{itemize}
	\item \textbf{Standard API}: the free and public API offering basic query functionality and foundational access to Twitter data.
	\item \textbf{Premium API}: introduced in November 2017 to close the gap between Standard and Entrprise API. Improvements over the Standard 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 API start at 149\$/month.
	\item \textbf{Enterprise API}: tailored packages with annual contracts for those who depend on Twitter data.
	\item \textbf{Ads API}: this 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 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 API is the right one. For using the API, first, 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 API.

Twitter offers almost the entire range of functions via the 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 request restrictions.

The API can be accessed using HTTP requests. The data exchanged are in JSON format. Furthermore, there are also various libraries (e.g., Twit\footnote{https://github.com/ttezel/twit}), some of which 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 API.