Zanim dodam do aplikacji obsługę składników czas wrócić na chwilę do ogólnej struktury projektu i ogarnąć trochę ten bałagan. Czas jest odpowiedni skoro właśnie będę dotykać wszystkich warstw żeby dodać i obsłużyć dwie klasy (Ingredients i IngredientsContract), a już niedługo dojdzie tabela asocjacyjna łącząca składniki z posiłkiem.
Zaczęłam od poprawiania nazw metod, bo w moim DbHelperze miałam metody insertValueDbHelper i updateValueDbHelper… nie było to najszczęśliwsze – teraz nazywają się po prostu insert i update. Tak samo w klasie DinnerContract metoda insertDinner zmieniła się w insert, no bo wszyscy wiedzą, że to dinner będzie dodawany 
Wyodrębniłam metody delete i przerzuciłam je do klasy abstrakcyjnej BaseTable, po której dziedziczą wszystkie klasy z sufixem Contract.
Udało mi się namierzyć i usunąć dziwne rzeczy jak przekazywanie w funkcji zmiennej Context i SQLiteDbHelper po to żeby potem utworzyć z Context mój CoNaObiadDbHelper rozszerzający SQLiteDbHelpera…
Zgodnie z tym artykułem utworzyłam też dodatkowe package na klasy typu adapter, activity, itd. Tak teraz wygląda struktura mojej aplikacji.
Szkoda, że z layoutami nie można zrobić tego samego w taki prosty sposób. Ale na to też jest pomysł (więcej tu i tu).
Muszę jeszcze usunąć zahardkodowane wymiary z layoutów i przenieść je do dimens.xml i mogę wracać do implementowania nowości.
Dzięki za linki odnośnie strukturyzacji layoutów. Fajna sprawa
fajnie, że się przyda