Final fixs

sections/intro.tex

@@ -12,11 +12,11 @@ \section{Introduction}
 	\item Galleries that are containers of images grouped by both partners;
 	\item Infos of Chat, Gallery and To-Do list, accessible from the menu of each, show the date of creation and, optional, the photo cover. Only for the galleries there is the optional placement, selectable through a Location Picker UI;
 	\item To-Do lists managed by both, for any kind of topic, like grocery list, movies to watch, trips to plan;
-	\item Geogift, are messages like a post-it, pictures or emoticons, geolocalized. The partner won't know about the gift until he/she will come exactly on that physical place e.g., a specific street address or store in the city. This thanks to the geofence, a virtual perimeter set on a real geographic area that should be monitored by a service. The simplest geofence to be created needs of center position, explicated by latitude and longitude, and the radius of circle area, setted in meters. When the boundary of geofence is crossed, the user is alerted by a push notification;
+	\item Geogift, are messages like a post-it, pictures or emoticons, geolocalized. The partner won't know about the gift until he/she will come exactly on that physical place e.g., a specific street address or store in the city. This thanks to the geofence, a virtual perimeter set on a real geographic area that should be monitored by a service. The simplest geofence to be created needs of center position, explicated by latitude and longitude, and the radius of circle area, setted in meters. When the boundary of geofence is crossed, the user is alerted by a push notification. This feature need to be enable manually in the settings activity;
 	\item Maps to see, as a markers, the Geogifts sent or discovered and the galleries that have a photo cover and a location specified;
 	\item Calendar where to easily visualize the own saved message (bookmarked).
 \end{itemize}
 
-For that we don't put so much effort into usability and accessibility of an Android app, for example our app lacks of a initial tutorial or a welcome page where the user is instructed with what he could do with Sweetie furthermore some important feature: image compression and a complete notifications service were not implemented, we preferred to invest the last works time to test our application in order to fix underhand bugs.
+We don't put so much effort into usability and accessibility that an Android app needed, for example our app lacks of a initial tutorial or a welcome page where the user is instructed with what he could do with Sweetie furthermore some important feature: image compression and a complete notifications service were not implemented, we preferred to invest the last works time to test our application in order to fix underhand bugs. The application is built and tested for Android Lollipop 5.1, Marshmallow 6.0 and Nougat 7.0, these version are almost the 70\% of the market and we think that when Sweetie will be release the percentage will increase\footnote{Data collected during a 7-day period ending on September 11, 2017 \url{https://developer.android.com/about/dashboards/index.html}}. 
 
 The paper is organized as follows: section~\ref{sec:app-domain} describes how we analysis the domain of Sweetie and what are the entities that we manipulated for create the core business logic of the application. Section~\ref{sec:app-architecture} expose the app architecture, with merits and defects, and why we have done some choices. Section~\ref{sec:ext_api} show the list of external library that are used in order to support some feature of Sweetie. In section~\ref{sec:issues} we group all the major problematics that requires more effort and we explain the solution or workaround that we implements with some accepted trade-offs. Section~\ref{sec:futureworks}  show some important feature that our app has not yet implemented. Finally the section ~\ref{sec:conclusion} describes our considerations on the development of this project.

sections/issues.tex

@@ -18,7 +18,7 @@ \subsection{Images}
 
 \subsection{Chat keyboard}
 As Hackborn said \cite{Dianne_Hackborn_keyboard} the Android SDK doesn't expected that a developer needs to know when soft keyboard is open, unfortunately this is not the case. In order to create a custom emoticons keyboard interchangeable with soft keyboard we need this information. So we built a workaround and implement a listener that it is triggered when the GlobalLayout object change height, from that we calculate the height of the soft keyboard. In the layout we put a FrameLayout placeholder that use this calculated height for push up the chat items and give space to the custom emoticons keyboard and soft keyboard, in this way the switch between keyboards is pleasant. 
-We have not be able to resolve a bug in the first opening of keyboard, that is the moment where app registers the height of soft keyboard, in this case the window resize is not executed correctly: the toolbar disappears as long as the keyboard remains open.
+We have not be able to resolve a bug in the first opening of keyboard, that is the moment where app registers the height of soft keyboard, in this case the window resize is not executed correctly: the toolbar disappears as long as the keyboard remains open. The same problem appears to GeogiftMakerActivity.
 
 \subsection{Offline persistence data}
 We don't have the offline persistence data feature into the app. Although the Firebase API gives to developers the possibility to caching the data from real time database\footnote{\url{https://firebase.google.com/docs/database/android/offline-capabilities}} we didn't enable it in order to avoid concurrency problems which extend over a long time, between two paired users. This obviously goes again the usability, the app in fact has always to download all data from network and if user's device is offline, the user can't modify existing data but only create new data. So the issue remains open and certainly will be a high priority task in the future development.