12-12-2014 18:09
12-12-2014 18:09
The ids of food logs have now exceeded the maximum signed 32 bit integer (2,147,483,647) and are expected to exceed the maximum unsigned 32 bit integer (4,294,967,295) in the next quarter. Application developers are advised to accept 64 bit unsigned integers for food logs.
Affected endpoints: Log Food, Get Food Logs, Delete Food Log
12-28-2014 08:31
12-28-2014 08:31
12-28-2014 08:37
12-28-2014 08:37
12-30-2014 16:16
12-30-2014 16:16
Hi Wowie,
Where are these logs from? This indeed may be related and we're trying to push out updates to all of our mobile apps.
@Wowie wrote:
This is rather frustrating since the UI is a clunky piece of junk to begin with
Ya know, we're real people over here. I'm sorry that you're upset, but please keep your criticism constructive.
12-30-2014 22:01
12-30-2014 22:01
The Logcat isn't related, because it happens without the flaw in question expressing itself. This is not an external application's log, if that's what you're interested in.
The line that may be of interest however is near "PackageManager: Failure retrieving resources..." It's a Warning level error. There's strange user-facing issues that are being discussed: https://community.fitbit.com/t5/Android-App/App-not-showing-accurate-info/td-p/580210
To be more clear, logging calories is fairly time consuming. The search box isn't very responsive, and it's often difficult to find the food I'm looking for (which is incredible given the quantity of entries). Back a step, the lists (which are effectively duplicates) of "Most Recent" and "Most Often" is completely redundant, and makes the list on that page effectively useless, since scrolling all the way to the top or bottom means basically nothing. By the way, showing the "Most Recent" item first on the list is almost in conflict with your construct of having the users type in the portion that they ate in units of oz / eclairs / etc. And really, every good UI design since the 2000's puts either a very condensed "Most Often," the user's "Favorites", or both front and center. Back another step up, putting the search button behind the "+" button is completely redundant. Really wouldn't it be pretty easy to put a searchbox there, and spare us waiting on whatever database pinging or confirmations the app decides to do at that point? Pane-switching is fairly slow on every cell phone UI. And seriously, I've got a phone that's like 2 years old, and every time I click that "+" button, the screen flicks "No common foods yet."
1.) Add an optimized search box to the calories log.
2.) Change "Common Foods, My Foods" to "My Foods, Most Recent, Most Often" or something like that, and probably make it user-customizable.
3.) Fix the search box in the first place. Why is it that when I type in "Mcd" I get a full page of results where that isn't even a substring of any of the results, and one local result that I had to created previously? That's madness!!
01-05-2015 07:58 - edited 01-05-2015 08:01
01-05-2015 07:58 - edited 01-05-2015 08:01
Good, still difficult for my tastes though since macros are only found on the web anyway. Good work though. Hopefully the new found quality doesn't overwhelm your servers and inconvenience many lol.
E: I love it!