steenburgh / hvzhub-mobile Goto Github PK

Steps to reproduce

1. Log in if you didn't already, go to the home screen
2. Switch to a tab other than 'news'
3. Rotate the device, and it will switch back to news.

Needs further investigation.
As of right now if you exit the app and receive more than one notification, the messages appear to come in in a completely random order. For example if I send 1 2 3 4 5, it might show up like 2 5 3 4 1 in both the notification and chat.

While the chat is open, however, or if chat is refreshed, the notifications appear in the correct order, which makes me believe that this is the DB's fault, not the GCM service's fault.

When chat is paused (eg. partially visible, see: Activity Lifecycle), it is missing messages. This needs further investigation. I'll look into this next weekend.

Need to create a setting for Vibration time on each notification.

This will of course cause problems when you aren't user 1. We need a way to get the current user's id to fix this.

Currently if there are no mod updates/chats/missions/etc, the user will just see an empty screen. We need to add a message that alerts the user that the view is actually supposed to be empty so they don't assume something went wrong.

This would include things like:

• Human and Zombie Count
• Blaster level unlock status
• Mission objective status + other relevant information.

This should be doable right now using sample data from http://hvzhub.com/{chapter}/games/{game number}/news.json to get an idea of what the final API call will look like

A couple of players have said this is the primary reason they use the HvZHub website.

This can be done using heatmap.json. Using the Google Maps API would be a good idea.

http://developer.android.com/guide/topics/ui/settings.html
This will need to have at least:

• The option to disable notifications for chat
• The option to set the 'priority' of chat notifications

https://developers.google.com/cloud-messaging/gcm
We will need to explain how GCM works to our API dev team in order to properly implement this.

To reproduce, just push the back button several times. Eventually, you'll end up with an empty screen.

If the same user sends multiple chats, only display the timestamp and username once.

For Example, this...

Duncan                           12:15pm
3 Zombies spotted by Van Vleck

Duncan                           12:17pm
Update: Looks like there's about 4-5 of them now.

Becomes...

Duncan                           12:17pm
3 Zombies spotted by Van Vleck
Update: Looks like there's about 4-5 of them now.

This Issue represents a short list of things that have to be removed from the code before release:

• Remove okhttp logging from ServiceGenerator.java and app/build.gradle
• Change the API Url to point to the real website.
• Remove debug strings from strings.xml
• Remove Log calls
• Optimize APK size. Example: shrinkResources true
• Generate signed APK
• Double check that the google maps API key is working when users download from the play store

Chat can be disabled by the mods. As of right now, the app doesn't check this and could have unpredictable behavior if chat is disabled.

We kinda need one. I'd suggest looking through these: https://design.google.com/icons/ for an icon. The logout process code should probably work similarly to the code in MainActivity.onLogout()

This will allow users to refresh the game status screen on demand instead of having to reload the entire app each time.

Duncan: If you don't know where to start with this, it'd be a good idea to take a look at how I did this for news and mod updates.

Currently, there is a placeholder notification icon. We need a better icon before the round starts. Of note is that we cannot simply use the app icon. As of 5.0, Android requires notification icons to be white:

Update or remove assets that involve color. The system ignores all non-alpha channels in action icons and in the main notification icon. You should assume that these icons will be alpha-only. The system draws notification icons in white and action icons in dark gray.

A couple of users mentioned that it took a bit to figure out that you have to tap and hold the tag location marker to move it. A message/hint of some sort should show up somewhere on the screen so users don't get confused.

Implement methods to send + get chats in the API wrapper.

These methods will use fake data and not actually connect to the server. This will allow us to simply change the API wrapper later when the API routes for chat are done without having to worry about modifying ChatActivity. The API methods should follow the similar patterns to those used in 'API.login()' to keep code in the API wrapper consistent.

• Get: Instead of connecting to a server, use fake data retrieved from http://hvzhub.com/{chapter}/games/{gameid}/chat.jsonhttp://hvzhub.com/uwmadison/games/8/chat.json?h=T&i=0&l=128
• Send: Instead of connecting to the server, add the chat to the fake data that Get uses.

Chat.json parameters

These will probably be the same in the final API implementation, so the API wrapper needs to support these:

• h means 'human' if h=T, you're requesting the human chat. Otherwise you're requesting zombie chat
• i means 'initial' and represents the index of the first message to get
• l means 'length' and represents the number of messages to get

The following features will be required:

• List Chapters
• Join Chapter
• List Games
• Join Game

I'd suggest extending ListActivity for straightforward and easy implementation.

Look at /src/app/api/v1/chapters.py in the HvZHub.com repo for more information.

Let something happen.

We need a simple link on the login screen that takes the user to a create account page on HvzHub.com

The database calls should be asynchronous to keep the UI responsive.

~~It might be a good idea to use a 'CardView' for this:~
http://developer.android.com/training/material/lists-cards.html#CardView~~

Edit: Cards may look pretty, but according to the android design spec, they are not the right UI element to use for a news feed.

Not high priority at the moment, but also a relatively easy fix. The issue is that this will pollute the server's DB with unused session_ids as the API /logout route deletes the current session from the server.

Example: When a user posts a link in chat. This link should automatically become clickable.

It looks like there is a library for this called Android-Linkify that may make this a lot easier.

When a user is turned, they will continue to receive notifications for human chat. The app in general will not respond to this change either. For example, the my code screen will still display.

https://support.google.com/googleplay/android-developer/answer/6112435?hl=en

When a user is turned, they won't start receiving notifications for zombie chat until either the app is re-opened, or a chat is received. This is not easily fixable without either wasting a ton of battery by constantly checking if the user has been turned, or the HvZHub server sending a GCM message when the user is turned.

Currently, API error handling consists of lines and lines of copy/pasted code. This code works, but really needs to change as it's extremely prone to bugs. Refactoring common error checking routines into utility methods is probably the best way to deal with this. For example, checking if the user's session id was invalidated, or checking if they've been turned.

What happens when I hit "Add location" then back out?
Like, if I get to the map, then hit back instead of "tag"? The button updates to say "(0,0)", which is definitely a wrong lat,lon (okay I guess it could be valid - but you should be able to know if you got a response back or not)

We'll need a database to persist chats. This will allow us to automatically add chats to the DB as GCM notifications come in in order to reduce loading time of the chat view after a user clicks a notification. This will also significantly reduce load on the HvZHub servers, and improve battery life for app users as it won't have to poll HvZHub for new chats every time the chat fragment is unloaded.

We haven't done this very often, and I was just testing this on an android 4.4 device and found a couple of issues.

Depending on the distances of the farthest tags, the heat map should be able to zoom to the correct level to see MOST of the tags on first view.