The following crash appears to be caused by a null object reference of the mediaPlayer member of TalkPlayerFragment:

java.lang.RuntimeException: Unable to start activity ComponentInfo{org.dharmaseed.androidapp/org.dharmaseed.androidapp.PlayTalkActivity}: java.lang.NullPointerException: Attempt to invoke virtual method 'boolean android.media.MediaPlayer.isPlaying()' on a null object reference
    at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2358)
    at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:2420)
    at android.app.ActivityThread.access$900(ActivityThread.java:154)
    at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1321)
    at android.os.Handler.dispatchMessage(Handler.java:102)
    at android.os.Looper.loop(Looper.java:135)
    at android.app.ActivityThread.main(ActivityThread.java:5294)
    at java.lang.reflect.Method.invoke(Native Method)
    at java.lang.reflect.Method.invoke(Method.java:372)
    at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:904)
    at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:699)
Caused by: java.lang.NullPointerException: Attempt to invoke virtual method 'boolean android.media.MediaPlayer.isPlaying()' on a null object reference
    at org.dharmaseed.androidapp.PlayTalkActivity.onCreate(PlayTalkActivity.java:173)
    at android.app.Activity.performCreate(Activity.java:5990)
    at android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1106)
    at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2311)
    ... 10 more

Should be able to enter in a retreat code and see the talks from it.

Include a recent database and teacher photos with the app, to avoid long initial data sync times on first use.

Need to figure out how not to overwrite the database if the user already has one.

We understand that space constraints may make this difficult.

Dropping the teacher name on the Teacher detail page, or Center name on the Center detail page, may make it easier to display the pertinent information.

Oops, I broke the talk view's back button in 8d80911, which renamed the applicationID from org.dharmaseed.androidapp to org.dharmaseed.android. Clicking that button now yields the following error:

E/NavUtils: getParentActivityIntent: bad parentActivityName 'org.dharmaseed.android.NavigationActivity' in manifest

whenever a talk is clicked and PlayTalkActivity is launched, this error appears in the logs

See #52. Sometimes we fail to download talks, and it would be nice to remember the talks that fail in the DB so that we can re-try them later on.

We'd like to have these be readily visible and easily accessible.

If the user downloads some talks and for whatever reason deletes and re-installs the app or deletes the data, the dharma talks will remain on their device (which I intended), but we will not know that those talks are downloaded. So on boot up, we should check the DIRECTORY_MUSIC/dharmaseed folder for dharma talks and update any talks in the DB. This will prevent confusing behavior if I downloaded a talk, uninstalled the app, re-installed, and then clicked that talk in the app - the app would not recognize I had downloaded it and I would have to download it again.

• The app should list only the teachers that are considered "Dharma Seed public teachers", as indicated by the "public" field of the teacher API.
• When listing the teachers, the monastics should be listed first, as indicated by the "monastic" field of the teacher API.

Need to figure out how to preserve state properly when the screen is rotated

Centers that do not have has_venue_view set to True are not considered to be separately indexed entries in the Dharma Seed catalog. However, their name & other information can be displayed in talk listings.

When a talk is playing in Dharma Seed, there should be an icon in the status bar indicating that a talk is playing, and swiping down from the top should allow the user to pause the talk without having to enter the app.

Teacher names & photos are not correct. Maybe something with android re-using the list view objects? Need to better understand how the custom list view adapter works.

Sometimes in RequestAggregator.fireRequest(), where we download talk data 500 at a time, we get a SocketTimeout. Then we just move on to the next batch of 500, so we lose out on 500 talks. I think instead we can save the talks we timed out on and try them again at the end.

This can be confusing if the user quickly exits and re-opens a talk that is being downloaded. The original button will be there, perhaps looking like the download was cancelled, which is untrue. This could potentially be solved by having a "download" status column in the DB for talks, with statuses like not_downloaded, downloading, and downloaded, so we can set the appropriate image. But this isn't very high priority.

We should have things to do for specific upgrades so we don't have to drop every table (which is what we do now) and re-download it. For example, adding a new column to the centers table shouldn't cause us to drop the Talk table and take 10 minutes re-downloading it.

The Repository Pattern separates the DB logic code from the 'client' (in this case, the presentation layer, or the activities). This is useful to allow for testing of DB methods, cleaning up the presentation layer, and removing duplication of code, among others. This became clear to me after trying to address issue #37 . With the current architecture, the best way to do this would be a query on line 283 here:

And then circumventing a function call later down in the code. But this would only add to the vast amounts of querying done from the Activity and serve to make the logic less intuitive, less maintainable, and harder for a newcomer to understand. The goal would be to remove all queries from any Activity and to instead retrieve data via the respective Repository.

A good first step is to create a TalkRepository class for just the Talk entity, and then expanding as needed, only creating methods for accessing the DB as needed and not creating a whole bunch of generic methods that aren't used.

This should be done before #37.

The recording_date column in the table talks is incorrect.
We insert values into talks based on the info we get from the api. So if there is a recording_date in the talk json from the api, we insert that into the db. But in the api, the field is rec_date, so recording_date doesn't get inserted. Since we don't have a recording_date, we use the update_date, which causes the most recent talks in the NavigationActivity to often be from one teacher because that teacher got updated last of all. For example:

Looking at the returned json for the talk "The Kalama Sutta":

{"edition": "2019-01-06 21:02:07", "items": {"54055": {"upload_date": "2019-01-04 00:00:00", "is_featured": false, "audio_url": "/teacher/484/talk/54055/20170724-Brian_Lesage-FIMC-the_kalama_sutta-54055.mp3", "original_audio_file_name": "uploads/7_24_17_THE_KALAMA_SUTTA___NAVIGATING_THE_PATH.MP3", "id": 54055, "description": "This talk offers reflections on the Kalama sutta that make this discourse relevant to our lives.", "update_date": "2019-01-04 22:44:25", "venue_id": 256, "title": "The Kalama Sutta", "is_not_sellable": false, "destination": "web", "language_id": 1, "recording_type": "Talk", "duration_in_minutes": 30.7713333333333, "rec_date": "2017-07-24 19:00:00", "is_album": false, "retreat_id": 4129, "tracks": [], "publishability": "general", "teacher_id": 484, "isNotSellable": false, "recording_date_in_seconds": 1500922800.0, "talk_code": "", "isAlbum": false}}}

We see that the key is rec_date and that the rec_date is "2017-07-24 19:00:00", but the update_date is "2019-01-04 22:44:25", so it appears near first in the list of talks.

Check out these two queries:

sqlite> select count(_id) from talks where recording_date IS NOT NULL;
0

sqlite> select count(_id) from talks where recording_date IS NULL;
32022

So a simple change in the DB from recording_date to rec_date should fix this.

It would be nice if it were the same width for visual consistency.

Just like stars, we should be able to list only downloaded talks

If I'm playing music on Google Play and I play a talk on Dharma Seed, both will play at the same time. Dharma Seed should pause Google Play when starting a talk.

Need to split the terms by whitespace and issue separate search clauses for each (joined with ANDs) in the SELECT query.

Instead of hitting the media.dharmaseed.org server directly, follow the redirect when hitting dharmaseed.org so that if a talk title changes, we can still download the file.

Downloading the talks when opening the app for the first time seems unpredictable:

I fresh install the app, it downloads a single talk (or it only displays a single one), but navigating to the teachers page, it is filled with teachers. I clear data, re-run and it downloads what seems to be all the talks, but takes minutes and the "loading" circle animation doesn't go away.

This is vague, but the downloading of the dharma seed api on app start-up needs to be examined and improved.

Currently the talks shown on any particular teacher detail page sometimes include other teacher's talks (most likely due to string matching the teacher's name against the talk name or talk description field).

Instead, show only the talks whose teacher ID matches the id of the teacher in question.

The api talk entry field "rec_date" should be used to sort talk entries (sorted in most-recent-talk first order).

For example, when the file_path column was added to the Talk table, I added code in onUpgrade() to drop the table and re-create it:

But we should strive to avoid dropping and re-adding any table because of the time taken to re-populate the entire thing (the Talk table takes somewhere around 10 minutes). Instead we should alter the table if we're just adding a column.

Apparently this is caused by having too many cursors open... need to figure out how to close them.

We will add retreat support once Dharma Seed adds a retreat API. Until then, we'll add it to the DB to make life a bit easier then (and because I had already done some of the work).

Run Analyze -> Inspect Code in android studio and clean up any problems it finds.

Would be nice to add 'expand/constrict' functionality to the page to enable easier viewing of the course description .... for old people with bad eyes like mom! ;o)

We probably need to save the list view's location in onPause and restore in onResume.

If you scroll down really fast in the Talks view (like say you want to see talks from a year ago) the app crashes.

E.g. Zohar Lavie (522), Yuka Nakamura (757), Willa Thaniya Reid (239), etc.

The teacher photo is available through e.g.

http://dharmaseed.org/api/1/teachers/239/photo.png

However, it can be scaled by attaching a maxH and maxW parameter (one or both), e.g. fetching

http://dharmaseed.org/api/1/teachers/239/photo.png?maxW=350&maxH=350

will cause a redirect to a generated or cached image here:

https://media.dharmaseed.org/uploads/photos/teacher_239_350_350.png

Goal is to eliminate all messages like I/Choreographer(1378): Skipped 55 frames! The application may be doing too much work on its main thread.

This would be nice for maintaining consistent style and preventing formatting noise in PRs.

Changing a query is kind of a headache because you don't know if you're accidentally breaking something tiny. Unit tests would fix this.

Ajahn Chah, for example, has no talks on the app, but according to the website, he has 11.