Gaia/New-Architecture-Program/Contacts/FxOS-S2(10 Jul)

From MozillaWiki
Jump to: navigation, search

General info

  • Members
    • Borja Salguero (DEV)
    • Fernando Campo (DEV)
    • Jorge Prudencio (DEV)
    • Manuel Casas (DEV)
    • Alberto Villena (QA)
    • Maria Oteo (EPM)
  • Meetings:
    • Daily happening everyday in Mumble at 10:30 CEST
    • Sprint Planning, on Monday (every two weeks)
  • Links of interest:

Sprint objectives

  • Last sprint we were focused on having a demo in Whistler where these basic form (NEW) and details (OPEN) could be shown as self contained views. During this sprint FxOS-S2 we need to land all this code in master. For that we need to:
    • Land all the pending bugs from last sprint relative to make Contacts app more modular.
    • Include tests for the WIP patches that implement NEW and UPDATE activities.
    • Test these patches by QA team before they land in master (at least exploratory testing) to ensure that no major regressions are introduced

Besides, we would like to start with these tasks if we have time:

  • Creating a new library /shared folder with the navigation model that we presented in Whistler. This library should be plug-gable so other apps can use it. Manu working on it, he's doing it as a Gaia component , see his Repo for more info.
  • Start implementing other activities as matching_contacts.html, import...

Bugs for this sprint

No results.

0 Total; 0 Open (0%); 0 Resolved (0%); 0 Verified (0%);

Other bugs to pay attention

Daily meetings

Issues during the sprint

  • After talking with Francisco we have agreed on:
    • View Separation(/views/$VISTA/), following these assumptions:
      • Boot will load the UI and its controller (different controllers for the same UI). Controller selection can be based on HASH or any other parameter.
      • Independent UI based on events. This will allow us to change the controller in the future.
      • The UI will render and work without the Controller help.
      • The Controller makes the operations with ContactsService and decides when we finish them.
      • Matcher, launch activities, import.... depend on the Controller
      • Nomenclature: $VISTA_ui.js, $VISTA_controller.js
      • Avoid this bad Practice: var $function = function $function() in the code
    • Navegation
      • First pre-render version is ongoing and Vivien wants to land it in the following weeks
      • The navigation that we showed in our Contacts prototype in Whistler based on the URLs navigation, and in the absence of a specific UX, is now the way forward.
      • They have asked us to create a plug-gable navigation library so other apps can use it.
      • We can now add the views and use SessionStorage and when Vivien's pre-render is ready, the current 'flickering' will be fixed
    • Confirmed that the issue reported in Bug 1176712 is a bug and we could have two activities with same name and different filters.
    • Views priority:
      • #new, #open, #details, #import...
      • matching_contacts.html, import... and similars
      • Settings
    • FB Datastore
      • We can not eliminate FB from the Datastore, we need to wait SMS and Dialer to remove it first.
      • We should wait before removing it in our manifest but we can start eliminating:
      • Redirects in the Manifest. Done it when eliminating FB toggle in the FTU (see bug )
      • APP_ID in the BUILD process
    • FB Buttons in contact details, included Link Contact that right now is not disabled when no FB sync, that it seems it's a bug (see
  • Contacts out of Communications (in /Contacts folder) communication Done
    • Francisco will send an e-mail to agree in the following actions (specially with UX team):
      • Change absolute paths to relative ones
      • Separate Contacts out of Communications and adjust the Build process
      • Eliminate Contacts from the navigation bar (if we remove Contacts, only Call Log and Dialpad would be available).
        • The current proposal includes maintaining the Contact button but launching a pick activity. Mozilla (PM and UX) will have to confirm if that is ok with them or if they have others alternatives.
  • First version of the self-contained matching view by Manu:
  • Vivien sent the first version of the pre-render:
  • Confirmed working week in Paris from 3rd to 7th August.



Actions taken from last sprint

See also for more detail:

Things that went well

  • All the sprint objectives achieved, the only pending thing is landing #open activity when tests pass.

Things that went not that well

  • Blocked in some revisions due to holidays, peer's workload...
  • Many problems when treeherder: there have been some changes that imply higher versions of npm, phyton...
  • It's been necessary deactivating some tests to land some of the patches, QA team is overloaded and they have not time to update or modify the tests quickly.

Actions for this sprint (apart of the Sprint Objectives)

  • Raptor vs Marionette:
    • AP1:Check Alberto repos to verify the performance measures extracted and printed using marionette. The idea is sharing it with Raptor team.
    • AP2:Follow-up meeting with Eli to share with Raptor team, NGA Contacts's needs and also check the progress of bug 1169775
  • Development Synchronization is necessary: weekly meetings, or weekly mails so everybody is aware of the changes and progress in the NGA libraries.
    • AP3:Vivien sent a complete update via dev-gaia list last 19th June but we need to ensure that this sync continues after Whistler ww.
  • AP4:Create a demo branch where we can play/test the ongoing work (no for QA testing) that can help us to:
    • detect future issues
    • We have agreed creating two repos:
      • Production one: we will wait to create it when all the bugs pending to be landed in this sprint (FxOS-S1) are merged in master (specially the relative to open and new activities)
      • Development one: it will be based on Whistler demo branch:
  • AP5:Regarding vcard importing (check, we are asking Francisco how to proceed with this, should we maintain the current behaviour? Specially for the single contact vcard importing. Or are they planning to unify it? (See Bug 1175505 and Bug 1149938)
    • We have also created this excel to see the Contacts activities that other apps in Gaia are using: We think that deprecating Import and using Open for importing from BT and NFC could unify the code, the functionality and the shown UI.
    • Done, It's been agreed with Francisco, that we should deprecate "import" activity and reuse "open" in the same way that it's done when importing from e-mail or sms application. Fernando is preparing a plan to do it to be shared with Francisco.
  • AP6: We need to clarify with Francisco who is gonna to take care of the 2.5+ bugs in Contacts application. Nobody is fixing them and the list is growing ( Done We will fix the regressions (2.5+) that can be introduced due to NGA porting, but our main target is focusing on the NGA objectives.
    • If we have time, and while cleaning code, we can try to fix older 2.5+ bugs but it's a nice to have.
    • Francisco has already asked for more resources in Mozilla to help resolving 2.5+ bugs in Dialer and Contacts applications.