Closed Bug 1037573 Opened 10 years ago Closed 7 years ago

[v2.1] Feature Proposal: Text Search in Messages App

Categories

(Firefox OS Graveyard :: Gaia::SMS, enhancement)

Product:
Firefox OS Graveyard
Component:
Gaia::SMS
Platform:
ARM
Gonk (Firefox OS)
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: Mozilla_BEC, Unassigned)

References

Details

(Keywords: feature) 

I'd like to see the Search field from the Email app make its way into the Messages app.

Naturally, the idea of having the search field show up when at the top of the list doesn't work for the Messages app's UI/UX as the user would have to scroll an incredibly long distance.

Instead, I propose that the search field be put as an option under the ... menu.

Alternatively, it could be made to work by tapping on a small search glass / loupe icon on the right part of the banner that contains the Mobile, ######### code.

As a final alternative, a simple tap + hold in the empty conversation space / background could work to call up the search field.
We eventually want a search functionality but we're not sure yet how we'll do it. One likely possibility is to integrate it within the new rocket bar.

I'm not sure we have an open bug for this so I'm keeping it open for now.
If the rocketbar is going to function like webOS' Universal Search or Just Type feature, then you have my 100%, unconditional support.

If not, expect more feature suggestion bugs :)
Hey Jenny, just want to know if that's the direction you have too.
Flags: needinfo?(jelee)
(In reply to Julien Wajsberg [:julienw] (PTO Monday 14th July) from comment #3)
> Hey Jenny, just want to know if that's the direction you have too.

Hmmm yes, search is always a nice to have feature.
Adding Wilfred to take a look at this =)
Flags: needinfo?(jelee) → needinfo?(wmathanaraj)
I mean, is this how you think the search should be implemented (in the rocket bar only) ?
(In reply to Julien Wajsberg [:julienw] from comment #5)
> I mean, is this how you think the search should be implemented (in the
> rocket bar only) ?

From what I know, it seems integrating local app search in the rocket bar is not in the scope (for now anyway). Though I think it makes sense to do that.
blocking-b2g: --- → backlog
Flags: needinfo?(wmathanaraj)
Hey Bevis,

I can see 2 solutions to this.

Short-term solution:
* first add a new function to the Gecko API (and add IDB indices in Gecko)
* then use this new function in the application

Long-term solution:
* move all data to a DataStore
* add indices inside Gaia

What do you think?
Flags: needinfo?(btseng)
(In reply to Julien Wajsberg [:julienw] from comment #8)
> Hey Bevis,
> 
> I can see 2 solutions to this.
> 
> Short-term solution:
> * first add a new function to the Gecko API (and add IDB indices in Gecko)
> * then use this new function in the application
> 
> Long-term solution:
> * move all data to a DataStore
> * add indices inside Gaia
> 
> What do you think?

Both are doable.

Instead of creating indices in the DB currently we have, I'd like to suggest a better approach for this:
1. It will be more flexible for gaia to create another DB(could be IDB/DataStore) just for searching.
2. This decouples the dependency between the searching algorithm from the implementation of MobileMessageDB.
3. What gecko has to do in current design is to ensure that gaia will always be aware of the update of the MobileMessageDB. (If we rely on the |sms-xxx| system messages we have, a new system message for |sms-deleted| shall be required for this.)
2. Then, in this case, gaia will have more flexibility to add/remove the interesting fields at anytime from original message DB into this searchable DB to support this search function. (Even the MMS attachments (text) can also be taken into consideration if needed.)
Flags: needinfo?(btseng)
> a new system message for |sms-deleted| shall be required for this.

Either a new system message, or a way to get the deleted id since last time (but this starts to look like datastores, right ? :) )

How difficult would it be to just store the messages in a DataStore, while keeping the current DB? This could allow to slowly move to a DataStore-based application?
Flags: needinfo?(btseng)
(In reply to Julien Wajsberg [:julienw] from comment #10)
> > a new system message for |sms-deleted| shall be required for this.
> 
> Either a new system message, or a way to get the deleted id since last time
> (but this starts to look like datastores, right ? :) )
Yes.
> How difficult would it be to just store the messages in a DataStore, while
> keeping the current DB? This could allow to slowly move to a DataStore-based
> application?

Are you talking moving all the message from gecko to gaia into a DataStore?
Except the deleting operations, data migration with currently API and the system messages we have is doable, IMO.

However, the real challenge is the problem mentioned by Vicamo earlier while discussing the re-implementation of SMS/MMS DB with DataStore in dev-webapi mail-list:
https://groups.google.com/forum/#!msg/mozilla.dev.webapi/7fSvp7Dklwk/YdWSBcTbYMEJ
which introduces more dependency between gaia/gecko to comply these SMS/MMS transaction flows. :(
Flags: needinfo?(btseng)
(In reply to Bevis Tseng [:bevistseng] (btseng@mozilla.com) from comment #9)
> (In reply to Julien Wajsberg [:julienw] from comment #8)
> > Hey Bevis,
> > 
> > I can see 2 solutions to this.
> > 
> > Short-term solution:
> > * first add a new function to the Gecko API (and add IDB indices in Gecko)
> > * then use this new function in the application
> > 
> > Long-term solution:
> > * move all data to a DataStore
> > * add indices inside Gaia
> > 
> > What do you think?
> 
> Both are doable.
> 
> Instead of creating indices in the DB currently we have, I'd like to suggest
> a better approach for this:
> 1. It will be more flexible for gaia to create another DB(could be
> IDB/DataStore) just for searching.
> 2. This decouples the dependency between the searching algorithm from the
> implementation of MobileMessageDB.
> 3. What gecko has to do in current design is to ensure that gaia will always
> be aware of the update of the MobileMessageDB. (If we rely on the |sms-xxx|
> system messages we have, a new system message for |sms-deleted| shall be
> required for this.)
> 2. Then, in this case, gaia will have more flexibility to add/remove the
> interesting fields at anytime from original message DB into this searchable
> DB to support this search function. (Even the MMS attachments (text) can
> also be taken into consideration if needed.)

Sorry to jump in :P
Just want to say that I totally agree with Bevis's comment - This decouples the dependency between the searching algorithm from the implementation of MobileMessageDB. IMO, we shouldn't add more dependency b/w app UI behaviour (searching is one example) and gecko API implementation. So Julien's option 2 (the ultimate aim) and Bevis's suggestion (a transient stage before the ultimate aim) look a right direction to go.
(In reply to Bevis Tseng [:bevistseng] (btseng@mozilla.com) from comment #11)
> (In reply to Julien Wajsberg [:julienw] from comment #10)
> > > a new system message for |sms-deleted| shall be required for this.
> > 
> > Either a new system message, or a way to get the deleted id since last time
> > (but this starts to look like datastores, right ? :) )
> Yes.
> > How difficult would it be to just store the messages in a DataStore, while
> > keeping the current DB? This could allow to slowly move to a DataStore-based
> > application?
> 
> Are you talking moving all the message from gecko to gaia into a DataStore?
> Except the deleting operations, data migration with currently API and the
> system messages we have is doable, IMO.
> 
> However, the real challenge is the problem mentioned by Vicamo earlier while
> discussing the re-implementation of SMS/MMS DB with DataStore in dev-webapi
> mail-list:
> https://groups.google.com/forum/#!msg/mozilla.dev.webapi/7fSvp7Dklwk/
> YdWSBcTbYMEJ
> which introduces more dependency between gaia/gecko to comply these SMS/MMS
> transaction flows. :(

Thanks for the link, I think I missed this thread :) But I see it was agreed at the end that Gecko will write to this Datastore, so maybe a migration path could be that Gecko keeps the current DB _and_ write to the DataStore?

The goal is that we don't need to change all the gaia application and can migrate during several releases.

There could be performance penalty in doing this though... Maybe we don't need to wait for the DataStore write if we wait for the DB write (or the other way around)?
Flags: needinfo?(btseng)
(In reply to Julien Wajsberg [:julienw] from comment #13)
> (In reply to Bevis Tseng [:bevistseng] (btseng@mozilla.com) from comment #11)
> > (In reply to Julien Wajsberg [:julienw] from comment #10)
> > > > a new system message for |sms-deleted| shall be required for this.
> > > 
> > > Either a new system message, or a way to get the deleted id since last time
> > > (but this starts to look like datastores, right ? :) )
> > Yes.
> > > How difficult would it be to just store the messages in a DataStore, while
> > > keeping the current DB? This could allow to slowly move to a DataStore-based
> > > application?
> > 
> > Are you talking moving all the message from gecko to gaia into a DataStore?
> > Except the deleting operations, data migration with currently API and the
> > system messages we have is doable, IMO.
> > 
> > However, the real challenge is the problem mentioned by Vicamo earlier while
> > discussing the re-implementation of SMS/MMS DB with DataStore in dev-webapi
> > mail-list:
> > https://groups.google.com/forum/#!msg/mozilla.dev.webapi/7fSvp7Dklwk/
> > YdWSBcTbYMEJ
> > which introduces more dependency between gaia/gecko to comply these SMS/MMS
> > transaction flows. :(
> 
> Thanks for the link, I think I missed this thread :) But I see it was agreed
> at the end that Gecko will write to this Datastore, so maybe a migration
> path could be that Gecko keeps the current DB _and_ write to the DataStore?
> 
Yes, once DataStore API could be accessed inside Gecko, we could start the DB migration.
> The goal is that we don't need to change all the gaia application and can
> migrate during several releases.
> 
> There could be performance penalty in doing this though... Maybe we don't
> need to wait for the DataStore write if we wait for the DB write (or the
> other way around)?
If the DB migration will be done at once from indexedDB to DataStore before any access to the MobileMessageDB, then there shall not be any impact to the searchable DB in gaia, IMHO.
Flags: needinfo?(btseng)
(In reply to Bevis Tseng [:bevistseng] (btseng@mozilla.com) from comment #14)
> > There could be performance penalty in doing this though... Maybe we don't
> > need to wait for the DataStore write if we wait for the DB write (or the
> > other way around)?
> If the DB migration will be done at once from indexedDB to DataStore before
> any access to the MobileMessageDB, then there shall not be any impact to the
> searchable DB in gaia, IMHO.

I meant: if we need to write both to DataStore and IndexedDB when receiving a message, or sending a message, or other operations that I don't know yet (mark as read?), then there can be a performance issue.
blocking-b2g: backlog → ---
tracking-b2g: --- → backlog
Mass closing of Gaia::SMS bugs. End of an era :(
Status: UNCONFIRMED → RESOLVED
Closed: 7 years ago
Resolution: --- → WONTFIX
Mass closing of Gaia::SMS bugs. End of an era :(
You need to log in before you can comment on or make changes to this bug.