Areas of concern for rearchitecture discussions

Android Object Design Guidelines

Android Source Format Guidelines

Prio is (mja/bc)

• Layer Generalization ( 2 / 1 ) → 1.5
  • Done 2016
  • Old model had few instances based on LayerEnum (compile time tags)
  • Newer model (SmartPlan/TrackManager) needs layers distinguished by runtime tags (names?)
  • Can create new layer and drawables for things that require project inspection by renderer. (e.g. user location).
• Code modernization ( 3 / 2 ) → 2.5
  • Remove deprecated dialog interaction in SmartsuiteActivity, etal.
  • Implement new (API 23) permission model
  • Rewrite activities to avoid needing “noOrientation” activity flagm, use savedState
  • Relace some activies with Fragments, e.g. SG Alignment, recovery, task chooser
  • 64 bit versions of the .so files (need NDK modernization?)
• NDK ( 11 / 11 ) → 11 2.5 (by lumping in with Code Modernization)
  • Use more modern NDK / Approved Gradle build scheme.
  • Strip un-needed .so files from some apps, such as Trimble from everything except for Grade/Blade
  • See 64 bit native implementation note in Code Modernization.
• Warnings: ( 9 / 4 ) → 6.5 2.6
  • Handler (replace with Runnables)
  • Processing classes
  • Reformatting of source
  • Diamond operator
  • Examine every single ToDo: Fix, ameliorate, remove
• Project class refactoring ( 1 / 6 ) → 3.5
  • App vs. AGTEK_Lib; e.g. SD vs. All, SG/SB vs. rest; not needed code
    • e.g. carry too much un-needed functionality on some apps (e.g. highway aligns in SmartPlan, etc)
    • e.g. too much inheritence from unwanted apps.
  • Too many times in which m_project must be cast to the specific class when in main activity to use app specific methods.
• Testing ( 5 / 3 ) → 4
  • Improve unit test coverage / unit test instances
  • Implement UI tests
• Alignment classes (4 / 8) → 6
  • Make easier for use in applications
  • Q: Why does an application need it's own alignment classes?
  • Q: Why is “defaultAlignment” called what it is? Isn't it just a “singlePoint” alignment, vs. a dual alignment?
  • Currently there are alignment methods in Project classes, activity classes, and projection vs. alignment: reduce
• Final isolation of graphics from Project/Layer objects ( 8 / 5 ) → 6.5
  • (no reading the project)
  • Shaders
  • No more coupling to Project class
  • Repackage to non smartsuite
• Multi thread impl to speed things up. ( 7 / 7 ) → 7
  • e.g.draping, isopach?
  • e.g. Measure volume computation parallelization
  • Action Item: identify other areas to be parallelized.
• ADF evolution ( 6 / 9 ) → 7.5
  • Define layer visibility entry
  • Define layer color
  • Allow layer properties
  • Saved measure area
  • Draw area on layers
  • Allow layers with LLA lines, not just NEZ.
  • View type structure for ADF, explicit vs. app implicit
• UI ( 10 / 10 ) → 10
  • Common bits like MeasureArea entry.
  • Better tree-view (current one has too much exposed functionality).
  • ActionItem: Identify other common UI bits.
• CachedProjectManager ( 12 / 12 ) → 12
  • Better mirror of project structure (sub folders)
  • background syncrhonization with server
  • Allow prefetch of file contents (e.g. referenced images? AKA pre-cache)

• File Hell
  • We are starting to create a classic CAD file hell: Lots and lots and lots of files and you can't recreate what you have sompleace else because there are too many local files or hidden files and you need a special export/import routine to collect them all in one place or put them back in the right places.
    • KMZ vs ADF
    • Photos
    • Notes
    • Tracks
    • Measure