This document is the final report for the term project for CSCI-578. The project is not running anywhere and must be download and compiled by the user. This is a proof of concept project and is not intended to be a final project.
The following section does not contain a comprehensive description of all the modifications to the architecture. Many of the API methods were modified slightly to account for different Android requirements. To view the original architecture, click the link below.
Over the course of the project, the architecture of TrojaNow evolved. This is a result of the mapping problem between the original architecture and the Android SDK. Modifications were made so that mapping would be easier and more intuitive.
Due to the time-constraints on the project, not all of the original functionality was able to be implemented. Below is a list of the components their current implmentations.
Login functionality was originally expected to be provided using OAuth 2.0 through Google+ and Facebook logins. Unfortunately, this functionality proved to be to time-consuming to be implemented for the project. As a result users are able to authenticate with their own username and password. Transaction-Level authentication takes place through the use of token-based authentication.
Anonymous posts were originally slated to be marked as anonymous as part of the post model. Instead, anonymous posts are now assigned to a special user. This allows posts to be anonymous even from the server.
Android screens are dividided into activities and fragments. Passing data between these screens can be complicated. In order to save time on development, the different managers in TrojaNow were converted for static use. This was acheived by creating a constant in each of the managers and hiding the constructors.
The initial intention in the architecture was to store the current user in the authentication manager. During implementation, the storage of the user was moved to the Android Account Manager. This allows the account to be displayed in the Android Settings application.
In order to account for the custom functionality in TrojaNow, a custom server was written. This server was written in Rails. The following commands are necessary to start the server.
# Reset the database rake db:drop rake db:create rake db:migrate # Start the Server rails s
Development was performed on a small test server. To run the Android app, you will need to recompile the application with the appropriate server. To do this, change the setting specified below.
// us.grahn.trojanow.logic.Utilities.java
private static final String SERVER = "http://[YOUR SERVER IP]:3000/";
One of the primary reasons for choosing the Android SDK was the ability to conform with Google's Material Design. This allows for advanced animations in the GUI with minimal effort. Frameworks built on-top of the SDK aren't able to take advantage of Android 5.0+'s special handling of animations.
Choosing this approach allows the application to blend-in with the system applications with which the user is familiar. This cuts down on the learning-curve.
One of the hardest parts of this project was conforming to the original architecture. Due to constraints placed upon interactions by Android, it simply wasn't possible at certain spots.
If your intended target already has support for a particular architecture, think long and hard before differing form that architecture. Working against a target is much harder than working with it.
If I were to redo the TrojaNow architecture, I would make modifications so that the application could map more directly to the Android SDK. This would allow for faster coding with less hassle.
If an architect isn't doing development, they need to frequently hear the feedback of the developers. As the architect of my project, it hurt every time I had to change the architecture. At the same time, I was occassionally frustrated by limitations of the architecture and conflicts with the target.
Being aware of these conflicts allowed me to make executive decisions about how and where to change the architecture. If another target is added, I would recommend creating a modified architecture for the new target. Most parts of the architecture would stay the same, but some may have to change.
An easy way to catch up with your favorite pals.
The first screen you will see is a feed of all the recent posts. Each post will either be anonymous or associated with a user. The posts will be timestamped for easy reference and may include emotions or environments.
If you want to create a new post, just tap the "(+)" floating action button.
A streamlined interface for sharing thoughts.
Creating a new post is a simple process accessed from the "(+)" floating action button.
The interface allows you to add emotions and environments to with minimal interaction. Don't want the post to associated with you? Mark it as anonymous with the touch of a button.
An informative message for every important error.
Error handling is built into all network communications of TrojaNow. Whenever an error occurs, a message is displayed. This message can be customized on the server without modification to the client.
In the screenshot, a user has entered an invalid name to the sign up form. Instead of having vague feedback or receiving an error, they are shown a helpful dialog.
A simple way to verify your identity with the server.
Authentication with the server couldn't be easier with this form. Password managers such as LastPass will recognize the form and auto-complete credentials as appropriate.
A new account without leaving the mobile application.
Signing up for a new account is easy to do with the sign up form. Just a few entries allows you to create a new account without leaving the mobile application.
Don't worry about messing up a field. We will warn you!.