Open Brahmancer opened 8 years ago
This should be included in the scope of #43
//@colinrford @Brahmancer @brandonschabell @Wall-Dough @MrJohnson I see a lot of "this and that should work together" and I think we should implement some kind of centralized access to the data. I know we have Realm and all, but how do you all suppose we integrate the data for every module?
So here are a couple of ideas (Spoilers, I'll be thinking in mind of using Realm but this can change if we do not use it):
RealmObject
per Module
. We then have an all encompassing class that stores an instance of each RealmObject
and we can use the individual data generated from each module. Problem's that come to mind with this approach is we need to clear about the schema of each module's data storage. I know this is lengthy so I can clarify on certain points if something doesn't make sense.
I think we can have the model layers in their own package and go with option 2, like so:
package com.sciencesquad.models;
@AutoParcel
public class StepModel extends RealmObject {
@Required
public Date entryDate;
@Required
public int steps;
}
Then we'll have a module like so:
package com.sciencesquad.modules;
public class StepModule extends Module {
/* code here */
// uses StepModel to manage data.
}
This way we can have a true decoupling between all three layers in MVC. Now, for the diet module:
package com.sciencesquad.modules;
public class DietModule extends Module {
/* code here */
// uses DietModel to manage data.
// Get all steps walked today as an integer.
private int _stepsWalked() {
return this.context.realmThing().getData(Date.Today, StepModel.class); // pseudocode
}
}
@Brahmancer How does that sound?
If I understand 2 properly, @Brahmancer, I think this could be the ideal option, as long as we can quickly compile/gather data from each Module together when we present the daily ( #31 ) and weekly/monthly/yearly ( #40 ) health progression. When the amount of data from each Module becomes quite large, we'll also want to be sure that the accessibility to this data remains quick so that the user sees their health overview quickly
Just clarifications on the _stepsWalked() method @avaidyam , this would query a database associated with the StepModel for the amount of steps gathered?
I kinda have an idea: We have objects for exercise/run/etc. with variables for things like calorie consumption, each is an item such as a set of bicep curls or a 10 minute jog. An array of pointers to the objects, keyed by day. Another array of pointers to the objects, keyed by specific exercise. Another array of pointers to the objects, keyed by source module (run, step, exercise, etc.). In each object, pointers to each array of objects (allows for easy navigation from day/category/exercise to item, and back again)
In a main class that keeps track of overall health information, there would be total calories expended/consumed, among other data points, and an array of objects that contributed to the overall data.
We'd probably want to use things like tries, which we learned in 251(?), for quick and responsive searches.
@colinrford Yeah, the separation of the model layer (i.e. StepModel
) would do this, as every module has the same Realm database underlying it. We can also maintain aggregate data that is lazy-computed only once and then stored in the database as well.
@Brahmancer Yes! This is assuming that the abstract Module
class provides the hook to the underlying Realm database that every module accesses and stores information in.
@Wall-Dough Pointers don't happen in Java. :cry: I'm supposing Realm provides the keying of data, like SQL
query syntax. @Brahmancer, do you know?
Tries make me cries. We have a database layer, let's see if it does this stuff for us, for free. Free lunches are great! :laughing:
@avaidyam Java doesn't allow for pointers explicitly, but at least implicitly, right? Like you can set one variable equal to another variable that's an object, and they're the same object?
I guess I'm still thinking in terms of local data. How much of the data would be local, and how much would remain in Realm?
Everything in Java is references except primitive types (int
, float
, char
, etc.) Our goal is to move all our data into Realm and not think about it too hard. It should go there and be there, and come back when we need it. :100:
@avaidyam Got it. I assume some form of caching will be involved though, yes?
So Realm does follow a SQL-like query syntax but in the from of Java Method calls. It may sound a bit confusing but much like SQL queries, it's very intuitive. You can provide a primary key for each module which is stored.
There's also an option of creating multiple Realm "tables" under different names where each module can read, write, and query to.
My thinking is whatever is essentially to the module that isn't easily computed should be stored in Realm.
@Wall-Dough Caching is nice. Caching is good. Caching is love.
@Brahmancer Native Java is the bee's knees and totally rocks my socks. Sounds like a plan.
Idea: For diet/recipe recommendations, include several options for a given diet based on how much time/funds someone has available for food preparation.
E.g.: Make it for me - recommend a restaurant I've got some free time - recommend a quick and easy recipe - include slow cooker recipes, since they're relatively hands-off I've got all the time in the world - no necessary time limit
@Wall-Dough we could abstract it into categories "Make it for me, I'm no cook, and Master Chef". This would absolutely awesome for me since I could then tell our app "pls gimme some pizzer and mcdoobies" without feeling bad....
@avaidyam
mcdoobies
:hamburger: :ok_hand: :dash:
:rocket:
Implement a feature where the app will recommend a diet to the user based on user info.
Sprint 3:
Improve upon NutrientQuery class Link NutrientQuery class to other modules Improve upon ConditionModule