Brew中的重入问题，谁能解释一下

[NothingRemained]

Brew的应用切换A-〉B ，A应用需要启动B应用，B起了之后又要启动A应用，这样启动的A应用是之前的上下文，怎么解决这种问题。

[hhygcy]

你现在有A和B的所有代码吗？其实这个问题很现实：）如果没有就别想了，如果有的话，可以考虑让B作为background程序启动。
看看这篇文章吧：
https://brewx.qualcomm.com/bws/content/gi/common/appseng/en/knowledgebase/docs/bg_apps.pdf

[bluegift]

[Quote=引用 1 楼 wireless_com 的回复:]
A启动B时，如果B成功启动，则A被Suspend了，B运行结束后，A被Resume继续执行。这是BREW自身的机制。
[/Quote]

二楼说得对,当A被resume后，当然是他原来的状态了，可以继续执行。brew的可重入就是为了保证你的程序随时能被suspend,下次启动时他会保证从你停止的那个状态重新执行（他的运行机制可以保证这一点）。

如果你不想让A从当前状态重新执行，那你只有kill掉它了。

[GEATA]

我没理解错的话，楼主B->A的这个A要同前面那个A不同，也就是创建第二个A的实例，如果是A是独立APP的话，好像是不能的，但是窗口是可以创建多个实例的。
可以将A的窗口做成接口，将A窗口创建于你的B APP里里面，类似于你在IE里面打开word,pdf这样。

[zsf81]

想要A不是原来的A，那么可以在启动B之前CLOSE A。又不是什么麻烦事

[FLYUP_CHEN]

在 app中的suspend 和resume中做操作就行了

[visual4825]

>Brew的应用切换A-〉B ，A应用需要启动B应用，B起了之后又要启动A应用，
>这样启动的A应用是之前的上下文，怎么解决这种问题。

Step.1
A挂起时，调用SetResumeData，向Apphistory设定复归情报，

----
B topvisible status
----
A1 suspend status
----

Step.2
进行多重启动

----
A2 topvisible status
----
B suspend status
----
A1 suspend status
----

[sunyymq]

A启动B，A挂起，B启动，B启动A，B挂起，A先记录下状态，然后关闭，再启动新的！

[l1w1w1]

绕口令呀，呵呵。

[iBug168]

[Quote=引用楼主 nothingremained 的回复:]
Brew的应用切换A-〉B ，A应用需要启动B应用，B起了之后又要启动A应用，这样启动的A应用是之前的上下文，怎么解决这种问题。
[/Quote]

不是很明白LZ的问题所在。。。

[kingfenggg]

A->B时，挂起A,启动B;
B->A时，挂起B,激活先前的A就可以了;
从而可以无限次的调用，也可以通过其他按钮关闭你想结束的A或B。

[kingfenggg]

EVT_APP_SUSPEND，挂起事件
EVT_APP_RESUME，激活事件

[lhy_hetty]

每个应用就相当与一个线程，同一时刻只能一个线程运行，
只不过是没有保存界面的状态，要在resume时重新刷新你的当前状态的界面

[nicefuture]

visual4825 回答的对。

LZ的这个需求其实是很常见的一种需求。 典型的做法就是利用单独的App History Entry来实现。 具体可以参考SDK中的IAppHistory

[cryindance]

=======================================================================
Function: AEE_EnterAppContext()

Description:
This function is used to set the application context, asserting
permissions and marking the application context as running.

Prototype:
ACONTEXT *AEE_EnterAppContext(ACONTEXT * pc);

Parameters:
pc: pointer to the new application context

Return Value:
The previous application context to later be passed to
AEE_LeaveAppContext()

Comments:
You must use AEE_LeaveAppContext() to undo and restore the
previous ACONTEXT.

Side Effects:
None

See Also:
AEE_GetAppContext(), AEE_LeaveAppContext()

=======================================================================
Function: AEE_LeaveAppContext()

Description:
This function is used to de-assert an application context and
to restore the *previously* asserted ACONTEXT.

Prototype:
void AEE_LeaveAppContext(ACONTEXT *pacRestore)

Parameters:
pacRestore: the application context to return to

Return Value:
None

Comments:
pacRestore should be the return value of a matching call to
AEE_EnterAppContext().

Side Effects:
None

See Also:
AEE_GetAppContext(), AEE_EnterAppContext()

=======================================================================
Function: AEE_GetAppContext()

Description:
This function is used to get the current application context.

Prototype:
void * AEE_GetAppContext(void);

Parameters:
None

Return Value:
Pointer to the current application context

Comments:
None

Side Effects:
None

See Also:
AEE_GetLastAppContext(),AEE_EnterAppContext(), AEE_LeaveAppContext()

=======================================================================
Function: AEE_GetLastAppContext()

Description:
This function is used to get the most recently running, non-system app context (if any).
For ex: While App A is executing, if it switches temporariy to system context (for
privilege purposes), this API can be used to determine the class ID of the app (A) that is
running while A has switched to system context.

When A has switched to system context, calling the function AEE_GetAppContext()
will not yield the app context of A since that function returns the current app-context. This
function AEE_GetLastAppContext() has to be used for that purpose.

After obtaining the AppContext, the function AEE_GetAppContextCls() can then be used to
obtain the actual ClassID of the app is running. If that returns AEECLSID_SHELL, it indicates
that the system context is currently running and there is no non-system app
executing currently.

Prototype:
void * AEE_GetLastAppContext(void);

Parameters:
None

Return Value:
Pointer to the current application context.

Comments:
None

Side Effects:
None

See Also:
AEE_GetAppContext(),AEE_GetAppContextCls

[niimp2]

回调函数.

[incaution]

[Quote=引用 14 楼 nicefuture 的回复:]
visual4825 回答的对。

LZ的这个需求其实是很常见的一种需求。 典型的做法就是利用单独的App History Entry来实现。 具体可以参考SDK中的IAppHistory
[/Quote]

谢谢，学习了。

[悠然红茶]

BREW机制中没有多实例Applet，所以B再次启动A时，只是resume A。但是我们可以把A内部的逻辑组织成多实例的。这样可以部分解决问题。当然，如果还要更进一步做到resume A之后，按照原来的逆序逐个回退Applet，也就是说A退到B，B再退到A，那么还要做更多的工作。

[twoconk]

貌似高通的这个机制并不复杂~

[malu_1982]

BREW有N种方法可以实现。

A运行 A关闭 B运行 B关闭 A启动
A运行 A挂起 B运行 B关闭 A恢复

[muwesky]

呵呵，就是反复启动。