ischeinkman / unofficialazaapp Goto Github PK

From @ischeinkman on September 13, 2015 9:2

Add ability to clear rides except for passengers at the same location as the driver, like the driver themselves and family.

Copied from original issue: ischeinkman/OfficialRamonApp#42

Some people have requested the ability to add chapter-specific songs, like Chapter Cheers, to their apps via Chapter Pack.

Many chapters use facebook to manage their events.
The app should be able to login to the user's facebook account and retrieve event information from their event feed.

We should allow alephs to pick a contact via settings as "themselves."
This will allow easier control mechanisms in the future, like rides and turning certain modes off and on.

Right now we have no ability for accounting for hangouts in the rides process. We should include the ability to only include hanging out passengers in hanging out cars.

Right now we have one big string resource file. It should be split up into multiple based on purpose.

Right now we rely on the song titles in SongInfoWrapperGenerator to construct the resource name and retrieve the resource. This is stupid and leads to situations #22 being difficult to fix even though it should be quick.

From @ischeinkman on July 17, 2015 19:1

Copied from original issue: ischeinkman/OfficialRamonApp#16

The handler currently contains some Android dependencies. Due to the impending API creation those should be moved into the support class.

If no events are planned, indicate that on the events screen so that the user knows that the app is functioning.

Currently we create and retrieve handlers in inconsistent ways, e.g. sometimes we create a ContactDatabaseHandler from the ChapterPackHandlerSupport class, sometimes we create it from a context instance, and sometimes we create it from a SQlite Database instance. Handlers should be retrieved using the same method throughout the code.

Chapter Packs should be loaded via a selection list accessible from Settings. This eliminates the need to move Chapter Packs after loading and reduces the possibility of breakage.

From @ischeinkman on September 12, 2015 20:59

For example: an address located in Sunnyvale receives a latitude and longitude in Alaska.

Copied from original issue: ischeinkman/OfficialRamonApp#40

To reproduce:
-Create X number of passengers
-Create a driver with less than X spots
-Run Naive Hungarian using "None" cluster type

Right now the rides page, with its "Algorithms" and "Clusters", scares users and sometimes leads them to creating badly generated rides.
In future releases we should automatically choose a designated best generator by default (probably Naive Hungarian with Snake Clusters) and only allow changing with Debug on.

Right now we have no unit or integration tests.
We need tests.

To reproduce:
-Open app
-Open drawer
-Click "Songs" or "Contact List"
-Open drawer
-Click "Frontpage"

Expected:
-Action bar title changed to "Frontpage"

Actual:
-Action bar title remains previous page's title

From @ischeinkman on July 30, 2015 4:47

On website update and pre event

Copied from original issue: ischeinkman/OfficialRamonApp#20

From @ischeinkman on September 6, 2015 5:9

Email, text, etc

Copied from original issue: ischeinkman/OfficialRamonApp#36

Right now we call classes that interact with different sources for information "handlers," like the ContactDatabaseHandler class and EventRSSHandler class.
It has come to my attention that Android itself has classes named "handlers" as well, for dealing with delayed and multithreaded events.
This then begs the question -- should we rename our "handler" classes to something else? "Interactor"? "Generator"? "Factory"?

After talking with advisors and staff, it has been brought to my attention that BBYO is pushing for event attendance reporting to accurately gauge and rank events and chapters. Integrating this with the app should increase the app's image in corporate's eyes.

Right now our interactions with the database, Internet, etc are done by synchronous methods of a "handler" class returning some InfoWrapper[] executed in seperate AsyncTask threads.
I propose instead of having a handler InfoWrapper[] getWrappersFromSource() method that is then executed from an async task, the handler has an Observable getWrappersFromSource() method and the UI activity/fragment/view then subscribes to the observable using RxJava.

Benefits:
*Allows partial loading
*Easier error handling
*Easier UI testability
*Don't have to worry about AsyncTasks

Drawbacks:
*Reactive programming has a learning curve. Even I took a while to understand it.
*Introduces a new dependency to the API

It would be nice to have a digital copy of the Blue Book in the app.

Right now we cannot search for a specific contact in the contact list.

We should be able to find specific contacts via some sort of search bar.

The song "For Tomorrow and Today" misspells tomorrow as "tomorow"

We do not include the date in the list or the details view.
Users should be able to see an event date somewhere.