Skip to content

My major concerns #6

@CodyRoy

Description

@CodyRoy

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions