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 choice due to the numerous negative headlines about data protection. With over 2 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, the Facebook API was further restricted.

However, the Facebook API is not suitable for developing an own client anyway. 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 4, 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 entry\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 "Friendly for Facebook" don't manage to keep up with the changes. The result is erroneous representations that worsen the user experience.

For this number of reasons, Facebook dropped out as OSN candidate for the prototype despite the special 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 detailed 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 a 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. In order to use this API you first have to create a \enquote{Twitter App}. After registering you will get a consumer key and access token. These two authentication tokens are required to log in users via their own app and successfully execute requests to the API.

Twitter offers almost the entire range of functions via the API. The lack of functionalities (such as querying Reply to a Tweet or the search results come only from the last days) are not so difficult. A major limitation is the limitation on the number of requests. This is to prevent Twitter being exposed 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 limitation.

Basically, the API can be used via HTTP requests. The data exchanged are available in JSON format. However, 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 greatly simplify the use of the API.