Architecture
Our project will be using the following:
- React
- React Native
- Firebase
- firebase NPM package
- AsyncStorage
Our project will use NPM for package management and Expo as a general framework for testing, visualization, and building.
React/React Native will be our main library for content delivery.
Firebase will host some essential user data and an array of post ids and will work as a "middle man" for P2P connections.
firebase NPM package will be our interface between the javascript app and firebase DB.
AsyncStorage will manage local storage.
| Adam | Carleigh | Cole | Divine | Kevin |
|---|---|---|---|---|
| Database management. [1] | Post creation and access. [4] [5] | Peer-to-peer data flow. [7] Local data management. [6] |
Social functionality. [3] | User login and authentication. [2] |
Expo allows our ReactJS codebase to be built as .apk and .ipa files for use on Android and iOS platforms respectively.
The main means of testing the application will be emulating Android and running the .apk file. Expo runs the codebase in the web browser, while Android emulators, such as Bluestacks, and our collective personal devices will serve as testing environments for the application.
The App class will serve as a wrapper and 'driver' for the entire application, mainly making function calls to ScreenGenerator to render components on screen dependent on application state.
The ScreenGenerator class will contain the bulk, if not all, of user interactivity and code pertaining to how the screen is drawn, and which actions can be taken from each one. User state and local data are set and manipulated as well.
The User class encapsulates user characteristics (username, ID, posts, etc.) alongside functionality (up-vote, down-vote, make a post, etc.), of which can be accessed and rendered into React components.
The Post class aggregates post characteristics (content, file, score, etc.) to also be rendered into React components.
The Utility class acts as the backbone of the application in authenticating users, accessing the database, generating unique information, and coordinating network activity.
Our app will maintain the state in memory as all data storage is done on-device.
Subject to change, our database will likely be structured with a large table consisting of five columns:
| Username | Passphrase | MiD | Network | Posts |
|---|---|---|---|---|
| A public alias for the users to log in with. Not unique. | A passphrase, stored in a hashed format for security. Checked with the username. | A unique integer value for each account, this field acts as our primary key. | An array of other MiDs that serves as this user's network. | An array of Post IDs (also unique) that serves as this user's post history. |
At this time, this covers all the data we intend to store in the Firebase DB, mostly relying on local storage for other data. This is obviously an early concept, and subject to change. For common queries, I'm going to use SQL because that's what I'm familiar with, but firebase has its own API, so the below code probably won't appear in our source. It's just for demonstration.
Common queries:
- Compare hashed passphrase for username
SELECT Username FROM Users WHERE Passphrase LIKE <HashedPassphrase>;
- Get MiD of specified user
SELECT MiD FROM Users WHERE Username LIKE <Username>;
- Get Post array for a specific user's network
SELECT Posts FROM Users WHERE MiD IN (SELECT MiD FROM Users WHERE CONTAINS(Network, '<MiD>,');
The above query & subquery combo is a model for getting all posts of users in one's network (where '<MiD>,' represents said (source/root) user and a comma, to guarantee that it's an actual instance of the MiD and not a repetition in a different one. This relies on a reciprocal network structure: If I'm in your network, you must be in mine.
Of the four User "screens" available, only User Profile and Data Management will appear on the Proof-of-Concept demo (along with an undrawn login/create account screen).
This view consists of a singular view and a number of buttons. Ideally, the My Information portion of the screen can be generated by the user class itself (toRender()). Then, the buttons are added and styled via the Screen Generator for simple navigation.
Similarly, the bottom bar should be a common element, either guaranteed by the ScreenGenerator or the Main App.js itself. This is likely only a bit of style and navigation buttons.
This view consists of information on a user's data and a button to remove data. It likely won't be this well-displayed in the demo. Instead,
A Data List will likely be used as a view to show the data currently stored, likely generated by the Utility class. A button will be a part of each data view, allowing the user to individually delete posts. Each data is its own view, compiled together in a scrollable list by the Screen Generator. (Or, possibly a separate function in the Utility class).
At the bottom, a Delete All button should be accessible, likely generated by the Screen Generator.
Of the three Network "screens" available, only post view will be available in the Proof-of-Concept demo.
This view consists of a scrollable list of individual, interactive elements (posts). Posts will be loaded (ideally in chronological order) and displayed as they are fetched, likely up to a sensible limit (say, 20) to manage storage effectively. Since this is a scrollable list, they will all be rendered at once.
Posts are likely rendered by an internal method for the post object, displaying the text content and an interactable scoring component (toRender()). They are individual views, rendered together.
Searching may be cut for Proof-of-Concept demo but would function as a text field made by the renderPosts() method (via ScreenGenerator), and would index the usernames that are in the current list of rendered-posts, and then, upon submissions, likely call a private method (say, getPosts(searchedUsername)) to limit results to only matching usernames.
Of the three Friends "screens" available, only a list of friends and a profile view will be in the Proof-of-Concept demo.
This Friends screen will likely appear as displayed, with a searchable field similar to the one described above in posts and a scrollable list of friends. Each arrow button might be replaced with an x for removal, or an eye to bring up the profile view. This page would be generated by Screen Generator after fetching the list of friends from CurrentUser.
The User's Profile Screen (merged with 'Add Friend') will likely consist of a view rendered by the user's toRender() field, as it displays the same information as the My Information view. Then, the Screen Generator will add a "Add Friend" button if the user is not in the Current User's network, or a "Remove Friend" button if the user is in the network. Direct messaging and Post history are not intended to be implemented at this time.
This view would be generated by the Screen Generator, then used to create a new Post object to be stored in the current User's post array. It'll be a simple view, consisting of a text box and a post button at a minimum - additional widgets may not make it into the demo.
🏠