Additional Espresso and JUnit tests should be added to fully test the UI and business logic across the entire app. MVVM-specific tests should be implemented as well.

See more details on implementing MVVM tests here: https://medium.com/@hiBrianLee/writing-testable-android-mvvm-app-part-1-ac2c39f31710

Currently, the restaurant list data is reloaded when switching between "Discover" and "Favorite" options in the navigation drawer.

As this reduces the general flow of the app, we should instead use the display restaurant list data to build the favorites list (and vice-versa). By doing so, we minimize the number of necessary API calls and user flow is less disruptive.

A login screen that has input fields for a user's e-mail address and password would be nice to implement, as well as retrieving the auth token and storing it for later use for future sessions.

Endpoints:

Authentication

URL: POST to /v2/auth/token/
Body Params:
• "email" - email which you signed up with
• "password" - password

Response: Token which you will put in your authorization header. The format you should put in your Authorization header will be "JWT {Token}". For example, if the token returned is 'xyzls', you should have the following as your auth header: JWT xyzls

User details

URL: GET to /v2/consumer/me/

Response: JSON blurb of all the necessary metadata of an individual.

Token Refreshing

Additional Info: JWT token lasts about 6 hours and then it expires. You can refresh it with the following URL. Embedded within each JWT token, there is some metadata. You can read more at https://jwt.io/.

URL: POST to /v2/auth/token/refresh/
Body Params:
• "token" - current token you used for authorization

Response: New token that has been refreshed and has a new expiration date.

If the app loses network access, data caching strategies should be implemented, by persisting and utilizing the most recent restaurant list data, until network access is restored.

When MainActivity is shown, the toolbar name is set to "Dash Nearby", when it should be "Discover", as per design docs. The toolbar name is also reset to "Dash Nearby" instead of "Discover" or "Favorites" when a screen orientation change occurs.

The "Add To Favorites" button in RestaurantDetailsActivity layout should have a "ripple" effect on devices running on Android 5.0 and above.

LeakCanary should be implemented for this project to detect any memory leaks.

When the up arrow in RestaurantDetailsActivity is pressed, the restaurant list is reloaded in RestaurantListFragment. This is probably due to the following line of code in onOptionsItemSelected():

NavUtils.navigateUpFromSameTask(this);

This bug is likely related to the activity task flow. See more here: https://developer.android.com/guide/components/activities/tasks-and-back-stack.html

The app crashes when a screen orientation change occurs while the restaurant list is still loading:

java.lang.NullPointerException: collection == null at java.util.ArrayList.<init>(ArrayList.java:94) at com.huhx0015.doordashchallenge.view.fragments.RestaurantListFragment.onSaveInstanceState(RestaurantListFragment.java:99) at android.support.v4.app.Fragment.performSaveInstanceState(Fragment.java:2356) at android.support.v4.app.FragmentManagerImpl.saveFragmentBasicState(FragmentManager.java:2607) at android.support.v4.app.FragmentManagerImpl.saveAllState(FragmentManager.java:2678) at android.support.v4.app.FragmentController.saveAllState(FragmentController.java:134) at android.support.v4.app.FragmentActivity.onSaveInstanceState(FragmentActivity.java:571) at android.support.v7.app.AppCompatActivity.onSaveInstanceState(AppCompatActivity.java:509) at com.huhx0015.doordashchallenge.view.activities.MainActivity.onSaveInstanceState(MainActivity.java:62) at android.app.Activity.performSaveInstanceState(Activity.java:1487) at android.app.Instrumentation.callActivityOnSaveInstanceState(Instrumentation.java:1318) at android.app.ActivityThread.callCallActivityOnSaveInstanceState(ActivityThread.java:5489) at android.app.ActivityThread.handleRelaunchActivity(ActivityThread.java:5440) at android.app.ActivityThread.access$1200(ActivityThread.java:229) at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1827) at android.os.Handler.dispatchMessage(Handler.java:102) at android.os.Looper.loop(Looper.java:148) at android.app.ActivityThread.main(ActivityThread.java:7331) at java.lang.reflect.Method.invoke(Native Method) at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:1230) at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1120) at de.robv.android.xposed.XposedBridge.main(XposedBridge.java:102)

This crash occurs in onSaveInstanceState() when attempting to add mRestaurantList to the Bundle outstate when it is null.

When switching between "Discover" and "Favorite" options in the navigation drawer, a new instance of RestaurantListFragment is created and loaded each time.

As both options are using the same type of fragment, but with slightly different behavior, it is more optimal to just refresh the view in RestaurantListFragment accordingly when switching between the two options.

As the restaurant list data can be very large, it would probably be more efficient to dynamically update the restaurant list data as the user scrolls. We can use the existing v2/restaurant/ endpoint, in addition to the offset and limit parameters to get a specific number of restaurants, starting from the offset position.

Right now, the restaurant list is only loaded when the app is launched. It would be nice to add a "pull to refresh" feature using SwipeRefreshLayout so that users can manually refresh the data.

While Sugar ORM is simple and easy to use for data persistence, it may be too basic when storing more complicated data in the future. Also, the current release of Sugar ORM is currently incompatible with Android Studio's Instant Run feature; a fix has been merged, but no word on when the next version of Sugar ORM will be released: chennaione/sugar#564

Other database persistence libraries like Realm, DBFlow, Room, GreenDAO, etc. should be considered as possible alternatives.

Reference: Performance Comparison of Database Libraries by Andrew Grozner: https://github.com/agrosner/AndroidDatabaseLibraryComparison2/tree/master/app/src/main/java/com/grosner/androiddatabaselibrarycomparison2

Instead of hard-coding test coordinates for the app, it would be nice to make the app location aware so that the restaurant list results loaded are appropriate to the user's actual location. Note that Android 6.0+ devices, location permissions must be requested before attempting to access location services.

Reference:
https://developer.android.com/training/location/index.html
https://guides.codepath.com/android/Retrieving-Location-with-LocationServices-API
https://developer.android.com/guide/topics/permissions/requesting.html

The favorites list isn't refreshed properly when returning from RestaurantDetailsActivity after removing a restaurant from favorites.

An option to filter the restaurant list by category tags would be nice for users, rather than displaying the full restaurant list.