Stephen Smith's Blog

Musings on Machine Learning…

Posts Tagged ‘Android

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.

Written by smist08

June 28, 2014 at 5:28 pm

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

Frustrations in Developing Mobile Applications

with 14 comments

Introduction

Recently I’ve been talking to many people about various techniques to develop portable mobile applications. In the good old days of the 90s with the Wintel monopoly usually you could just develop for Windows and you would reach 99% of the market. The main challenge was just adapting to new versions of Windows where you would get things like UAC thrown at you.

Now suddenly we are developing for various Windows devices, various Apple devices and various Android/Linux devices. Plus we have some other contenders like Blackberry clamoring for our attention. The market is now highly fragmented and all of these have considerable market share.

I develop business applications and the functionality I’m most interested in has to do with ERP and CRM workflows. This means I’m not writing games, although it would be fun to produce a game like “Angry Accountants” or “ERPville”.

I know I’ve blogged about mobile development a few times like here and here; but my thinking on this keeps changing and I’m still not happy with the whole situation. There are many mobile frameworks and I’m only touching on a couple of representative ones here. I’ve got to think there will be a better solution, but until then I feel like ranting.

mobile device frustration

Going Native

There is an appeal to going native. The native development environments are really excellent. I’ve been playing with Apple’s XCode development tools for OS/X and iOS development and they are really amazing. They’ve progressed a lot since I last saw them over 20 years ago when I worked for a company that did NeXTStep development for the NeXT cube. Similarly Visual Studio 2012 for Windows 8 development is really quite good and so are all the Android tools.

If I only needed to development for one of these, I would be happy with any one of them. But keeping several in my brain at once really hurts.

You get the best results for the given platform with any one of these, but you don’t really get anything reusable except the basic design. All the platforms use a different object oriented extension of C (namely Objective C, Java and C#). All the platforms have different operating system functions and different separations between what you do in the application versus have as a service.

C Reborn

One surprising thing I found from talking to people was that the idea of writing as much as you could in C. All the main platforms use extensions of C and all support compiling and running C code. This reminds me of the old days where you tried to write a portable application for Mac, Windows and Linux by isolating the operating system dependent parts and then writing as much code as possible in good old portable C. Funny how what was old can be new again. But then it was a good idea back then, why wouldn’t it be a good idea now?

Air

Much maligned Adobe always seems to have a proprietary solution in the game. With Flash being booted from most platforms, Air seems to have followers in some areas. Some people really like Adobe development tools, I’ve always found them strange. Like with Flash, uses ActionScript which is a nice object oriented extension to JavaScript, but then that makes it all non-standard. Then strangely you have to structure Flash projects as a movie which I’ve never liked. Air seems to claim to follow standards but then keeps dragging in Flash technologies. My own bias is that if you go down this route, you may as well stick with using JavaScript which is then more standard and more cross platform.

The other problem with Adobe is that they are the leading vendor in producing software with giant security flaws. This means they are more likely to be blocked or dropped from platforms. It is also a big risk for app development since your app could be tarred by Adobe’s problems.

Xamarin

Xamarin takes the Mono project and ports it to mobile devices like iOS and Android. The goal then is that you can develop a C# Windows application that will also run on iOS and Android. We tried Mono as a way to move some .Net projects to Linux, but just ran into too many problems and had to give up. As a result Mono has left a bad taste in my mouth so I’m inclined to avoid this. I also wonder how much code you will have putting the .Net runtime on top of the native iOS or Android operating systems. Is this just going to have too many layers and is it just going to be too fat and bloated?

If they can pull it off with high quality and compatibility there is potential here, but I suspect, like Air, you will just get a big non-standard mess.

JavaScript/HTML5/CSS

Ever since the first Netscape browser we’ve been promised that the web will standardize all programming. Then came a proliferation of web standards and incompatible browsers. Now things are coming back together in the web world. We have good standardization on HTML5, JavaScript and CSS. We have a number of browsers with good support for these and they run on pretty much all PCs, laptops, tablets and phones. So you would think you can just develop once as a web application and run happily everywhere.

Unfortunately all the vendors have a vested interest in their app stores (like iTunes). Vendors like Apple, Google and Microsoft make 30% off all software sold through their stores. They make nothing on people running web applications from browsers. As a consequence quite a few native platform functionalities are held back deliberately from the web. Then they market hard that for the best experience you must use a native app form their store or you are getting a second rate experience. Strangely the reverse is often the case where the app is just providing a subset of some web site and you lose abilities like being able to zoom.

In the current market/environment it’s very hard to compete against native apps with web apps which is really too bad. I think at some point the app store monopoly will fall apart, but that is today’s reality.

Phonegap

Phonegap is an open source library to try to bridge the gap between HTML/JavaScript apps and native apps. It adds a hardware API for JavaScript apps and allows them to be packaged for distribution via app stores. Phonegap was recently purchased by Adobe which really worried me. So far Adobe hasn’t done anything bad (that I’ve seen) and hopefully it will survive as a good open source solutions.

The main risks with Phonegap is that it usually lags the native apps in adoption of new operating system features, Apple may at some point start rejecting apps made with Phonegap and Adobe may start adding proprietary Flash like technology.

Beside these drawbacks the other problem is that your app is still made out of Browser controls and not the UI widgets that are part of the underlying operating system. You can style away a lot of differences but discerning users will be able to tell the difference.

Phonegap is a great technology which does really help JavaScript/HTML apps be more native and is really worth considering if you go down this road.

Summary

I’m still frustrated. I’m not really happy with the quality of apps produced by the cross platform technologies and I don’t like developing the same thing multiple times using the native SDKs.

I also find it a bit monotonous to develop the same program over and over again for iOS, Android, Blackberry and Windows.

Written by smist08

February 23, 2013 at 11:34 pm

Linux is Everywhere

with 4 comments

Introduction

It’s been a long running joke that at the beginning of each year, probably for the last twenty years, someone prognosticates that this will be the year of Linux. Often this is prefaced by the year of the Linux desktop or the year of the Linux server. But somehow in spite of all the hype, most desktops are still Windows as are a good number of servers.

I don’t really want to prognosticate that this will necessarily be the year of anything in particular, but recently it appears that everywhere I turn, I see Linux.

Telikin

My wife spent November and December in Arizona with her parents who are snowbirds, since I had quite a bit of business travel going on. Since she was there for 2 months she was determined to get her parents on-line. So they could Google things themselves rather than phoning her, so they could e-mail and use Facebook. So off they went and bought a shiny new Lenovo Windows 8 laptop with a touch screen and all the bells and whistles. This turned out to be quite frustrating and they had all sorts of learning and usage problems. The big one being that the touch interface didn’t work well. So they returned it and got a large screen Windows 7 laptop, which my wife thought would be easier since she knew it better and there was no touch stuff. Didn’t go so well. Then they saw an ad for a Telikin PC which was a special purpose PC for seniors with a touch screen as well as a mouse, with special easy to use software which included senior friendly features like large fonts and large graphics.

Telikin-TLMS18T3202W-PC

This actually worked out quite well. They could do e-mails, browse the web, print, upload photos from their camera and use Facebook. They then asked me about recording audio, so I got a freeware program and went to install it. I imagined that the senior friendly software was just a shell over Windows, and I just needed to figure out how to exit that or run a CMD prompt. No luck. I then Googled the computer and to my surprise found out it was powered by Linux! Apparently Linux is making it into the Desktop in a number of special purpose PCs. I then had to point them to a web site that allowed you to make audio recordings and away they went. Further they seem to be able to keep using it now that they are on their own again, since we returned home.

Android

Of course I couldn’t write an article about Linux taking over without mentioning Google’s Android operating system for phones and tablets. Last September, Google announced that 500 million Android devices have now been activated. That’s an amazing number. Basically Android is proving to be the market leader in both smart phones and tablets. Samsung has experienced tremendous growth with their Android devices.

ChromeOS

For laptops, Google is promoting their ChromeOS which is a minimal Linux based computer that is more oriented being a web browser. Surprisingly ChromeOS based laptops have topped the Amazon best seller lists for laptops in recent months. These are special purpose devices, but are gaining quite a bit of traction.

Tizen

Tizen is another open source Linux based smart phone operating system. This is being promoted as even more open than Android. It is being picked up by several Chinese phone manufacturers as well Samsung has announced they will be releasing Tizen based phones. Partly this is in reaction to Google shipping Google branded devices in competition to their hardware partners.

Ubuntu

Ubuntu has been a leading Linux distribution that has gained quite a bit of traction on the desktop. It is a full distribution of Linux and not one of the special purpose limited sets. Now Ubuntu is developing a smart phone version of their Linux version. The idea is that when the phone is mobile it runs a limited set of programs in a manner similar to Android or Tizen, but when you dock the phone and it’s connected to a monitor, keyboard and mouse, then you get the full Ubuntu distribution. This way your phone is also your laptop and tablet.

This is rather an interesting idea that the phone is your computing core with all your files and programs on it. Then depending on the hardware, connectivity and power you get the subset that is appropriate for that usage.

Raspberry Pi

The Raspberry Pi is a $25 computer that is oriented to hobbyists. It is based on the ARM CPU and runs Linux. The Raspberry Pi doesn’t even come in a box. But since it just recently went on sale, it’s already sold 1 million units. This has certainly woken up the home hardware hobby industry and I suspect the core design of this will end up in many other devices.

800px-RaspberryPi

Everything Else

At the recent CES show, there seemed to be a plethora of special purpose Linux based appliances from intelligent fridges to Linux being the operating system for your car. I don’t know how many of these will be successful but it appears that nearly everything is getting a CPU, memory and connectivity. Whether these have any lasting value or are short term gimmicks is yet to be seen.

Programming

As a programmer we want all our programs to run in as many places as possible. These days the market has become quite fragmented between Windows, MacOS, iOS and then all the Linuxes. One way to program for all these devices is to use HTML5/JavaScript since they all have Internet connectivity and good browsers like Firefox or Chrome. Another way is to use Java which runs on all these as well. For Windows, Linux and MacOS you can also use C/C++ and just isolate the operating system dependent parts in separate modules to handle differences in things like mutexes and file locking. Unfortunately besides using HTML5/JavaScript the preferred native way to create User Interfaces is completely different on all of these and tends to lead to very different ways of doing things.

Summary

It seems that Linux has been making inroads slowly in all sorts of places. Now all of a sudden it seems to be everywhere. I think this is a great tribute to what can be accomplished with open source software and how a great many profitable ventures can be based on it.

Written by smist08

January 19, 2013 at 5:55 pm

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.

Accpac on the iPhone and Android

with 15 comments

In a previous posting (https://smist08.wordpress.com/2010/03/19/sage-erp-accpac-6-x-mobility/), I talked about our mobile strategy of using HTML and JavaScript screens to run on mobile devices. But how exactly will that work? Mobile phones like the iPhone allow you to run web sites in the same manner you run native applications. So you can add an icon to the phone’s home page and then run your web based application. But does it look like a true iPhone or Android native application? Well it does with a little help. There are now several JavaScript libraries that reproduce the look and feel of native phone applications. In the screens below, I used the JQTouch (http://www.jqtouch.com/) library to easily construct some menus to act as an “Accpac Mobile Desktop” to launch our various data portlets (https://smist08.wordpress.com/2009/12/24/sage-erp-accpac-6-0-data-portlets/). This lets a user see various dashboards in real time from their phone.

In this picture we have a basic iPhone with some home page icons, including one for Accpac.

When you select the Accpac icon you then go to a set of menus for Accpac. Notice that even though this is a web page, it looks just like any other iPhone application. There isn’t any sign of the Safari browser, everything is nicely hidden.

The menus have nice animated transitions, so when you select them they slide to the side. Clicking on Payables yields:

Then if we click on Aged Payables we get to our regular Aged Payables snapshot that we normally see in the new portal/desktop. At this point our portlet isn’t styled to fit into the iPhone and there are a few style sheet bugs. But otherwise it does nicely display your aged payables.

Actually it looks a little better in landscape:

To use Apple’s iPhone SDK and iPhone emulator you need a Mac computer. I don’t own an iPhone, an Android phone nor a Mac. To test for the iPhone I used the MobiOne Test Center (http://www.genuitec.com/mobile/). For Android, I used the emulator in the Android SDK (http://developer.android.com/sdk/index.html).

Same sort of thing in Android:

Since we have made all our screens with standard HTML and JavaScript we will work on all modern devices. Plus as HTML5 is rolled out over the next few years we will pick up all the advances there as well.

Written by smist08

June 25, 2010 at 11:40 pm

Posted in Mobility, sage 300

Tagged with , , ,

Sage ERP Accpac 6.x Mobility

with 7 comments

Although we aren’t targeting mobile clients for our first couple of releases, we are architecting the Accpac 6.x series with mobility in mind. This blog posting isn’t meant to layout a roadmap for our mobility support, but to talk about what we are doing to support mobile clients and why. Mobile devices are proliferating. By mobile device, I mean anything you can carry around with you and stay connected to the Internet, from cell phones to iPads to netbooks. Typically these devices are connected to the Internet via cell phone carriers, or through WiFi hotspots.

The first key to our mobility support is Internet Browser independence. On regular PCs, most people run Internet Explorer. On mobile devices, almost no one uses IE. The most common mobile browser engine is WebKit an open source technology that is at the heart of the Apple Safari, Google Chrome and RIM browsers. Other popular contenders are mobile optimized versions of Firefox and Opera. For Accpac we need to ensure we work well in all these environments.

Generally we are taking the approach of running well in a mobile browser rather than developing mobile applications for each platform. If we were to do this we would need a version of Accpac for the Apple iPhone, iPad and iPod; Microsoft Windows Mobile; Google Android and ChromeOS; RIM Blackberry; Palm OS; Nokia Symbian, etc. This proliferation of mobile platforms has led to fierce competition and moved the technology ahead in leaps and bounds. But it makes it hard for software vendors to natively support them all. Plus there is the added complexity of dealing with all the separate application stores and all their rules and regulations. For us its way easier to be a well behaved Web Application that runs well in each device’s native browser.

The first thing is to handle hugely varying screen sizes. You can get racks that hold 6 large screen monitors and hook them up to your PC to get a tiled giant high resolution display, then at the other end of the spectrum, there are cell phones with huge computing power, but tiny low resolution screens. We certainly don’t want to optimize all our screens for 320×120 resolution and have a postage stamp sized screen on a big screen regular PC monitor. Our regular screens actually work fine on devices like the Google Android, but you have to scroll around quite a lot to get to all parts of the screen. In the Accpac 6 architecture the screen layouts are contained in separate XML files, unlike our previous VB6 technology where the screen layout was part of the program file. This allows us to maintain a repository of different XML files on the server and have some intelligence to serve up the correct layout based on the circumstances. It then becomes much easier to have minimal low resolution versions of the screens along with the regular ones. Plus all these can be customized. It might even eventually be necessary to produce medium resolution version for devices like the Apple iPad. On the other hand, the screens on these devices are getting better and better, but there are limits to what the human eye can discern. After all no one wants a giant cell phone, the smaller the better, so at some point improving the resolution doesn’t help.

We also need a minimal version of our main program Portal. Probably something with just a few big buttons to run a handful of screens, then when pressed each one takes up the whole screen with no Portal frame around it. Mobile users might even just run the screens directly in their Browser from their favorites menu.

Another difference in the mobile market are the input devices. No mouse and you are lucky if you have a qwerty keyboard. Touch screens aren’t as precise as a mouse and we have to have bigger buttons and controls or the user can’t select or manipulate them. New input devices like motion censors are present. What does it mean to Order Entry if someone shakes the iPhone? Does this mean clear the order and start over? Basically to work well on these devices we need to figure out what all these new metaphors mean to our Accounting Applications.

When we architected Accpc 6 to run in any Browser, the goal wasn’t so much being able to run in Firefox on Windows, it was more about extending the reach of where you can run Accpac screens, including PCs like Macs or Linux Netbooks, tablets like the iPad, or all the small cell phone based devices like the Apple iPhone and Google Android.

Written by smist08

March 19, 2010 at 9:20 pm

Posted in Mobility, sage 300

Tagged with , , , ,