User Tools

Site Tools


programming:android_rearchitecture_2016

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
programming/android_rearchitecture_2016.txt · Last modified: 2017/05/05 18:31 by mjallison