By MarcusWolschon
Android app has wrong navigation
Bug: The Android App has a custom written, iOS like navigation. It does not match the Android Design Guidelines and Material Design. https://developer.android.com/design/index.html It uses an iOS-like "back" button, where an "up" navigation should be. It uses gradients where the Material Design calles for flat surfaces. It shows results in the action bar and not a single action. It uses custom numeric keyboards that lack the decimal separator of the user's language. It uses a custom number format instead of the default number format of the user's locale. The "help" page explains the term "Depth of Cut" while the tab actually contains "DOC". The unit of the feedrate and cutting speed can not be chosen to match the machine-control software (m/min, mm/min, m/h, mm/h)
MarcusWolschon
From the angle of a professional Android developer this app looks like terrible craftsmanship. Like a team with a few seasoned machinists from a deeply imperial-based country but in dire need of help from at least a single actual Android devloper (and probably also a designer and an experienced, professional tester). It was probably written using one of these dreaded "cross-platform" tools that by default always create apps their look and behave different from what the platform demands.
Eldar Gerfanov (Admin)
I am not going to respond to questions like "why does your app look crappy to me" I could have made it look better (see FSWizard.com) but frankly I just don't care about whether looks match the android guidelines. The question I have to ask before doing anything is "will it make it more useful and sell better?" Do you have any feedback or questions on the functional part?
MarcusWolschon
This is not looks, it's navigation, localisation, input and a11y. That simply is not an Android app but an iOS app that happens to run on Android throwing out well working and established UI concepts for it's own, limited and implementation. As for features... the desktop app can safe material+curtting parameter sets. Having the full power of embedded SQLite provided by the system and a even a link to the user's license (simple via Google Play License Service or self-written) and to the offer of saving app-data on his/her Google Drive via Play Services to be shared between all Android devices of the user.... this should be trivial to implement on the Android app. Marking some materials as prefered, to be listed at the top, would make searching on the small screen easier. You mentions not having the KiloWatt -limit of the desktop app implemented in the Android app. Since you have access to the (Google Play or self-written) license service, that shouldn't be too hard. For a device that's online 75-90% of the time, sharing data with the desktop app would be a reasonable step. If the math on the Android app is simpler, at least machine limits and prefered material+cutter selections would go a long way. On Configuration-Changes such as Screen-Orientation+Size the entire screen blacks out for at least half a second on a high powered 2xquadcore device. Either the LayoutManagers are stacked too deeply (something you would do before the introduction of the ConstraintLayout) or you used some kind of HTML based layout with non-native components. The later would explain why l10n is not working and this app uses different numerical representations and decimal separator-inputs as everything else on the phone. Forcing the user to type the thousands-separator (.) instead of the decimal separator (,) in respective locales. Obviously translations would drive sales. Letting engineers and hobbyists (who have no values from experience and thus refer to a calculator to find the limits of their machines) in other countries use familar wordings and material-names. I already mentioned a lof of functional changes in the initial posting.