What You Should Do First

What You Should Do Now...

Check Out the WebOrderMobile Example

The WebOrderMobile example introduces all of the new concepts that are embodied in the mobile/touch extensions to the Web Framework. As you use the application and examine its structure in the Studio, you will start to get a feel for:

The application Dashboard
The drill-down interface and navigation logic
Select and Zoom views and the associated DEO behaviors
The breadcrumb trail
Multi-line rows
Action Menus

...and much more.

Read the What's New

Really! There are significant improvements in DataFlex 18.1 and the best way to learn about them is to read the What's New section. Pay special attention to the entire book titled "The Mobile/Touch Application Style". Then, read it all again.

Before You Get Started

Before you get started, you want to read the documentation about the mobile framework extensions. These are not meant to be beginner wizards. These create sophisticated applications and there is a lot you can do with these. If you just start building random views, your experience will be less than optimal. In particular, if the following terms are not familiar, read up on them:
Zoom View
Select View
Forward Navigation (NavigateForward)
Back Navigation (NavigateClose)
from-main (nfFromMain)
from-parent (nfFromParent)
from-child (nfFromChild)
WebSetResponsive
Action menus
View-stack
Breadcrumb
Know what it is you are trying to build. We will provide an example of this below. When you work with your own data, you want to have a similar plan. Remember that Zoom Views are not that useful by themselves and they need a Select to navigate forward into them. Also, remember that the same views will be used in a variety of contexts.
The wizards will suggest you use a prefix naming convention of “Select” and “Zoom”. Start with that convention.
You will be asked for a description of a view. Keep it short as this is what appears in the breadcrumb trail. There are ways to customize this so you can have custom captions, custom breadcrumbs, etc., but to start, keep those names simple. For example, a customer select view might have a description of “Customers” and a customer zoom view might have a description of “Customer”.
As you build views, be aware of the smallest device you will be using these on. The responsive mechanism works well and you can significantly customize views to make them fit on a variety of devices. However, views that are very wide (zooms with lots of web-forms on the same line or selects with lots of columns) will be harder to work with.
To start with, don’t try to use an existing WebApp project for your mobile WebApp. Don't try to add some mobile views to an existing application. This will be doable, but we don't have the documented pieces in place to support this yet. If you try to do that now, it will not work. Create a new workspace for your mobile application.
Use a desktop browser that can work in mobile emulation modes. Chrome supports this nicely. In addition, test your applications on real mobile devices and test them on all of the devices you intend to support. The emulators are not perfect.
When building views, you will discover that you may need to link to views that are not yet created. This is expected. You can leave those names blank in the wizard and code will be generated that you can fill in later. Whenever this happens, a “// Todo:” will be added to your code, making these easy to find. In addition, errors are placed in the same code area so that attempting to link to a view that does not exist yet will raise an unhandled error. This may seem disconcerting at first, but this is a programming error and we felt it was best not to hide this. When running your sample in the debugger, you can select the “Debug” button and break on the line that has the error.
Note that when adding views (via wizards, templates, or whatever) that the Select views are added to a test views menu, while the Zoom views are not. You usually want to access a Zoom view through a Select view, so adding them to the view menu just makes things confusing.
When running the wizards, particularly when getting started, you will make mistakes. It’s a bit like writing code – mistakes happen. You may find that you’ve linked to the wrong view or that you selected the wrong type of navigation options or you didn’t add all the fields you wanted in the properly formatted fashion. You can correct and augment any of these in source code. In some cases, you might find it easier to just run the wizard again and copy over your existing view. There is no harm in doing this (as long as you’ve made a copy of your old view if desired).

Suggested Course of Action

We have made a copy of the Web Order sample workspace and placed it in MobilePlay. This contains your data and DD classes, but no projects or views. Here is a suggested course of action for building a web mobile order entry application.

The Plan

As a starting point, we will create an application that supports two styles of querying into an order:

Order List -> Order
Customer List -> Order List -> Order

In addition, we will want the ability to add/edit Customers, add/edit Sales People, and add/edit Orders. The following navigation paths will be supported:

SelectCustomer -> ZoomCustomer
SelectSalesP -> ZoomSalesP
SelectOrder -> ZoomOrder
SelectOrder -> ZoomOrder -> SelectCustomer
SelectOrder -> ZoomOrder -> SelectCustomer -> ZoomCustomer
SelectOrder -> ZoomOrder -> SelectSalesP
SelectOrder -> ZoomOrder -> SelectSalesP -> ZoomSalesP
SelectCustomer -> SelectOrder -> ZoomOrder
SelectCustomer -> SelectOrder -> ZoomOrder -> SelectSalesP
SelectCustomer -> SelectOrder -> ZoomOrder -> SelectSalesP -> ZoomSalesP

To do this, we need to create three zooms (ZoomSalesP, ZoomCustomer, and ZoomOrder) and three selects (SelectSalesP, SelectCustomer, SelectOrder). You can build these in any order you wish. The wizards will ask about forward navigation options. Since you cannot create all views at the same time, some of the views you want to navigate to will not be created yet. When that happens, leave those names blank and fill them in later in the Studio.

The steps below show how to do this. This has been ordered so that you can do as much in the wizards as possible. When you build your own views, it may not be as optimally ordered. In general, build the simple zooms first (e.g., ZoomCustomer, ZoomSalesP). Then build the selects that are not used for child queries (SelectSalesP). Then fill in the rest.

Create a new mobile web app project. Make sure you use the “Web Mobile Project” in the create new “Projects” tab. Compile and verify it runs.
Create a SalesP Zoom. Don’t mess with the Avatar field.
Create a SalesP Select. Use the WebApp Designer to see what you’ve got. Try left aligning the first column and right aligning the next column. We only want to navigate forward to a SalesP zoom. In the “Web View Forward Navigation”, select the first option (“Main Zoom”). On the next page, add a from-main zoom to your newly created SalesP zoom. When in doubt, leave the other options enabled.
Compile and run. Creating a Select view will add an option to your “Views” menu (the menu button on the top left). The views menu will now have the Select SalesP view. You can select this and drill into the SalesP zoom view. You’ve created your first mobile drilldown linked application!
Create a Customer Zoom. Try using groups. Try aligning two groups side by side (adjust the group’s column span and column index). When using the WebApp Designer, it is best to leave the width at 1024. This will give you the best idea of how things lay out. Experiment with the layout. If you wish, you could also try building this with tab pages.
Create a Customer Select. Try creating a multi-line list. Keep Customer Name and Number in the first line and add an additional line for email address and an additional line for phone number. Use the WebApp Designer to see what you have. With this select, we want to be able to drill down to orders (constrained by customer) and to see a customer Zoom. On the “Web View Forward Navigation” page, this will be the default choice (“Both”) – leave it as is. In the next page, when adding a link to the child select link, that view (Order Select) does not exist yet – just leave the file and object names blank. We will fill that in later. Add a from-main zoom to the Customer Zoom, because that does exist.
If you run now, the customer select drill down will raise an error when you select a row item because you have no Order Select view. That’s expected and we will fix this later. You should be able to use the row’s info button to drill into the customer zoom. That should work.
Try creating an Order zoom. This will be a header/detail style view. Play with the layout until you get something you like. Create from-child (Assign Parent Lookup Prompts) links to the Customer and the SalesP parent Selects. You don’t have an order detail zoom yet, so there is nothing to fill in there yet – leave it blank.
Create an Order Select view. A row select will always navigate to an Order Zoom. Therefore, set the “Web View Navigation” page option to “Main Zoom”. In the next page, define a link to the Order Zoom, which should now exist.
If you run now, you have an Order Select to Order Zoom drilldown and this should work. The Customer Select to Order Select (OnRowSelect) will still raise an error – let’s fix that now. In debug mode, click on a Customer Select row. This will bring up that error. Click “Debug” and you will see where the error occurs. Manually create links to the Order Select view. You must add a “Use” to the top (Use SelectOrder.wo). Look for “// Todos:” (Ctrl+Shift+T) and figure out what to do. The code should guide you. This is the first time manual code is needed!

Except for order details, you now have a running order entry system. You can view/add/edit/delete sales people, add/edit/delete customers, and add/edit/delete orders. You can get to order from an order query (list of all orders) or a customer query (list all orders for customer). When changing or adding orders, you have access to the SalesP and Customer Select, which you can use for selection (plus you can add and edit these parents).

Open Dashboard.wo and see if you can hook up two of the tiles to the Order Select view (order query) and the Customer Select view (customer query). Just look at the code and figure it out.
If you have Chrome, try running this in an iPhone/iPad emulator. A reasonable set of responsive changes is already built in. This will look and run pretty well on mobile devices.

You've just built a pretty sophisticated mobile application. The various views will all do the right thing at times based on context. The DataFlex DDs, DEOs, and the mobile framework extensions make this all possible.

If you want to finish this off, you will need to create a Vendor Zoom, a Vendor Select, an Invt Zoom, an Invt Select, and an OrderDtl Zoom. Once you’ve done that, you could actually remove all of the Select view menu items that were added. Your dashboard query options (Customer Query and Order Query) could be used to access and edit all views.

Read the What's New (yes, again)

You'll thank us later!

The Mobile/Touch Application Style

Create a Mobile/Touch Application Using One of Your Workspaces

Just as we provided in the MobilePlay workspace, one of the best ways to learn about and experiment with this new toy is to make additional playgrounds from your own application workspaces.

But don't do this experimentation in your actual workspaces (especially if those workspaces already contain a desktop style web application).

Create a new workspace.
Copy the contents of the Data and DDSrc folders from one of your workspaces.
If you are copying data from a current WebApp workspace over to a new WebApp mobile workspace, you need to make sure your web prompt lists are handled properly. The mobile style does not use or need standard web lookup objects (These objects are referred to as Web Lookup Objects in the Studio’s Data Dictionary designer and Field_WebPrompt_Objects in the DataDictionary class). If these objects are already defined in your DataDictionary class, they will get compiled into your application but not accessed, which is fine. However, for this to compile, you must copy those web lookup objects (e.g., CustomerWebLookup.wo) into your AppSrc directory. Doing this allows you to use the same DataDictionary classes in web desktop and mobile style applications. Alternatively, you could remove the web lookup object references from your DataDictionary classes. If you are creating new DataDictionaries or you are copying your Data and DDSrc from a Windows-only workspace, you do not have to worry about this.
Make sure you are familiar with how to use the new Wizards.
Create a new mobile web app project. You will need to create a new WebApp project. Make sure you use the “Web Mobile Project” in the create new “Projects” tab. Compile and verify it runs.
Start working through your plan, using the wizards to create the various selects and zooms you need.
Start small, working "down" from the parent files (just like you did when you worked through the MobilePlay exercise) toward the more complex views you'll want for the transactional children.
Have fun!

Previous Topic

Font Icon CSS Class Styles

Next Topic

What's Not Done Yet