Stephen Smith's Blog

Musings on Machine Learning…

Posts Tagged ‘argos

Developing for Mobile Devices

with one comment

Introduction

Having just posted a couple of articles on the Argos Mobile SDK here and here; and with the news that Windows 8 has just been released to manufacturing; I thought it might be a good time to reflect a bit on mobile devices and how to develop for them.

By mobile devices we tend to mean smart phones and tablets and not laptop or desktop computers. Certainly there is a lot of blurring around the edges of these categories. Phones becoming as big as tablets, laptops with detachable keyboards and touch screens, etc. There are all sorts of charts showing the growth of mobile devices such as this one from Business Insider:

Today you see iPads, iPhones, and Android devices everywhere. There is a huge market already and from these growth trends you can only see the market demand accelerating in the future. We are already at the point where many workers perform all their computing tasks through a tablet or a phone and may not have access to a desktop or laptop computer at all.

How to develop for mobile devices is a very hot topic around the web. There is a lot of debate around whether to develop using the native SDK’s from the device manufacturers, using a third party toolset that targets multiple devices or writing a web application that runs on anything. What are the pros and cons of all these approaches? What are the tradeoffs you are making when deciding between these?

Device Experience

Apple has done a great job creating the iPhone and iPad and giving them a great user experience. Anyone writing apps that run on these devices want to make their apps as great as any app from Apple when run on one of these. The same goes for creating Android apps or for creating Windows 8 Metro apps. So what are some of the things that you want in your application to fit in naturally into these environments?

  • Follow the look and feel guidelines for the platform. Look and behave like any of the applications that the manufacturer provides. Honor all the touch gestures on the device, have great professional graphics and layout at the right resolution.
  • Integrate with all the build-in hardware on the device. For instance able to access contacts, dial the phone, use the GPS, read the accelerometer, take photos, record sound, receive input via voice, film movies or any other neat hardware feature where ever they make sense.
  • Integrate with the native operating system and utilize all its features. For instance on Windows 8 Metro, support the charms, command bar and integrated application search.
  • Have great performance. Feel just as snappy as any other app on the platform. Don’t hog bandwidth; remember bandwidth can cost money.

Device Differentiators

What distinguishes all these devices? What makes them different? What do you need to support for the best experience?

  • Screen size, we have all sorts of screen sizes from small but high resolution (iPhones with retina displays) to large with low resolution (cheap large screen desktop monitors). Being adaptable is quite a challenge.
  • Input methods. Devices support touch, voice, keyboard, mouse, pen, QR codes, NFC, etc. Supporting all these can be quite a challenge.
  • Different hardware devices. How multi-touch is the device, does it have GPS, does it have a thermometer, is there a sim card, etc.
  • Operating system version. How up to date are most people? Which version do you want to support?
  • Different processor power, battery life and memory.

Using a Web App as a Device App

With all these consideration, is it possible to have a web application pose as a native app? That is what we have been doing with the Argos SDK. The nice thing about Web applications is that they run pretty much anywhere; all the mobile devices have really good browser support. Web applications are also good at adapting to different screen sizes; HTML has always been doing this. The device manufacturers have been good about adding input events to the JavaScript programming model, so you do get notified of touch gestures in your JavaScript application.

However device support is limited. It slowly makes its way into JavaScript, but generally web apps tend to trail native applications in hardware and operating system support. Another key problem is that you can’t post a URL to the app stores like iTunes, these only take native applications.

Enter systems like PhoneGap. These take a web app and wrap it in a native application. In addition to creating a native wrapped app that you can post to the app store, it also adds a lot of hardware abstraction, so you can access things like the accelerometer, but in a way that PhoneGap will make work on all devices.

The Argos SDK is fully PhoneGap compatible, so you can create mobile applications with Argos, compile them with PhoneGap and then deploy them through an app store.

Windows 8

I know Microsoft just dropped the use of the “Metro” name for its native tablet apps, but without a replacement I’m going to just keep calling it Metro. Metro is a subsystem of Windows 8 that allows you to build tablet type apps. Similar to iPhone apps, these can only be distributed via the Microsoft Store (or via a very arcane Enterprise distribution system). The intent of these is to define a new modern UX model for Windows applications. These programs run by themselves and can’t be displayed as Windows in the regular Windows desktop. There are two ways to develop these via Visual Studio 2012, either as C#/XAML apps or as JavaScript/HTML applications. PhoneGap doesn’t have Windows 8 support yet, but I would expect to see it down the road.

If you develop a Metro app in JavaScript/HTML in VS 2012, don’t expect it to run anywhere except in the Metro environment. This is standard JS, but the core of the program structure is proprietary and you have to use a number of proprietary native controls to get proper Windows 8 functionality. All that being said, you can leverage a large number of standard JavaScript libraries such as JQuery or HighChart. You can also structure your program to isolate the proprietary parts to keep as much reusable as possible.

To use operating system you need to be a native application and you have to use proprietary controls to access things like the integrated search and the charms. You can probably simulate the command bar via other means.

If you buy a Windows 8 ARM Processor based device, then it only runs Metro or Web apps, it will not run any other type of application. So if you want to participate in this world then you do need to develop for Metro (or rely on a web app). It will be interesting to see if sales of ARM based Windows 8 devices takes off. Microsoft is releasing their Surface tablet in both ARM and Intel processor based versions.

Right now there is a lot of impedance between current laptops/desktops and Windows 8. Metro is really designed for the next generation of hardware and doesn’t work at all well with current hardware. Perhaps it’s a mistake making it compatible with old hardware since it yields a bad experience, but Microsoft’s hope is that as new hardware comes to market, then the Metro experience will greatly improve.

Summary

It seems that applications need the experience of native applications, but want to leverage the portability of Web apps. After all what developer wants to create 4 or 5 different versions of their program? This is leading to new categories of hybrid applications that have large parts written as web apps, but then merged with parts that are created natively to directly interact with operating system and device features. It certainly leads to programmers needing quite a plethora of skills starting with JavaScript/HTML/CSS for Web Apps and Metro Apps, Objective C for iOS and Java for Android.

Advertisements

The Argos SDK Part 2

with one comment

Introduction

Last week I introduced a sample of how to develop mobile apps for Sage 300 ERP using the Argos SDK. In that article I covered where to get the sample and how to get it working. This week, we’ll start to look at how it is put together and how it works.

Sign On

The first thing you need to do is sign-on or authenticate. There is a standard method of authentication built into SData which is explained on the SData website here. Usually you would want to create a sign-on dialog and then feed the results into the SData access layer. This is all done in the sample application.

Basically the file src\Application.js is responsible for orchestrating the running of the application. When it starts running, it calls handleAuthentication() which usually calls navigateToLoginView() to run the login screen. This is done in src\views\login.js. This file displays the UI and gets the data entered. We’ll talk more about how UIs work next. It basically sets up the credentials data structure, calls authenticateuser to save these for the SData layer and then navigates to the initial screen.

Anatomy of a View

For Sage 300 ERP developers this is going to be confusing, because in the Sage 300 ERP world, business logic objects are called Views. But here in the Argos SDK world, Views are UI screens. Basically you provide a data structure (JavaScript object described in JSON notation) with all the fields you want and an HTML template on how you want them displayed, and then Argos has base classes to display these. The Argos SDK uses object oriented JavaScript, so it’s often worth going into the SDK and browsing the base classes to see what things are derived from. This gives you a good idea of what is done for you and what behavior you can override.

The most basic such View is src\views\VendorGroups. This is used as a finder when adding new Vendors. The code is:

define('Mobile/Sage300/Views/VendorGroup/List', [
     'dojo/_base/declare',
     'dojo/string',
     'Sage/Platform/Mobile/List'
 ], function(
     declare,
     string,
     List
 ) {
     dojo.declare('Mobile.Sage300.Views.VendorGroup.List', [List], {
         //Templates
         itemTemplate: new Simplate([
             '<h3>{%: $.DESCRIPTN %}</h3>',
             '<h4>{%: "Code: " + $.GROUPID + " Active: " + $.ACTIVESW %}</h4>'
         ]),
        //Localization
         titleText: 'Vendor Groups',
        //View Properties
         icon: 'content/images/Accounts_24x24.gif',
         id: 'vendorgroup_list',
         security: 'Entities/VendorGroup/View',
         queryOrderBy: 'GROUPID',
         querySelect: [
             'GROUPID',
             'DESCRIPTN',
             'ACTIVESW'
         ],
         resourceKind: 'apVendorGroupsFinder',

         onRequestDataFailure: function(response, o) { 
               alert( Mobile.Sage300.Environment.parseErrors(response.responseText) );
               Sage.Platform.Mobile.ErrorManager.addError(response, o, this.options,
                   'failure');
               dojo.removeClass(this.domNode, 'list-loading');
         },      
         formatSearchQuery: function(query) {
             return dojo.string.substitute('upper(DESCRIPTN) like "%${0}%"',
                 [this.escapeSearchQuery(query.toUpperCase())]);
         }
     });
 });

This is basically the JSON definition for this View object. This one fairly simple and bare bones, the main points are to define the SData feed in the resourceKind: property, along with the query fields we need. Notice the simplate which  is used to format and display each entry in the list, these are described in the next section. Then there is an error handler and a function to perform searches. The rest is done in the base class for this View. For more complicated objects, you will need to override more functions and provide more input (like more details about fields for editing).

Simplate

Simplate is a small templating engine for JavaScript. We use the templates to dynamically combine HTML and data in our views.

The Simplate syntax is a mix of markup, tags and JavaScript code. These are the most common syntax items you’ll see:

  • {%= … %}: Output the result of the inner JavaScript
  • {: … %}: Output the HTML encoded result of the inner JavaScript
  • $: References the data object (in our case, the JSON entry retrieved via Sdata)
  • $$: References the data object container (in our case, the view)

You can check out the code and some examples here:

https://github.com/mmorton/simplate

Debugging

When developing you run into lots of bugs, so how to solve them? The nice thing about JavaScript is you just update your files, save them and then hit refresh on the browser to run. But since JavaScript is interpreted and not compiled, you only find out about syntax errors when you run. If the syntax error is bad then it can stop the whole program from running (extra or missing brackets are bad for this), simpler errors will just stop the program when it hits that line of code. Also beware that if you misspell variables, JavaScript will just happily keep going using an undefined value, so be careful.

I like to run in both Firefox and Chrome. Firefox (with Firebug) is good at pointing out syntax errors, so they are easy to fix. Chrome has an excellent JavaScript source code debugger built in that is great for setting breakpoints and tracing through code. Another tool I really like is Fiddler which spies on all the SData server calls being made. From here you can look in depth at what is going on with the SData server.

Since the Argos SDK along with any other libraries it uses are all open source JavaScript projects that means you can examine any of the source code in the Argos SDK and debug into it to see what is happening there as well as what is happening in your own code.

Also remember the SalesLogix and Sage 300 sample applications, chances are you can find an example of what you are trying to do in one of these programs.

Summary

The Argos SDK is a powerful mobile development platform that combines SData with the Dojo JavaScript framework to give quite a deep method to quickly develop mobile applications for various Sage SData enabled products.

Written by smist08

July 28, 2012 at 5:03 pm

The Argos SDK

with 16 comments

Introduction

Argos is a framework for creating mobile SData clients using HTML5, JavaScript and CSS. This was originally developed by the Sage SalesLogix group to create the mobile interface for the Sage SalesLogix Mobile product. However since SalesLogix uses SData as its Web Services interface, this library was created entirely on SData. As a consequence it can be used with any product that supports SData.

As part of our Sage 300 ERP 2012 development we tested Argos on our SData feeds and produced a sample mobile application.

Note: that to run this application on your own system, you need at least the Sage 300 ERP 2012 beta.

Argos SDK

The Argos SDK is open source and available on github:

This includes a JavaScript SData client library that you can use standalone independent of the rest of the SDK along with a sample application that shows Argos running on SalesLogix. The SalesLogix sample application also includes the second sample which shows how to customize the first without requiring code changes to it.

Sage 300 Sample Argos Application

Sorry, the Sage 300 team doesn’t have a github account like SalesLogix right now. However I posted the Sage 300 Sample application and the matching Argos SDK on GDrive here:

Generally you would put these as folders under the c:\inetpub\wwwroot folder. Then you can start the app via: http://localhost/sage300/index-dev.html. (Or substitute your own hostname as needed).

In the Sage300 application there is a runtime folder. This needs to be copied to: C:\Program Files (x86)\Common Files\Sage\Sage 300 ERP\Tomcat\portal\sageERP\runtime. These are the definition files for the SData feeds that this sample uses. After you copy this, you need to restart the “Sage 300 ERP Tomcat” service for them to get read.

CORS

The last gotcha is that the Argos SDK uses Cross Origin Resource Sharing (CORS). This is a mechanism where the server that is serving the HTML can let the browser know its ok to talk to another server. This way the Web Server that serves up the HTML, CSS and JavaScript files can be different than the SData server. Normally this isn’t allowed as it’s considered a severe security threat since it allows malicious programs to send sensitive data to a third server or to send out things like Spam. CORS is an internet standard that provides a way to let the browser know what is ok and what is bad in a secure manner.

As a result, you have to configure the IIS (or whatever web server you use for the static content) to grant access to the SData server. You still have to do this, even if they are the same, since all SData requests from the Argos SDK are CORS validated. The Wiki attached to the Argos SDK on the main Github site above has complete information on this.

But since I’m not exposed to the outside world and don’t usually worry too much about this, I tend to just let CORS say everything is valid with a simple web.config file (in c:\inetpub\wwwroot):

<?xml version=”1.0″ encoding=”UTF-8″?>
<configuration>
<system.webServer>
<handlers accessPolicy=”Read, Execute, Script” />
<httpProtocol>
<customHeaders>
<add name=”Access-Control-Allow-Origin” value=”*” />
</customHeaders>
</httpProtocol>
</system.webServer>
</configuration>

Like I said, don’t just specify “*” like I have for a real situation, but if you are on different networks with a laptop, sometimes this is just easier. Similarly in a real environment, you would want to use https rather than http.

Configuring to Connect to Sage 300 SData Feeds

The key to interfacing to Sage 300 is the development.js file in the configuration folder. To work with Sage 300 it needs to look something like this:

define(‘configuration/development’, [‘Mobile/Sage300/ApplicationModule’], function() {
return {
modules: [
new Mobile.Sage300.ApplicationModule()
],
connections: {
‘crm’: {
isDefault: true,
offline: false,
url: ‘http://localhost/sdata/sageERP/sage300mobiledemo/SAMINC/&#8217;,
virtualDirectory: ‘SDataServlet/sdata’,
json: false
}
},
enableUpdateNotification: true
};
});

The key parts are the virtualDirectory to form the correct SData URLs for Sage 300. Remember that Sage 300 URLs start SDataServlet/sdata rather than just sdata. This is to avoid conflict when we are installed on the same server as Sage CRM. So notice the url: tag doesn’t include SDataServlet and then the virtualDirectory tag does. This will then cause the correct URLs to be formed. If you are having trouble with URLs then the Fiddler tool is great for debugging what is going on.

Note that to work, at least you need to change localhost to the server name you are using. Localhost will only work when running on the same computer.

Setup Quick List

So to summarize setup:

  1. Unzip the two zip files under the c:\inetpub\wwwroot folder.
  2. Add something to c:\inetpub\wwwroot\web.config for CORS.
  3. Copy the sage300\runtime folder to …\portal\sageerp\runtime.
  4. Restart Tomcat
  5. Edit the development.js file if you need to change the hostname.

Hopefully this will get you going fairly quickly.

Create Your Own App

This blog post is already getting a bit long, so I’ll go into more detail on how this sample program works in a future post. However this should be enough to get you started with the Argos SDK Wiki information and a working sample.

The Argos SDK is written in JavaScript and oriented to JavaScript development, so learning JavaScript is crucial. There are many good books on JavaScript as well as many good free web based resources. I like “Eloquent JavaScript” by Marign Haverbeke since it is fairly short and complete.

The Argos SDK relies heavily on the Dojo JavaScript framework. Along with the Simplate library and iUI library. My experience is that you don’t need to know too much about these to work with Argos, but I imagine if you get deep into it, it doesn’t hurt to know something about these.

Summary

One of the goals of SData is to enable the use of common tools across all Sage products. The Argos SDK is an example of this; it is a mobile SDK library for creating mobile applications that use SData to communicate with on-premise Sage applications. Over time you will see more and more of these sort of tools that leverage SData to provide enhanced functionality for a whole range of Sage applications.

Written by smist08

July 21, 2012 at 6:25 pm

SData Enhancements for Sage 300 ERP 2012

with 4 comments

Introduction

I’ve previously blogged on the enhancements for the framework for creating custom SData feeds for applications here and here. In this posting I’m looking at enhancements to our core SData protocol support. We’ve been working hard to add more features and correct some inconsistencies and bugs.

The main purpose of this exercise is to make SData work better for integrators and to make sure the Sage 300 ERP SData feeds work well with other Sage tools like the Sage CRM dashboard and the Sage Argos Mobile Framework.

Global Schema

Generally SData features are mostly of interest to programmers. However some, like this one, enhance existing integrations between different products. Global schema is a mechanism to return all the SData meta-data for a dataset (company) in a single call. In version 6.0A, you could only get the metadata for one SData resource per call. Rather esoteric. But having this enhances our integration to the Sage CRM SData dashboard. Previously when you created an SData widget pointing to an Sage 300 ERP SData feed you needed to specify the $schema for a specific feed, something like:

http://sage300erpdemo.na.sage.com/SDataServlet/sdata/sageERP/accpac/SAMINC/arCustomersFinder/$schema

Now you can give the $schema to the company using an URL like:

http://sage300erpdemo.na.sage.com/SDataServlet/sdata/sageERP/accpac/SAMINC/$schema

Which means you don’t need to know the resource component of the URL. In Sage CRM it looks like this, first you give the URL to the global schema:

Then you get a list of SData resources to pick from in a more human readable form:

Previously you only got the feed you specified. Then you select a feed and hit next to choose the fields you want from that feed.

SData Validation Tool

Sage has written a tool that will validate the correctness of SData feeds. This tool is available here (you need to scroll down to near the bottom of the page). The intent of this tool is for anyone, whether internal or external to Sage to be able to validate any Rest web services for SData compliance against what is described in the spec at the SData Website. This tool was around in the 6.0A days, but it needed work. Back then 6.0A passed the feed validator. With the new tool 6.0A has a lot of problems reported against it. With 2012, quite a bit of work went into making our feed compliant. Which means you can expect them to work as the specification states and integrations with other SData aware products and tools becomes much easier. This tool is continuously being updated and will probably auto-update itself as soon as you install it. Below is a screenshot. Hopefully by release a few of the remaining errors will have been corrected.

Argos

Argos is a framework for creating mobile SData clients using HTML5, JavaScript and CSS. This was originally developed by the Sage SalesLogix group to create the mobile interface for the Sage SalesLogix Mobile product. However since SalesLogix uses SData as its Web Services interface, this library was created entirely on SData. As a consequence it can be used with any product that supports SData.

As part of our Sage 300 ERP 2012 development we tested Argos on our SData feeds and produced a sample mobile application.

As part of this development we fixed a couple of bugs and made sure our SData support works well with the Argos SDK. I’ll write a future blog posting on more details on the Argos SDK and how to write mobile applications for Sage 300 ERP. However if you are interested in Argos, you can check it out, since the whole project is open source and available on github:

E-Tags

We finished implementing e-tags with this version. These allow proper multi-user control when you have multiple sources updating records. Basically when you read a record, it returns an e-tag which has the date and time the record was last modified. When you update the record this e-tag is included with the update message and then the server can see if the record has been modified by someone else since you read it. This detects the multi-user conflict. Sometimes the server will just merge the changes silently and everyone is happy, sometimes the server will need to send back the dreaded “Record has been Modified by Another User” error response.

Using Detail Fields in Select Clauses

In 6.0A, if you read an SData feed with header and detail components (like O/E Orders), then you got back the header fields and links to the details. Even if you specified detail fields in a select clause. This meant if you wanted both the header and detail lines you needed to make two SData calls. Further this was annoying because it meant the format that you get back reading records is different than how you write the records, so you would need to combine the separate results from the header and details back  together to do an update or insert. Now if you specify detail fields in the select clause you will get back all specified fields in the XML package, which will likely be a header with multiple details all returned for the same call. This saves an SData call, but further it’s much easier to deal with, since now you have an already correct XML template for manipulating to do future inserts and updates.

Define Your Own Contracts and Have Your Own Classmaps

In version 6.0A, the only contract we supported for SData feeds created by Sage 300 ERP was the accpac contract. Now in the classmap file you can specify the contract your feeds belong to. This has always been in the classmap files, it just didn’t work. This means you can ensure any feeds you define yourself won’t conflict with anyone else’s.

Another problem in 6.0A was that to create your own feeds, you either needed to be an activated SDK application with your own program id, or you needed to edit one of our existing classmap files. This was annoying since your changes could well be wiped out by a product update. Now you can copy your own classmap file into an existing application (like O/E), you just need to name it classmap_yourownname.xml and it will be added to the defined SData feeds.

Further all the feeds that make up the accpac contract were oriented to the Orion UI work. They weren’t necessarily a good fit for people doing general integration work. So we are creating a new contract which will have the main master files and documents in it that is oriented towards integration work and stateless operation.

Summary

SData continues to be a foundation technology that we are building on. Quite a lot of work has gone into improving our SData support in Sage 300 ERP for the forthcoming 2012 release. This will allow us to leverage many other technologies like Argos to accelerate development.

If you are interested in learning more about SData check out my learning SData videos which are located here and which I blogged about here.

 

Written by smist08

May 26, 2012 at 4:31 pm