helyoWAP

Autor: Helio Fonseca Rosa

Esta página contém muitas figuras. Aguarde a carga se a conexão estiver lenta.

O conceito de "atividades" ou "contextos" da Phone.com

A empresa Phone.com (ex-Unwired Planet - daí a sigla UP)  inventou a HDML (Handeld Devices Markup Language) que deu origem à WML.
Na documentação do UP.SDK da HDML havia referência à procedimentos avançados que visavam tornar os programas mais estruturados. Definia-se então o conceito de ATIVIDADE , que podia ser entendida como uma tarefa ou um conjunto de tarefas. Estando em uma atividade, era possível definir e/ou  desviar o programa para uma atividade embutida ou aninhada dentro dela (uma "sub-atividade"). Dentro desta atividade mais interna era possível definir novamente uma atividade ou  mais atividades interiores, resultando em vários níveis de processamento embutidos. 

[Em tempo: estou usando os verbos no passado pois comecei a estudar programação "wireless" pela HDML,  até "descobrir" a existência de sua sucessora , a WML. No entanto, a HDML está bem viva, nos celulares pioneiros neste tipo de serviço e (de modo transparente para o usuário) nos gateways e celulares WAP utilizados no Brasil, até a data desta publicação. A HDML é anterior ao padrão WAP.]

Nas nossas aplicações rotineiras já utilizamos  procedimentos "semelhantes" , por exemplo, quando um card "chama" ou se desvia para um segundo card e este se desvia para um  terceiro. Mas isto tem ocorrido num mesmo nível.

Na documentação do UP.SDK da Phone.com sobre WML este conceito de "atividade" mudou de nome para "contexto".

A Phone.com criou "extensões" da linguagem WML para poder implementar este conceito de "contexto". Até o momento não tenho conhecimento se os softwares de outras empresas também utilizam esta implementação ou a suportam.

As  "extensões" utilizadas na implementação dos "contextos" são : <spawn>, <send>, <receive>, <exit> <reset>, <catch> e  <throw> .

Neste início de página vamos comentar um pouco o elemento <spawn> antes de apresentar os programas que o utilizam.
O potencial do elemento <spawn> não pode ser bem avaliado em programas de estruturas simples. Num programa mais complexo, com vários níveis de tarefas ( "atividades" ou "contextos")  fica evidente seu poder de organizar o programa de uma forma estruturada. 
 Esta organização pode ser observada com muita paciência e atenção no registro histórico do processamento do programa encontrado na janela "Phone Information" que acompanha o UP Simulator. Este tipo de análise não cabe nesta página de estudos iniciais. Talvez mais adiante.
Numa aplicação simples, o elemento <spawn> pode ser entendido como um substituto do <go>, efetuando desvios programados. O <go> produz um desvio para o mesmo nível de processamento. O <spawn> produz um desvio para um nível inferior;  na verdade, ao utilizá-lo já estamos definindo a existência deste nível mais interno.
Imagine um programa principal que, de repente, executa um desvio para um programa secundário (ou sub-programa ) onde é executada alguma tarefa, que envia ou não dados de volta para o programa principal, que prossegue, então, em seu caminho normal.  
Leia mais sobre este assunto, na "fonte" : "Chapter 2: Doing more with WML" na documentação UP.SDK Developer's Guide"  que acompanha o download do produto ou on-line, no site da Phone.com.

Programa Phone23.wml 

Objetivo: Imaginemos  que há um card (secundário) que contém uma mensagem indicando um erro ocorrido (no momento não estamos preocupados como este card foi montado, quem sabe por uma aplicação dinâmica tipo ASP). Desejamos que um card principal faça um desvio para este card secundário (ou "sub-card") e traga esta mensagem para ser exibida em sua tela. Após esta exibição, deve ser possível efetuar um novo desvio para outro card secundário que retorne ao card principal uma mensagem em branco para funcionar como "apagador" ou "limpador" da mensagem já exibida. Eis a seqüência de telas:

----> 

--> -->

Phone23.wml (código):

<?xml version="1.0"?>
<!DOCTYPE wml PUBLIC "-//PHONE.COM//DTD WML 1.1//EN"
"http://www.wapforum.org/DTD/wml_1.1.xml">
<wml>
<card id="principal">
<do type="accept" label="Mensagem">
<spawn href="#msg_erro">
<receive name="codigo_erro"/>
<receive name="nome_erro"/>
</spawn>
</do>
<do type="options" label="Apagar">
<spawn href="#apaga_erro">
<receive name="codigo_erro"/>
<receive name="nome_erro"/>
</spawn>
</do>
<p align="center">
** helyoMOBILE **<br/>
(tela principal)<br/>
Foi encontrado o seguinte erro: 
</p><p align="left">
<b>Codigo: $(codigo_erro) <br/>
Nome: $(nome_erro)</b>
</p>
</card>

<card id="msg_erro">
<do type="accept">
<exit>
<send value="99"/>
<send value="Inv. Key"/>
</exit>
</do>
<p align="center">** helyoMOBILE **<br/>
Retornando mensagem de erro para tela principal...</p>
</card>

<card id="apaga_erro">
<do type="accept">
<exit>
<send value=""/> 
<send value=""/>
</exit>
</do>
<p align="center">** helyoMOBILE **<br/>
Retornando mensagem em branco para tela principal: apagando mensagem de erro...
</p>
</card>
</wml> 

(A listagem acima foi copiada/colada/gravada e testada no UP Simulator)

Comentários:
Este é um programa com um deck e três cards.
O elemento <spawn> define dois níveis de contexto, como na figura abaixo (estão representados os <card id="principal">, <card id="msg_erro> e <card id="apaga_erro>):

A operação do programa é a seguinte: exibida a tela inicial (produzida pelo <card id="principal">, pressiona-se a tecla "ACCEPT" cujo label é "Mensagem";   a programação desta tecla, a cargo agora da dupla "do" / "spawn" faz um desvio para o <card id="msg_erro">.  
O usuário poderia nem perceber a existência deste card se senão fosse a exibição da mensagem "Retornando mensagem de erro para tela principal..." , incluída aqui somente com este objetivo (este seria então um "no-display card, de utilização possível , mas perigosa , pelos erros também "ocultos" que podem surgir).
Pressionada a tecla com o label "OK" abre-se novamente a tela principal.
Os dados sobre o erro são enviados de volta para o <card id="principal"> e quem faz esta conexão é a dupla "send" / "receive" . 
A tela principal é exibida  agora com a mensagem de erro.  Vamos então pressionar a tecla "OPTIONS" cujo label é "Apagar". 
A dupla "do" / "spawn" desta tecla agora faz o desvio para outro card "secundário", o <card id="apaga_erro"> . 
Este card é idêntico ao comentado acima, claro, mudando o que deve ser mudado, ou seja, há um aviso intermediário e vai ser enviada à tela principal uma mensagem em branco; mais precisamente, as variáveis que continham os dados de erro recebem um novo valor, um "branco" ou "vazio" ("empty string").
Os elementos "send" / "receive" fazem uma boa dupla, como já vimos, e bem descomplicada, por sinal : comunicam-se de acordo com a ordem em que aparecem no programa. Vejam a correspondência: "codigo_erro" --> "99"    e   "nome_erro" -->  "Inv.Key".
*************************************
<receive name="codigo_erro"/>
<receive name="nome_erro"/>
*************************************
<exit>
<send value="99"/>
<send value="Inv. Key"/>
</exit>
************************************
Dizemos que estes elementos são responsáveis pela comunicação entre um contexto externo (contexto-pai) - no caso o <card id="principal"> e o <card id="msg_erro"> (contexto-filho).
O elemento <exit> ( "saida") faz isto mesmo que você está imaginando ; encerra a tarefa no contexto-filho (interno) e  envia os dados para o contexto-pai (externo) . O contexto é eliminado, isto significando que suas varáveis e o próprio histórico são apagados.
Apesar de já ser assunto estudado, não custa chamar a atenção para as variáveis : seus nomes são "codigo_erro"  e "nome_erro" e seus conteúdos são referenciados como  $(codigo_erro) e $(nome_erro) .