Fernando Campo (:fcampo) Reporter
	Description • 11 years ago

In some cases, we need to create an Activity to access specific settings, without breaking the flow of the current app. That means that we need to keep the user on the designated path, not letting him to go around other settings, as this won't let him to go back to the original app once the changes are done (back button takes the user to the main settings page).

For doing this, we need either to create a new activity with inline disposition, or modify the existing one.

	(inactive after 6/18) Alive Kuo [:alive]
	Comment 1 • 11 years ago

I think this is one of the target of in-app navigation.
See https://bugzilla.mozilla.org/show_bug.cgi?id=922641#c4
Also c.c. Arthur.

	Arthur Chen [:arthurcc][inactive after 6/30]
	Comment 2 • 11 years ago

To support the use case we must create a new inline activity. Please be informed that inline activity of settings app is not supported as it may affects the launch time given the current architecture. I was wondering is there any schedule as this could be done much easier after settings app supports in-app navigation in the next few releases.

	Fernando Campo (:fcampo) Reporter
	Comment 3 • 11 years ago

Hi Arthur, 

the schedule for this would be v1.3, as it directly blocks one of Messaging use cases.
The specific use case I'm talking about needs to call settings app and open it on the MMS settings panel, to later go back to Messaging app not letting the user mess around with other settings.

Not being able to do this would break the app flow, leaving the user wandering around settings app instead of back to messages (only way to do this would be long press on home > apps manager > messages, or single click on home > open messages app).

To clarify the importance of not breaking the flow, or taking a decision on leaving it the way it is now, I'm gonna ping Ayman, so he can explain it better.

	Arthur Chen [:arthurcc][inactive after 6/30]
	Comment 4 • 11 years ago

Fernando, thanks for the clarification. I totally understand that this is critical to user experience.

Kaze, Evelyn, any ideas on fulfilling this request? Currently I am not able to come up a solution that can fit into the 1.3 schedule. One feasible workaround would be implementing the MMS settings panel in Messaging app in 1.3 and switching to inline activity once settings app supports it.

	Evelyn Hung
	Comment 5 • 11 years ago

Can we have a quick test to see how an inline activity will affect launch time? I will guess it's bad on the glittered UI but not slow UI.

	Fernando Campo (:fcampo) Reporter
	Comment 6 • 11 years ago

Well, for this specific case, the main problem I'm having with my tests (not using inline, just the normal window) is that current implementation of settings panels is loading the necessary files on the main panel (second level from settings main screen), so when I load a child panel (third level), I can see the structure (good html and css), but is not loading the content (not executing the js).

So apart from the test with inline activity, a bigger change is needed on settings app (at least for this specific case loading a third level panel), to try and load the necessary files on demand instead of on the main panel. Also, for this we would need to split the functions from carrier.js into the different subpanels, so we don't load everything at the same time (most of it is not gonna be used). But now that I write it, it seems like we could make another different bug from this. WDYT?

	Arthur Chen [:arthurcc][inactive after 6/30]
	Comment 7 • 11 years ago

Evelyn, to avoid glittered UI, we need to wait for the system message of the web activity and then we are able to decide what to display, and which results in poor perceived launch time. We can do some quick tests.

Fernando, you are right, we are surveying how to extract common logic from settings.js and other huge scripts to the shared folder so that we can break the dependency between panels. However, which requires lots of effort and I don't think we are able handle it and the potential regressions in this release. One option would be extracting the code of manipulating mms settings to the shared folder and use it in messaging app. Is it acceptable?

	Fernando Campo (:fcampo) Reporter
	Comment 8 • 11 years ago

(In reply to Arthur Chen [:arthurcc] from comment #7)
> One option would be extracting the code of manipulating mms
> settings to the shared folder and use it in messaging app. Is it acceptable?
With this you mean that for changing the settings we wouldn't need to call the settings app anymore but operate those settings directly from messages app?
or is it just to separate the logic on settings as you said before, but just for the messages related ones case?

If it's the former, I've been following the bug 919974, where they're proposing the same: to take all the sms specific settings out from settings and into a messages app specific screen. If so, we could add the mms settings to it.

If instead you are referring to the second option, It would work for me (I don't really mind where the code is) as long as we are able to call the screen, operate it and return directly to the caller app without being able to mess around more settings.

	Steve Chung [:steveck]
	Comment 9 • 11 years ago

Based on bug 919974 comment 22, message app will be able to open settings activity and return after user confrims the changes. But this behavor definatly need more ux input and non-trivial efforts in settings app code base changing. Hi Ayman, do you have any idea about how this flow works and deals with possible problem(for example, opening another settings app from notification center)?

	Arthur Chen [:arthurcc][inactive after 6/30]
	Comment 10 • 11 years ago

(In reply to Fernando Campo (:fcampo) from comment #8)
> (In reply to Arthur Chen [:arthurcc] from comment #7)
> > One option would be extracting the code of manipulating mms
> > settings to the shared folder and use it in messaging app. Is it acceptable?
> With this you mean that for changing the settings we wouldn't need to call
> the settings app anymore but operate those settings directly from messages
> app?
> or is it just to separate the logic on settings as you said before, but just
> for the messages related ones case?
>

I am referring to the second option, which seems to be more feasible for both sides (settings app and messaging app). Even though settings app does support inline activity and the desired panel is perfectly navigated, users may still see other settings field not related to the current work flow in the same panel. Thus I would suggest to implement the panel in messaging app so that you can customize the panel to fit the work flow.

> If it's the former, I've been following the bug 919974, where they're
> proposing the same: to take all the sms specific settings out from settings
> and into a messages app specific screen. If so, we could add the mms
> settings to it.
> 
> If instead you are referring to the second option, It would work for me (I
> don't really mind where the code is) as long as we are able to call the
> screen, operate it and return directly to the caller app without being able
> to mess around more settings.

	Fernando Campo (:fcampo) Reporter
	Comment 11 • 11 years ago

(In reply to Arthur Chen [:arthurcc] from comment #10)
> Thus I would suggest to implement the panel in messaging app
> so that you can customize the panel to fit the work flow.
That sadly doesn't seem like an option after bug 919974 comment 22, as steve stated.

	Arthur Chen [:arthurcc][inactive after 6/30]
	Comment 12 • 11 years ago

(In reply to Fernando Campo (:fcampo) from comment #11)
> (In reply to Arthur Chen [:arthurcc] from comment #10)
> > Thus I would suggest to implement the panel in messaging app
> > so that you can customize the panel to fit the work flow.
> That sadly doesn't seem like an option after bug 919974 comment 22, as steve
> stated.

It seems like we need to go for supporting inline activity.

I wonder how does the inline activity work? To support AC3 in bug 919974, we might need to tweak the current message setting panel so that users won't see APN settings or other setttings not related to reading receipts. Is that what you have in mind?

	Fernando Campo (:fcampo) Reporter
	Comment 13 • 11 years ago

(In reply to Arthur Chen [:arthurcc] from comment #12)
> It seems like we need to go for supporting inline activity.
> 
> I wonder how does the inline activity work? To support AC3 in bug 919974, we
> might need to tweak the current message setting panel so that users won't
> see APN settings or other setttings not related to reading receipts. Is that
> what you have in mind?

Not exactly. I don't see any reason to hide the rest of settings, as long as they are related with messaging.

What we need so far is to be able to call the subpanel 'carrier-mmsSettings', and that this panel loads the values for the settings correctly (right now it doesn't, because most of the js files needed are loaded in the parent panel -carrier-, which we don't load).

Once it's loaded and the user does what he intended to, we need that the back button close the settings app and goes back to messages app (right now it goes to the setting main panel, and let's the user mess around with other non related settings). This is the use for inline.

Hope this helps.

	Ivan Tsay (:ITsay)
	Comment 14 • 11 years ago

It's risky to do this in v1.3 since the there is no concrete solution for this issue so far. Remove 1.3? flag.

	Fabien Cazenave [:kaze]
	Comment 15 • 11 years ago

I’m afraid I can’t help on this bug. Too much work on Comms. :-(

	Tim Guan-tin Chien [:timdream] (please needinfo)
	Comment 16 • 10 years ago

Is this still valid?

	Arthur Chen [:arthurcc][inactive after 6/30]
	Comment 17 • 10 years ago

This had been completed when bug 1007600 landed.