Comverse
Description:
​
Comverse is an app for showing and creating comic Wikipedia, it has following 4 major functions:
-
Home: browsing latest popular comic Wikipedia feed.
-
Search: searching comic-related info within API provided categories like “character” “power” “concept” “power”, etc.
-
Creation: creating customized comic posts. Together with posts functionality, these two functions are the keys of this app. The idea is to allow users to compose relations between comic items (character, team, power, issue, etc.) by creating their own “comic node”, within which they could customize their own find and weave comic world relation web visually and share with others.
(side note: this major function deviated from the original proposal, which is about building a score battle system between comic hero. The reason behind this change is two-fold. One is that the comic hero score battle API is a bit simple in nature. It only has numerical data, doesn’t require auth key, and support very minimal query fields for data fetching. The second reason is that the database behind it is a bit static. It doesn’t have many updates. I believe a good app needs to constantly update its content so that it could create sticky bond between app and user.)
-
Posts: reviewing others’ customized comic posts. Together with creation functionality, these two functions are the keys of this app. This is a reverse process of creation function. It allows the user to unfold the complex post object created by others and display the detail content.​​
Front-end:
​
-
a lot of the UI code are trying to minimize the duplication of code in adapter and fragment by providing arguments to adapt to different data input.
-
in order to better provide the “relation” feel and look in creation function, the app uses circular layout manager created by Kapilesh Tharaknath.
-
the overall app material design is trying to minimize textual content because most users nowadays favor visual content over textual content. The full-on detailed content usually displays either by tooltip text when long clicked or when user intentionally clicks into a detail view.
API, Built-in Features & External Resources:
​
-
using ComicVine API (https://comicvine.gamespot.com/api/).
-
The control system mostly uses android navigation graph to switch between fragments. Navigation drawer and action bar are used to supply supplemental info during navigation, such as updating user info in drawer, reflecting current fragment info in action bar, providing log-in/log-out action, etc.
-
using Glide to help fetch images:
-
pros: abstract the image loading logic
-
challenges: hard to load gif as placeholders
-
-
using Retrofit2 for creating API interface:
-
pros: easy to add query path and field parameters in API call
-
challenges: none
-
-
using Kapilesh Tharaknath’s circular layout in creation function to help visualize comic item relations
-
pros: provide nice circular scroll experience, such as stabilization, item highlighting, scroll state control, etc.
-
challenges: not many parameters to play with the overall circular shape by using provided methods.
-
-
using Firebase Auth to control authentication:
-
pros: abstract auth layer
-
challenges: not much room to control UI display
-
-
using Firestore to maintain posts database:
-
pros: easy to do CRUD
-
challenges: none
-
Back-end:​
​
-
The back-end stores users’ posts data structured as above. It includes post’s own info (selfID, imageURL, apiURL, relatedNodes list, user description) and associated account ID (ownerUID). The relatedNodes list contains same comic node object with the same field structure. With log-in account info, user can do CRUD with their posts and update them in cloud and other users can review but not change the posts that don’t belong to their accounts.
-
The overall downloaded data from API, uploaded data to cloud database and downloaded from cloud database are guarded by validation check to prevent app crashing.
-
Firestore database schema:
Challenge:
​
-
The most interesting thing as well the biggest challenge is to create and unfold this “comic node” object, where it has related “comic node” lists, info about itself, user’s customized plots and user id info. The hardest step is actually in design phase and create several user behavior cases, such as one user cannot create a node without log-in info; one user might want to duplicate others’ node and start to modify it and then do upload; under log-in mode, user can save a “comic node” with user description and related “comic node”, etc. This function could be applied to scenarios like user has found several “hard-to-find” connections of seemly unrelated comic items; user simply wants to save up a story with related comic items and share with others; user wants to create a connection map to visualiz complex lines between multiple comic nodes.
-
Future improvement: ideally, it would be great if the app could visualize a graph-like connection web between multiple nodes as an overall map. This would require graph data structure such as adjacency list or adjacency matrix to maintain the connection info.
-
One bug that bothers me a lot is the android system takes back resources from my app activity and push the app to background when I have low VM heap. I still couldn’t figure out a way to tackle this issue using emulator with Pixel 3 API 28 and 256 MB VM heap. The logcat doesn’t give me any error when this weird behavior happened, and I later realized that maybe the low memory was the issue. The temporary workaround is to change the emulator settings. In order to run the app smoothly, I would suggest using Pixel 4 XL with API 30 and setting up available RAM with 2GB and available VM heap with at least 512 MB.
-
Another bug/issue I cannot find a good solution is the API call rate limiting. The API documentation says that if 2 calls are within 1 second or you are making 450 calls within 15 minutes, you will be blocked. So if you do search super quick, it will block the API use.