Stephen Smith's Blog

Musings on Machine Learning…

Posts Tagged ‘mobile

Google Mobile Trends

with 2 comments

Introduction

In a previous blog I talked about Apple’s mobile directions following their annual developer’s conference. This past week Google help their annual I/O developer’s conference in San Francisco. So it seems like a good time to comment on Google’s mobile trends. There is a lot of similarity between Apple and Google’s directions. But there are also differences since each company has a slightly different view on what direction to take. Both companies are very large and have their hands in a lot of pies. As a consequence their announcements tend to be quite diverse and it’s interesting to see how they try to unify them all.

New Android

Like Apple announced a new version of iOS, so too Google announced a new version of Android namely “L”. I don’t know what happened to the cute code names like Kit Kat or Ice Cream Sandwich, but “L” it is. One big feature they’ve added is 64 Bit support. Apple recently introduced 64 Bit processors in their latest phones and now Google devices can catch up. This means that most new higher end phones are now all going to sport 64 Bit quad core processors. This is an amazing amount of computing power in such tiny devices.

As with most new operating systems these days, it includes a new UI look. With the new Android this new update is called Material Design and follows the fashion of a flatter more austere look to things.

There are many other new features in the new version of Android which will hopefully make people more productive.

Wearable’s Everywhere

A big trend in rumored and announced, but generally not shipping products are wearable’s. Google leads the way in these with Google Glasses. Then there are the endless smart watch announcements, rumors and even the odd product.

smartwatch

I have a Garmin GPS Watch with a heart rate monitor. Combined with the website where I upload the data, this is a great device to track my cycling and running. It would be nice if its battery lasted longer and if it was more waterproof so I could swim with it. In the meantime there are many great apps to do the same sort of things with your phone. These all do more than the Garmin watch, but the phone is bulkier and less durable in damp environments.

Having a waterproof watch that can do more than my Garmin and has a longer battery life would be fantastic.

Although in the early stages, both Google and Apple see the fitness market for metrics and tracking as a huge potential market. Both companies are both partnering and developing new sensors to measure new things, like small waterproof sensors for swimming or unique ways to measure other sports like for golf swings. Similarly measuring all sorts of biometric data beyond heart rate to include blood pressure, blood glucose levels and all sorts of other things. Eventually these will morph into a Star Trek like medical tricoder.

Home Automation

Google has now purchased a number of home automation companies including Nest. And are now integrating these with Android to provide full control of everything in your home from your phone. Including remotely setting the thermostat, receiving smoke detector alerts and monitoring security cameras. Most of these things are available now as separate discrete components but Google is working especially hard to make this whole area much more unified.

nest_thermostat_insteon-800x420

Online Cars

Another big area of interest is integrating into cars. Already most cars can interface to iPhones and Android phones to make calls hands free and play music. Now the goal is to sell Android (and iOS) into the auto industry. To have better more connected GPS (with real time traffic updates) and access to all your music library. Further many car companies are enabling using your car as a Wi-Fi hotspot.

I’m not sure how far this should go, since it all gets very distracting. Already we have so many potential distractions in cars. And just things like texting are causing many accidents.

Everything in the Cloud

With all Google’s products, the emphasis is storing all data in the cloud. They will only store things on local devices if there is a huge outcry of people that need to work offline (like on airplanes). Chromebooks really showed that this was possible and Google has led the way in offering lots of free cloud storage and making sure everything they do will interact seamlessly with these cloud documents.

They tout the convenience of this that things are always backed up, so if your laptop is stolen or destroyed you don’t lose anything. However critics worry about privacy concerns with storing sensitive data under someone else’s control, especially a search provider. It’s rather scary to corporate compliance officers that sensitive corporate documents might start showing up in people’s search results. Often this wouldn’t be due to Google doing something maliciously as someone just misclicking the visibility of the document to allow it to be viewed by anyone, and by anyone this means anyone on the Internet (and not just anyone that finds it on the corporate network).

All that being said, Google, Apple and Microsoft are all pushing this model like mad, and a lot of innovations that are in the pipeline completely rely on the adoption of this philosophy. It certainly is convenient to have all your photos and videos automatically uploaded and not to have to worry about sync’ing things by hand anymore.

Big Data

Google really started the big data revolution when they published the details of their Map Reduce algorithm that the original Google search was built upon. This then spawned a huge industry of open source tools and databases all built around this algorithm. Map Reduce was revolutionary since it let people get instant search results on searching for everything. Basically it worked by having a database of everything people might search for, like a giant cache that could return results instantly.

The limitation of Map Reduce is that constructing queries is quite difficult and often requires the database to be rebuilt in a different way. If you don’t do that, although the main query the database solves returns instantly, any other query takes a week to process.

Google is now claiming Map Reduce and all the industry like Hadoop based on it are completely obsolete. They were heavily promoting their new Cloud Dataflow service where the claim this service can also do efficient real time analytics as well as preserve the performance of the main functionality.

It will be interesting to see what this new service can really do and will it really threaten all the various NoSQL databases like MongoDB.

Summary

There are a lot of interesting things going on in the mobile world. It will be interesting to see if all our phones are replaced by watches or glasses in a couple of years. It will be interesting to see what great things come of all these new cloud big data services.

Advertisements

Written by smist08

June 28, 2014 at 5:28 pm

Sage CRM 7.2 Available for Sage 300 ERP

with 8 comments

Introduction

Earlier this year Sage CRM 7.2 was released for standalone CRM customers. We have competed the Sage 300 ERP integration in conjunction with the Service Pack 1 release of Sage CRM 7.2. We have now released the Sage 300 ERP 2012 integration for Sage CRM 7.2 and this is the integration that will be included in the forthcoming Sage 300 ERP 2014 release.

Generally customers find that combining Sage CRM as a front office solution to Sage 300 ERP as the back office  solution creates a much more powerful combined system than having separate ERP and CRMs. The level of automation, reporting and customer connectedness is greatly increased across the organization. As such introducing a new version of CRM can provide many immediate benefits for companies and this blog is looking at some of the things that are new in this version. We find that customers running both of these Sage products together have much higher net promoter scores than customers running non-integrated systems.

Social CRM

Historically CRM programs managed communications with customers and other business contacts by managing e-mails and phone calls. CRM had all the basic contact information, integrations to help automate these processes like creating e-mails and automatically recording the information in CRM. Auto-dialing phones and logging that you called and letting you fill in some comments. Setting reminders and schedules for performing these tasks.

However, how we are communicating with our business contacts is changing. Many people are using e-mail and voice phones much less than they used to. I ignore most incoming calls from unknown callers because they are usually cold sales calls or scams (like you have just won a cruise vacation). E-mail is getting much noisier with spam and other junk, causing more important e-mails to just get lost. It’s been found that recent high school graduates actually have quite an aversion to actually talking on a phone and don’t use e-mail much.

Now there are many more communication channels. Many people now communicate via various social websites like Facebook, LinkedIn, Google+, Yammer and Twitter. Many calls are made via services like Skype and there are people texting more than ever and even using systems like BBM.

So if we want to get a complete comprehensive picture of all our communications with a customer, we need to see all of these in CRM as well. We added LinkedIn and Twitter connectors to Sage CRM last version and with this version we have added Facebook integration.

socialcrm

With this Facebook integration you can bring Facebook information right inside Sage CRM to better understand your customer. You can associate Facebook pictures and profiles with prospects. Generally this is an avenue to get a more complete picture of your customer, or potential customer’s business.

Getting good leads is usually a big problem for companies. Chances are that for a given customer, his contacts will be related in some way and perhaps offer good prospects to market to. If you do get a response from one of a customer’s contacts then you can use the original customer as a reference to help make the sale, or act as an introduction to get you in the door.

Social Media stores terabytes and terabytes of information on business’s and people. Being able to effectively mine all this information is going to be a huge competitive advantage in the future.

Another social feature added to Sage CRM 7.2 is Yammer integration. Yammer is a social network for collaboration within a company. With this integration your sales teams can collaborate and share information using Yammer from Sage CRM.

socialcrm3

Mobile CRM

People don’t necessarily spend their entire day sitting at their desk behind a computer. They work from home, they travel on business trips and visit customers face to face. You CRM system contains tons of useful information that will help you do your job better if accessible in these situations. Over the past couple of versions and further with this new version, we‘ve been adding mobile features to Sage CRM to make it easier to access from mobile devices.

Sage CRM is a web application and with the previous version we enhanced to work with all popular browsers. This then allowed mobile users (which usually have Safari or Chrome) to browse the Sage CRM screens. Perhaps this works a bit better for tablets, but tends to be a bit of a pain on an iPhone.

As a result we’ve been adding native device apps to complement the web interface to Sage CRM. Plus we’ve been working on improving the web interface so it will work much better on table devices like the iPad.

The picture below shows the Sage CRM web application rendering itself for an iPad:

mobilecrm1

Next we have the iPhone native Sage CRM application:

mobilecrm2

And finally the Sage CRM 7.2 Windows 8 application for Windows tablets:

mobilecrm3

As we move forwards we will be providing more and more functionality on more and more mobile devices so you can instantly get any information you need instantly. Down the road you might be wearing your Google glasses and when you say the customer’s name, all the information on that customer will be right there in your view to reference.

Reporting

With this version of Sage CRM we’ve improved the reporting capabilities. A new HTML5 based charting library has been added, so you don’t need Adobe Flash for charts anymore. You can clone reports to get started with a customization. There are more chart types with more configurable settings. There are new security settings so you can better control who can see what.

Customization

Sage CRM 7.2 adds more codeless customization capability where you can design more powerful screens right in the product without writing code. Sage CRM also doesn’t use frames to hold custom screens anymore. This will affect some ASP based customizations, but generally leads to better ability to control your own web pages (especially the CSS).

Integration

The main change to the Sage 300 ERP integration was changing Quotes to Orders to work in the new frameless Sage CRM web pages. Most other changes have already been released in service packs or hotfixes for Sage 300 ERP 2012, so if you are fully current you won’t see much different. But if you are coming from an older version, you should see a number of improvements.

Summary

Sage CRM 7.2 integrated with Sage 300 ERP make for a powerful front/back office solution. This release is definitely worth checking out especially for the mobility and social features.

Written by smist08

September 7, 2013 at 4:59 pm

Sage Mobile Sales

with 10 comments

Introduction

This is the third article in my series on Sage’s new Web and Mobile applications that were released at Sage Summit this year. Previously I blogged on our Sage Mobile Service iPhone Application and our Sage Billing and Payments Web Site.

For this article, I’m going to be looking at our new Sage Mobile Sales application. This application has two parts, an iPad native application for taking sales and a web site for managing inventory, customers and sales people.

This application enables sales people to show customers products right from a catalog on their iPad, they can review and edit customer information, they can create a quote and have it e-mailed to the customer, they can check product availability and they can enter an order and accept immediate payment.

Generally this application is best for salespeople working directly with clients to create a quote or order. It makes getting information on the items being sold easy as well as allows you to easily create the order.

The diagram below shows the mobile application interfaced to the Sage Data Cloud and the Sage Data Cloud connected to the on-premise ERP system to synchronize data. You can take credit card payments directly from the iPad or take orders on account. If you take the order on account then you can use the Sage Billing and Payments application to collect the money which is also shown connected to the Sage Data Cloud.

ERP-mobility-launch-graphic-ms

The iPad Application

The sales people will install this native iPad application onto their iPad from the Apple store. You can see the Apple store entry here. This application fully uses the capabilities of the iPad to make life as easy as possible for the sales people. Below is a screen shot of the customer list:

sms3

If you tap any of these customers then you will get more detailed information on that customer:

sms4

This includes their contact information as well as giving you their sales history.

Similarly you can get a list of inventory items and if you tap them you get detailed information on the item for sale:

sms5

Notice you see the price and the quantity available. You also get a number of photos of the item. You can immediately add it to a quote. You also see links to similar items.

The application is written in Objective-C and developed using Apple’s XCode integrated environment. Note that this application requires at least iOS 6, which means you need at least an iPad 2. If you need to be truly mobile, then you would need the cellular version of the iPad (rather than the Wi-Fi only one) and a mobile data plan.

The Web Application

You use the web application to manage your inventory, customers and sales people. The initial data is uploaded from your on-premise ERP system, but there is some additional data that you would want to add to make this a better experience. Further this is a good portal to get information on how your sales are going and how your sales people are doing.

Below is a screen shot of the inventory list screen:

sms1

From here you click on an inventory item to get more detailed information:

sms2

Here you do things like setup related items or add the item to a category (which makes browsing them on the iPad much quicker). You can also add more photos for the item. Generally these should be produced professionally and not just taken with your iPad camera.

For the Team, tab you can manage your sales team, set quotas and see how your sales people are performing against their quotas.

Connected to ERP

Like the other two mobile/web applications I blogged about, this one uses the Sage Data Cloud and will work with any ERP that is connected to this cloud. Currently that is Sage 100 ERP and Sage 300 ERP with Sage 50 ERP (Canadian and US) following shortly.

If you were to use all three of these application, you would still only use one connector which would synchronize ERP data to and from the Sage Data Cloud and would share common items like the customer master file.

Credit card processing is via Sage Payment Services so again everything here is synchronized between the ERP, Sage Payment’s virtual terminal and the Sage Data Cloud.

Summary

This iPad native application is a great way to enable a mobile sales team to interact with customer and build quotes and orders. It has many ease of use features that iPad users expect and fully integrates with your current Sage on-premise ERP system.

Google Forks WebKit

with one comment

Introduction

WebKit is the underlying HTML rendering library used primarily by the Apple Safari and Google Chrome browsers. It is used in a lot of other projects like the Blackberry Browser, Opera, Tizen, Kindle and even some Microsoft e-mail clients. Even Nokia was a big WebKit user before switching to Windows Phone. Generally it’s been considered a great success, rallying the web around standards and making life easier for web developers.

webkit

WebKit is a solid open source project with lots of support. This is one reason it’s so successful. Currently in Internet browsers there are three main HTML rendering engines: the Internet Explorer Trident engine, the Mozilla Firefox Gecko engine and then WebKit.

The big news around the Internet on this front recently is that Google is forking WebKit (meaning starting a new open source project based on WebKit) and then taking it in its own direction with a project called Blink. This raises all sorts of questions: like what it means to web developers? What is Google’s real agenda? Will this damage web standards? Will this slow WebKit development? In this blog posting I want to give my perspective on a few of these questions.

History

Actually WebKit was started out of a similar controversy. Back in 2001, Apple forked the KHTML/KJS HTML rendering engine used by the browser that is part of the KDE Linux User Interface system. Basically Apple wanted something better and more tuned for its OS X project. The result was the Safari browser built on the first WebKit HTML engine. At the time no one in the Linux community was happy about this, but in the end looking back, success makes everything all right.

So now that Google is forking WebKit, claiming that it’s for the same reasons that Apple forked KHTML, will history repeat itself and a much better HTML rendering engine will emerge? Or will this just fragment the market into more slightly different HTML rendering engines making life more difficult for web developers?

WebKit’s Mobile Success

In recent years, now that Android and the iPhone have completely taken over the mobile phone market, developing web sites with HTML5 and JavaScript has become much easier. This is because WebKit is used in both of these families of devices. This means to cover 95% of the mobile market you just need to target WebKit. This greatly simplifies development and testing. Further WebKit follows web standards diligently, it keeps up with evolving standards, has great performance and great quality.

I think that WebKit has been a major contributor to the combined success of both Android and the iPhone. You can easily browse most websites from these devices. Plus when Apps incorporate browser controls they are using WebKit.

Further both Apple and Google are contributing actively to WebKit. It’s been an interesting combination of co-operation and competition. When new hardware devices come out, initially it tends only be accessible for Apps. But Google tends to very quickly add JavaScript APIs for the device to WebKit. Then Apple tends to follow suite quite quickly. Further each is driven to keep incorporating the latest version into their devices since they don’t want to let the other get ahead of them.

One of the worries of Google forking WebKit and going its own way is that we will lose the competitive nature of Apple versus Google that has been driving WebKit forwards.

Why Fork?

So why is Google forking WebKit? A lot of opinion on the Internet is that this is a strategy to sabotage Apple. I guess Google could be egomaniacal enough to think that WebKit will fail without them participating. But Apple is such a big company with so much money and talent, I think they can do just fine with WebKit, after all they did start it without Google’s help. Further I suspect the army of independent open source programmers that contribute to WebKit will continue to do so and won’t switch to Blink.

Google’s official reason is that the code in WebKit is getting too burdened with supporting code for Safari, Chrome and all the other various things it does. That if they take WebKit and remove anything that Chrome doesn’t use then they will have a smaller, faster and easier to develop code base. Basically they claim they want to move the HTML engine forwards more tightly coupled with their multi-processor architecture to improve security and performance. That doing this while supporting competing architectures within the same code base is getting harder and harder.

When Apple started WebKit and later when Google joined it, both Google and Apple were primarily worried about Microsoft and wanted to have Browser technology clearly superior to Internet Explorer. Now with their success, Microsoft is now pretty well non-existent in the mobile world. I think as a result Google isn’t feeling threatened by Microsoft anymore and is turning its attention to Apple. Generally relations between the two companies have been getting colder and colder in recent years.

Actually Google currently only uses the HTML and CSS rendering part of WebKit called WebKitCore. They stopped using the JavaScript component JavaScriptCore in favor of their own V8 JavaScript engine. The V8 JavaScript engine has been blowing away the competition in JavaScript benchmarks for some time now. In fact the V8 JavaScript engine is also the heart of Node.js the highly successful JavaScript server side processing framework. I think Google is looking to get the same sort of success out of Blink that they got from V8.

What’s the Problem?

The problem is for developers. Right now developing good web pages that run nicely anywhere means targeting IE, FireFox and WebKit which then covers the main HTML/CSS rendering engines. Unfortunately HTML and CSS are very complicated and quite subtle. Although all adhere to the published web standards, there are differences in interpretation. Also there are emergent properties that get exploited as features, things that aren’t really in the standard but have appeared in an implementation.

In the mobile world right now, developers have it easier since they can target Android, iOS, Blackberry, Tizen and Symbian by just targeting WebKit. This makes life much easier since you really can develop once and deploy pretty much anywhere. It will be a pity to lose this, and potentially quite expensive for smaller development organizations.

I imagine that many source code files will continue to be shared by WebKit and Blink. But for how long? When will we have to pay attention between differences between Blink based browsers and WebKit based browsers?

Summary

Although I find it appealing that Google is hoping to do for HTML/CSS rendering speed what it did for JavaScript execution speed with V8, I’m really worried that this is going to fragment HTML5 development for mobile devices. I tend to think this will cause more web developers to decide that if I need to develop Android and iOS separately then I may as well do both natively in Apps. To me this will be a sad further fragmentation and polarization of mobile developer communities.

Written by smist08

April 13, 2013 at 3:40 pm

Voice Input and Concierge Services

with 2 comments

Introduction

Some of the most exciting new technologies appearing on mobile phones are around voice recognition and concierge or personal assistant type of applications. These include ambitious applications like Apple’s Siri, along with a number of initiatives from Google including Google Now and Google Voice Search.

The voice recognition by itself is a truly amazing technology, but this is only a fraction of the story. After the voice input is recognized the query is combined with other input, like your location, to determine a lot of context for what you are asking about, identifies the problem domain and gives a truly meaningful answer along with relevant data to correctly answer or respond to your query.

Of all the technologies on Star Trek, we don’t see any sign of a working warp drive or transporter, but being able to ask a computer anything on any topic and get a good answer, we seem to have that now. So perhaps if Star Trek IV was set another ten years ahead, then Scotty wouldn’t have had any trouble interacting with our primitive computers.

star_trek_4_apple_mac_plus1

Device or Service?

An incorrect assumption is that you can integrate apps running on your phone to these services. This is the wrong way to think about how they work. They aren’t a voice recognition/query engine running on your device. In fact they send all the (nearly) raw input to a major data center to process them. Even though there isn’t a device API for accessing Siri, developers have found clever ways around this, by putting clever things in the contact list and constructing special text messages, but again this is really just using Siri as voice recognition software. The real intent of Siri is much deeper; it’s really a task completion engine.

These engines are really taking your voice input and then mapping them to various problem domains which then talk to many APIs on the backend. The goal isn’t to run an app and then just provide a voice recognition engine that translates voice commands into regular app commands as if the user had typed them. The goal is really that you don’t need device apps. When you ask Siri a question, you don’t need a matching app running, if you ask about airline info, it gets it, if you ask about weather, it gets it. You don’t need to run the right app.

In a way a limitation of current mobile phones is the need to download and install so many apps. Do you really need all of these? Most of the apps on my phone are specialized query information gathering apps like weather, news and such. The real beauty of these new personal assistant type applications is that they eliminate the need for all these other apps. Wouldn’t a phone or tablet be much easier if you didn’t need to find and install all these apps? Isn’t this the original appeal of the Internet to PC users? You don’t need to install dozens of applications (which got more and more painful); all you needed was a Browser and nothing else. To some degree these personal assistant applications become a workable Browser for mobile devices, where you no longer need all these apps anymore. Sure there are some special purpose apps for playing games and performing specialized functions, but generally you can just use Siri, Google Voice Search or Google Now for most things that you probably use Apps for now. Sure these aren’t perfect yet, just like the original Netscape Browser wasn’t perfect, but they are getting there very quickly.

Integrating to ERP and CRM

OK, so we don’t integrate to these new services via Apps talking to APIs on devices, so if we want to integrate our CRM or ERP into say Siri, how do we do it? Suppose we want to ask Siri what is the status of an Order from a vendor, or we want to ask Siri what is the credit limit of a customer I’m about to visit?

The key is to have this information available on the Internet via RESTful Web Services like SData. The reason for RESTful Web Services is that they allow discovery by search engine spiders. Generally shortened URLs give the list of how to build the rest of the URL, this allows a general engine to discover all the data. RESTful Web Services are the new Internet standard and all these services are built to interact with them.

The key is for vendors (like Sage) to make the right agreements with these services, so that the data can be accessed in a secure way, and you aren’t doing something like exposing all your ERP data to the Internet in general. Security and the rules for who can access what are crucial. Standard sign-on mechanisms like OAuth are going to have to be used.

The other thing is that all this data must be in a central location. This means that any ERP or CRM data that is going to be available to these services must be sync’ed to a central cloud location. This then fits in with Sage’s connected services strategy of sync’ing key on-premise data to the cloud (of course if you are already running your CRM or ERP in the cloud then you can skip this step). I blogged about Sage’s Hybrid Cloud here. From Sage’s Hybrid Cloud we can expose the correct data via SData Web Services for anyone that wants to participate in these services. Then Sage can make the correct deals with the services and is responsible that all the security concerns are setup correctly.

This can then lead to a company’s employees and customers being able to make general inquiries into these services and for the right questions have them mapped to a problem domain in the ERP or CRM space, have the backend systems provide answers with relevant data added from the Hybrid Cloud.

None of these services would look into the Hybrid Cloud in real time, they all operate like Search Engines which are continuously polling sites and updating their master databases, then for performance reasons all the real queries are handled as highly optimized Big Data queries against a master search database, so that all questions are magically answered instantly.

Overtime the questions answered can become more and more sophisticated, incorporating more and more sources of business data. Perhaps you can ask Siri: What’s the best way to increase my company’s revenue? And then get back a useful answer.

Summary

I think these personal assistant type applications are going to become more and more prevalent in the mobile world (or even on regular computers). To me it’s exciting to consider participating in this and to think about all the questions that we can help answer.

Star-Trek-The-Original-Series-TV-1966-movie-props

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.

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