1067306 - [Contacts] Estimate current haida status in contacts

Status: RESOLVED FIXED

(Firefox OS Graveyard :: Gaia::Contacts, defect)

Description

[Francisco Jordano [:arcturus] [:francisco]]

In bug 1022646 we started working on haida, but work has been stop.

We need to estimate current work, and see what things are missing to plan haida for next sprints.

Comment 1

[Francisco Jordano [:arcturus] [:francisco]]

Here I manage to put some ideas separating the form to a document:

=====================
Contacts dependencies
=====================


Navigational changes
====================

Contacts.cancel
  - Cancel edition and transition to the contacts list

Contacts.navigation.home
  - Go back to the list after a contact delete. Replaceable by
    a message

Contacts.goBack
  - Navigation to go back after we pick the another contact for
    merging. This saves and go back. Navigation action replaceable
    by message


Utility functions
=================

Contacts.updatePhoto
  - Setup a new photo and propagate to the rest of the app
    the new photo. Can be extracted to an utility method.
    NOT A MESSAGE TO OTHER PARTS -> ISOLATED

Contacts.goToSelectTag
  - Just used in the form, we can move it outside Contacts.js

Contacts.isEmpty
  - Used to check for contacts empty fields. Used in form and
    detail. We can move this to an utility class

contacts.NFC
  - Stop listening for NFC events, we could lazy load the NFC
    class.

Contacts.confirmDialog
  - For confirmation when deleting. Lazy load the dialog html
    in theory could be extracted to an utility library


Interaction with other parts of the application
===============================================

contacts.Search
  - When deleting a contact we need to invalidate the search.
    We can replace this with a message.

Contacts.setCurrent
  - Used to notify contacts what's the current contact object selected.
    We can replace this with a message.



Deep integration (matching and mergin)
======================================

Contacts.extServices
  - Shows duplicated contacts. Check if we can lazyload or we
    need to load from scracth.

contacts.Merger
  - Right now is lazy loaded, shouldn't be a problem

contacts.Matcher
  - Lazy loaded and executed, shouldn't be a problem.


Facebook
========
Makes uses of all the facebook set of functions and postmessaages.
Wich means that we need to load the fb frames as well.


Activities
==========
form.js handles 1 activity, 'new' we dont need to load the whole activity handler,
right now we use just
ActivityHandler.currentlyHandling
ActivityHandler.postNewSuccess
We could have an activity handler just for the form. Also we need to setup the
message handler.


====
HTML
====
- We need to try to get a bare minimun html for form.html. Use the element form.html
  as content, it doesnt make sense to lazy load just that section.


================
Other objectives
================
- Avoid to load contacts.js

Comment 2

[Francisco Jordano [:arcturus] [:francisco]]

Latest work can be found here:

https://github.com/michalbe/gaia/compare/Bug946750-form-temp


Key points that I think that are important:

- Create a new document form.html
- Load the new document into the current architecture via navigation shim.
- Communication between documents via broadcast messenger shim.

Things we need to worry about:
- We have already several iframes that will be reused, and can be triggered from both documents. FB (iframes). This was causing some problems on undesired executions.

- We should trim the form.html to ideally contain just the minimun, current solution also loads contact.js
Otherwise our memory footprint will grow like crazy.

- Don't share all the code, we have activities that are a lot of code. Let's just put the specific part that each document will need.

Comment 3

[Francisco Jordano [:arcturus] [:francisco]]

I would suggest to land following the plan:

- Integrate in the current branch thew new form design.
- Clean html for the form.html
- Fix problems with frames interactions (merge, fb, etc.)
- Work on form startup (initialization with data)

I would suggest continue working on a separate branch and perform constant (every single day) rebase from master.

The task could be splitted as exposed above, and this is my estimation for them:

- Integrate the current branch (last work) with latest master: 4 points (16 hours)
- Clean html for the form.html: 2 points (8 hours)
- Fix problems with frames interactions: 3 points (12 hours)
- Work on form startup: 4 points (16 hours)

Definitely to be splitted in more than one sprint.

Comment 4

[Francisco Jordano [:arcturus] [:francisco]]

Folks,

I would need you to validate my estimations and work to be done, based on the comments on this bug.

Thanks!

Comment 5

[Jose Manuel Cantera]

hi Francisco

I see your estimations rather optimistic. This task has been deviating for a long time so we would need to be conservative with our estimations

thanks!

Comment 6

[Francisco Jordano [:arcturus] [:francisco]]

(In reply to Jose Manuel Cantera from comment #5)
> hi Francisco
> 
> I see your estimations rather optimistic. This task has been deviating for a
> long time so we would need to be conservative with our estimations
> 
> thanks!

Thanks for the feedback Jose, any proposal?

Comment 7

[Jose Manuel Cantera]

(In reply to Francisco Jordano [:arcturus] [:francisco] from comment #6)
> (In reply to Jose Manuel Cantera from comment #5)
> > hi Francisco
> > 
> > I see your estimations rather optimistic. This task has been deviating for a
> > long time so we would need to be conservative with our estimations
> > 
> > thanks!
> 
> Thanks for the feedback Jose, any proposal?

I would suggest we double those estimations, WDYT?

Comment 8

[Sergi Mansilla [:sergi] (Telenor) [PTO]]

I agree with doubling the estimeation.