-
Notifications
You must be signed in to change notification settings - Fork 0
Description
I feel like I'm rewriting a lot of code which I've found usually implies I'm doing something wrong, or at least inefficiently. specifically, the adapters and layouts are REALLY similiar. My intuition tells me that the activity_restaurant, activitiy_event, activity_park .xml's can be combined into a single "list_view_activity.xml" and just maintain separate "XYZ_list_view_item.xml" for each seperate activity.
I have nearly 20 (as of writing) warnings rn almost all of which are telling me "public" is an unncessary modifier and that i should leave my classes as "package private". Its an easy fix but I've never had this issue in the past so I'm hesitent to fix something when I dont totally understand why its broken. this extends to the few "@nonnullable / @nullable" warnings as well.
Still not 100% on when to use fragments. As far as i can tell, a fragment allows multiple "screens" to be visable at a given time for larger android devices like tablets, but on movile devices like phones, they're functionally equivlent to creating new activities. Is it just this UI advantage for larger screens or is there a performance impact (positive or negative) when using fragments? I feel like im missing some detail that udacity hasnt expalined to me yet.
Still unsure the implication of activity being in the AndroidManifest.xml, Udacity made a big deal about checking that out.
need to work on naming convention and commenting