[res005ru@verizon.net]

In creating a new app, each page is created and when exported a <page name>_export directory is created. Fine so far. Now add new java script functions to a screen in its XXX_custom.js file.

In this case I have phone number page, to allow user to type in phone number and then select a call buttom to make the call. The call buttn markup is below:

<div id=”m1-HandTalkDialPhoneNumber-MakeTheCall” class=”m1-clickable m1-hyperlink m1-button”
name=”MakeTheCall” href=”javascript:GetPhoneNumber()”> Call</div>
<img id=”m1-HandTalkDialPhoneNumber-PhoneImage” class=”m1-hyperlink” src=
“res/images/75-phone.png” href=”"javascript:GetPhoneNumber() "”/>
</div>

" is not required as my java script returns a string such as “tel:2145582819”
code:
function GetPhoneNumber()
{
var tel = “tel:” + $(“input”).val();
return tel;
}

Removing the " in the html file will work and dial the phone.

It would seem you would have one directory for each page in the app and only html,css
and js files for that page only in the _export directory.

If I remove all files not part of the start page of my app and then rebuild by export
None of the new modifications made in the HTML page and XXX-custom.js are there in the
new build

So, if you build each page individually, you are ok, however build all into the app start directory,
all html .css and script files are built from your initial build scripts, not from the XXX-export directory. This seems to be a major problem.

Or am I all wet, standing in the rain, and need more educating here as to proper build
procedures.

Rick

[support-michael]

<Long>
In an upcoming release MobiOne will provide a much more explicit design and resource management model, i.e., projects, page-flows, … Until that time a MobiOne app is comprised of a main or startup page design file (.mobi) and the transitive closure of any additional design pages that it links to, i.e., a connected graph. When you run or export this main page design file, MobiOne generates the code for it and its linked design files into a common directory.

Example:
Linked Design Files: D1>D2>D2
Generated code (using Run In Test Center):
D1_export/
D1.html
D2.html
D3.html
D1.css
D1.js
D1_custom.js
<other resources not listed>

If during your development you run and test a secondary design page, (e.g., D2) MobiOne will generate html resources for it independent of your main design page.

Example:
D1_export/
D2_export/
D2.html
D2.css
D2.js
D2_custom.js

Limit all of your customizations to only the resources generated from your main design page. Customizing resources generated from a sub-design pages will have no effect on your app.

The reason for this limitation is that MobiOne generates an AJAX webapp architecture and requires visibility to all of the design pages during the code-generation phase. My understanding is that it would be a hairy, if not impossible, process to reliably merge customized code from previously generated pages that may be invalidated by more current design changes.

I’m personally very interested to see introduction of project and app concepts to provide much better management tooling and less confusion.

Wayne
Genuitec Mobile Team

[res005ru@verizon.net]

Wayne

Thanks for your reply. When will that release be ready, ballpark from right field,
I know you and your team are busy. Second, if I understand correctly, I need to
put all of my designs from the .mobis’ in the startup directory.

Rick

[support-michael]

Last Q first – Tips:
1) Create a directory for your app and locate all resources in this directory
Your design files can reside anywhere on disk but a best practice is to colocate them in the same directory. That is, treat the common directory as your project resources.

2) Only customize files exported from your app’s main (startup) design file
That is, if your app consists of linked designs D1>D2>D3. D1 is your app’s startup design file. Export it explicitly using the File>Export action or the Run in Test Center action to generate corresponding HTML for D1 and all linked designs. For example if during testing you export D2 or D3 independently, a subsequent D1 export will have no knowledge of the prior D2 or D3 generated code.

Second question is that we are working as quickly as we can to improve the overall MobiOne experience as well as introduce new device support such as iPad tablets. Early to mid-April is the timeframe for the 1.2 update.

Wayne
Genuitec Mobile Team

[res005ru@verizon.net]

Wayne

Thank you for your help, from this help I will rearrange this code. I eagerly await the new code base,
and I assume others too :). I do really like what has been built so far and my customer also is impressed
with how fast we have created and exported to the IPhone. I know this must be a lot of work and your team
is probably running around like chickens who have lost their heads. Keep up the great work.

Rick

[Author]

Posts