mrstarktastic / sugardays Goto Github PK

Does the app need a way to register weight?

Must think of a better GUI for the camera.

Every page will have a card or an ActionBar strip with overall/average data for the particular day with graphs as well.

Right now there are no specific designs for landscape layouts of DayPagerActivity (and its fragments) and ViewLogActivity. Suggestions/ideas are welcome.

The Google Places API method returns the closest place to the current location instead of a more accurate address. For example, when I'm home, it returns the location of a park that's about 200 meters away.
The Geocoding API is a much better solution for this.

Both FatSecret and Google (for the Places API) have their attributions displayed right where the respective data is fetched. Should it be displayed in other places in the app? According to both policies, yes. However, I'm not sure about that and I don't see the point and I don't wanna ruin the UX by pushing attributions everywhere.
Also, the Google Places API requires 3rd party attributions to be displayed (if any) and they can be fetched as follows: place.getAttributions().

The header might have potential, any idea what should be there instead of the placeholder?

Think of how to implement the possibility of navigating between saved logs while inside a ViewLogActivity.

When swiping between 2 days such that they are in different months or swiping between months in the CalendarView, there seems to be a slight lag with the ViewPager. It doesn't happen when swiping into (not out of) the first day of the current month or swiping into the current month. I'm clueless here.

The app should have its own gallery activity accessible from the menu drawer in DayPagerActivity.

• It would be awesome if photos were able to be linked to their SugarLogs.

• When a user wants to register a new SugarLog with a photo which was already used in other logs, it would be best if the user was presented with the option to choose a photo from the app's gallery. Thus, the image file won't have to be duplicated.

Please note that both suggestions likely require each photo to have its own POJO with fields such as a counter (the file will be deleted once the amount of dependencies is 0) and an array of day IDs it appears in.

Not proud of that at all. I am partly to blame because Google's preference tools don't work well at all so I simply gave up, stopped caring and wrote inefficient garbage code (mostly in PreferenceFragment) which works but I wish to clean it up and improve it in the future.
This issue is assigned strictly to ME because I'm the only one who can understand what's going on in there so please, if you're not me, DO NOT TOUCH anything that's related to the app's settings

Currently, the task is initialized, executed and forced to retrieve the data all at once on the main thread (with the exception of the autocomplete adapter). This behavior is extremely bad but I implemented it this way to save some time. In order to fix the behavior, one will have to show the dialog (non-dismissable by the user) inside onPreExecute() and dismiss it inside oonPostExecute(). Back where the data needs to be fetched, the loading dialog should have an OnDismissedListener and in there call task.get() and do the thing with the data...
Additionally, the task must also have a timeout set (perhaps 10 seconds?)

One must be able to make the app remind him via a notification to register a new log in X hours.

Currently, each day's ID (10,000 * year + 100 * month + dayOfMonth) is a column in the SQLite database and it contains an array of SugarLogs. That array is serialized into a JSON string which is encapsulated by a Day object and thus it is saved to the database (later when the day is loaded, the string is deserialized). It was done this way in order to save time and avoid complications because the SugarLog class contains all kinds of other POJOs (some of them not designed by me so I can't change them). I imagine it might be hard or even impossible to make an SQL relationship and ditch the Day class because every class and the classes/objects it contains must extend SugarRecord.

The database works perfectly fine even with serialization, albeit I think it might be nice to avoid serialization and have a full-fledged many-to-many relationship based database.

Search engine to allow the user to find logs based on a variety of queries.
This might require #11 to be resolved.

Most diabetics consult their doctor/endocrinologists regularly and they must bring a data report with them (usually a table with blood glucose levels and insulin intakes). Here, reports can be a lot more detailed (accurate times, graphs, photo thumbnails and what not...) and exported easily. This app was built with this major feature in mind.